On Sun, 6 Jun 2004, Sebastian Geerken wrote:
> 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 :-)
I reviewed the patch and commited some changes.
Here go my comments:
* I liked very much the new menu-title widget!
* gcc showed some "missing initializer" warnings. It was the
lack of the latest pointer in three GtkTypeInfo structures.
Fixed.
* The "." shortcut was not working. Fixed.
* There was a warning for a signed/unsigned comparison, so I
switched _GtkExtButton's pressed_button to guint. Fixed.
* The "View Page Bugs" menu item for the page menu doesn't
work. It went to a segfault once. NOT fixed.
Some inside comments refer to unused code, for instance on Home
and reload buttons. Yes, it was meant for future extensions (e.g.
a reload images menu item). Now that there's a new way to code
this (as with Back and Forward), the old way can be safely
deleted.
I changed the text for the tooltips of these buttons. Lots of
mouses have two buttons and emulate the middle-click when both
are pressed, so "right-click" and "middle-click" are a bit better
than numbers in this case.
It was nice to see the middle-click over "clear-url" button as
a shortcut for paste. It'd be perfect if the entry can be focused
at the same time.
>
> 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.
Yes, the toolbar icons and the "Hide controls" one are OK
without a relief, but after watching how the bug-meter button
looks without a relief, and how much it hints the user of being a
button, I'd much prefer to have the relief back.
Note that the "Hide controls" button has a drawed frame around
that helps getting the idea of it being a button! Perhaps a more
orthogonal way of doing it is to have a relief for both, but
it's simpler to keep it as it was.
>
> > > 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.
Good!
> > > 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.
Cute icons :)
> > > 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.
Good work. It looks cleaner too.
Cheers
Jorge.-
