- Dillo-dev - lists.mailman3.com

[Dillo-dev]email adress and public key
by Sebastian Geerken Sept. 6, 2004

Sept. 6, 2004

Hi, as I noticed some time ago, I've always had a sgeerken(a)dillo.org email address. I'd prefer this adress in the future for private mail related to dillo. A new PGP/GPG key can be found at <http://www.dillo.org/authors/sgeerken.gpg>, the link in the authors page is wrong, and will be updated soon. (This mail is signed for testing purposes.) Sebastian

3 2

[Dillo-dev]dillo rendering redesign version 3
by Sebastian Geerken Sept. 1, 2004

Sept. 1, 2004

Hi, the newest version of the rendering abstraction prototype (at <http://www.dillo.org/misc_files/dillo-0.8.3-pre-dw-redesign-3.tar.gz>) does not contain anything fundamentally new, but features an interesting application of the new design, a preview window. Just press the mouse button on the button in the lower right corner of the right viewport. Sebastian

2 3

[Dillo-dev]anyone plans to port dillo to gtk+-directfb-2.0?
by Calvin Yu Sept. 1, 2004

Sept. 1, 2004

I'm porting dillo to gtk+-directfb-2.0. By now I have done some work and created new binary. But there are still some critical problems. If there are some persons who are dealing with similar work, we can share and exchange the experence. :)

1 0

[Dillo-dev]dillo rendering redesign version 2
by Sebastian Geerken Aug. 28, 2004

Aug. 28, 2004

Hi, a new version of the rendering abstraction prototype can be downloaded at <http://www.dillo.org/misc_files/dillo-0.8.3-pre-dw-redesign-2.tar.gz>. The new version adds images, which are in the Gtk+ version realized with GdkRGB, we'll have to see how this is done in FLTK. Sebastian

1 0

[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