- Dillo-dev - lists.mailman3.com

Any interest in non-RedHat RPMs?
by Kelson Vibber June 21, 2003

June 21, 2003

Right now I've got RPMs for Red Hat 7.3, 8.0, and 9.0 available at http://www.hyperborea.org/software/dillo.html . I've got my computer triple-booting into all 3 versions in order to build these. I also have a whole lot of unused space on my drive, so it would be possible to set up another partition or two to build RPMs for (an)other distribution(s). A few months ago I tried out both Red Hat 9 and Mandrake 9.1, before settling again on Red Hat - so I have the Mandrake CDs available. And assuming that SuSe has rpmbuild in their free version, I could probably download that if there was enough interest. I may also be able to get access to a Power Macintosh and experiment with something like Yellow Dog. So would anyone here be interested in additional RPMs, or do you think the SRPM is enough? Kelson Vibber kelson(a)pobox.com

2 1

transient find-dialog
by Andreas Zwinkau June 19, 2003

June 19, 2003

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

2 2

Re: [Dillo] Charset representation patch
by Jorge Arellano Cid June 19, 2003

June 19, 2003

On Wed, 18 Jun 2003, Nikita V. Borodikhin wrote: > Hello, Jorge ! > > Jorge, I'm sorry for annoying you but can you say anything about > the future of this charset representation patch also posted to > dillo-dev list at Mon, 9 Jun 2003 17:40:24 +0700 ? > > Some time after that (2003/06/12 20:51:00) you add 0x2022 code > to UCStolatin1 handler so this patch differs from mailing list one > in one line. This is at least my third answer to this not high priority issue. From my previous response, still this concern remains unanswered: > (I wrote) > > Finally, I can't see (yet) how having this entitites character > representation helps when using another character set (as with > the russian encoding workaround), unless you first convert the > regular HTML character encoding into the current locale! > Certainly a hairy problem, and one of the main reasons for GTK+2 > design decision of using UCS instead of the current locale as its > internal representation. Now, considering that the default dillo uses Latin1, after reviewing the patch, I found 38% of the big representations table is useless... (and there are other things). > I know you are now hard-working but this patch is not too big > to review... Yes, it is not too big to read, but the work behind integrating a patch is certainly bigger than the patch itself. Most of the time it involves reviewing some RFCs, the internal working structure of the browser in that matter, performance issues, impact, internal standards, future, an so on. IMHO, this is not my duty to do, but the patch sender's, and when I see it was done losely, certainly it discourages me from working on it. If it regards a matter with low priority, then I have one more reason... Now, considering that I have excellent patches in the queue to review (with versions, research, README, Documentation, explanations...), I feel really guilty for dedicating much time to other stuff, but I hope this explanation serves everyone. > Once more sorry. I'm also sorry. Jorge.-

1 0

Tabbed version of Dillo, remarks
by Frank de Lange June 19, 2003

June 19, 2003

One last thing before I go to sleep... As already stated in the documentation (doc/DilloDoc.txt, but who reads documentation anyway?), the tabbed version of Dillo sometimes (to be specific, when loading a tab in the background) produces Gdk_CRITICAL messages on stderr. Like these: Gdk-CRITICAL **: file gdkwindow.c: line 1274 (gdk_window_set_cursor): assertion `window != NULL' failed. These messages come from deep within dw_widget (line 706), and seem to be caused by an error/a bug in the widget. What seems to happen is that the widget tries to reset the cursor for a non-existing window (gdk_window_set_cursor (GTK_LAYOUT(viewport)->bin_window, NULL while the viewport does not yes have a bin_window defined). Sebastian, any input on this? 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." ]

2 1

Re: [Dillo-dev] Tabbed version of Dillo
by Frank de Lange June 19, 2003

June 19, 2003

Andreas Schweitzer wrote: > Hi, > > >>Yes, it does facilitate the development of a frames-capable Dillo. I >>have some ideas about how to implement this, and might implement it >>after the tab code is ready for first release. > > > If the "might" should not happen, I'll certainly look into it :-) Well, the weekend is nearly over and I have not used a computer other than to send this message, so it'll definitely be somewhere coming week for the first release of dillo/tabs. By theway, do not let me possibly working on tabs withold you from doing the same... > Oh, one thing : Sebastian Geerken is the one responsible for > the widget part - unless he already mailed you :-) Ack, have not seen mail from him... Sebastian, maybe dw_gtk_scrolled_window needs a method to remove the gadget? I re-use the BrowserWindow's full_screen_off_button gadget in all tabs (reparenting it when needed), but I have to forcibly NULLify the window->gadget attribute to be able to add a new gadget to a dw_gtk_scrolled_window. It is not 'right' to mess with interal widget structures... or am I missing something? The code does not seem to provide a way to remove the gadget once it has been defined. 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." ]

2 1

[RFC] Plans for next version of tab patch
by Frank de Lange June 18, 2003

June 18, 2003

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. 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... Anyway, some plans: Architecture ------------ - further separate interface code out of document code (interface messages currently go directly to the interface, some mediation might be necessary) Functionality ------------- - focus tab contents on tab switch (so key navigation works correctly without having to first click in the tab pane) - focus location bar on switch to empty tab/new tab - new empty tab should show/focus, even when 'tab load in background' is set - after tab delete, switch to NEXT tab instead of PREVIOUS (like mozilla) Coding ------ - clean up code organisation (declarations before g_return/comments) Bugs ---- - full screen off widget does not show after tab switch in full screen (probably hidden, it IS reparented) There might be more, or less. Let me know. Jorge, let me know if/when you plan to commit the patch to CVS Sebastian, do you have any suggestions as to why dw_widget tries to set the cursor on a non-existing bin_window in the mouse event code? See my earlier message on the Gdk-CRITICAL messages which sometimes appear when opening a document in a tab in the background... 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." ]

4 6

Anti-Tab
by Andreas Zwinkau June 18, 2003

June 18, 2003

I just want to throw in, that tabbing may be a bloat-feature. Just because every modern browser has it and everybody wants it, i needn't to be necessary. I watched a similar discussion some time ago and a wise argument convinced me, that tabbing is not a task for a browser. Before you call me loony, listen. Tabbing is about handling different windows, but handling windows is nothing a browser should do. Leave to the programs, which are made for especially that: Window Managers! Tabbing should not be implemented in a browser, but in the window manager. Sorry, if KDE and Gnome don't support it (i think, am i wrong?) Just my 2ct ;) mfg Andreas Zwinkau | web: andi.dasstellenwirinsinternet.de | mail: andi(a)buxach.de | jabber: beza1e1(a)amessage.de

7 9

Location entry shortcuts
by Johan Hovold June 18, 2003

June 18, 2003

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

2 2

RE: [Dillo-dev] [RFC] Plans for next version of tab patch
by Eric Gaudet June 17, 2003

June 17, 2003

> 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.

1 0

Suggestion for a next dillo version
by Manuel Serrano June 17, 2003

June 17, 2003

Hello there, first of all, many thanks for making Dillo available. I'm using it on a daily basis. It does almost anything I want of my web browser (nearly may be CSS2 but this is not the purpose of this mail :-). I like the new feature of 0.7.2 that enables to hide the navigation bar. I was wondering if it could be possible to have an automatic hidden bar such as in many window manager (fluxbox, kde, gnone, ...). That is the navigation bar is automatically hidden until the mouse fly over the very top lines. If the mouse fly over these lines, it automatically appears... Do you think that it would be difficult to implement this feature in a coming version? Many thanks in advance and one more time, thanks for making Dillo available. -- Manuel

2 1