MUI - Gradients & other bugs - Update3

A forum for general AmigaOS 4.x support questions that are not platform-specific
Lemen
Posts: 6
Joined: Fri Sep 09, 2011 11:14 pm

MUI - Gradients & other bugs - Update3

Post by Lemen »

Hello

MUI Preferences/Builtin/Guages/Container Design/Background;
Set a gradient as vertical (or any of the other 3 choices) and this is shown
correctly in the Example display.

MUI Preferences/Builtin/Guages/Knob Design/Background;
Set a gradient as vertical (or any of the other 3 choices) and this is shown
incorrectly in the Example display; e.g, select vertical and the gradient
shown in the example is horizontal.

MUI Preferences/External/BetterString/Background/Inactive;
Set a vertical gradient here and you may get graphical glitches at the
right-hand end of the box.

MUI Preferences/External/NListviews/Colours/Background/Title;
MUI Preferences/External/NListviews/Colours/Background/Selected;
MUI Preferences/External/NListviews/Colours/Background/Cursor;
MUI Preferences/External/NListviews/Colours/Background/Inactive;
Vertical gradient doesn't work.

MUI Preferences/External/TextEditor/Design/Background;
Try a horizontal gradient here and you may get major graphical corruption of
the text-edit window - try resizing it.

Listviews & NListviews - gradient set in cursor;
The gradient does not appear within the height of the cursor
itself, (the cursor looking to have a plain flat colour) but rather, is
spread over the height of the window. With NListview it's particularly
noticeable with YAM of course - click to highlight an email at the top of
the window and you have the lightest colour of the gradient, then click to
highlight an email at the bottom of the window and you see the cursor
becomes the darker colour of the gradient.

MUI menu troubles;
If you have the MUI menu gadget enabled in the window title;
MUI Preferences/Builtin/Windows/Gadgets (the first of the gadgets -
(downward pointing triangle with rectangle under).
This is usually positioned at the right-hand of the screen.
When you come down the menu from the top, you come to "Jump to screen" which
has a sub-menu, this is displayed and now blocks the rest of the original
menu (if your screen names are long enough). So, if you were aiming to get to
"MUI settings...", you now need to move the pointer back up to "Unsnapshot", then
move the pointer off the menu to the left and take your mouse pointer around the
outside of the menu in order to come up from the bottom to be able to select
"MUI settings..."

With MUI prefs open on Workbench, Clicking "Test" or "Use" will cause a switch to an
open MUI screen.

I know that MUI is very complex and is always going to have some problems,
but it seems there is a lot more work to do here.

Regards
Lemen
User avatar
tboeckel
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 68
Joined: Mon Jun 20, 2011 8:56 am
Contact:

Re: MUI - Gradients & other bugs - Update3

Post by tboeckel »

Lemen wrote:MUI Preferences/Builtin/Guages/Container Design/Background;
Set a gradient as vertical (or any of the other 3 choices) and this is shown
correctly in the Example display.

MUI Preferences/Builtin/Guages/Knob Design/Background;
Set a gradient as vertical (or any of the other 3 choices) and this is shown
incorrectly in the Example display; e.g, select vertical and the gradient
shown in the example is horizontal.
This is intentional. The same question arose on the beta list. Sliders and gauges have a default direction. For sliders this is horizontal, for gauges it is vertical. Gradients will be rotated according to that default direction. For exactly this reason there are both horizontal and vertical example objects, which you very obviously are not noticing.
Lemen wrote:MUI Preferences/External/BetterString/Background/Inactive;
Set a vertical gradient here and you may get graphical glitches at the
right-hand end of the box.
Just fixed this in BetterString.mcc. But this requires a new release of BetterString.mcc. MUI cannot do anything about this, because BetterString.mcc used wrong corrdinates.
Lemen wrote:MUI Preferences/External/NListviews/Colours/Background/Title;
MUI Preferences/External/NListviews/Colours/Background/Selected;
MUI Preferences/External/NListviews/Colours/Background/Cursor;
MUI Preferences/External/NListviews/Colours/Background/Inactive;
Vertical gradient doesn't work.
It has been stated several times by now that NList itself is already fixed in this respect, but the fixed version has not been released yet.
Lemen wrote:MUI Preferences/External/TextEditor/Design/Background;
Try a horizontal gradient here and you may get major graphical corruption of
the text-edit window - try resizing it.
This is a similar bug as with BetterString.mcc. TextEditor.mcc wants to be very smart and updates only those regions which might require updating. However, the coordinate calculation is not suitable for gradients here. This will also require a new release of TextEditor.mcc, but there is no fix checked in yet.
Lemen wrote:Listviews & NListviews - gradient set in cursor;
The gradient does not appear within the height of the cursor
itself, (the cursor looking to have a plain flat colour) but rather, is
spread over the height of the window. With NListview it's particularly
noticeable with YAM of course - click to highlight an email at the top of
the window and you have the lightest colour of the gradient, then click to
highlight an email at the bottom of the window and you see the cursor
becomes the darker colour of the gradient.
Vertical gradients will always be draw with respect to the object's height. And in the case the object is the visible list, not the cursor.
Lemen wrote:MUI menu troubles;
If you have the MUI menu gadget enabled in the window title;
MUI Preferences/Builtin/Windows/Gadgets (the first of the gadgets -
(downward pointing triangle with rectangle under).
This is usually positioned at the right-hand of the screen.
When you come down the menu from the top, you come to "Jump to screen" which
has a sub-menu, this is displayed and now blocks the rest of the original
menu (if your screen names are long enough). So, if you were aiming to get to
"MUI settings...", you now need to move the pointer back up to "Unsnapshot", then
move the pointer off the menu to the left and take your mouse pointer around the
outside of the menu in order to come up from the bottom to be able to select
"MUI settings..."
The menu layout did not change since the previous release. Hence this is nothing new but already several years old. But I admit that the layout process is a bit too simple and you are correct. If a submenu does not fit right of the parent menu it should be placed on the left side instead of right across the parent menu.
Lemen wrote:With MUI prefs open on Workbench, Clicking "Test" or "Use" will cause a switch to an
open MUI screen.
This does not happen here.
User avatar
BillEaves
Beta Tester
Beta Tester
Posts: 202
Joined: Wed Dec 22, 2010 10:14 am
Location: Caithness, Scotland
Contact:

Re: MUI - Gradients & other bugs - Update3

Post by BillEaves »

tboeckel wrote:
Lemen wrote:MUI Preferences/Builtin/Guages/Container Design/Background;
Set a gradient as vertical (or any of the other 3 choices) and this is shown
correctly in the Example display.

MUI Preferences/Builtin/Guages/Knob Design/Background;
Set a gradient as vertical (or any of the other 3 choices) and this is shown
incorrectly in the Example display; e.g, select vertical and the gradient
shown in the example is horizontal.
This is intentional. The same question arose on the beta list. Sliders and gauges have a default direction. For sliders this is horizontal, for gauges it is vertical. Gradients will be rotated according to that default direction. For exactly this reason there are both horizontal and vertical example objects, which you very obviously are not noticing.
I noticed too the the gradient direction for guages has now to be the other way round from before and applies to a vertical guage rather than a horizontal one. Strange as all real life examples in MUI applications ,gauges are all horizontal and not vertical, in fact the only vertical gauges I ever recall seeing are the ones in the MUI Settings, Gauges section. It would make sense to revert back to the previous way, not that important as just setting the direction the "wrong" way seems to work OK.

Lemen wrote:Listviews & NListviews - gradient set in cursor;
The gradient does not appear within the height of the cursor
itself, (the cursor looking to have a plain flat colour) but rather, is
spread over the height of the window. With NListview it's particularly
noticeable with YAM of course - click to highlight an email at the top of
the window and you have the lightest colour of the gradient, then click to
highlight an email at the bottom of the window and you see the cursor
becomes the darker colour of the gradient.
Vertical gradients will always be draw with respect to the object's height. And in the case the object is the visible list, not the cursor.

This REALLY messes things up, the gradient used to be spread over the height of the current cursor object not the whole NList object. It worked perfectly in the previous MUI 3.9, now it is just a complete mess. This really needs putting back to the way it was. It makes NO sense whatsoever, for a Cursor, Active, Selected entry etc. to have its gradient spread over the Nlist height. Also though not mentioned by Lemen, I noticed that with a long list, the gradient did not spread over the entire list either but only so far and then graphical corruption occurs.
User avatar
BillEaves
Beta Tester
Beta Tester
Posts: 202
Joined: Wed Dec 22, 2010 10:14 am
Location: Caithness, Scotland
Contact:

Re: MUI - Gradients & other bugs - Update3

Post by BillEaves »

I write a new post as this does not involve the gradients but there is another bug that has arisen with the update 3 version of MUI.

There used to be a setting where Windows could be chosen to open on the Defaul screen (usually WB), a screen from the database, and finally the most useful one the frontmost screen - eg the one you are acyually using. This setting seems no longer available.

MUI apps running on WB are fine, windows open on the workbench. If using a screen from the MUI screens database windows will open on that.

However an application which creates its own screen and then ties it to MUI, eg is NOT in the MUI database now will insist on opening the applications MUI Prefs and About MUI windows on Workbench rather than the one the application is running on. Given that the user can no longer choose the frontmost screen option, is there a way either in the MUI prefs or by coding to make the above mentioned windows open on the CURRENT SCREEN and not the Workbench.

This new bug/feature affects my MUI applications Digital Univers and 3D Stars and also the older programme Digital Almanac (not one of mne).
User avatar
ssolie
Beta Tester
Beta Tester
Posts: 1010
Joined: Mon Dec 20, 2010 8:51 pm
Location: Canada
Contact:

Re: MUI - Gradients & other bugs - Update3

Post by ssolie »

BillEaves wrote:I write a new post as this does not involve the gradients but there is another bug that has arisen with the update 3 version of MUI.
I would prefer it if you would file your bug reports in bugzilla against the MUI product... thanks. ;)
ExecSG Team Lead
User avatar
tboeckel
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 68
Joined: Mon Jun 20, 2011 8:56 am
Contact:

Re: MUI - Gradients & other bugs - Update3

Post by tboeckel »

BillEaves wrote:However an application which creates its own screen and then ties it to MUI, eg is NOT in the MUI database now will insist on opening the applications MUI Prefs and About MUI windows on Workbench rather than the one the application is running on. Given that the user can no longer choose the frontmost screen option, is there a way either in the MUI prefs or by coding to make the above mentioned windows open on the CURRENT SCREEN and not the Workbench.

This new bug/feature affects my MUI applications Digital Univers and 3D Stars and also the older programme Digital Almanac (not one of mne).
If certain applications require that MUI windows open on a specific screen, then using MUIA_Window_(Public)Screen is a by far better option than urging the user to configure a specific screen. Furthermore this ensures that the windows will always open on that screen and not by accident on another screen which the user just might have brought to front.
User avatar
BillEaves
Beta Tester
Beta Tester
Posts: 202
Joined: Wed Dec 22, 2010 10:14 am
Location: Caithness, Scotland
Contact:

Re: MUI - Gradients & other bugs - Update3

Post by BillEaves »

tboeckel wrote:
BillEaves wrote: This new bug/feature affects my MUI applications Digital Univers and 3D Stars and also the older programme Digital Almanac (not one of mne).
If certain applications require that MUI windows open on a specific screen, then using MUIA_Window_(Public)Screen is a by far better option than urging the user to configure a specific screen. Furthermore this ensures that the windows will always open on that screen and not by accident on another screen which the user just might have brought to front.
Thanks for the tip.

All windows except the MUI Config and About MUI did open on my screen by using MUIA_Window_Screen.


I have now set the AboutMUI window to open on the desired screen by setting the Reference Window for MUIM_Application_AboutMUI. I had worried that it may not work if the user used one of the MUI menus in the window the MUI Menu Gadget in the window border, rather from the Menu in my code but it seems to work both ways :-)

I was going to do something similar for the Config window, but when I look at the autodoc for MUIM_Application_OpenConfigWindow, I am presented with:

===============================================
SYNOPSIS
DoMethod(obj,MUIM_Application_OpenConfigWindow,ULONG flags, STRPTR classid);

FUNCTION
yet undocumented, please complain in mailinglist :)

INPUTS

RESULT

BUGS

SEE ALSO
==================================================

which is not very helpful in getting the Config window to open on the desired screen.

Any ideas ?
Lio
Posts: 47
Joined: Tue Sep 13, 2011 8:07 pm

Re: MUI - Gradients & other bugs - Update3

Post by Lio »

I have to report several bugs which mostly arise in MUIOWB but also in IBrowse :

* in bookmarks, there is only one level for drawer (bookmark/drawer/link) but there are at least 2 levels existing for IBrowse (bookmark/drawer/drawer/link)

* in bookmarks again, unfolding a drawer is fast but refolding is very slow

* in bookmarks again, dragging a link to the fast/quick link does not work the first time and you always have to do it a second time to make it work (very annoying). same behavior when you want to drag a link to a drawer.

* in MUI prefs/screens you can not delete a screen ! there is a requester but only one button to confirm/cancel and pressing it always seems like it is set to cancel !

* not sure if it is related to MUI or OWB but in IBrowse, you could surf back with one of the extra button of your mouse and it is still working in IBrowse but not in MUIOWB

* you can not center the navigation buttons in MUIOWB (no option available)

* in IBrowse pressing ESC would close the active tab, but in MUIOWB it would close the whole browser (granted there is a requester , which could be turned off -> very dangerous !)


thats all for now but I would like to thank all the people involved in the release of this fantastic browser, which is quite complete, only needs to fix the latest bugs !
User avatar
tboeckel
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 68
Joined: Mon Jun 20, 2011 8:56 am
Contact:

Re: MUI - Gradients & other bugs - Update3

Post by tboeckel »

BillEaves wrote:I was going to do something similar for the Config window, but when I look at the autodoc for MUIM_Application_OpenConfigWindow, I am presented with:

===============================================
SYNOPSIS
DoMethod(obj,MUIM_Application_OpenConfigWindow,ULONG flags, STRPTR classid);

FUNCTION
yet undocumented, please complain in mailinglist :)
For me the config window correctly opens on the same screen I configured for an application, i.e. Scout or YAM.

Second, the flags parameter of MUIM_Application_OpenConfigWindow cannot be used to force the config window to a specific screen. The only existing flag is this one:

#define MUIV_Application_OCW_ScreenPage (1<<1) /* show just the screen page of the config window */

The classid parameter is completely ignored at the moment.
User avatar
tboeckel
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 68
Joined: Mon Jun 20, 2011 8:56 am
Contact:

Re: MUI - Gradients & other bugs - Update3

Post by tboeckel »

@Lio

First of all, please stick to the topic, which reads "MUI - Gradients & other bugs - Update3", not "MUI and MUIOWB - Gradients & other bugs - Update3". Please do not mix up the two very different things. If you have bugs in MUIOWB to report then please use its own bug tracker.
Lio wrote:* in bookmarks, there is only one level for drawer (bookmark/drawer/link) but there are at least 2 levels existing for IBrowse (bookmark/drawer/drawer/link)
No MUI bug. Handling of Drag'n'Drop actions must be implemented by the application.
Lio wrote:* in bookmarks again, unfolding a drawer is fast but refolding is very slow
Not very specific. Does this happen with other applications as well?
Lio wrote:* in bookmarks again, dragging a link to the fast/quick link does not work the first time and you always have to do it a second time to make it work (very annoying). same behavior when you want to drag a link to a drawer.
No MUI bug. Drag'n'Drop in general works perfectly. If it does not for MUIOWB then you know the culprit.
Lio wrote:* in MUI prefs/screens you can not delete a screen ! there is a requester but only one button to confirm/cancel and pressing it always seems like it is set to cancel !
No problem here, neither with the german catalog, nor with the builtin english strings. I always get the usual Yes/No buttons and selecting Yes will of course delete the selected screen. Are you using a different language?
Lio wrote:* not sure if it is related to MUI or OWB but in IBrowse, you could surf back with one of the extra button of your mouse and it is still working in IBrowse but not in MUIOWB
Again, no MUI bug. It is the application's decision how to react on certain inputs.
Lio wrote:* you can not center the navigation buttons in MUIOWB (no option available)
Again, no MUI bug, obviously.
Lio wrote:* in IBrowse pressing ESC would close the active tab, but in MUIOWB it would close the whole browser (granted there is a requester , which could be turned off -> very dangerous !)
Again, no MUI bug. How an application reacts to specific key presses it up to the application.

To sum it up: all except one is no MUI bug and does not belong here, at least not in this thread. For the future please use MUIOWB's bug tracker for MUIOWB related bugs.
Post Reply