- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]Toolkit & dillo

by Lars Segerlund

All in this case means, ( I think ), that gtk can run on a framebuffer device without X as well as under X11, ( and GNOME / KDE ) since that toolkit has a quite solid abstraction. As discussed previously however, gtk ( 2 ) has a ton of dependencies since there has not been any work to reduce them, thus it is BIG and SLOW compared to more light weight approaches. Using a toolkit built on top of Xt on the on the other hand trades some portability, ( need's X11 ), for speed, size and a bit more low level handling of the callbacks and action tables. It is possible to have some toolkits run on 'raw' graphics devices though. / Lars Segerlund. On Mon, 15 Nov 2004 11:00:12 +0000 robert w hall <bobh(a)n-cantrell.demon.co.uk> wrote: > In article <41987D95.7010209(a)sad.it>, Roberto A. Foglietta > <roberto.foglietta(a)sad.it> writes > >Lars Segerlund wrote: > >> There has been a lot of talk about toolkits and dillo, and I had a small > >idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can > >bring only the widgets you need ) and if done with some care a statically linked > >dillo would not be bloated. > > > > Suggest: use directfb combined with gtk eventually > > will that translate easily across all machine architectures? > > > > > > Cheers, > > -- > robert w hall > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 15, 2004

[Dillo-dev]Orthogonalize the parser (leaks, XML, CSS)

by Jorge Arellano Cid

Hi there, I'm devoted 100% to this task now. It started as a small polish and ended being a huge patch. It's incredible how tricky optional tags can get when combined into a pot of tag soup! :-) Add, memory management (almost done), validation, HTML+XML soup and you'll get the idea. I'm testing now. It seems pretty good by now, but there's a page where it hangs dillo with almost no CPU consumption. A riddle to solve... -- Cheers Jorge.-

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Riccardo Mottola

robert w hall wrote: > > > > Suggest: use directfb combined with gtk eventually > > will that translate easily across all machine architectures? absolutely not. WHile Motif/lesstif is. -R

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Roberto A. Foglietta

robert w hall wrote: > In article <41987D95.7010209(a)sad.it>, Roberto A. Foglietta > <roberto.foglietta(a)sad.it> writes > >>Lars Segerlund wrote: >> >>> There has been a lot of talk about toolkits and dillo, and I had a small >> >>idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can >>bring only the widgets you need ) and if done with some care a statically linked >>dillo would not be bloated. >> >>Suggest: use directfb combined with gtk eventually > > > will that translate easily across all machine architectures? ALL? What does it means? ;-) Before choosing a toolkit is necessary understand the target of users. What kind of usage and what kind of arch is very impostant for dillo? In my opinion Dillo is not a good project BECAUSE graphic and gtk are mixed up with HTML rendering engine and everything else. You have to split up: - html engine - cache doesn't have to depend on html engine - plugin and applet engine - users functionalities \___ gui - graphic / Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by robert w hall

In article <41987D95.7010209(a)sad.it>, Roberto A. Foglietta <roberto.foglietta(a)sad.it> writes >Lars Segerlund wrote: >> There has been a lot of talk about toolkits and dillo, and I had a small >idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can >bring only the widgets you need ) and if done with some care a statically linked >dillo would not be bloated. > > Suggest: use directfb combined with gtk eventually will that translate easily across all machine architectures? > > > Cheers, -- robert w hall

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Roberto A. Foglietta

Lars Segerlund wrote: > There has been a lot of talk about toolkits and dillo, and I had a small idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can bring only the widgets you need ) and if done with some care a statically linked dillo would not be bloated. Suggest: use directfb combined with gtk eventually Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Nov. 15, 2004

Re: [Dillo-dev]Task list & priorities

by Jorge Arellano Cid

Hi Brian, Please keep this thread on dillo-dev. On Tue, Nov 09, 2004 at 08:12:50AM -0500, Brian Hechinger wrote: > On Mon, Nov 08, 2004 at 06:15:59PM -0300, Jorge Arellano Cid wrote: > > > > Great! > > Now we have a man in charge of it. > > i would be honored. > > > str = a_Prefs_get("font_factor"); > > if (str) > > ff = strtol(str); > > g_free(str); > > i've read all your email, and it looks like mostly enough to get me started, > but i just had this thought: > > if the dpi reads all the rc files in, we're going to have to be able to > specify which rc file we want to get our config from. we need to > implement a system of scope for the rc files. i don't want the cookie > module asking if it has permission to authorize a site to use cookies > by getting it's config from the cacherc which has an identical format. > > what do you think is the best way to go about doing that? make the rc > filename a requirement in the call? > > str = a_Prefs_get("font_factor", "dillorc"); This is a good idea to start with. > > and then in the dpi just have the rc files as a linked list with an entry for > the filename to do a strcmp() on? Maybe, but remember that cookiesrc has another format. It's not a variable/value pairs list, but a list of instances of the same abstract variable (to name it somehow ;). This also needs some thought. > > also, i still need to read about dpis of course, but are they long running > processes? Dpi servers, YES. Dpi filters come and go per request. > the way i'm thinking is that we don't want the rc files read > every time a preference is needed, so the first instance of dillo will start > the config dpi running, and it will continue to run until there are no more > instances of dillo running. does this sound reasonable? Yes. In fact, that's what the bookmarks dpi server does. You don't even have to worry about launching a dpi, that's the dpid job. It's done automatically. -- Cheers Jorge.-

Nov. 9, 2004

Re: [Dillo-dev]Toolkit & dillo

by Riccardo Mottola

Hello, Lars Segerlund wrote: > > There has been a lot of talk about toolkits and dillo, and I had a small idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can bring only the widgets you need ) and if done with some care a statically linked dillo would not be bloated. You immediately would have a supporter! a tester and partially a coder too. > I can have a look at it, but I would like the general opinion first, ( I would even give Xt a shot :-) that way it would be FAST & SMALL ). Well, Xt is pretty extreme, maybe Xaw in case then. Anyway rememebr that most graphic part in Xm is just passed over to Xt calls. I have already proposed and welcomed a motif port. Lately I am coding a bit on my IRC application written in it and am always surprised by the speed and the cleaniness of the result GTK doesn't even get close. But Motif is tricky, do something wrong and you end with a segfault. It is quite low-level sometimes and tied to X11 quite a bit. Even if I learned quite a deal of Motif, doing a port of dillo myself would be out of reach. But I could probably help. Also I have various OSs with different Motif implementations, from 1.1 to 2.1. It's great for testing. My desperation for motif was so great that I went up to digging out mMosaic! and the last beta of it is interesting. It is so fast in the interface (menus, scrolling etc) although the parser is often inferior to dillo. I never coded a single line of Athena though. VIM supports athena, motif, gtk and lately QT even. It would be nice to be able to accomplish this in dillo too! -R

Nov. 9, 2004

[Dillo-dev]Toolkit & dillo

by Lars Segerlund

There has been a lot of talk about toolkits and dillo, and I had a small idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can bring only the widgets you need ) and if done with some care a statically linked dillo would not be bloated. I can have a look at it, but I would like the general opinion first, ( I would even give Xt a shot :-) that way it would be FAST & SMALL ). regards, Lars Segerlund.

Nov. 9, 2004

Re: [Dillo-dev]Task list & priorities

by Jorge Arellano Cid

Hi Brian, On Sat, Nov 06, 2004 at 11:44:48PM -0500, Brian Hechinger wrote: > On Sat, Nov 06, 2004 at 07:11:12PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > Hello!! > > > > [3] Preferences dpi. > > > [3] Handling of configuration data. > > > > <Sebastian> > > I'd regard this as one task (from the user's point of view). Here, I'd > > rather focus on designing a solid base rather soon, on which future > > extensions may be build on. It is not clear yet, how this will look > > like at all, but supposed (as an example), that dillo manages the > > configuration data (not a dpi), communication with configuration dpis > > should be considered, but made possible later. > > > > (Except the feature, on which Daniel Fairhead is working.) > > > > <Jorge> > > Configuration data also needs some sync. For instance, dillorc, > > cookiesrc, cacherc, <dpis>rc. Maybe having a common format and a > > powerful preferences dpi makes sense at this stage. > > ok, i will take ahold if this one if no-one objects. i would love to > see this done, as it makes doing lots of other things much, much simpler > in the future, especially the cache thing. since the cache thing is now > going to be pretty much on hold until after the CCC study, i need something > to do in the mean-time. ;) Great! Now we have a man in charge of it. > > i don't think it should be too relevant as to if configuration is handled > by a dpi or by dillo proper, since it's just a matter of what part things > ask to get their configuration data from, as they should never have to > look at a config file themselves. it should be fairly trivial to rewrite > how things ask for their config. keep in mind i have yet to look at the > dpi system at all, so i could be completely wrong with that assumption. There's at least one big advantage of having the preferences done in a dpi server instead of Dillo (but some more come to mind :). If you have two instances of Dillo which one is in charge of preferences? If you have a dpi running, and the user exits from Dillo what happens with preferences. If there're two Dillos running we'd need to provide for Dillo to Dillo communcation. How do we handoff preferences from an old Dillo that exits to a newer instance? etc. On the plus side, a Dpi server solves those problems. The issue with this approach is how to communicate with Dillo, but we already have the dpi protocol (dpip). Which is flexible and extensible and can make this communication happen (for instance as the "chat" command in bookmarks). The rc files could all reside in ~/.dillo/ and there would be no race conditions on them (as now with cookies). For instance a simple approach (and simplicity is an asset) is something like: str = a_Prefs_get("font_factor"); if (str) ff = strtol(str); g_free(str); a_Prefs_get() could do it task by sending a dpi command: <dpi cmd='get_preference' name='font_factor'> the answer can arrive packed like this: <dpi cmd='answer' to_cmd='get_preference' name='font_factor' value='1.25'> and recovering "value" with a_Misc_get_attr_value() is trivial! > i'm assuming that being able to offer a configuration API would allow a > layer of abstraction that would hide the internals of how things are > actually done as pertaining to aquiring configuration data. Sure. > > i've got a higher priority project currently on my plate, but the way > things are looking, it shouldn't be but a couple more days until i'm > done with it, at which time i will study the dillo code at great length > and evaluate which would be the easier way (for me at least) to handle > this. Read doc/Dpid.txt. It's a good introduction. You can also have a look at Cfg.txt inside: http://www.dillo.org/misc_files/cfg-test-0.0.3.tar.gz but this is more advanced than what we need now. Anyway it may show some light of things we may require in the future. Sebastian can provide more feedback on that part although I'd regard that as part 2. > > > > [3] Make cookies into a dpi server. > > > > <Jorge> > > Procrastinated from a long time ago. This solves the problem of > > only the first Dillo instance (and its child windows) having > > cookies enabled. Now that cookies work better (with 302 > > redirections) this problem will be more evident. > > i think it may be to my advantage to tackle this task first, as it > will give me a much greater understanding of the dpi structure. that > should certainly make a configuration dpi a very simple task to get > completed. I'd advice to try to use the 'chat' command for this task, and asking me when in trouble. Getting inside the CCC at this stage is not a good idea. > > > > [5] GUI dpi for downloads. > > > > <Sebastian> > > i agree 100% with you on this, however....... > > > <Jorge> > > i think of such annoying sites as sourceforge that do all sorts of > wonky things with the url you send it that wget just doesn't properly > grok. while i certainly prefer to copy the url and give it to wget > myself, sometimes that just isn't practical. This is very simple, but needs some time. For instance, adding login information messages to the FTP dpi is a matter of calling dup2 on stderr, and dup2 into a pipe for stdout, that way the former stderr can be parsed, the pertinent 'send_status_message' commands sent into the pipe, followed by the actual data. The same applies for downloads, and there's a prototype. -- Cheers Jorge.-

Nov. 8, 2004