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.-