- Dillo-dev - lists.mailman3.com

Re: CSS loading, part 1
by Johannes.Hofmann＠gmx.de Dec. 19, 2008

Dec. 19, 2008

Hi Jorge, On Fri, Dec 19, 2008 at 03:37:28PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > The attached patch does better than the current way, it has > more consistency betweeen what's shown the first time and after > back and forward (at least with my test set). > > Please test it and apply to the css-proto tree. Thanks! Pushed to css-prototpe. > > I don't know what's to be done when multiple stylesheets are > specified, like in this site: http://www.lacuarta.cl. Are they > all supposed to be loaded? If that's the case, I'd like to load > them all and after that, make a single repush instead of one per > arrival. Yes, all stylesheets with a matching media type have to be loaded. I noticed a regression on http://src.opensolaris.org/source/ Maybe it's because now only one stylesheet is loaded? I agree that having just a single repush is probabely better. I don't yet fully understand the new logic and the difference to corvid's approach. Are the style changes in css.cc and css.hh intentional? Generally it would be good to keep whitespace only changes in separate commits. That simplifies reviewing and the search for faulty changesets. BTW. "hg bisect" is a fanatastic tool for that! (similar stuff exists for git too of course). > > If that scheme is implemented, then it'd be simple to extend > the code to parse this case: > > <style type="text/css" media="all"> > @import url('/style.css'); > </style> > > > BTW, it's a very nice feeling to see CSS working. Yes it's fun! Cheers, Johannes

2 1

[patch]: use $(srcdir) in Make rules
by onepoint＠starurchin.org Dec. 19, 2008

Dec. 19, 2008

I was revising the autoconf docs and noticed that make rules should prefix all sources with $(srcdir) to support separate builds[1]. We don't do this, so here's a patch. (Patch generated with Mercurial Queues, BTW.) Jeremy Henty [1]: (autoconf.info)Installation Directory Variables

3 6

revision control and other project infrastructure
by dillo-dev＠toykeeper.net Dec. 18, 2008

Dec. 18, 2008

Hello. I noticed some recent messages about revision control and possibly switching to a DVCS. This makes me happy. :) So, I was wondering about general project infrastructure... things like bug trackers, todo lists, mailing lists, help forums, release management, news, patch queues and code review, code repositories, etc. What I've found so far is the following: dillo.org: - general project info - release tarballs - bug list - FAQ auriga.wearlab.de: - mailing lists - cvs freshmeat.net: release announcements freenode: IRC (inactive?) http://misc.andi.de1.cc/dillo/ : Packaging for Debian, Ubuntu, Openmoko http://www.hyperborea.org/software/dillo/ : Packaging for Red Hat http://freehg.org/u/dillo/css-prototype : Prototype CSS branch Is that about right? Did I miss anything? -- Scott

6 9

dillo_dbg_rendering
by corvid＠lavabit.com Dec. 16, 2008

Dec. 16, 2008

I'm finally bored enough to copy the cmdline code from dillo1. Does anyone care about the dillo_dbg_rendering option? It forces borders in table.cc.

2 1

shaded colors and css
by Johannes.Hofmann＠gmx.de Dec. 15, 2008

Dec. 15, 2008

Hello, mapping css properties to dw::core::style::Style members went very smooth, because Style was obviously implemented with css in mind. Just for the shaded color thing I can't find a corresponding concept in css. What exactly is the definition of a shaded color? Is it just a bit darker than the normal one? Does anyone know the corresponding concept in css? Cheers, Johannes

2 4

Plans for the near future
by jcid＠dillo.org Dec. 11, 2008

Dec. 11, 2008

Hi there, Sorry for the unresponsiveness. I'm too busy in my regular job these days... Besides that, I've read the mailing list and gave some thought to these interesting topics. 1.- CSS plan (basic) 2.- Basic authentication 3.- Toolbox Icon 4.- Gmail compatibility (at least read/send) 5.- Close icon in Tab label 6.- Switch to mercurial I believe our next release would attract more people if it had, at least, implemented a couple in the {1,2,3,4,5} set. ----------------- A bit more detail: ----------------- 1.- CSS plan (basic) a) I have to implement the network retrieval of CSS stylesheets, so Johannes can continue working from there. b) Deciding a basic CSS set (e.g. just colors) is the next step before including it in the main tree c) Hooking it to a dillorc preference and to point 3.- (Read below) 2.- Basic authentication a) I have to review this patch after working on point 1.- b) This is a very requested feature after CSS. It'd be great to have it working. 3.- Toolbox Icon a) Since a long time ago I'd like to have a Toolbox icon to the right of bookmarks with a drop down menu. Something like: [Tb Icon] .-------------------. .---------. | Change charset >|--------------------------------->| UTF-8 | | Force my colors >|-------------------->.-----. | Latin1 | | CSS >|---------->.-----. | On | | Cp 1250 | | Free memory >|--. | On | | Off | | ... | '-------------------' | | Off | '-----' '---------' | '-----' | .------------------. '->| Images | | Local Files | | Everything unused | '-------------------' 4.- Gmail compatibility (at least read/send) a) From what I read it's clear that at least it can be made to work with some tweaks. What do we need to have it working out of the box? b) It'd make a nice headline! ("Fast Read/Send from gmail"). 5.- Close icon in Tab label a) This is much needed as anyone using Tabs has experienced. b) Not too hard to implement, but I have to work on 1 and 2. 6.- Switch to mercurial a) From comments it looks like switching to Hg is a good idea. b) Yes, I'm only updating Mercurial these days as an experiment. c) Switching as soon as I have some time to do it. Probably after 1.- and 2.- -- Cheers Jorge.-

4 4

Dillo and Gmail
by daniel.victoria＠gmail.com Dec. 10, 2008

Dec. 10, 2008

Hi all, First off, I got to say, congrats on the great browser. I have an old laptop and firefox just takes ages to load. Dillo, on the other hand, is lightning fast! Great! The only thing I'm missing is Gmail. Does Dillo work with gmail? Do I need to do any special tricks? I compiled the latest DIllo2 from svn and I did enabled https so I can get past the login page but then I'm stuck at a warning page about a non-standard redirect and, the link on that page does not work. The link is: https://www.google.com/accounts/CheckCookie?continue=http%3A%2F%2Fmail.goog… Thanks for the great work Daniel

4 4

Thoughts on revision control
by onepoint＠starurchin.org Dec. 10, 2008

Dec. 10, 2008

I've been using git to manage the Dillo source locally. I just installed mercurial to experiment with. Things I like about git are the ability to rebase, ie. reorder patches. This is neat because I can develop a patch on top of my local modifications and then push it down the stack so that I submit a patch against the pristine source rather than my customised version. The ability to stash your current changes in a temporary branch is useful too. You could do all this with explicit branches, but it would be more involved and git gives you nice, quick and easy ways to do the same thing. Mercurial seems to be the same sort of beast, though perhaps it is a bit less of a "Swiss Army Chainsaw" than git. I'd be surprised if there were any real issues using either to manage Dillo since I doubt we'd be using anything more than the basic facilities that both offer. I'd prefer git but only out of laziness as it's the one I already know (which means I should probably investigate mercurial just to broaden my mind if nothing else). Regards, Jeremy Henty

2 2

empty html elements
by Johannes.Hofmann＠gmx.de Dec. 10, 2008

Dec. 10, 2008

Hi, while working on css I came across the following: <a class="d" name="INCR32"/> (found at [1]) dillo currently doesn't recognize that the element is empty. The relevant code is at html.cc:3530: /* Test for </x>, ReqTagClose, <x /> and <x/> */ if (*start == '/' || /* </x> */ html->ReqTagClose || /* request */ (tag[tagsize - 2] == '/' && /* XML: */ (isspace(tag[tagsize - 3]) || /* <x /> */ (size_t)tagsize == strlen(Tags[ni].name) + 3))) { /* <x/> */ We could simply drop the requirement for the blank before '/' which would lead to /* Test for </x>, ReqTagClose, <x /> and <x/> */ if (*start == '/' || /* </x> */ html->ReqTagClose || /* request */ (tag[tagsize - 2] == '/')) { /* XML */ or allow a '"' instead of the blank or keep things as they are, if XML requires a blank before the '/'. >From http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags I'd say the blank is optional. What do you think? Cheers, Johannes [1] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port…

5 11

how about a form menu?
by corvid＠lavabit.com Dec. 9, 2008

Dec. 9, 2008

I was playing around with making a form menu. So far: 1) Submit. Nicer from the user's perspective than prefs.generate_submit. 2) Reset. Not really needed when you can just press back and forward. 3) Show/Hide Hiddens. Lets you edit them, which I believe the user should have the power to do. ..and thinking of making an Info option to show submission charset and, oh, whatever else. What I have now is icky proof-of-concept code (although it's been working fine), so I want to see how well the idea goes over before trying to clean it up.

2 2