- Dillo-dev - lists.mailman3.com

[Dillo-dev]Porting dillo to another UI toolkit
by Sebastian Geerken Aug. 25, 2004

Aug. 25, 2004

Hi, I intended to post this a bit later, not before some usable code is available, but I changed my opinion, it may be useful to outline, how porting will happen. The most complex part is certainly Dw, since it is tightly bound to Gtk+. By all means, I want to prevent, that there exist different versions of Dw, with different features (e.g., when the development of the Gtk+ version continues, while the FLTK version is developed), which are hard to integrate. For this reason (and others), I'm currently working on a redesign of Dw, which will make Dw toolkit independant. This is not the single goal of this redesign, it will also make some other features possible, e.g. a preview window, in which the whole page may be seen with reduced size, also, it will make reusage of Dw within graphical plugins possibel, and some more. (Actually, the idea for this design is already older, except the platform independency, but this was simple to add.) I'll soon (within a week or so) post the first usable version of it, which will only include a small program to test Dw, not dillo itself, the integration into dillo will be done later. However, it will already make it possible to start with the porting work. A documentation, which changes should remain small, is already attached. As for the actual port, the following steps should be done: 1. Realize the test program, but for another UI toolkit. This will still have to include Gtk+, because of the Gtk+ object model, but the new toolkit should be in control over the event processing. (Furthermore, GLib will, in this phase, still be needed.) What is needed for this step: (i) an implementation of DwRenderPlatform and DwRenderView, and (ii) ports of the modules Dw_style and Dw_tooltip. These will perhaps also be abstracted, see DwRender.txt for details. The rest should not be touched, if this should become necessary, this is a bug. The changes in Dw_style and Dw_tooltip should not be too hard, and these modules will not change much in the near future, so this simple approach for porting is reasonable in this case. The experiences made on this should be interesting, if the design of Dw_style and Dw_tooltip should be enhanced, as described as an idea in the attached document. 2. The second step (regarding Dw) should be to get rid of Gtk+ and GLib. Since a port to FLTK is planned, it makes sense to port the C code to C++, this would also make the code cleaner, since dealing with classes and interfaces in C (with the Gtk+ model) is quite fiddly. Details of this step have still to be clarified, but the features, GLib and Gtk+ provides, should be relatively easily replaced. Notice also, that I plan to make an own library of Dw (at least the core of it), most of it has already been finished, but the release has been delayed, because I assign a greater priority to the dillo project. For the rest of the port, I do not have any plans, but AFAIS, I see far less problems as for Dw. Sebastian

1 1

[Dillo-dev]why must FLTK?
by Calvin Yu Aug. 20, 2004

Aug. 20, 2004

hello everyone: In order to support double-byte characters, we must port GUI from gtk+1.2 to others, right? The FAQ tells me that the developers are planning to port GUI to FLTK. Who is so kind to tell me any alternatives? I hear FLTK is very complex and not stable. By the way, has anyone taken gtk+-directfb into account? I complied it and ran some example applications. It looked pretty. If we port GUI to gtk+-directfb, we don't need X server any more. It would save a lot of resources. Futhermore, the work will be much less because of similar APIs between gtk-1.2 and gtk-2.x. Best Regards From Calvin Yu

2 1

[Dillo-dev]contrast_visited_color
by Jorge Arellano Cid Aug. 16, 2004

Aug. 16, 2004

Hi there, I've been playing with this patch for enough time to start to like its effects. It changes the old 'force_visited_color' dillorc option with 'contrast_visited_color' (featuring a new algorithm). This allows Dillo to choose the visited link color, in such a way that it makes good contrast with the rest of the page. Please update your dillorc with the new option, test it, and say how it works for you. A suggestion: http://www.paulgraham.com (any link). -- Cheers Jorge.-

4 10

[Dillo-dev](no subject)
by opus＠milneweb.com Aug. 15, 2004

Aug. 15, 2004

I will try to post this again.... I am having this issue when I get to 'gmake' doing the CVS build. [FreeBSD happy.hopto.org 4.10-RELEASE FreeBSD 4.10-RELEASE #0] interface.c: In function `Interface_make_search_url': interface.c:1350: syntax error before `*' interface.c:1352: `search_url' undeclared (first use in this function) interface.c:1352: (Each undeclared identifier is reported only once interface.c:1352: for each function it appears in.) interface.c:1353: warning: control reaches end of non-void function gmake[3]: *** [interface.o] Error 1 gmake[3]: Leaving directory `/usr/home/petie/dillo/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/home/petie/dillo/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/petie/dillo' gmake: *** [all] Error 2 -- Pete http://milneweb.com http://nomorevirus.com

4 4

Re: [Dillo-dev](no subject)
by David McKee Aug. 15, 2004

Aug. 15, 2004

On Sat, 14 Aug 2004, Opus wrote: > On Sat, 14 Aug 2004 19:02:02 -0400 (EDT), David McKee <dmckee(a)jlab.org> wrote: > > Pete, > > This is the problem I reported (and supplied a patch for) under the [snip] > > On Sat, 14 Aug 2004 opus(a)milneweb.com wrote: > > > I am having this issue when I get to 'gmake' doing the CVS build. > > [snip] [snip] > Hey David....thanks. You surely take me for someone that has a clue > what you said means...lol! > > After you said "This is the problem I reported (and supplied a patch > for)" I got lost. I have used CVS for a while now, I am lucky to be > able to get it compiled when things go well. > > Maybe I should skip it now til all is fixed....unless you have a > reasonably 'do-able for me' suggestion. I certainly appreciate your > response though. *;o) Try grabbing the CVS from before the latest patch... man cvs and look for the -D option which lets you set the date spec... BTW- The web access to the CVS archive is the easiest way to learn when that patch was applied. Good luck, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

1 0

[Dillo-dev]thread-safe X at fresco
by robert w hall Aug. 13, 2004

Aug. 13, 2004

The thread-safe versions of XFree3.3.3.1 have disappeared from linuxsavvy, (and my own attempts too recompile my own have produced useable, but not wholly error-free results)... But I note that vintage.fresco.org still has two earlier thread-safe Xlibs, 3.1.2 and 3.2, linked statically. Anyone used these? dillo glib gtk appear only to use libX11, libXext, (which is all the earlier fresco 3.1.2 package provides). Bob Going bravely backwards from kernel 2.6.7! -- robert w hall

2 3

[Dillo-dev]Re: Is IO.txt outdated?
by Calvin Yu Aug. 13, 2004

Aug. 13, 2004

>> It says dillo uses threads for DNS querying and reading local >> files, and signal driven I/O for TCP connections. When the socket >> gets ready for transmission, the data is sent using >> g_io_channel_write. But I can't not find the place where >> g_io_channel_write is invoked in the code. > > Yes, once upon a time it used g_io_channel_write, but not >anymore. I'll update this doc ASAP and let you know when its >ready. > >> >> In previous posts I see >> "When using threads and mutexes (pthreads), thread scheduling is >> done by a third thread or by the kernel (depends upon the >> implementation), and it is preemptive. Now, the address space may >> be shared, so the need for mutexes arise, and because of both >> reasons, performance is degraded. >> Using a pseudo-thread (CCC thread), doesn't require scheduling >> by an external process or by the kernel. All is done in the same >> process, but there's no preemption." >> But I do find a thread is spawned in "a_IO_write_chunk()". >> Would you please tell me the reason? > > Otherwise it wouldn't generate IO signals. > >> What does pseudo-thread mean? > > A non-preemptive thread as those handled by CCC. > I don't think it is really parallel. If there are several connections at the same time, one must wait until another one completes data transfer. assume such a case: one connection is responsible for downloading a big image, and other connections are going to download small images. The former one's G_IO_IN event is triggered first and it begins to download the big image. It will take long for it to complete downloading and other connections have to wait. It's unfair for them though they will cost much less time. I don't know whether I'm right. Must other connections wait until one completes or error occurs? >> Is such thread spawned in >> "a_IO_write_chunk()" pseudo-thread? > > No that one is a POSIX thread (or pthread at least ;). > >-- > Cheers > Jorge.-

2 2

[Dillo-dev]gmake error
by Opus Aug. 12, 2004

Aug. 12, 2004

Freebsd 4.10, doing CVS, gmake gives me this: gmake[3]: *** [interface.o] Error 1 gmake[3]: Leaving directory `/usr/home/petie/dillo/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/home/petie/dillo/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/petie/dillo' gmake: *** [all] Error 2 -- Pete http://milneweb.com http://nomorevirus.com

1 0

[Dillo-dev]urlencoding and the search dialog
by Jorge Arellano Cid Aug. 12, 2004

Aug. 12, 2004

Hi there, A patch for urlencoding what's entered in the search dialog has just been added. A couple of functions in the URL API changed its name. Everything should be OK, but further testing is welcomed. Now you can enter non safe characters in the web search dialog (mainly non ASCII) and have then automatically urlencoded in the query. The FORM submittion routines also use these functions so testing your favorite FORMS is also adviced. Cheers Jorge.-

1 0

[Dillo-dev]Is IO.txt outdaetd?
by Calvin Yu Aug. 11, 2004

Aug. 11, 2004

It says dillo uses threads for DNS querying and reading local files, and signal driven I/O for TCP connections. When the socket gets ready for transmission, the data is sent using g_io_channel_write. But I can't not find the place where g_io_channel_write is invoked in the code. In previous posts I see "When using threads and mutexes (pthreads), thread scheduling is done by a third thread or by the kernel (depends upon the implementation), and it is preemptive. Now, the address space may be shared, so the need for mutexes arise, and because of both reasons, performance is degraded. Using a pseudo-thread (CCC thread), doesn't require scheduling by an external process or by the kernel. All is done in the same process, but there's no preemption." But I do find a thread is spawned in "a_IO_write_chunk()". Would you please tell me the reason? What does pseudo-thread mean? Is such thread spawned in "a_IO_write_chunk()" pseudo-thread? Thanks a lot!

2 2