- Dillo-dev - lists.mailman3.com

Pending issues

by corvid＠lavabit.com

Johannes wrote: > On Sat, Nov 08, 2008 at 04:31:41PM +0000, corvid wrote: > > patch: middle-click submits in new window/tab > > (This last one had been sent directly to Jorge. > > It's a cheap way to get some degree of > > pages-remember-form-data without having to, > > you know, actually remember form data.) > > Hey that's clever! I already thought about actually implementing > pages-remember-form-data... I wouldn't want to stand in the way of that :) Where do you think form data would fit best? In the history list? (nav stack would require a lot of digging around to clear upon reload, and the cache is low-level and full of images) > A problem may be how to communicate that feature to the user. Quite true.

Nov. 8, 2008

rebased patch: print numeric addresses instead of pointer

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 *bump* ;) Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkV4Q0ACgkQoPmwNWhsaZZgxwCgmF6KnAmGgHrckPYHMkGScLsE xPgAnjNFE4UzuAN1t6tDmgHCXcblGocq =Cd16 -----END PGP SIGNATURE-----

Nov. 8, 2008

Pending issues

by Johannes.Hofmann＠gmx.de

On Sat, Nov 08, 2008 at 04:31:41PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Nov 08, 2008 at 02:49:35PM +0000, corvid wrote: > > > Jorge, is there any chance of my various > > > patches getting looked at in the near > > > future? I feel reluctant to start playing > > > with css until then. > > > > Oh, which ones besided the "view source" one? > > patch: click elsewhere on page, fltk widget loses focus > > patch: prefs.vw_fontname as fltk ui's default font > > patch: middle-click submits in new window/tab > (This last one had been sent directly to Jorge. > It's a cheap way to get some degree of > pages-remember-form-data without having to, > you know, actually remember form data.) Hey that's clever! I already thought about actually implementing pages-remember-form-data... A problem may be how to communicate that feature to the user. Cheers, Johannes

Nov. 8, 2008

Pending issues

by corvid＠lavabit.com

Jorge wrote: > On Sat, Nov 08, 2008 at 02:49:35PM +0000, corvid wrote: > > Jorge, is there any chance of my various > > patches getting looked at in the near > > future? I feel reluctant to start playing > > with css until then. > > Oh, which ones besided the "view source" one? patch: click elsewhere on page, fltk widget loses focus patch: prefs.vw_fontname as fltk ui's default font patch: middle-click submits in new window/tab (This last one had been sent directly to Jorge. It's a cheap way to get some degree of pages-remember-form-data without having to, you know, actually remember form data.)

Nov. 8, 2008

Pending issues

by jcid＠dillo.org

On Sat, Nov 08, 2008 at 02:49:35PM +0000, corvid wrote: > Jorge, is there any chance of my various > patches getting looked at in the near > future? I feel reluctant to start playing > with css until then. Oh, which ones besided the "view source" one? -- Cheers Jorge.-

Nov. 8, 2008

patch: savefile url name

by corvid＠lavabit.com

Anyway, here's a patch that I've had sitting around for a while. I have a bad habit of hitting space to page down when the Location field still has focus, which would break things when trying to save...

Nov. 8, 2008

Pending issues

by corvid＠lavabit.com

Jorge, is there any chance of my various patches getting looked at in the near future? I feel reluctant to start playing with css until then.

Nov. 8, 2008

Pending issues

by jcid＠dillo.org

Hi there, For those of you that wrote me willing to join the project as developers, and to the older ones too ;), here's a pending list of simple matters that need patches. Just in case! 1.- Check the "pending issues" dillo thread in FLTK' site: http://fltk.org/newsgroups.php?gfltk.general+T (search for "dillo") there you'll find a few and some hints too. 2.- CLI From dillo1: $ dillo1 --help Usage: dillo [OPTIONS] [URL|FILE]... Options: -x, --xid XID Open first Dillo window in an existing GtkSocket which window ID is XID (decimal). -v, --version Display version info and exit. -h, --help Display this help text and exit. -f, --fullwindow Start in full window mode: hide address bar, navigation buttons, menu, and status bar. -l, --local Don't follow links for this URL(s). -g, -geometry GEO Set initial window position where GEO is <width>x<height>{+-}<x>{+-}<y> -D, --debug-rendering Draw additionaly several lines in a web page, representing its structure. For debugging. URL URL to browse. FILE Local FILE to vie We need to mimic this. The only complex point is XID option. We don't yet know how to do window embedding by XID with FLTK2. Asking in FLTK general may help. I hope this gets somebody started. /me goes back, to CSS. -- Cheers Jorge.-

Nov. 8, 2008

Few more dillo issues

by sandshrew＠gmail.com

Issues: 1) ssl dpi looping when entering: http://www.elitehackers.info/forums 2) logging into kde forum (forum.kde.org) and gmail (which I reported earlier) doesn't seem to work for same reasons. I guess there should be much more similar cases.

Nov. 8, 2008

Re: css prototype on freehg.org

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Nov 07, 2008 at 11:36:21AM -0300, Jorge Arellano Cid wrote: > Hi, > > We've been arranging some CSS things behind the scenes > with Johannes (he'll forward some past mails here soon). > > > On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > I just created a repository > > http://freehg.org/u/jh33/dillo-css-prototype/ > > > > freehg.org is a free mercurial hosting service. > > This gives access to the newest version of the css prototyping work. > > Also you can check whether you like mercurial. > > > > To get a copy of the repository call > > > > hg clone http://freehg.org/u/jh33/dillo-css-prototype/ > > > > and start hacking. You can commit locally using > > > > hg commit > > OK, I'll make some patches with Hg once I grasp how this > distributed model works. > > On the current code, basically it looks OK to me. i.e. we can > continue working from that basis (having in mind that it's still > in a flux state and that a validation is pending on whether the > model is able to handle the current functionality in html.cc). > > My main comment is that the code needs more comments! :) Agreed. I started to add comments (visible in the hg repo). > > Accurate comments are written when the code is developed (every > detail is in the brain then). I've tried in the past to develop > first and comment later, and found it only works OK for small > code projects. > > As with CSS we don't have a main expert (yet), the team will be > trying to understand and develop at the same time, and thus > comments are very necessary. Even something like "I don't know > how to implement this part" helps! > > I'd suggest to use the same format that's in css.cc. e.g. > > /** \todo dummy only */ > > with a view to integrate it smoothly with doxygen docs. in the > future. > > > Some specific examples: > > 1.- What do these functions do? > - style0() > - startElement() > - endElement() > > 2.- On memory handling, there are some places with: > > // html->styleEngine->style () = > // Style::create (HT2LT(html), &style_attrs); > // old_style->unref (); > > or > > // (html->styleEngine->style ())->unref (); > > Why are they commented and left in the code? Is proper > memory handling pending, is there a design decision to be > made before getting rid of them? They can be deleted. I will do that. The idea is that in html.cc no styles are created anymore. Instead only the style handed out by styleEngine is used. > > 3.- With regard, for instance, to font_factor and visited link > color. Do they belong to buildUserAgentStyle() or > buildUserStyle() or elsewhere? I think the userAgentStyle should contain the defaults, the userStyle can override those. We can create the userStyle from what's in dillorc or - once we have a CSS parser - we could parse a user defined custom stylesheet as it is possible in other browsers. > > 4.- strdup/free should be dStrdup/dFree > (Please let me use this extremely simple case to make my > first Hg patch :-) > Great. You could also create a repo on freehg.org were you can publish your work. We could then pull from each other. Or we send patches to the list and someone integrates them. > > I know this was just a prototype for the CSS implementation > idea, but considering that we don't have any better, and that we > agreed on it, now it has attained the status of "official CSS > merge effort". ;-) > > From now comments are paramount, and we may eventually get to > a dw-like quality docs in the future. Yes, let's take dw as an example. The documentation is really good there. > > > Bottom line: Great, let's get started! Excellent. Here's my todo list: * Adjust CssProperty::Value. As Sebastian has stated "CssValue (is) a union, which represents values exactly in the way they have been parsed" In addition to the values from style.hh it must be able to hold relative values (e.g. "bolder" for font weights). The translation to actual values is then done in StyleEngine::apply (). * Add support for pseudo classes and use it to change the color of visited links in Html_tag_open_a(). * Transform the rest of html.cc, table.cc, and form.cc to use styleEngine instead of creating styles itself. * Port the CSS parser code from dillo-0.8.0-css-3. Any help or comments are welcome! Make sure to have a look at dillo-0.8.0-css-3 as it contains a lot of useful code! Cheers, Johannes

Nov. 7, 2008