[PATCHES] hand_cursor and image_popup, some remarks
[ Jorge, your mailserver is not healthy... I tried to send this 3 times without success, so it goes to the list instead... ] On Mon, 8 Sep 2003 11:13:32 -0400 (CLT) Jorge Arellano Cid <jcid@softhome.org> wrote:
You're right. In that case it causes more troubles than help. Please send me the patch to commit it to CVS.
It is part of the tab/frame patch... It uses the document abstraction. In non-patched Dillo, it would be something like: if(bw->nav_stack_ptr != -1) gtk_widget_grab_focus(GTK_BIN(bw->docwin)->child); else gtk_widget_grab_focus(bw->location); Question is, how much sense does this make in a single-document window? When the window is created, the navigation stack is empty, so focus will always be on the location bar... By the way, there are some problems with 'hidden focus' in Dw. These problems only become directly noticeable in the tab/frame patched version, but they are present in CVS Dillo as well. To see the problem: 1. start dillo on a longish directory listing or a long document (so that the vertical scroll bar appears) 2. use up and down arrow keys to scroll the document. This works in unpatched Dillo. In the (current) patched version, it only works AFTER pressing the UP key once... 3. press SHIFT-TAB twice. Focus is now set on... something. Something invisible. There is no visible focus cue 4. press DOWN key. Nothing happens, no matter how often you press it... Same for TAB, ENTER, RIGHT, ... 5. press UP or SHIFT-TAB or LEFT key. Focus is now on the document, and scrolling keys work as they should. The problem does not show (in patched or unpatched Dillo) when in fullscreen mode. I've searched for the cause of this problem, but have not yet found it.
Clashing with other apps. is almost unavoidable (unless we clone), but we have chosen to rely over an underlying cognitive model for our UI. It has been very succesful, and praised!
Now, as a matter of serendipity :), the bouncing keyboard may have shown us both a better way. If we make Ctrl-L focus the location bar (as Ctrl-U does now) and a second Ctrl-L to clear it, that may be a good choice.
Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not in GTK2 though), so I think it is best to use it for that purpose in Dillo as well. For GTK2, following the toolkit default bindings is the logical thing to do. Even better is to allow users to decide for themselves which bindings they want. GTK2 does not allow this by default, but it can be re-enabled. No matter how well thought out a model is, the user should *always* be able to override the designer's defaults. Even if that user messes up a perfectly thought out cognitive model. That is also why I make just about everything user-selectable using preferences with sane default values. So, one of my next goals will probably be to implement user-selectable accelerators in Dillo... Based on GTK's default mechanisms for doing such a thing.
Of course, a more orthogonal way to do it, is the same functionality, but inside the location popup. But please experiment with the above suggested idea, and tell me your findings.
Generally I find that popup menu's are more a hinder than a help. This is more of a problem with window managers which do not correctly manage them than with the basic concept of popups, but as the state of the art currently stands I try to avoid them as much as possible. I will therefore try to implement the functionality of Dillo's transient popups (find and open url) in the main window, the former probably in the status bar and the latter in the location bar. And, of course, make a preference to allow the user to choose which version to use - popup or main window. As for using CTRL-L for clearing the location bar, I do not think this is a good idea. But, it is not for me to say it is a bad idea either.
PS: If you send me the requested patches, chances of fast commit are very high
Attached two patches, one for hand_cursor, one for right_click on image. Some remarks: The 'image save as' function in the image popup works, but is dependent on the dpi for the actual save function. That dpi (or, rather, wget) does not know how to handle some link types (eg. file: links), so it will fail on those. The hand_cursor patch works fine, but input_images do NOT work as stated in my previous message. Reverse the patch to dw_button.c to get them back to live... Maybe the image popup should be a submenu on other popups? See the frame/frameset popups (in the tab/frame patch) for an example of what I mean. That way, the image can also be accessed in links (and, maybe, in input images, even those currently do not react to RMB-clicks for obvious reason...) Please be aware of the fact that I will have to keep on adding these patches to the tab/frame patch while the document abstraction has not been committed to CVS... So I will have to patch my own patches, not something I want to keep on doing too long... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
Hi there! On Tue, 9 Sep 2003, Frank de Lange wrote:
[ Jorge, your mailserver is not healthy... I tried to send this 3 times without success, so it goes to the list instead... ]
Yes, softhome has being acting strange the latter months. Fortunately we've being working with Andi K. to enable email from the wearlab. Please try: jcid at dillo.org It's working, so please use it (we're testing). With regard to softhome, I've received two of your 3 email attempts there (it sometimes reports a timeout error and _after_ that, accepts the mail ;)
On Mon, 8 Sep 2003 11:13:32 -0400 (CLT) Jorge Arellano Cid <jcid@softhome.org> wrote:
You're right. In that case it causes more troubles than help. Please send me the patch to commit it to CVS.
It is part of the tab/frame patch... It uses the document abstraction. In non-patched Dillo, it would be something like:
if(bw->nav_stack_ptr != -1) gtk_widget_grab_focus(GTK_BIN(bw->docwin)->child); else gtk_widget_grab_focus(bw->location);
Hmmm, I see. Read below.
By the way, there are some problems with 'hidden focus' in Dw. These problems only become directly noticeable in the tab/frame patched version, but they are present in CVS Dillo as well. To see the problem:
1. start dillo on a longish directory listing or a long document (so that the vertical scroll bar appears) 2. use up and down arrow keys to scroll the document. This works in unpatched Dillo. In the (current) patched version, it only works AFTER pressing the UP key once... 3. press SHIFT-TAB twice. Focus is now set on... something. Something invisible. There is no visible focus cue 4. press DOWN key. Nothing happens, no matter how often you press it... Same for TAB, ENTER, RIGHT, ... 5. press UP or SHIFT-TAB or LEFT key. Focus is now on the document, and scrolling keys work as they should.
The problem does not show (in patched or unpatched Dillo) when in fullscreen mode.
I've searched for the cause of this problem, but have not yet found it.
Yes, that problem is known since a long time. It was very hard to root down! The good news is that it's solved. It's not a problem of dillo but of GTK1. details here: http://mail.gnome.org/archives/gtk-list/2003-June/msg00289.html (As Sebastian, I think we'd better solve this with GTK2.)
Clashing with other apps. is almost unavoidable (unless we clone), but we have chosen to rely over an underlying cognitive model for our UI. It has been very succesful, and praised!
Now, as a matter of serendipity :), the bouncing keyboard may have shown us both a better way. If we make Ctrl-L focus the location bar (as Ctrl-U does now) and a second Ctrl-L to clear it, that may be a good choice.
Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not in GTK2 though), so I think it is best to use it for that purpose in Dillo as well. For GTK2, following the toolkit default bindings is the logical thing to do.
For now, I'll leave it as explained here: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001113.htm...
Even better is to allow users to decide for themselves which bindings they want. GTK2 does not allow this by default, but it can be re-enabled. No matter how well thought out a model is, the user should *always* be able to override the designer's defaults. Even if that user messes up a perfectly thought out cognitive model.
That is also why I make just about everything user-selectable using preferences with sane default values.
So, one of my next goals will probably be to implement user-selectable accelerators in Dillo... Based on GTK's default mechanisms for doing such a thing.
We agree more with the line of GTK+2 authors. BTW, we follow Havoc's guidelines: http://www.dillo.org/ui-prefs-tips.html http://ometer.com/free-software-ui.html Consequently, I'd rather set a low priority on it. I'd much prefer the work to be focused on enabling basic DOM data-access, CSS parsing, floating-objects handling and thinks like that.
Of course, a more orthogonal way to do it, is the same functionality, but inside the location popup. But please experiment with the above suggested idea, and tell me your findings.
Generally I find that popup menu's are more a hinder than a help. This is more of a problem with window managers which do not correctly manage them than with the basic concept of popups, but as the state of the art currently stands I try to avoid them as much as possible.
I will therefore try to implement the functionality of Dillo's transient popups (find and open url) in the main window, the former probably in the status bar and the latter in the location bar. And, of course, make a preference to allow the user to choose which version to use - popup or main window.
(same as above)
Attached two patches, one for hand_cursor, one for right_click on image. Some remarks:
[...]
Thanks. We'll look at them with Sebastian.
Maybe the image popup should be a submenu on other popups? See the frame/frameset popups (in the tab/frame patch) for an example of what I mean. That way, the image can also be accessed in links (and, maybe, in input images, even those currently do not react to RMB-clicks for obvious reason...)
FWIW, we have this implemented with Eric for probably more than a year. The only reason it was held is to keep the UI consistent.
Please be aware of the fact that I will have to keep on adding these patches to the tab/frame patch while the document abstraction has not been committed to CVS... So I will have to patch my own patches, not something I want to keep on doing too long...
I know the problem pretty well: that's why I suggested to select a release, or CVS date to base the patch on. Now, considering all the facts, the document abstraction seems a good part to start reviewing/merging. Please isolate it to start working on it. Regards Jorge.-
On Tue, 9 Sep 2003 15:57:42 -0400 (CLT) Jorge Arellano Cid <jcid@dillo.org> wrote:
Yes, that problem is known since a long time. It was very hard to root down! The good news is that it's solved.
It's not a problem of dillo but of GTK1. details here:
http://mail.gnome.org/archives/gtk-list/2003-June/msg00289.html
(As Sebastian, I think we'd better solve this with GTK2.)
This is not the same problem. set-focus-chain allows you to program around this problem... The real problem, however, is still there... There is a widget, somewhere, which gets focussed without showing a visible focus cue (this is the problem you described, which could be avoided by setting an explicit focus chain) and - the real problem - does not allow the tab key OR gtk_widget_grab_focus(some_other_widget) to shift away focus from it.
Clashing with other apps. is almost unavoidable (unless we clone), but we have chosen to rely over an underlying cognitive model for our UI. It has been very succesful, and praised!
Now, as a matter of serendipity :), the bouncing keyboard may have shown us both a better way. If we make Ctrl-L focus the location bar (as Ctrl-U does now) and a second Ctrl-L to clear it, that may be a good choice.
Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not in GTK2 though), so I think it is best to use it for that purpose in Dillo as well. For GTK2, following the toolkit default bindings is the logical thing to do.
For now, I'll leave it as explained here:
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001113.htm...
Well, let's just say that I do not agree with all the choices (Ctrl-S for searhc the web? While just about every other application uses that for 'save'? And while searching can be done from the location bar or a search box? Please, no...) and, since I am not only a developer of (my version of) Dillo but also a user, I want my browser to do what I want, not what someone else thinks it should do. Hence the preferences. I guess I'm not the only one who feels like that - I know I'm not - so I feel that user choice is a good thing. Havoc's ideas notwithstanding. By the way, Havoc speaks about 'having good defaults'. Well, I think Dillo has some good defaults. But some defaults are less than good. Those which are - in the user's opinion - less than good can be changed using a preference (in the dillorc or some future preference plugin), those which are fine are left at their default setting. So, the user has as few or many preferences in the preference file as s/he wishes. Ain't choice a beautiful thing? Those who want their I-want-to-be-able-to-control-EVERYTHING app can have it, while those who are happy with the defaults can go by without any preferences at all... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
participants (2)
-
Frank de Lange -
Jorge Arellano Cid