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