Re: [Dillo-dev]Some remarks on the UI
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.-
On Tue, Jun 08, Jorge Arellano Cid wrote:
[...] * The "View Page Bugs" menu item for the page menu doesn't work. It went to a segfault once. NOT fixed.
Fixed. I removed it temporally, since the signature of the callback did not fit, and forgot it before comitting. I hope that the segfalt does not occur anymore (I could not reproduce it).
[...] 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.
Done.
[...]
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.
I'd have a further suggestion: Make the right part of the status bar more look like a tool bar, and keep the reliefs hidden. The number of bugs should then move out of the button. Something like: | viewport | +-------------------------------------+--------------+-+-----+ | URLs etc. | 3 bugs found |#| B H | +-------------------------------------+--------------+-+-----+ "B" is the bugmeter button, "H" is the "Hide controls" button, and "#" is a handle to drag the new button bar out of the window. Otherwise, I'd prefer both buttons to have a relief. Sebastian
On Thu, 10 Jun 2004, Sebastian Geerken wrote:
[...]
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.
I'd have a further suggestion: Make the right part of the status bar more look like a tool bar, and keep the reliefs hidden. The number of bugs should then move out of the button. Something like:
| viewport | +-------------------------------------+--------------+-+-----+ | URLs etc. | 3 bugs found |#| B H | +-------------------------------------+--------------+-+-----+
"B" is the bugmeter button, "H" is the "Hide controls" button, and "#" is a handle to drag the new button bar out of the window.
When designing the bug-meter interface, it took some time to find a way that made the appropriate "gestalt" out of the meter. Separating the bug number from the bug-button requires a new hint because the former gestaltic perception is lost.
Otherwise, I'd prefer both buttons to have a relief.
OK, let's have a relief on both. Cheers Jorge.-
participants (2)
-
Jorge Arellano Cid -
Sebastian Geerken