- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Re: /. crap

by Stephen Lewis

On Sat, Oct 18, 2003 at 09:58:05PM +0200, The Night Howler wrote: <snip> > Maybe by version 1.0 we can include some kind of > "render_uglily_coded_webpage" function to deal with that, but as far > as I'm concerned I'm very happy with dillo the way it is. I have a suggestion regarding this: While supporting broken HTML isn't really in the project goals, would it be possible to wrap a tool like htmltidy using the dpi? So that dillo itself never even gets delivered broken HTML at all, becauses it's all been pre-processed into something valid... Just a thought :) -- Stephen Lewis

Oct. 18, 2003

Re: /. crap

by The Night Howler

Some comments on /. stuff : > 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? Oh, which ones ? On my P 120, which is my only computer, I tried mozilla and its derivatives - they filled up my 56 Mb of RAM just for loading and took a dozen of minutes to show up even a simple page. This without counting the megabytes they took on my hard-drive. So I had a few choices : either switch back to Windows 98 and Internet Explorer, which *is* in comparison damn fast, or use Lynx on my Debian. Or finding another fast linux-graphical browser. I browsed the net. I tested "browsers" like Chimera2, that no one ever heard about, and was very upset with every browser I tried until I found Dillo. Even if Dillo is very strict regarding HTML compliance of pages, it is, as far as I know, the only Linux graphical browser working correctly on legacy computers. > But I have other things to worry about, and you have > other browsers to choose from that render Slashdot just fine. Yes - it works fine with Lynx. I guess maybe we pushed the issue a little too hard - after all, Slashdot is not the only website that doesn't display correctly on Dillo. As the development philosophy is "stick to the standards", I think we shouldn't care too much about badly formatted pages. Maybe by version 1.0 we can include some kind of "render_uglily_coded_webpage" function to deal with that, but as far as I'm concerned I'm very happy with dillo the way it is. I guess for people like me, who use old computers in everyday's life, using Dillo+Lynx is a very good way of accessing a great part of the web resources. Best regards, Mathieu -- "Just living is not enough," said the butterfly, "one must also have freedom, sunshine, and a little flower." Hans Christian Andersen

Oct. 18, 2003

Re: [Dillo-dev] Re: FLTK and Dillo (fwd)

by Melvin Hadasht

> 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... :( It is not removed but disabled by default: you have to add gtk-can-change-accels = 1 to ~/.gtkrc-2.0 -- Melvin Hadasht

Oct. 18, 2003

Re: [Dillo-dev] FLTK

by johannes leimbach

Hi! I have used FLTK a little too, and i was astonished how fast and easy you get results with it, anyway, i haven't used gtk(2), so i can't compare. But you might look at the Fl_Help_Browser widget. Though the name is somehow disturbing, it's a full featured HTML display widget, which indeed gave some nice results. So much for FLTK not good enough for a browser :) Cheers, johannes

Oct. 18, 2003

Re: FLTK and Dillo (fwd)

by Jorge Arellano Cid

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

Oct. 18, 2003

FLTK and Dillo (fwd)

by Jorge Arellano Cid

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/

Oct. 18, 2003

Re: [Dillo-dev] FLTK

by Indan Zupancic

Hello, I have used FLTK a little, and from what I know of it it has less features than GTK, FLTK is probably faster, but GTK was made for GIMP, a drawing program, so I guess it has the functionality you need for a browser. If the current Dillo would be too slow then I would consider switching to FLTK, but not as a upgrade, more a downgrade ;). Though I only know the older FLTK, and not the newer one, so that one may have a lot more functionality. FLTK is written in C++, but you can use it from a C program, or at least you don't have to link to C++ libraries. If your goal is a reasonable fast browser, instead of a very fast one, then I'm afraid I won't use Dillo anymore :(. Looking at the test results, how alpha they may be, I can as well use Firebird. I have two computers, one 233 mhz and one 800 mhz, both are practical GTK2 free, and I would like to keep it that way. The great thing of Dillo is that it's so damn fast, where's the joy if you must wait 3 seconds before it's loaded? If the only reason to switch to GTK2 is to have better fonts support, then I would just stick to GTK 1 and use the freetype library directly, something along the line of prerendered fonts and use them as small pictures, whatever is fastest. Personally I don't need unicode support, can understand that there are a lot people that need or want it, but maybe it's not Dillo's task to support it, maybe a poll on the main website to ask the users about it? For me CSS support is much more important than most other features. I'm digging in Dillo's code to find out a nice way to implement https support, I think the current patch (besides that it's old) is unnecessary big and complicated, I think it can be implemented much cleaner, will post later more about it, probably asking how to handle the variables of the ccc function ;). Greetings, Indan

Oct. 18, 2003

Re: [Dillo-dev] FLTK

by Sebastian Geerken

Hi! Just some remarks: - The performance by this patch is indeed not acceptable, so don't be afraid that it gets, *in* *this* *form*, into the main trunk. - However, the patch is immature, so is may still be improved to gain a reasonable performance (and I'm quite certain that the problems may be fixed). I'm in no way familiar with Pango, so someone else may look at it. The main issues are: - It is worth to examine the drawing times more, I found only slight differences. OTOH, Pango configuration seems to be a difficult problem. Certainly, informations about Pango configuration will be displayed in the splash page. - The low speed of page build, and the memory usage: The patch uses PangoGlyphString, while a previous version used PangoLayout. Maybe PangoLayout may faster, this should be tested. As I already wrote, I'm not familiar with Pango, I should look at it soon, but someone with Pango experiences may give some clues. At least, with Pango, TMTOWTDI. On Tue, Oct 14, Jorge Arellano Cid wrote: > 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? GtkLayout is mainly there to overcome the limited size of X windows. When I started to develop Dw, I first tried to get a similar result by writing anything myself, but finally gave it up. Look at the Gtk+ documentation, GtkLayout does some weird things which may not be possible with FLTK. On Tue, Oct 14, Madis Janson wrote: > On Tue, 14 Oct 2003, Eric Gaudet wrote: > > > 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! > > > > Two applications I used to run regularly when they were on gtk1.2 were > > ported to gtk2.0: pan and edonkey2000-gtk. > > > > I'm not using them anymore, because their rendering became painfully slow: > > scrolling the lists down takes several seconds to refresh on my 300MMX > > laptop. > > I had similar experience with xchat 1.x (based on gtk1.2) and 2.x (gtk2) - > text scrolling in 2.x version was noticably slow, when i used it on > 200MHz pentium. Even new irc messages caused visible redraw when old > messages were scrolled up by 1 line. Can these problems be fixed with another Pango configuration? On Wed, 15 Oct 2003, Eric Gaudet wrote: > What is the purpose of Dw_page_shape_glyphs? At least, it is called, whenever a new word is added to the page, and it somehow determines the size of the word. Sebastian

Oct. 18, 2003

dpi patches and dpilib

by Carlos Daniel Ruvalcaba Valenzuela

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

Oct. 18, 2003

Re: GTK2 performance and Dillo

by Alex Pavloff

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

Oct. 17, 2003