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

Re: FLTK and Dillo (fwd)
by Jorge Arellano Cid Oct. 18, 2003

Oct. 18, 2003

Hi, Here're Michael's answers: Cheers Jorge.- ---------- Forwarded message ---------- Date: Fri, 17 Oct 2003 08:40:53 -0400 From: Michael Sweet <mike(a)easysw.com> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: FLTK and Dillo Jorge Arellano Cid wrote: > ... > 1.- C bindings. > Dillo is written in C while FLTK in C++, is there a way to > bind C code with FLTK? Not directly; since FLTK is based heavily on C++, the easiest way to bind C code to a FLTK-based UI is to do the UI in C++ and provide specific C bindings to/from that UI interface. It might also be possible to generate a whole C binding library to FLTK, but that would be a rather large project and keeping things in sync would be a bitch. > 2.- Unicode, UTF-8. > This was the main reason for considering GTK2. Is FLTK ready > to render Unicode characters? The patched version is, and FLTK 2.0 will fully embrace UTF-8. Rendering of certain languages will likely need work, since the initial version will not likely support the rewriting rules needed for languages like Arabic, Hindi, Vietnamese, etc. Those add a lot of bloat, and coming up with a space/time efficient solution will be a challenge for another day... > 3.- Antialiasing. > Is it possible? Text, yes on all platforms, graphics, yes on OSX. > 4.- Tables, layout? and extensibility > This is maybe the core of it. Currently dillo not only uses > GTK1's widgets, but has its own set: dillo widgets or Dw. > These Dw are embedded into GTK1 widgets, and Dw can also > embedd GTK1 widgets. > > Can we do something alike with FLTK? Yes, via subclassing (which actually makes it a lot simpler than GTK and other toolkits...) There is an excellent table widget in the links pages that Erco has been working on and which will eventually be part of FLTK. The current FLTK layout mechanism is infinitely flexible, but takes a little getting used to since there are no layout "hints", just resizeable widgets inside groups. In short, you group widgets (and sometimes create empty "box" widgets) to get the layout behavior you want. This is actually a lot faster than the older Motif-style layout stuff that GTK+ uses... There are specialized group widgets (Fl_Pack, Fl_Tile, etc.) that provide for special positioning/resizing capabilities separate from the user resizing the window. There is currently no support in 1.x for dynamically-sized labels (e.g. resize a button to hold the localized text), so right now you need to design your UI to leave enough space. FLTK 2.x CVS has some support for this via the specialized Layout widget. > 5.- Keyboard bindings > Is it possible to customize keyboard bindings? Keyboard bindings are generally "compiled in", but your app can override them quite easily. There isn't anything like the GTK1 "press your new shortcut while the menu item is selected" feature, something which was (IIRC) removed from GTK2... :( > 6.- Copy&Paste (clipboard) > Does FLTK provide this? Can it be extended with our custom > widgets inside Dillo? Yes and yes. There is also drag-n-drop support, FWIW... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com

2 1

FLTK and Dillo (fwd)
by Jorge Arellano Cid Oct. 18, 2003

Oct. 18, 2003

Hi guys! Here's a copy of an email I sent to Michael Sweet (maintainer of FLTK). Hold your breath and I'll forward the answers! Cheers Jorge.- ---------- Forwarded message ---------- Date: Thu, 16 Oct 2003 17:59:23 -0300 (CLST) From: Jorge Arellano Cid <jcid(a)dillo.org> To: mike(a)easysw.com Subject: FLTK and Dillo Hi Michael! Brief: is it possible to port Dillo to FLTK? We were following our plan to port dillo from GTK1 (currently used TK) to GTK2, when one of our list subscribers suggested considering FLTK because of shared philosophy backgrounds: > [...] > IMHO considering Dillo's concentration on speed and stability, it seems > like it would be more appropriate to port the future Dillo to fltk not > fat bloated GTK2.0. I made a skim visit to FLTK's home and it looked far from being able to supply what we need, but then I came across this comment of yours: <q> "First, the current 1.x release of FLTK is portable to all systems using X11 and has "native" support for Windows and OSX, too. The whole low-level interface to the window system is abstracted via a very thin layer within FLTK, which means that you can easily port it to other environments (there is a version of FLTK for many of the Linux-based PDAs, for example.) The 2.0 release of FLTK (currently in development) will actually have separate modules (a la GDK in the GTK+ world) that implement the device class for various interfaces - X11, Quartz, WIN32, any of several framebuffer APIs, etc. Second, there is a version of FLTK 1.1.x that uses UTF-8 for input and display of Unicode; this will also be part of 2.0." </q> And things started to look interesting... I started a thread on our mailing list to ask for comments from the other developers (subject FLTK): http://news.gmane.org/thread.php?group=gmane.comp.web.dillo.devel I beleive that if it's possible to port Dillo to FLTK, it'd be a great step ahead for both projects. Now, you being the project maintainer of FLTK are among the best ones to ask! :-) In general terms, here're our main concerns: 1.- C bindings. Dillo is written in C while FLTK in C++, is there a way to bind C code with FLTK? 2.- Unicode, UTF-8. This was the main reason for considering GTK2. Is FLTK ready to render Unicode characters? 3.- Antialiasing. Is it possible? 4.- Tables, layout? and extensibility This is maybe the core of it. Currently dillo not only uses GTK1's widgets, but has its own set: dillo widgets or Dw. These Dw are embedded into GTK1 widgets, and Dw can also embedd GTK1 widgets. Can we do something alike with FLTK? 5.- Keyboard bindings Is it possible to customize keyboard bindings? 6.- Copy&Paste (clipboard) Does FLTK provide this? Can it be extended with our custom widgets inside Dillo? That's the core of the problem (AFAIS). It'd be great if we can collaborate to make it happen. Please feel free to answer to me, or to the FLTK thread in our list (it doesn't require a subscription). I'll be looking forward to hear from you. Sincerely Jorge.- http://www.dillo.org/

1 0

dpi patches and dpilib
by Carlos Daniel Ruvalcaba Valenzuela Oct. 18, 2003

Oct. 18, 2003

Hi everybody I have uploaded the patches for dpi autoloading, its kind of inestable, but works, i got to do some fixes, i'll upload updates as they are ready. Just download the tarball, unpack on the src dir, and: $ patch capi.c capi.diff $ patch IO/dpi.c dpi.diff Also i uploaded the dpilib, a helper library to create plugins for dillo. Check all this on: http://earth.prohosting.com/wbuffer Cheers Carlos Daniel Ruvalcaba Valenzuela

1 0

Re: GTK2 performance and Dillo
by Alex Pavloff Oct. 17, 2003

Oct. 17, 2003

I hadn't seen this posted on dillo-dev yet, so I thought I'd forward it along. I'm just the messenger, put the guns away. -------- From: Owen Taylor <otaylor(a)redhat.com> To: Robin Rowe <rower(a)MovieEditor.com> Cc: gtk-app-devel-list(a)gnome.org, Stephen Lewis <slewis(a)paradise.net.nz> Date: Fri, 17 Oct 2003 11:12:48 -0400 On Thu, 2003-10-16 at 14:09, Robin Rowe wrote: > Hi. Dillo is a very small fast web browser (400kb executable). Stephan > Lewis posted some interesting performances tests yesterday comparing > GTK1 and GTK2 running Dillo. > > Can anyone illuminate further on the size and performance differences > between GTK1 and GTK2? I think these observations are basically irrelevant to most GTK+-2.x applications. GTK+-2.x *is* bigger and slower (this is an almost inevitable consequence of having more features and rendering nicer), but it's not megs bigger and minutes slower. > > Test 1: Base load times > > dillo1 > > Time to load+render: ~1s > > Time to quit: instantaneous > > Size (from top): 7MB > > dillo2 > > Time to load+render: ~3s > > Time to quit: 0.5s (estimated, "felt" slower than dillo1) > > Size: 14MB This is almost a plausible difference between GTK+-1.2 and GTK+-2.0 for a large program; though I suspect that reading the common FAQ's about how to read top sizes would show that the memory difference in actual memory used is much smaller than described above. Small GTK+-2.0 programs load in a few tenths of a second and malloc maybe ~600k of memory on X11. (Probably considerably less on Windows since a large amount that RAM is being used for font lists and fonts.) > > Test2: Loading a 1.8MB html file, styled text, bulletted lists, tables > > of text > > dillo1 > > Time to load: 3s > > extra time to finish rendering: 6s > > Time to quit: ~2s > > Size: 56MB > > dillo2 > > Time to load: 1m20s real according to the time command, more like > > 2m30s due to swapping > > extra time to finish rendering: 10s > > Time to close: 1m20s > > Size: 220MB This is a dillo bug and has nothing to do with GTK+. (Or alternatively dillo is misusing GTK+ badly; if it's creating a GtkLabel per paragraph or something you might get this kind of change. But the 56meg "before" is pretty bad too.) > > A couple of behavioural notes: > > 1) Progressive rendering wasn't useful in dillo2, you get an initial > > draw (which is largely useless), then dillo2 blocks, then the final > > draw. dillo2 issue; the expose models *are* different between GTK+-1.2 and GTK+-2.0. This needs to be taken into account if you are doing something like progressive rendering. Regards, Owen --------

1 0

[PATCH] Interface patch
by Johan Hovold Oct. 17, 2003

Oct. 17, 2003

Hi! Here's my patch that adds a search feature and makes a few minor modifications to dillo's interface. - Added search dialog. - Added search button to location bar. - Hidable using show_search preference. - Added cache for search, findtext and open url dialogs. - Added selection of contents upon opening of search, findtext and open url dialogs. - Added selection of text upon shortcut focusing of location bar. - Added deactivation of Ctrl-L in full screen mode. - Added focusing of document window at full screen mode activation. - Added shortcut (ESC) to focus document window. - Accelerators - Ctrl-L, focus location bar. - Ctrl-Shift-L, open url dialog. - Ctrl-S, open search dialog - Z, back - X, forward - ESC, focus document window Most of this has been discussed already in (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-June/000781.html) but some additional motivations goes below. Jorge, if you don't agree with me on the shortcut issue, please change them as you prefer. If you don't like the text selection parts, it's easily disabled in the corresponding open dialog callback. Cheers, Johan Some motivations: ================= - Selection of text upon opening of Open Url dialog. - Dialog most likely to be used to enter _new_ urls, hence the previous url should be cleared or should be easy to clear. - By selecting the previous url, it is easily cleared but also easily modifed, if desired. - Selection of text upon shortcut focusing of location bar, and upon opening of find text and search dialog. - As above, by selecting the text, it is easily cleared and also easily modified. - Common behaviour in other applications. - Added cache for search, findtext and open url dialogs. - Previously the text was cleared if you hit cancel (but not otherwise). Accelerators - Ctrl-L/Ctrl-Shift-L, focus locationbar/open url dialog - Partially overlapping functionality (hence shortcuts should be similar). - Use of location bar makes dialog (almost) redundant (hence ctrl-shift for open dialog). - Shortcuts also found in Mozilla. - Ctrl-U interferes with GTK's Delete line shortcut. - F11, fullscreen - De facto standard shortcut for full screen browsing. - Probably not one of the most used shortcuts, why the more awkward F11 key may be used instead of a quicker Ctrl-<key> shortcut. - Ctrl-H interferes with GTK Delete Backward Character shortcut. - Z/X, back/forward - These shortcuts will enable quick back/forw without having to move the left hand (from the left hand side of the keyboard) or to move the right hand from the mouse (assuming the majority of dillos users are right handed). - ESC, focus document window - Added as requested. - Temporary workaround for GTK focus issue?

2 1

Re: SPAM in the list :(
by Jorge Arellano Cid Oct. 17, 2003

Oct. 17, 2003

On Fri, 17 Oct 2003, Andreas Kemnade wrote: > On Fri, 17 Oct 2003 09:36:44 -0300 (CLST) > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > > Hi Andi, > > > > I just noticed four intances of the "nigerian scam" type of > > SPAM in dillo-dev. I'm worried because usually I also receive > > warning bounces from recipients telling that mail from dillo-dev > > may end being filetered out. > > > spamassassin is attached to dillo-dev now. Every message considered as spam > will be deleted without notice. > > Greetings > Andreas Kemnade Take note guys! If you ever feel unsure about whether a message made its way into the list, just check the archives. Cheers Jorge.- PS: Thanks Andreas.

4 3

Re: [Dillo-dev] Development
by Carlos Daniel Ruvalcaba Valenzuela Oct. 17, 2003

Oct. 17, 2003

> > Any comments?, anyone wants the patches? > > Good idea. Wheres the patches? This weekend i'll prepare the patches, i'll setup a site for all the stuff also. The dpi autoloading for dillo is quite safe, it works even with current plugins without much changes (just in the name of dpi executables). For example: We can do this: url = a_Url_new("dpi:/bm/", NULL, 0, 0); a_Nav_push(bw, url); This will load the bookmarks dpi, but it asumes certain format of the dpi exacurable, this can be replaced with a list of dpi executable -> dpi name list on the config file. It will asume dpiname_srv, thus the bookmarks dpi will be bm_srv. The modification dosen't changes the actual cominications of dpi<-->dillo, only adds dpi autoloading. The patches changes only: capi.c a_Capi_open_url() a_Capi_dpi_send_cmd IO/dpi.c a_Dpi_ccc Dpi_launch_server That's all, see ya the weekend. By the way, who is in charge of the Downloads Plugin? I 'm also working on it, soo if i can help on something, just drop a mail. Cheers Carlos Daniel Ruvalcaba Valenzuela _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

3 2

/. crap
by Andrew A. Gill Oct. 17, 2003

Oct. 17, 2003

[I'm not subscribed to the list, but I do read it in the archives.] Date: Fri, 17 Oct 2003 11:44:33 -0400 From: Jamie McCarthy <jamie(a)mccarthy.vg> Subject: Re: [secret-list] /. hubris superluser(a)frontiernet.net (Andrew A. Gill) writes: > For a while, users of Dillo (<http://www.dillo.org>) have been > having trouble reading Slashdot (<http://slashdot.org>). Looks > like a misplaced </td></tr> is to blame. Anybody want to > pester Cowboy Neal? Well, this is one of the fun things about working on a public project: I get bug reports through more than just the usual channels. Hi, I'm Jamie, I'm the one who wrote the bug, and I'm the one who will get around to fixing it... eventually. There's no immediately simple way to fix the HTML. What's going on is actually kind of interesting. Slashdot runs on Slash, which is a publicly available project used on hundreds of other websites. The look of Slashdot and its front-page table layout is fairly different under the hood from the layout of "Slashcode," which is the default theme that we ship. These differences are mostly encoded in template files, which are data chunks arranged mostly hierarchically that can be selected in all kinds of interesting ways. That means, sadly, that changing one template has many repercussions. Obviously I know where the buggy HTML output is; that's what that commented-out  tag is doing there. But I have to think about what that change would do not just to Slashdot, but to the Slashcode theme generically, to the sites that use that theme as-is, to the dozen other sites my company runs that have modified that theme, to the who-knows how many other sites that strangers run that have modified that theme, to "light mode," to the three or four separate scripts that use the template, I have to test with the pre-rendering caching, etc., etc. Slashdot's HTML layout has always been broken. Early this year I took it upon myself to fix it and quickly realized that there was no good way to fix just Slashdot, without either breaking Slashcode as well or introducing a large number of copy-and-pasted code as a difference between the two that would have to be maintained. What I did instead was write code for the Template Toolkit that lets these dozens of templates build the HTML tables dynamically. As new <TR> and <TD> tags are laid out, variables are incremented and decremented. By the time we get to the bottom of the page, the code knows how many <TD>s and <TR>s it's got to close, and how, in order to make the HTML all nice and pristine. That way, Slashdot.org and Slashcode.com can have wholly different columnar layouts and the low-level templates don't have to know about any of it. The CPU overhead is minimal, and overall it works great. Except there's one bug. It doesn't keep proper track of the tables it's building. It dumps errors in the log so I know about where it is. But it's difficult to narrow down. In my defense, it was broken before I wrote this code, and while it's still broken now, it's broken *less*. But it's broken *differently* and of course there is one browser that (unlike every other browser ever written) isn't smart enough to handle malformed table tags. <http://www.dillo.org/> This is the part where I rhetorically ask why anyone would write a web browser from scratch, the goal of which is to render 100% syntactically correct webpages really really fast. Are there not enough existing web browsers whose goals are to render pages really really fast? Is it perhaps not widely known that there exists, somewhere on the web, HTML code which just might not be 100% exactly correct? Is it smart to build a nitro-burning funny car dragster to carry your groceries and then complain to mailing lists about the potholes on Main Street? When version 0.7.2 of the funny car handled the potholes just fine, but 0.7.3 explodes on contact, should its designers necessarily be focused entirely on the potholes? And should anyone be surprised that writing a web browser is hard? If I could find a way to ask those questions without sounding like I was shifting the blame off my own fool self, I would. It's one of those things that is probably a nice easy single day of work. But I can't remember the last time I actually had a whole day to work on something. Our new load balancer is choking our webheads with unACK'd SYN's and I'm not sure whose fault it is. (And of course the new load balancer is named "pound," only the most common word in the English language, so good luck Googling for anyone else with the same problems.) Our new sites being launched are extending the code in ways it wasn't built for and we're having to scramble. DB replication on one of those new sites went down this morning, and while we built some kickass code to failover to the master, we hadn't had time to get that running yet. Oh, and either my ISP or my home router/gateway is flaky, so I keep falling off the internet. And of course, the day after I fix the HTML 3.2 table layout bug, I am quite certain my boss will email me to say it's finally time to start working on the switch to XHTML and CSS, which we've been planning for a year and just haven't had time for. So yes, I'd love to fix your bug. I don't like emitting broken HTML code either. I'm a big fan of adhering to standards, and I'm a big fan of not having my code embarrass me in public. I hate feeling like a jackass. But I have other things to worry about, and you have other browsers to choose from that render Slashdot just fine. Meanwhile, your bug sits right here, at Priority 5, where it's sat since we first diagnosed it in April: https://sourceforge.net/tracker/?func=detail&aid=719813&group_id=4421&atid=… -- Jamie McCarthy http://mccarthy.vg/ jamie(a)mccarthy.vg Date: Fri, 17 Oct 2003 12:50:48 -0400 From: Jamie McCarthy <jamie(a)mccarthy.vg> Subject: Re: [secret-list] /. hubris superluser(a)frontiernet.net (Andrew A. Gill) writes: > > Well, this is one of the fun things about working on a public > > project: I get bug reports through more than just the usual > > channels. Hi, I'm Jamie, I'm the one who wrote the bug, and > > I'm the one who will get around to fixing it... eventually. > > Do you mind if I forward this message to the Dillo people? If you do, mention to them that I'm not picking on them. This bug is my fault and I'll fix it. I wish them luck and I'm glad they're doing what they're doing (anyone writing GPL code is OK in my book). It's just that I won't fix it until it gets to the top of my priority list, fact of life, and there's a lot of other things up there... :( A workaround meanwhile is to try light mode, which you can get to past the black window with: http://slashdot.org/index.pl?light=1 http://slashdot.org/users.pl?op=edithome&light=1 and then check the "Light" box, and Save to make that your pref. -- Jamie McCarthy http://mccarthy.vg/ jamie(a)mccarthy.vg

1 0

FLTK
by Jorge Arellano Cid Oct. 17, 2003

Oct. 17, 2003

On Fri, 3 Oct 2003, David Martin wrote: > Jorge, > > I would like to quickly comment on the todo list. > > [Snip] > > *Future Goals* (these may change in the future) > Port dillo to GTK+2.0 > > [/Snip] > > IMHO considering Dillo's concentration on speed and stability, it seems > like it would be more appropriate to port the future Dillo to fltk not > fat bloated GTK2.0. > > I would expect that a staticly compiled Dillo-fltk binary would be > considerably smaller then a dynamically compiled Dillo-GTK2 binary. > > > Food For Thought. The FLTK idea is certainly an insteresting issue to analize. The porting task would be far from simple (if possible at all). Dillo does not only uses GTK+ for the user interface but for HTML rendering. Dillo has its own widget system (Dw), that's embedded inside GTK+ widgets, and that at its turn can also embedd GTK+ widgets again. This is the core of the porting problem. The main reason for porting dillo to GTK+2 (instead of sticking to 1.2.10) is Unicode support (explained in the [Project Notes] link). And yes, I've been somewhat scared by the size of GTK+2. For instance in Slackware it jumps from 4Mb to 17Mb! Now, considering that FLTK has Unicode support, gathering more information becomes an interesting thing to do. I don't know FLTK :(, but here is a list with some preliminary concerns (AFAIK): * Does it provide C bindings, or is for C++ only? * Does it have a table widget or similar to GTK+'s layout? * Can it be extended with Dw in the way stated above? * Unicode and antialiasing support status? Please don't get me wrong. This email is just a RFC to make a more informed decision on the issue. The current plan is to go with GTK+2, but if this path shows better, things can change. This is also an RFC for information on GTK+2 (speed, size, linkings etc). Please back your opinions with links, docs, facts or with whatever helps better to understand the point. Maybe a single email can show there's no way to do it, or maybe not! Cheers Jorge.-

7 10

PLEASE COME TO MY AID
by MR NZANGA JOSEPH MOBUTU Oct. 16, 2003

Oct. 16, 2003

FROM:Mr. Nzanga Joseph Mobutu ALTERNATIVE E-MAIL:nzanga_nzanga@tiscali.co.uk Dear Friend, I am the first son of the late Mobutu Sese Seko, the former President of the Congo Republic. I am presently under protective custody in Nigeria as a political refugee. I got your contact during my search for a stranger that can cooperate with me in this mutual transaction. I want you to note that this business will benefit both of us. However, you must confirm your ability to handle this because it involves a large amount of money. The money US$50 million US DOLLARS (Fifty Million United States DollarsOnly) is my share of my father's estate. I boxed and shippedthe money to a security company abroad at the peak of the war/politicalcrisis that rocked my country few years ago. Now the crisis has ended and Ineed a trustworthy person like you to proceed to the place of the securitycompany in order to clear the fund and invest on my behalf as I dont want myname to be used for now. Note that I will send to you the relevant documents that will enable you take possesion of the the fund for onward investment for our mutual benefit. All I need from you is as follows: 1. A letter of committment (duely signed) that you will keep the transaction strictly confidential. 2. Your confirmation of your abilityto handle this. 3. Your IDt or driving licence number for identification to the security company. 4. Your telephone and fax numbers for communication. 5. Your full permanent address. As soon as I get the above information from you, I will disclose to you the name and the country of the security company. I will forward your name and particulars to the securitycompany to enable them contact you accordingly. I will also send to you aLETTER OF AUTHORITY to enable you clear the fund on my behalf. Note thatthis is a very safe transaction as this money is my share of my father's estate. I am waiting for your response to enable us proceed. Regards, Mr. Nzanga Joseph Mobutu.

1 0