Hi, several remarks on the UI, which should be fixed IMO. 1. Bug meter: The bug meter button reacts on the "pressed" event, to show the window, but it should react on the "clicked" signal. Popping up a window after a "pressed" signal is usually only done for volatile windows (like menus, or overview windows, like in GIMP, which often vanish again, after releasing the mouse button). Reacting on "pressed" is always a bit problematic, also because the pointer grab initiated with this event can cause side-effects. Furthermore, it should not have a relief, compare to the "Hide Controls" button. 2. The menus behind the "Back" and "Forward" buttons: Consider the following scenario: (i) The user presses button 3 on the "Back" button, and the menu is shown. (ii) He keeps the button pressed, moves to one entry in the menu, and releases the button. Nothing happens. Currently, the menu items only react on "button_press", which is anyway wrong (see above). Furthermore, in this situation, the item should already react on the "release" event, either as described above, or in the way (i) click on menu, (ii) click on menu entry. The current behaviour is that much confusing, that a user may think that it does not work at all. (I did!) (The implementation would become a bit tricky, since button 2 will pop up the page in a new window. Perhaps, I'd even suggest to skip this feature, if a clean solution is not possible.) BTW, it is not very obvious, that there is a menu behind these two buttons. Perhaps there should be, in the icon, a small arrow directed downdwards, or so. 3. Attached is the incomplete code of a new widget, which changes the behaviour of GtkButton: (i) It reacts also on button 2 and 3, this would make multiple functions for one button possible. Actually, this feature should be reserved for very few situation (since it is simply confusing), namely the "Clear URL" button, which may also be used for visiting the URL in the selection buffer. (ii) It provides a function for attaching a menu in a better way, than we have currently, for the "Back" and "Forward" menus, and for the bug meter. Simply copy all files into one directory, call "make", and run "testprg". Look, what happens with different mouse buttons. Comments welcome. Sebastian
On Mon, 31 May 2004, Sebastian Geerken wrote:
Hi,
several remarks on the UI, which should be fixed IMO.
1. Bug meter: The bug meter button reacts on the "pressed" event, to show the window, but it should react on the "clicked" signal. Popping up a window after a "pressed" signal is usually only done for volatile windows (like menus, or overview windows, like in GIMP, which often vanish again, after releasing the mouse button).
Reacting on "pressed" is always a bit problematic, also because the pointer grab initiated with this event can cause side-effects.
Furthermore, it should not have a relief, compare to the "Hide Controls" button.
No problem. I even don't know why "clicked" should be used instead of "release" :-). I just copied the code from the menus. Note that the same code for the bug-meter button is used to handle the bug-meter menu entry in the "page menu". If a new implementation acts the same as the current one, from the user's point of view, it's perfect for me.
2. The menus behind the "Back" and "Forward" buttons: Consider the following scenario:
(i) The user presses button 3 on the "Back" button, and the menu is shown.
(ii) He keeps the button pressed, moves to one entry in the menu, and releases the button. Nothing happens.
Currently, the menu items only react on "button_press", which is anyway wrong (see above). Furthermore, in this situation, the item should already react on the "release" event, either as described above, or in the way (i) click on menu, (ii) click on menu entry. The current behaviour is that much confusing, that a user may think that it does not work at all. (I did!)
Yes. Sometime ago Ricardo Persichetti sent me a patch for this. It's just a couple of lines. Now on CVS for testing purposes, plus enhanced pixmaps for Back and Forward that hint their right click menus.
(The implementation would become a bit tricky, since button 2 will pop up the page in a new window. Perhaps, I'd even suggest to skip this feature, if a clean solution is not possible.)
I use this feature all the time! Before switching to fluxbox, it was quite handy to spawn new dillo windows, and now, under fluxbox, it's perfect for making new TABS.
BTW, it is not very obvious, that there is a menu behind these two buttons. Perhaps there should be, in the icon, a small arrow directed downdwards, or so.
Done!
3. Attached is the incomplete code of a new widget, which changes the behaviour of GtkButton:
(i) It reacts also on button 2 and 3, this would make multiple functions for one button possible. Actually, this feature should be reserved for very few situation (since it is simply confusing), namely the "Clear URL" button, which may also be used for visiting the URL in the selection buffer.
(ii) It provides a function for attaching a menu in a better way, than we have currently, for the "Back" and "Forward" menus, and for the bug meter.
Simply copy all files into one directory, call "make", and run "testprg". Look, what happens with different mouse buttons.
Interesting. I went through the code a bit. It's not obvious to me how to modify them to be able to provide the same functionality (new window on middle click on history), and not to screw the design at the same time.
Comments welcome.
BTW, are you working on the layering API of Dw we need to go FLTK? I ask because we may have to look at it again when re-making the UI for FLTK. Best Jorge.-
On Tue, Jun 01, Jorge Arellano Cid wrote:
On Mon, 31 May 2004, Sebastian Geerken wrote:
1. Bug meter: The bug meter button reacts on the "pressed" event, to show the window, but it should react on the "clicked" signal. Popping up a window after a "pressed" signal is usually only done for volatile windows (like menus, or overview windows, like in GIMP, which often vanish again, after releasing the mouse button).
Reacting on "pressed" is always a bit problematic, also because the pointer grab initiated with this event can cause side-effects.
Furthermore, it should not have a relief, compare to the "Hide Controls" button.
No problem. I even don't know why "clicked" should be used instead of "release" :-). I just copied the code from the menus. Note that the same code for the bug-meter button is used to handle the bug-meter menu entry in the "page menu".
In most cases, the most "abstract" events should be used, i.e. "clicked" for buttons, and "activate" for menu entries.
If a new implementation acts the same as the current one, from the user's point of view, it's perfect for me.
If should act different! The bugmeter window should be shown as soon as the user *releases* the button (as always).
[...]
(The implementation would become a bit tricky, since button 2 will pop up the page in a new window. Perhaps, I'd even suggest to skip this feature, if a clean solution is not possible.)
I use this feature all the time!
Before switching to fluxbox, it was quite handy to spawn new dillo windows, and now, under fluxbox, it's perfect for making new TABS.
Using the middle button on menu entries should probably be possible, perhaps we'll have to write a new widget for it, as I did with GtkButton. However, the new behaviour should be an extension to the standard, while the current behaviour is IMO very unusable.
3. Attached is the incomplete code of a new widget, which changes the behaviour of GtkButton:
(i) It reacts also on button 2 and 3, this would make multiple functions for one button possible. Actually, this feature should be reserved for very few situation (since it is simply confusing), namely the "Clear URL" button, which may also be used for visiting the URL in the selection buffer.
(ii) It provides a function for attaching a menu in a better way, than we have currently, for the "Back" and "Forward" menus, and for the bug meter.
Simply copy all files into one directory, call "make", and run "testprg". Look, what happens with different mouse buttons.
Interesting. I went through the code a bit.
It's not obvious to me how to modify them to be able to provide the same functionality (new window on middle click on history), and not to screw the design at the same time.
I'll look at it later.
BTW, are you working on the layering API of Dw we need to go FLTK?
I ask because we may have to look at it again when re-making the UI for FLTK.
Yes. It got a bit complicated, since in the old design, DwWidget and DwGtkViewport interacted very tightly, and DwWidget assumed too much about DwGtkViewport. Anyway (in case anybody thinks that a port could be simpler :-), as I already stated, this redesign is rather useful for the future, not only for the port (and it increases the code quality, since it reduces dependencies). Sebastian
On Wed, 2 Jun 2004, Sebastian Geerken wrote:
On Tue, Jun 01, Jorge Arellano Cid wrote:
On Mon, 31 May 2004, Sebastian Geerken wrote:
1. Bug meter: The bug meter button reacts on the "pressed" event, to show the window, but it should react on the "clicked" signal. Popping up a window after a "pressed" signal is usually only done for volatile windows (like menus, or overview windows, like in GIMP, which often vanish again, after releasing the mouse button).
Reacting on "pressed" is always a bit problematic, also because the pointer grab initiated with this event can cause side-effects.
Furthermore, it should not have a relief, compare to the "Hide Controls" button.
No problem. I even don't know why "clicked" should be used instead of "release" :-). I just copied the code from the menus. Note that the same code for the bug-meter button is used to handle the bug-meter menu entry in the "page menu".
In most cases, the most "abstract" events should be used, i.e. "clicked" for buttons, and "activate" for menu entries.
Thanks for the tip!
If a new implementation acts the same as the current one, from the user's point of view, it's perfect for me.
If should act different! The bugmeter window should be shown as soon as the user *releases* the button (as always).
Yes, I meant that, but failed to explain it properly. ;)
[...]
(The implementation would become a bit tricky, since button 2 will pop up the page in a new window. Perhaps, I'd even suggest to skip this feature, if a clean solution is not possible.)
I use this feature all the time!
Before switching to fluxbox, it was quite handy to spawn new dillo windows, and now, under fluxbox, it's perfect for making new TABS.
Using the middle button on menu entries should probably be possible, perhaps we'll have to write a new widget for it, as I did with GtkButton. However, the new behaviour should be an extension to the standard, while the current behaviour is IMO very unusable.
Note: I don't mean to be able to pop-up the history menu with the middle button, but to have the option of middle-clicking its entry to open a new window or tab.
3. Attached is the incomplete code of a new widget, which changes the behaviour of GtkButton:
(i) It reacts also on button 2 and 3, this would make multiple functions for one button possible. Actually, this feature should be reserved for very few situation (since it is simply confusing), namely the "Clear URL" button, which may also be used for visiting the URL in the selection buffer.
(ii) It provides a function for attaching a menu in a better way, than we have currently, for the "Back" and "Forward" menus, and for the bug meter.
Simply copy all files into one directory, call "make", and run "testprg". Look, what happens with different mouse buttons.
Interesting. I went through the code a bit.
It's not obvious to me how to modify them to be able to provide the same functionality (new window on middle click on history), and not to screw the design at the same time.
I'll look at it later.
Ok. Cheers Jorge.-
On Wed, Jun 02, Jorge Arellano Cid wrote:
On Wed, 2 Jun 2004, Sebastian Geerken wrote:
Using the middle button on menu entries should probably be possible, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ perhaps we'll have to write a new widget for it, as I did with GtkButton. However, the new behaviour should be an extension to the standard, while the current behaviour is IMO very unusable.
Note: I don't mean to be able to pop-up the history menu with the middle button, but to have the option of middle-clicking its ^^^^^^^^^^^^^^^^^^^ entry to open a new window or tab. ^^^^^
Yes, this is also what I mean. Sebastian
Hi, I've just committed several changes, which fix the issues mentioned here. Please test and report any bugs. If you are not sure, whether you have detected a bug, it's certainly a misfeature, so report it anyway :-) On Tue, Jun 01, Jorge Arellano Cid wrote:
On Mon, 31 May 2004, Sebastian Geerken wrote:
1. Bug meter: The bug meter button reacts on the "pressed" event, to show the window, but it should react on the "clicked" signal. Popping up a window after a "pressed" signal is usually only done for volatile windows (like menus, or overview windows, like in GIMP, which often vanish again, after releasing the mouse button).
Reacting on "pressed" is always a bit problematic, also because the pointer grab initiated with this event can cause side-effects.
Fixed.
Furthermore, it should not have a relief, compare to the "Hide Controls" button.
Also fixed, I've removed the relief.
2. The menus behind the "Back" and "Forward" buttons: Consider the following scenario:
(i) The user presses button 3 on the "Back" button, and the menu is shown.
(ii) He keeps the button pressed, moves to one entry in the menu, and releases the button. Nothing happens.
Currently, the menu items only react on "button_press", which is anyway wrong (see above). Furthermore, in this situation, the item should already react on the "release" event, either as described above, or in the way (i) click on menu, (ii) click on menu entry. The current behaviour is that much confusing, that a user may think that it does not work at all. (I did!)
Yes. Sometime ago Ricardo Persichetti sent me a patch for this. It's just a couple of lines. Now on CVS for testing purposes, plus enhanced pixmaps for Back and Forward that hint their right click menus.
I've written two new widgets, GtkExtMenu and GtkExtMenuItem, which handle this in a cleaner way. Connecting to "button-release-event" has several disadvantages, what I've seen until now, is: (i) keyboard navigation was not handled, and (ii) the menu was hidden too late. The new widgets resemble the standard way as far as possible, so problems shouldf be minimized.
BTW, it is not very obvious, that there is a menu behind these two buttons. Perhaps there should be, in the icon, a small arrow directed downdwards, or so.
Done!
You forgot the small icons, this is fixed now. Also, I've added text to the tooltips.
3. Attached is the incomplete code of a new widget, which changes the behaviour of GtkButton:
(i) It reacts also on button 2 and 3, this would make multiple functions for one button possible. Actually, this feature should be reserved for very few situation (since it is simply confusing), namely the "Clear URL" button, which may also be used for visiting the URL in the selection buffer.
(ii) It provides a function for attaching a menu in a better way, than we have currently, for the "Back" and "Forward" menus, and for the bug meter.
Simply copy all files into one directory, call "make", and run "testprg". Look, what happens with different mouse buttons.
Interesting. I went through the code a bit.
It's not obvious to me how to modify them to be able to provide the same functionality (new window on middle click on history), and not to screw the design at the same time.
Has been enhanced integrated (for forward, backward, and bug meter). See comments in the code. Sebastian
participants (2)
-
Jorge Arellano Cid -
Sebastian Geerken