June 2003 - Dillo-dev - lists.mailman3.com

transient find-dialog

by Andreas Zwinkau

Hi I use ion as my window manager and i found that the find-dialog is not marked 'transient', but a normal window. This is not a good behaviour in my eyes, i have to configure ion manually to treat it as transient. I must admit i do not fully know, what transient means, but it seems bad to me to have to configure such things myself. mfg Andreas Zwinkau | web: andi.dasstellenwirinsinternet.de | mail: andi(a)buxach.de | jabber: beza1e1(a)amessage.de

June 18, 2003

Re: [Dillo-dev] Location entry shortcuts

by Johan Hovold

Thanks for your reply! On Wed, Jun 18, 2003 at 01:12:08PM +0200, Melvin Hadasht wrote: > >When I tried > > to connect it to the main window, a backspace in a form (or in the > > location bar) would trigger "back". Why is this? > > This is because it is an event rather than a signal. And events can be > transferred to the parent widget if the event handler returns FALSE. So if the > (key) event handler in the entry (location bar) returns FALSE, the event is > forwarded to the other (key) event handlers of the same widget and then to its > parent (the main window). To avoid this, once you handled the event, you can > stop the event transmission by making your event handler return TRUE. See GTK > tutorial about the events handling. I figured that out (see below), but thanks anyway. > > Why doesn't the > > the current key_press_handler receive signals when entering text in a > > form? > > This is related to above. The default entry key event handler returns TRUE. > So I guess you added a key event handler to the entry and made it return FALSE, > am I right? I'm afraid not. I haven't added any event handlers to the location entry (nor to any text widgets for html forms). What I would like to have is a "global" handler, to handle any key presses not handled by a text widgets default handler (like function keys etc...) What I can't figure out is why a key press event is forwarded from a text widgets default handler (e.g. a form) to a handler connected to the main window (bw->main_window), but it is NOT forwarded to a handler connected to the main document window (GTBIN(bw->docwin)->child). Could it be that the main window handler somehow gets called before the text widgets default handler? To reproduce this just connect the current key press handler to bw->main_window instead of docwin->child. Then, entering backspace in an html form will trigger "back". Johan Hovold

June 18, 2003

Re: [Dillo-dev] Location entry shortcuts

by Melvin Hadasht

Hi Johan, on Wed, 18 Jun 2003 12:06 +0200, Johan Hovold wrote: >When I tried > to connect it to the main window, a backspace in a form (or in the > location bar) would trigger "back". Why is this? This is because it is an event rather than a signal. And events can be transferred to the parent widget if the event handler returns FALSE. So if the (key) event handler in the entry (location bar) returns FALSE, the event is forwarded to the other (key) event handlers of the same widget and then to its parent (the main window). To avoid this, once you handled the event, you can stop the event transmission by making your event handler return TRUE. See GTK tutorial about the events handling. > Why doesn't the > the current key_press_handler receive signals when entering text in a > form? This is related to above. The default entry key event handler returns TRUE. So I guess you added a key event handler to the entry and made it return FALSE, am I right? Adiu (Corsican: Farewell) -- Melvin Hadasht

June 18, 2003

Location entry shortcuts

by Johan Hovold

Hi! First I'd like to say thank you to every developer of dillo. For a long time I've been looking for a small and fast browser, and the recent development of opera has made this need even more acute. I've been working on a few improvements to dillos interface, which I will submit shortly, but there one thing I could use some advice on. I'm not a great fan of extensive mouse usage and would therefore like to have a shortcut to focus the location entry. In Mozilla and Opera ctrl-l and F8 respectively, focuses the location entry and selects its contents. Is this the way to go for dillo? Or is it better with one accelerator for location entry "grab_focus" (just focus) and one for the clear button "clicked" (clear and focus). I you prefer the first variant; should this shortcut also be available from within the location entry (one could instead use ctrl-a, ctrl-k), or just when the main document window has focus? The reason for the last question is that the current key_press_handler which handles backspace and '/' is connected to the main document window, and hence doesn't receive signals from the location entry. When I tried to connect it to the main window, a backspace in a form (or in the location bar) would trigger "back". Why is this? Why doesn't the the current key_press_handler receive signals when entering text in a form? Johan Hovold

June 18, 2003

Re: [Dillo-dev] Anti-Tab

by Jyri Jokinen

On Tue, Jun 17, 2003 at 07:29:54 -0700, Chris Palmer wrote: I won't even start to comment on all of it, mainly because this is going off-topic and it would make a really long message. > Let's pretend mainstream window managers like Window Maker, KWM and > Gnome WM Of The Week all supported tabs. How would Dillo tell the window > manager to attach the new window to an existing tab group? Afaik there > is no general protocol for this. I'm pretty sure ICCCM has nothing to > say on this topic. You really haven't looked in to how tabbing window managers work, have you? If so, imho, you are in no place to make comments about the subject. Making it a simple and short story: Clients/windows can be identified by many means, and the window manager can be instructed to group all the windows that match those criterias. > See above. If the toolkit used for both the application and the window > manager were the same, and the toolkit had a general mechanism for tabs, > it would be pretty easy. But not all window managers are implemented in > Gtk, so a protocol is needed. I must be a pure looney for having a working tabbing window manager without such a protocol then. Guess I've just imagined it all for several years now. -- shared, don't bother to answer, i know you didn't get it

June 18, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Jens Arm

Hi If I try to add a bookmark in the tabbed dillo version I get a SegFault: [tux@tux tux]$ dillo Setting locale to C... dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://www.dillo.org/< Dns_server [0]: www.dillo.org is 0x810f158 Connecting to 134.102.206.165 Dpi_parse_token: [<dpi cmd='chat' msg='Hi browser'>] Segmentation fault Jens

June 18, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Frank de Lange

Yeah, I'll try to find a good CVS drop to update against (possibly the 0.7.3 release, if that comes relatively soon) and tune the patch to that. <rant mode='puritan'> On the issue of 'tabbing being a feature of the WM, not the app' lots of words have been spoken, maybe wasted. That is one of the reasons I made the whole tab feature optional, so those who take different views can have tabs while the rest can ./configure --disable-tabs and use a tabbed WM. I personally think that a feature which is wanted by many should be implemented, unless is really breaks something bad - security, interoperability, bloat, etc. Tabs do not break anything (if they do, it is a bug, file it or fix it), many people want them, and - most importantly - the VAST majority of WM's does NOT offer tab features. So, currenty, for most people, to get tabs you more or less HAVE to put them in the browser. The WM's which do offer tabs are not really suitable for everyone yet. Once they are - or once the 'main' window managers adopt a good tabbing feature - yes, tabs should probably move to the WM unless there is a compelling reason to have them in the app (I do not know of such a reason). As long as they are not it would be senseless puritanism to NOT put tabs in the browser as an OPTION. Spoken by a user of the Ion WM... </rant> As stated before, I might not have much time the next few weeks, but will try to keep things going anyway. After the 13th of july I expect to have more time... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 18, 2003

Re: [Dillo-dev] Anti-Tab

by Chris Palmer

Jyri Jokinen writes: > "Everybody" doesn't want tabs inbrowser. That's a fact. Look around you. Mere semantics, as Kelson Vibber noted. > There are a lot of window managers other than PWM that support window > tabbing - one of the best is Pekwm, wich i've been using for surfing > with dillo for an eternity now. Waimea and Fluxbox are also getting > there slowly, but their implementations lack usability at the moment. Three obscure window managers, and of those, only one is usable enough even for a motivated expert user like yourself. Let's pretend mainstream window managers like Window Maker, KWM and Gnome WM Of The Week all supported tabs. How would Dillo tell the window manager to attach the new window to an existing tab group? Afaik there is no general protocol for this. I'm pretty sure ICCCM has nothing to say on this topic. > Having tab support in a window manager is flexiple. Much more flexiple > then they can ever get in a, lets say browser, without writing a > complete internal window manager. If the functionality doesn't exist, you have to create it. It didn't exist, and Frank created it. Are you going to create a protocol for tabbing in window managers, and convince all the wm developers to adopt it? Are you going to help them implement it? > > It would not be easy to use since the toolkit (Gtk) is not tightly > > integrated with the window manager > > How should this be of any importance? Please enlighten me, who wonder > in the dark. See above. If the toolkit used for both the application and the window manager were the same, and the toolkit had a general mechanism for tabs, it would be pretty easy. But not all window managers are implemented in Gtk, so a protocol is needed. > I care to object on the plea of ease of use. This far all the tabbin > browsers i have tried have been overly complicated to use compared to > the way pekwm handles it. It's a simple Ctrl-T in Phoenix and Command-T in Camino to create new tabbed windows. Ctrl-W/Command-W closes them. You can drag links to the tabs to cause that link to load in the indicated tab. That's pretty simple. Of course, your window manager will trap or ignore those keystrokes, making that very simple mechanism impossible. The window manager will have to support all of the several possible drag-and-drop protocols applications might use. Oops! > And the sheer fact that i can rebind my keys and mouse clicks with the > window manager but not with the browsers is enough to convince me of > ease of use. Hacking configuration files is not my idea of great ease of use. Software usability is acheived in part by defining and adhering to a user interaction policy. The X Window System and related projects have always eschewed policy setting; instead, only a mechanism is provided. (In some cases, not even a mechanism was provided: window management itself was an afterthought, as was drag-and-drop.) That leaves application developers "free" to devise their own wacky schemes, all different. The inevitable result is pain for users. > There are many great window manager projects developed, The very idea of a window manager as a distinct entity is stupid, from a usability point of view. There aren't 200 window managers for Mac OS, Mac OS X, Windows, PalmOS or BeOS. The makers of those products were trying to make something people could use. > and i do hope you take attleast that one back. After all, dillo once > was a petty crappy piece of software (and still is for an untrained > eye), but it has potential. Just like many of those window manager > projects, which you seem to doom as a byproduct to make a wery pointed > point. My point is simply this: For Dillo to succeed, it must meet the needs of users. Web browser users tend to open many documents at a time, and surf between them. They need a way to manage the clutter, and Frank has provided that in a manner similar to that used in other web browsers. Users also need HTTPS, which has also generously been provided. As of right now (I just updated CVS), HTTPS support is not in the source tree. > Closing word, The fact that dillo now could and probably will have > tabbing support is absolutely great. The fact that the work put into > it might get us closer to having frame support is absolutely great. > The fact that I can toggle it off at compilr time is absolutely great. > People being more or less out of order in a mailing list about a > matter like this is _not_great_. I agree! Everyone should be sending Frank cases of beer, not yelling at him for adding "bloat" or saying "That's great, but we prefer to do it in a way that is pretty much impossible to implement, so no thanks."

June 18, 2003

RE: [Dillo-dev] [RFC] Plans for next version of tab patch

by Eric Gaudet

> I'd advise you to choose a date from CVS and improve the patch > against it (not trying to catch up with current); that way the > patch can be polished without too much hassle and with the > feedback of interested developers. > I recommend we tag cvs for such things, to get an easy reference, or better yet, we branch, so merging is easy.

June 17, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Jorge Arellano Cid

Hi Frank, On Tue, 17 Jun 2003, Frank de Lange wrote: > Hej! > > Now that the first release of my tab patch is 'out there', I'd like to > give a short overview of my plans for the next version of this patch. If geocities stops working just let me know, or ask Andreas who mirrored the patch... > I > do not know when I'll be able to release this next version, as I'm busy > this week, followed by a trip to the UK (back the 13th of juli), but I > will try to make it relatively soon... No problem. Some time ago (maybe a lot), Arvind told me he had developed a "tabs" patch for dillo: http://www.dillo.org/test/dillo_tabs.png He had to work on it some more, then he got very busy, and I haven't heard of it in a long time... Technically, what interests me more about the patch is the separation of interface code out of document code. Now Sebastian is working on another separation; for CSS (it also involves several files), so I think it is better to keep both works separated until our re-structuring of the parser is well defined. I'd advise you to choose a date from CVS and improve the patch against it (not trying to catch up with current); that way the patch can be polished without too much hassle and with the feedback of interested developers. Then, when the time to merge comes, it will be stable, clean and polished. Personally, I can't look at it right now (because of the above mentioned reasons, plus I'm dedicated to the dillo plugins extensions). NOTE: We have advanced a lot with Ferdi on dpid, so it will soon be integrated and commited. ... it has come a tradition (or better, our way of development) to test a lot the patches before commiting them in. That way, the CVS keeps stable, the code clean, and we can keep up with the ideal of always releasing a better Dillo than the former. As you noticed, the patch generated a lot of feedback. I hope patches start to come just as bug notes! ;) > [...] > > Jorge, let me know if/when you plan to commit the patch to CVS (read above) Last, but not the least, I also think that tabbing is a function that should/must be done by the WM. I always try to find "the right place" to put a patch, and IMO it belongs to the WM. Now, as these days only a few WMs come with good tabs support, and as the patch seems small, it should pose no major trouble to eventually commit it. Welcome aboard! Jorge.-

June 17, 2003