- Dillo-dev - lists.mailman3.com

[Dillo-dev]Preparing the 0.8.1 release
by Jorge Arellano Cid April 28, 2004

April 28, 2004

Hi guys, 0.8.1 is getting closer every day. It will feature what's currently in the CVS (basically the improved HTML bug detection and rendering). I'd love to be able to switch this dillo version from alpha to beta stable, but for that there's a lot of testing required. That is, the new parser (going to lots of sites and asserting there're no crashes), and the recently found problems with puppy linux and downloading and FTP (has anyone experienced trouble with these dillo plugins on their systems?). Please test our current CVS hardly, and tell us how it did. Thanks to Jim, who was the first one to send some feesback: > Wow! I can see a big improvement, lots of sites that rendered readably, > but 'iffy', are now much clearer and cleaner. Cheers Jorge.-

10 16

[Dillo-dev]what should do after the window is scrolled?
by Lei Jin April 27, 2004

April 27, 2004

After the window is scrolled, should the new contents of the window be redrawed by the code written by human? Can we output the whole contents to a place, then when the window is scrolled, we only need to updated the visible rectangle parameter? --------------------------------- Do You Yahoo!? 惠普TT游戏剧，玩游戏，中大奖！

1 0

[Dillo-dev]install-dpi-local missing?
by Livio Baldini Soares April 26, 2004

April 26, 2004

Hello everyone, Long time no see, I know, I know... My life has been a (wonderful) big roller-coaster for the last 1 to 2 years, and it seems that the remainder of this year will be the same. Anyways, just wanted to try to report that reading the README file, one gets the impression that an "install-dpi-local" script should exist to install the dpis in your ~/.dillo/ directory for you. I have googled for it, and tried searching in the CVS ATTIC with no success. Things are working for me just fine, because I know how/where to copy the dpi files, but I can imagine that some of our users might be frustated, or require additional assistance. So, before releasing 0.8.1 it might be a good idea to fix the README, explaining what is needed for a "local" install, or even better, resurrect the install-dpi-local script. best regards to all! Livio

2 1

[Dillo-dev]About porting Dillo to FLTK.
by Jorge Arellano Cid April 24, 2004

April 24, 2004

Hi there, We've had long email threads (between our core developers and some FLTK core devs.) dicussing about how the port of dillo to FLTK could be done. We've explored different paths (in abstract) and posting all the threads to dillo-dev would add more to confussion than clarity because each one was explored as it were the chosen one. For simplicity and to keep all the developers in dillo-dev well informed (and certainly inviting the interested ones to take part in the process), I prepared this recapitulation about the more relevant issues. It's a long document with a lot of information. Cheers Jorge.- PS: Previous background on this topic can be found at dillo-dev's archives: http://www.dillo.org/search-dillo-dev.html. For instance: search for "FLTK" by "jcid" sorted by "Relevance". This will not only bring my posts but also the ones from Michael Sweet that I forwarded to dillo-dev. ---------------------------------------------------------------- > [Sebastian] > Furthermore, I have plans to extract at least the core of Dw, and make > an own library of it. The package is already finished, I'm just > polishing another package, which uses Dw. (This is "rtfl", the program > for which the macros in "debug.h" are for.) > > Perhaps it is at least possible, to make Dw itself independent of the > widget toolkit (Gtk/FLTK), ... > [Sebastian] > Dw can be rather simply extracted, and probably it is the best to > start with a testbed. I've attached a test program (I searched > for it somewhere in the mailing list, therefore the french > identifiers :-), you have to build dillo first, to run > it. Perhaps it is simpler to include it into the dillo tarball > itself. > [Sebastian] > Another aspect is portability: When using other toolkits than Gtk, > GtkDwViewport may be replaced. > > For archieving this, the following new design will be sufficient: > > +--------------------+ 1 * +-------------------+ > | DwRenderingContext |---------->| DwRenderingWindow | > +--------------------+ +-------------------+ > 1 ^ | 1 > | | > viewport | | child (the top-level DwWidget) > | | > * | V 0..1 > +----------+ 0..1 > | DwWidget |--. parent > +----------+ | > * | | > `-------' > (children) > [Sebastian] > As for the actual porting, I'm currently working on two topics, which > should make porting simpler, since they reduce the Gtk/Gdk specific > stuff into single modules: > > 1. I'm currently changing the design of image handling as I > described in doc/DwImage.txt in the tarball, section "Future > Extensions". As I've seen now, this is also necessary for > topic 2. > > 2. After this, I'll implement the ideas I wrote before (abstraction > of the actual drawing), in the best case, it should be a simple > matter to write a replacement for the viewport, plus some > changes in dw_style.[ch]. (Dependance of the GtkObject model not > yet considered.) > [Matt] > Abstraction is definitely the best thing to do here. I am pretty sure > we can cross reference between the a-layer and whatever FLTK has to > offer. Spontaneously I see the need for buttons and input fields, line, > box, text and image drawing, image scaling and the dreaded 16-bit vs. > 32-bit coordinates. > > [Jorge] > > Once again, I'd wish to know how a seasoned FLTK developer > > foresees the merging path (from their point of view). With regard > > to Dw, you're the authoritative source! ;) > > [Matt] > At this point - if you guys are still interested - I guess I should > take an extensive tour through the Dw code and see, which parts map > directly onto FLTK, and which parts would need modifications or even > rewriting. ------------------ 32 bit coordinates ------------------ > [Jorge] > > Hi Michael, > > We have been extensively discussing how to port Dillo to FLTK > with Mattias M. and Sebastian. One of the key points is how to > provide for a widget that overcomes the problem of 16 bit > coordinates (GtkLayout currently solves this). > > In a formar email you told me that FLTK2.0 had 32 bit > coordinates, but suggested me to use 1.2.x release that would > also come with 32 bit coordinates. > > Matt was somewhat surprised by this... > [Matt] > I talked to Mike. He changed the coordinates to 32 bit in his local > version already. So in short, fltk 1.2 will have 32 bit coordinates. > Versions 1.1 and 1.0 will not be changed anymore, however 1.2 should > become the standard as soon as we release it, since it is source code > compatible to 1.1. > [Matt] > I went through the current CVS code yesterday, and it seems like we had > a mixup between 1.1 and 1.2. Not a biggie, but I re-merged with a > previous CVS version. The current CVS is now fully 32 bit. tested and > working. > [Jorge] > So we have to use 1.2.x CVS, but which docs are recommended for it? > > [Matt] > The 1.2 cvs contains the full 1.1 documentation and is beeing corrected > to reflect 1.2 changes and additions. I am in the process of adding > doxygen style comments to all fltk classes and methods (95% done), so > simply running the command 'doxygen' will create a second, more > 'techie' documentation in docs/html/index.html. ------- Signals ------- > [Jorge] > Appart from that, the 32 bit issue and the signals (perhaps > solved with Fl_Signal). > [Sebastian] > As for signals: This should be rather simple to re-implement. I just > hacked a prototype of very simple framework for signals, which can be > downloaded at <http://www.dillo.org/misc_files/signals-0.0.1.tar.gz>. > It lacks events returning boolean (which we need), and some more > features (which we do not need), but shows that signals aren't really > a problem. ------- Plugins ------- >> OK, there's no plugin API in FLTK. > > Do you mean what GtkPlug/GtkSocket does? There protocol has been (or > is currently?) standardized at freedesktop.org, if an implemtation is > possible (and why should it not?), this is certainly a candidate for > merging into FLTK. > > > [Matt] > > Yeah, I talked to Bill, and we decided that we will create an Fl > > utility library that offers cross platform access to files and sockets, > > provides threads and locks, and also some standardised plugin > > interface. We will be smarter this time and write it in FLTK2 with an > > FLTK1 compatibility layer... . ------------------------------ About how to approach the port ------------------------------ > > >> [Sebastian] > > >> I'm more > > >> than ever convinced that this was the right decision, especially since > > >> then, incremental resizing has been added, what would have been very > > >> difficult in Gtk. Furthermore, this shows the benefit of having an own > > >> widget set, which can be infinitively changed to our needs. > > > > > > [Jorge] > > > In that case, it seems that the path to go is to port Dw to > > > FLTK, and maybe get rid of some widgets (as DwImage) when they > > > can be replaced by an FLTK embedded one. > > > > > > In anycase, Matt is better qualified than me to comment on > > > this. > > > > [Matt] > > All images in FLTK can be resized at any point. > > > > I understand that you prefer to have your own widget set, and I surely > > don't want to convince you different (because we wanted the same thing > > and that's why we wrote FLTK in the first place). However, should you > > decide to go with FLTK, then all the source code is available to you, > > so you can do the same modifications that you would do in your code. If > > those changes (or additions) are useful for the FLTK toolkit, I'll be > > happy to do them for you (ah, that's where the benefit is for you). > > [Jorge] > This is a very interesting collaboration scenery. I believe we > could start as Sebastian suggests, and merge those features you > see could benefit FLTK. (as for images, and maybe the "complex > resize" widget using size hints to name two). > > [Sebastian] > To make this clear again: What we currently have is an own widget > toolkit within Gtk, i.e. Dw widgets, from which the page is build, are > not Gtk widgets, but instead, for Gtk, a tree of Dw widgets is a just > _one_ huge Gtk widget. (With the exception of Gtk widgets embedded > into Dw.) > > I'd like to stick with the same design (with FLTK instead of Gtk), > also on the long run. For this, there are rather few requirements for > the GUI toolkit, mainly only the 32 bit issue. Integrating both > toolkits, in the way that Dw widgets will become FLTK widgets, will > however make things generally more complicated, we will have a hybrid > which has to deal with both rendering HTML (and other) documents on > one hand and GUIs on the other hand. The duplicate code in the current > design (like event handling), is rather minimal, but integrating would > mean one of the following possibilities: > > 1. Making FLTK as abstract as possible: This would make Dw as > complex as it is now, but instead add an unneccessary > dependency, where the development of dillo will often have to > deal with the limits which any GUI toolkit has. > > 2. Incorperating stuff from Dw into FLTK: This would IMO a very bad > decision of the FLTK team. Dw was designed for rendering > documents etc., and its layout mechanism has several ad hoc > features (size hints, width extremes, incremental resizing), > which should not be in a toolkit for GUIs. Actually, the design > is quite ugly at some points. > > Furthermore, the design often changes, some historical examples: > > - Dw widgets had baselines from the beginning, but they were > fist used much later. (I was indeed hesitating at the > beginning.) > - Tables made it neccessary to introduce width extremes. > (Very ad hoc: Why not height extremes? Because texts are -- > in most languages -- written horizontally, and then > vertically split into lines.) > > - Also with tables (although noticed some time later), it > became clear that the current resizing mechanism was > inefficient and had to be extended. (Notice that Dw > requires that several resizes per second must be handled, > much more what is neededfor GUIs.) > > These were certainly not the last changes, e.g. for CSS, we will > have some other requirements, which are yet not specified. Also, > this shows that most requirements are not obvious before they > are first needed. > > If FLTK wants to adopt Dw features, it will be neccecary to > change FLTK often, and since it is not part of dillo, the > development of dillo will be slowed down, until new FLTK > releases. > > 3. We move stuff from Dw into our own version of FLTK: This would > probably the worst possible desicion, we would fork FLTK and > have to maintain it, also the parts which deal with pure GUI > aspects. > > Dw will work fine with FLTK in the way analogue to the current way, > and the problems with this split are really not as dramatic as Jorge > describes it. The FLTK developers should not make the mistake to take > just one (probably rather prominent) project and change their work so > that it just fits within it. And dillo should keep it dependencies as > low as neccessary. ------------ Porting Plan ------------ > [Sebastian] > I'd suggest the following: > > 1. Finish the planned abstractions. The general idea is to have the > Gtk/FLTK specific code in small modules, which may be rewritten in > a simple way. > > 2. Extract Dw from dillo, and write a test program for several aspects > of Dw. > > 3. Rewrite those modules mentioned in 1, and adjust the test > program. This step will still make Gtk necessary, because of the > Gtk object model, but UI control, event handling etc. will be done > by FLTK. > > AFAIS, the affected modules are the new GtkDwViewport, ImgBuf, and > DwStyle. The abstraction in step 1 may taken a bit more extreme, by > splitting up the latter two into toolkit-dependant and -independant > parts, we'll see. The dillo widgets themselves should not be > modified, if this is really necessary, this is a fault of the said > abstraction. > > After this, we will have a version of Dw, which works with FLTK. The > next step is to see how the parts we take from Gtk (object model with > signals) and GLib (several utilities) can be replaced, so that we can > get rid of the Gtk dependencies. Another topic it the port of the > actual UI; AFAIS, there should be no major problems. Appendix -------- -------------- About printing -------------- > > [Jorge] > > Is printing lost because the widget tree is not native FLTK, or > > is it assured by using FLTK's drawing primitives? > > [Sebastian] > Some remarks on this. First, we still have a "native" FLTK widget, > just that we have one large, complex FLTK widget (which complexity is > manages by Dw), instead of multiple smaller and simpler FLTK > widgets. The reimplementation of the viewport should use FLTK methods > for drawing, so there is no problem at all. > > Second, the abstraction described above should make this possible with > any toolkit, it should be simple to write a printing "viewport". > > Third, printing will anyway become more complex, for several > reasons. For one reason, I quote myself from a mail I sent Jorge, this > may also be interesting for Matt: > > <q> > I'm very sceptical about the idea to use the current rendering for > printing, for two reasons: First, the current rendering is designed > for dealing with viewports, not for pages. Pages are in some ways > different, e.g. you must break pages (instead of having one page of > unlimited height), and you cannot widen the page, you must break a > word, when it does not fit into the line, while it is more > reasonable to let the user scroll to the right, when this is > possible. (Furthermore, from a typographic point of view, dillo's > typesetting quality is sufficient for screen rendering, but rather > poor for printing, especially page breaking cannot be done as > simply as line breaking.) > > Second, most of the complexity has its roots in the requirement of > incremental rendering, which is neither needed, nor desired for > printing. Actually, it makes use for printing more complicated and > inefficient. (Although one rendering iteration has a nearly > constant time, it is as a whole still slower than a simple > non-iterative run.) > > [...] > </q> > > Furthermore, even if we would use Dw for printing (with ugly page > breaks etc.), we would need another widget tree, with the same content > of the current one, but with a state, which is different, e.g. the > top-level available width, which is the window width for the screen, > but the standard paper width for the printer.

1 0

Re: [Dillo-dev]Can't start dpid
by Barry Kauler April 24, 2004

April 24, 2004

> > the problem is dpid won't start in my custom Puppy Linux > > distro. Jorge, Thanks for the feedback. Now that I have dillorc file, dpid does load, but it still isn't working. If I start dillo from the commandline, and enter a url https://www.paypal.com, nothing at all happens in the browser, no error msg even. I get this output from dillo on the stdout/errout: Nav_open_url: Url=>https://www.paypal.com< url_str = https://www.paypal.com Dpi_parse_token: [<dpi cmd='answer' to_cmd='open_url' msg='nothing sent...'>] Dpi: [Dpi_process_io] IOClose The paypal site is working, I just checked with Mozilla. If I right-click on a link to a file on a webpage and choose to "Save link as...", the destination choice window comes up, but after pressing OK button, the stdout/errout is this: ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start Dpi: [Dpi_process_io] IOClose So, I celebrated too soon! Do these messages mean anything much to you? Any suggestion what I should try next? Regards, Barry Kauler

1 1

[Dillo-dev]FTP
by Pete April 23, 2004

April 23, 2004

Morning all, Seeing as someone has mentioned 'FTP', I thought I would get in here. I cant seem to FTP with dillo. If I type is ftp://ftp.somewhere.com it will just hang there. If I type in ftp.somewhere.com it will take me to http://ftp.somewhere.com. So tell me, how do you FTP with Dillo? I am using CVS build. Thanks, -- Pete http://milneweb.com http://nomorevirus.com

1 0

Re: [Dillo-dev]About proxy authorization && password storing
by Jorge Arellano Cid April 23, 2004

April 23, 2004

On Fri, 23 Apr 2004, Ivan Daniluk wrote: > > [...] > > - renamed a_Http_use_proxy_passwd() to a_Http_set_proxy_passwd(). > > - Made the password not visible when typed. > > - Added a commented entry for "http_proxyuser" in dillorc. > > > > This patch is now in CVS, but is not tested because I don't > > have a proxy at hand! :-) > I've tested - it seems to be ok. Good. > And one correction from Francis Daly: > ------------------------------------------- > > From: "Francis Daly" <francis(a)daoine.org> > > To: "Ivan Daniluk" <Ivan.Daniluk(a)ucl.com.ua> > > > > On Thu, Apr 08, 2004 at 06:49:45PM +0300, Ivan Daniluk wrote: > > Hi there, > > One small thing: > > > + static const char *base64_hex = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" > > > + "abcdefghijklmnopqrstuvwxyz" > > > + "0123456789._"; > > > > RFC 2068 (HTTP/1.1) defers to RFC 2045 (MIME), which uses "+/" as the > > final two elements, instead of "._". > > > > RFC 1945 (HTTP/1.0) defers to RFC 1521 (MIME, obsoleted by 2045) which > > uses the same. Done! > PS. I've sent a letter to Madis, but have got no reply yet. Yes, he's under too much work now (we were working on the SSL plugin and he had to stop because of his duties). Please allow him some time. BTW, we have a new SSL dpi prototype (not for the next release though). More on this later. I'll send a recapitualtion about the FLTK port first... Cheers Jorge.-

1 0

Re: [Dillo-dev]Can't start dpid
by Barry Kauler April 22, 2004

April 22, 2004

Ok, I've joined the dillo-dev list! On Fri, 9 Apr 2004 08:13:17 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > I should also explain that I have my own distro, Puppy Linux, > > and everything is compiled against uClibc, not glibc. > > (www.goosee.com/puppy) > > Oh, it would be interesting to have Dillo running under uClibc! Dillo has been in Puppy right from the start (which was about one year ago). A few months ago I changed over to uClibc and recompiled everything, including Dillo, and all was well until I upgraded to Dillo v0.8.0. > Check if you can run them crom the CLI: > > cd /usr/local/lib/dillo/dpi/hello > ./hello.filter.dpi I'm doing this as root. When I try this I get: hello.dpi:: starting... and that's it, nothing more, doesn't exit until I ctrl-c. No error message. ...what is it supposed to do? Regards, Barry Kauler

4 11

[Dillo-dev]Re: [Fink-devel] [Dillo] FONTS
by Joe Corneli April 22, 2004

April 22, 2004

Thanks. I'm somewhat amazed that the Dillo people didn't catch that. >> My ~/.dillo/.dillorc Note that the file should be named ~/.dillo/dillorc (leave the second dot). I do think it would be nice to support a .dillorc too, for people who, like me, automatically type the `.'.

2 1

Re: [Dillo-dev]About proxy authorization && password storing
by Jorge Arellano Cid April 21, 2004

April 21, 2004

On Fri, 2 Apr 2004, Ivan Daniluk wrote: > Hi Jorge. Hi! > > > Maybe, we should open popup dialogue and ask user for > > > login/password? > > > > The login may be specified in dillorc, and the password asked > > in a popup dialog (whenever there's a login in dillorc :). > > > > This adds the burden of entering the password, but keeps things > > a bit more private. > I've implement this burden :), but stuck in a problem and need advice > and/or suggestion from you. > First, look to the attached current patch for stable dillo 0.8.0 > release. Oh, I haven't yet. Anyway, here's the answer. > Main problem for me is the way to stopping the query, waiting > until password will be entered or canceled, and resuming it. > When we call a_Interface_proxy_passwd_dialog(), the dialog window pops > up, and query goes forward, without being formed with proxy password. > So, I see two ways: > 1) to stop the query forming(in Http_get() function) and wait, while > proxy_passwd_dialog_window will be destroyed. > 2) to abort the query, and recall it when password will be entered. > > I'm a newbie in gtk programming, and can't figure out how to graceful > open dialog window and wait until it'll be closed. If it's possible, > than imho it's the best way. > About second choice.. There are complexity for me in a_Http_ccc stuff. > Sure, I'll win this problem, but it will take more time. And really > want to hear your thoughts about it. Use the third alternative! :-) AFAIS the simplest way to to it is to ask for the proxy password when dillo starts, that is, before any query is made, probably after the splash screen is displayed. That way, things would reach the same simplicity as in the first patch! > One more question around it. > Password dialog window is activating in case if there is option > "http_proxyuser" in config, but not when http query gets "Cache Access > Denied" error. > Is this way ok? AFAIU, yes. The proxy login/password pair is one thing, and HTTP's simple authentication mechanism (section 11) is another. It may happen that you reach a realm/password protected page through a login/password authenticated proxy. Now, if after this patch, you want to keep on working on basic authentication, be sure to contact Madis (AFAIR he once worked on it), and I can make the CCC bindings to stop/resume/forward the querying process. > And, the last note on patch. It's about following lines in IO/http.c: > + if ( strchr(prefs.http_proxyuser, ':') ) > + { > + DEBUG_MSG(5, "Storing proxy password in dillorc is insecure!\n"); > + ask_proxy_passwd = FALSE; > + HTTP_Proxy_Auth_base64 = a_Misc_encode_base64(prefs.http_proxyuser); > + } > It allows user to store in config file not only proxy user name, but > pair "user:password" as well. I've done it's mainly for convenience, > but of cource we can remove it from patch. Hmmm, this is one I'm not yet sure of. On one hand, it is very handy not to have to enter the password every time, and on the other, stealing the proxy's password becomes quite simple (for instance, a bathroom break and it's gone! ;). [minutes thinking...] It's not a thing I'd recommend. Now, as Dillo project is explicitly concerned about security, it can't do otherwise. Perhaps you may leave that portion of code commented out, so the responsibility is left to the one that decides to enable it. I'd like to hear comments about this. Specially from sysadmins. > Your suggestion for me are welcome. Thanks. Cheers Jorge.-

2 2