May 2004 - Dillo-dev - lists.mailman3.com

[Dillo-dev][전체회신] Re: [Dillo-dev]Downloads File
by vinod＠etri.re.kr 09 Jun '04

09 Jun '04

Hi Jorge > Hi all Hi Vinod. I assume you received my email, and after considering, you decided to work on the GUI dpi for downloads. (please confirm me that) # Yes. I did intend to confirm after reply from mailing list regarding work. > I am pretty new to Dillo and would like to work on the downloads file. > [dpi] Please could anyone guide me on the present structure and what > enhancement or modifications to be made ? > > The overview of the current structure : > > 3 Structures - DownloadFile, DownloadStatus and DownloadWindow > > Api's to start and free new download, update status, list and create log, > get download size and time, add download to list and start and close > download. Also, api's for read socket and print list are provided. > > Can anyone tell me how to enhance this structure better ? There're two problems with the GUI dpi as is: 1.- it doesn't work reliably 2.- it's too complex for the things it does So, the work basically is to play with it a bit to know what features are provided (the new one should provide the same), simplify the internal representation and algorithms (the GUI part, the part of the code that comes from the original dpi needs not to be touched), and finally debug and perform stress tests to achieve reliability. # Thanks Jorge, Will peruse through the code this weekend. Cheers Jorge.- Regards Vinod Joseph _______________________________________________ Dillo-dev mailing list Dillo-dev(a)lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

2 1

[Dillo-dev]Some remarks on the UI
by Sebastian Geerken 06 Jun '04

06 Jun '04

Hi, several remarks on the UI, which should be fixed IMO. 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. Furthermore, it should not have a relief, compare to the "Hide Controls" button. 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!) (The implementation would become a bit tricky, since button 2 will pop up the page in a new window. Perhaps, I'd even suggest to skip this feature, if a clean solution is not possible.) 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. 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. Comments welcome. Sebastian

2 6

[Dillo-dev]very simple question, and many kudos!
by Brian Hechinger 03 Jun '04

03 Jun '04

first off, i would like to say that i am completely impressed with dillo's efficiency. i finally found myself to be in the position where i needed to get X11 onto my Toshiba Tecra notebook so that i could use a web browser. it's a 166Mhz with 32M ram, so i asked around what would be the best browser for such a low resource machine, and was told firefox by a few. so i got a copy of firefox. it was so slow, not only was it unusable, it made the rest of my computer unusable. then someone mentioned dillo. so i got it. i have to say, i can't even put my surprise of how fast it was into words. i was floored. this is EXACTLY what i needed. so far, it's perfect for me. the only thing that i have a question about is PgUp and PgDn only moving half a page at a time. is there a way to get them to move a full page? thanks, and keep up the excellent work!! -brian -- "Performing a Google search on the fairly unique name you've chosen weeks ago for a piece of software you're writing, only to discover that the sole occurance of that name is as a pen-name for someone who spends his spare time writing X-rated PowerPuff Girls fan fiction is pretty-much a buzzkill." -- Jonathan Patschke --

5 10

[Dillo-dev]https (eg for posting to ps2 bulletin boards)
by robert w hall 02 Jun '04

02 Jun '04

Every time I read the playstation2-linux lists I realise how very useful dillo will be when it gets just a little further. How's the short/medium term future of https looking?(*) If an official plugin is in the offing then that's probably what we should all wait for. Otherwise, is the patch from 0.7 resurrectable?? Bob (*You need ssl to post to the ps2 bulletin board) -- robert w hall

3 4

[Dillo-dev]dillo as a debian package ..?
by Jorge Arellano Cid 01 Jun '04

01 Jun '04

Hi! It's been a long time since the debian package for Dillo is not updated. Since 0.7.3 to be accurate. :-( I've contacted Phil and, surprisingly, the only reason for them not being made is lack of time. Is here a Debian developer that can take the burden, or help Phil, or at least provide us with an x86 .deb to link to from the download page? It seems important because Debian lingering on 0.7.3 implicitly passes the (wrong) message of the latter versions of dillo not being worth an upgrade. TIA Jorge.- ---------- Forwarded message ---------- From: Jesper Olsen <__lazer __at phreaker__ net__> To: jcid(a)dillo.org Subject: dillo as a debian package ..? hello there .. Is there somewhere around where i can get dillo-0.8.1 as a .deb file?? i can't find it, i've almost looked everywhere :s MaNN, thank you for a wonderful browser .. it runs top stable and fast on my 166mhz .. well, it is a shame that i can't get the new versions of the browser ! DILLO ROCKS!!!!! - lazer

3 5

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)
by Sebastian Geerken 31 May '04

31 May '04

On Mon, May 31, Brian Hechinger wrote: > On Mon, May 31, 2004 at 03:09:03PM +0200, Sebastian Geerken wrote: > > > > Scrolling half a page is actually standard behaviour of Gtk, look > > e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or > > less responsible for this in our case, since our code uses > > GdkAdjustment::page_increment, which is set there. > > hmmmmmm. can't say i care for that behavior. maybe i should whine to the GTK > folks and see if i can either get that changed, or at least get it setup so > there is some way to override it at run/compile time? They won't probably change it, especially since dillo depends on Gtk 1.2, which development has been closed, AFAIK. > > The attached patch "solves" it, but I'm not sure, wether the standard > > behaviour should be overridden. > > how hard would it be to make it a runtime option? something in dillorc? that > way you can have standard behavior and also the option to change its behavior > to satisfy people like me? Actually, it envolves reading Havoc Pennington's essay "Free software and good user interfaces" (http://ometer.com/free-software-ui.html), especially the section "The Question of Preferences", and considering, whether or not this configuration option should be added. Actually, I'd rather like it either having applied or not (not configurable), the others should apply the patch. (Adding the code is BTW rather simple, just look at how other options are handled in "prefs.c".) > how about this. let me know when the CVS tree stablizes and i'll write that > for you. It will probably still take some time, it is a bit more difficult than I thought. Sebastian

1 0

[Dillo-dev]helper applications and their uses
by Randy 25 May '04

25 May '04

Hello, First of all,let me say that i don't know a command-line from a chorus line-my feeble knowlege of Linux consists mainly of downloading Apt and Synaptic for my RH7.3 and FC1 distros,and handling it all from the GUI. Just letting you know that your'e dealing with a novice here. : ) I like the concept behind Dillo,simple and fast.I understand that you might be working on a version for frames later on,which would be even better of course.My question though-without reliance on the usual Mozilla plug-ins(which Galeon,Epiphany and Firefox also use) is there anything I can download as a helper application? Would the full Java,for example,interact at all with Dillo when browsing the Web? Would Realplayer,or Gxine with Real plug-ins(i'm on Gnome,of course). Thanks in Advance, Randy

2 1

[Dillo-dev]Dillo RPM available for Yellow Dog Linux 3.0
by Kelson Vibber 24 May '04

24 May '04

In case anyone's interested, I posted an RPM for Yellow Dog Linux 3.0 over the weekend. The usual place: http://www.hyperborea.org/software/dillo/ -- Kelson Vibber www.hyperborea.org

1 0

[Dillo-dev]0.8.1 text centering error? (fwd)
by Jorge Arellano Cid 23 May '04

23 May '04

---------- Forwarded message ---------- Date: 18 May 2004 04:15:11 PDT From: Gregg <dude(a)scorpiorising.ca> To: Dillo <dillo-dev(a)lists.auriga.wearlab.de> Subject: [Dillo-dev]0.8.1 text centering error? Hello, I have compiled and run Dillo 0.8.1 flawlessly on Debian woody. However, I notice the browser "centering text" that wasn't on 0.8.0 and earlier. Example: http://www.cknw.com - my daily news, now shows the headlines as centred. Is this supposed to be? Thanks, -- Gregg _______________________________________________ Dillo-dev mailing list Dillo-dev(a)lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

1 0

[Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)
by Jorge Arellano Cid 23 May '04

23 May '04

Hi Sebastian, > Just FYI: I remember from the old discussion, that DwPage originally > collapsed spaces (i.e. calls to a_Dw_page_add_space), and that I > suggested some changes, so that this is not done anymore. Your patch > would reverse this change again. > > The discussion goes attached. I read the whole thread you sent me. BTW, the whole whitespace issue re-started when I found one of the patches you mentioned. I then read the past emails, and started to try to follow. It is not easy to make a clean picture of it though! --This mainly because of the way it used to be handled inside Dillo and because the SPECS seem not definitive in this matter. Here I'll try to cite past emails and comment my current thoughts: > [...] > This is because a_Dw_page_add_space is called twice, and this function > does actually not add a space, but change the current one. I've worked > on two solutions: > > 1. The first patch (underlined-spaces-clean.diff) changes the > behavior of a_Dw_page_add_space, but needs some changes in the > HTML parser, to control better when this function is called, > i.e. to ignore spaces after <A> and before </A>. This one seems the best candidate. With regard to fixing the parser for ignoring these spaces, see my comments below. > 2. The second one (underlined-spaces-kludgy.diff) tries to adjust > spaces, depending on rather hairy conditions. It works already > (if I'm not wrong, it has quite the same results as the code > before, except the bug). This option is no longer valid. As you clearly described: <q> > > > 2. The second one (underlined-spaces-kludgy.diff) tries to adjust > > > spaces, depending on rather hairy conditions. It works already > > > (if I'm not wrong, it has quite the same results as the code > > > before, except the bug). > > As I've now noticed, this will not work for CSS, e.g. the following > code: > > One non-underlined word > > will be displayed: > > One non-underlined word > ---- ----- > > just because this patch lets DwPage assume something about the > document structure (change from non-underline to underline == > beginning of a tag) which it can (and should) not. > </q> Now, > > Despite of the file names, I'm not sure if the changes in the HTML > parser can be done cleanly. So, if you think that this is difficult to > realize, apply the second patch. Especially, there is probably also an > other DwPage function necessary to remove again the last space, when > </A> is read after a space. I believe the parser is not very hard to modify for ignoring the spaces as patch 1.- requires. The problem is that the SPEC is not clear about exactly how these spaces should be collapsed. For instance: > A different case is "Some text". Your patch will make > "Some text" of it, but it should be really be > "Some text." Yes, I agree, "collapsing" here should be: 'Some text' => 'Some text' as you note. but what do we do with this: 'Some text' If we ignore white space after the start tag and before the end tag, it becomes 'Sometext' (with no space at all!) If we "collapse" as the SPEC says should be done, we have two possibilities: 'Some text' (as it was: underline the whitespace) and 'Some text' (move the space out of the tag) AFAICT, the SPEC leaves the choice open, and advices HTML authors against whitespace inside the tags. IMO, always collapsing white space after the start tag and before the end tag is the simplest to implement. Even more, as the SPEC doesn't define what to do in this case, it's an option left to the User Agent: <q source='HTML4.01 SPEC, 9.1'> In order to avoid problems with SGML line break rules and inconsistencies among extant implementations, authors should not rely on user agents to render white space immediately after a start tag or immediately before an end tag. Thus, authors, and in particular authoring tools, should write: We offer free <A>technical support</A> for subscribers. and not: We offer free<A> technical support </A>for subscribers. </q> Now, this solution would also account for the special SGML line break rules: <q source='HTML-4.01 SPEC B.3.1'> SGML (see [ISO8879], section 7.6.1) specifies that a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag. This applies to all HTML elements without exception. The following two HTML examples must be rendered identically: Thomas is watching TV. Thomas is watching TV. So must the following two examples: <A>My favorite Website</A> <A> My favorite Website </A> </q> Note that Firebird doesn't follow the SGML line break rules! This is not to say we should follow, but that we may find some buggy pages out there, but at least at this point the SPEC is quite clear. ;) > I'm not completely sure, we should carefully evaluate the specs, I'd > suggest to delay this for the 0.8.2 release. Neither I am sure! :-) At this point I see that applying patch 1, plus making the parser ignore whitespaces after a start tag and before an end tag is a correct solution that can endure a reality test. I'll start coding it. Please let me know your thoughts or any point I'm still missing. Best Jorge.- PS: This work is for 0.8.2.

2 9