- Dillo-dev - lists.mailman3.com

Splitting html.cc: what next?

by onepoint＠starurchin.org

On Wed, Jun 11, 2008 at 12:13:13PM -0400, Jorge Arellano Cid wrote: > I'd say go with table... OK, here's the patch. It's a much smaller change than the form.cc patch (table.cc is only 10k) because table parsing is much simpler and form.cc includes form submission code as well as parsing. It doesn't make nearly as much of an impact on the size of html.cc . It also moves more declarations into html_common.hh (stuff to parse colours and lengths and set styles). As before developers will have to " make maintainer-clean ; ./autogen.sh " so that table.cc gets built. > ...and that's it. :-( I was looking forward to more slicing and dicing! ;-) What do others think? Regards, Jeremy Henty

June 11, 2008

recent style/layout segfaults

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 07:21:35PM +0200, Johannes Hofmann wrote: > On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote: > > Johannes wrote: > > > Comments welcome! I feel a bit uncomfortable proposing a > > > pretty drastic change like this. > > > > Although obviously I don't know the code well, it seems like an improvement. > > After thinking some more about it, I believe this is the right way to > go. My initial patch had some issues though: It was complete > nonsense of course to make the destructor of the derived class > (FltkFont and FltkColor) virtual. It only worked because Font and > Color are derived from lout::Object which already has a virtual > destructor. So in fact the change does not add any additional > virtual methods. > I also decided to keep the interface to dillo2 as it is (the now > unused layout parameter in Style::create()). > > So attached is my official proposal to fix the style related > segfaults that where introduced by my style caching patch. Trying to be practical I'd say: if we don't have a comment in a week let's commit. -- Cheers Jorge.-

June 11, 2008

Splitting html.cc: what next?

by jcid＠dillo.org

On Sun, Jun 08, 2008 at 09:06:07PM +0100, Jeremy Henty wrote: > > Off the top of my head, some suggestions for more files that could > usefully be split out from html.cc: > > - table.cc , handles <table> , <tr> , <td> , <th> > - list.cc , handles <ul> , <ol> , <li> , <dl> , <dt> , <dd> > - text.cc , handles , , , , <strike> > - paragraph.cc , handles , <blockquote> , <center> , <address> > - page.cc , handles <html> , <head> , <title> , <meta> , <body> > > Thoughts? Considering: [...] 16 -rw-r--r-- 1 jcid jcid 14378 2008-06-01 21:59 nav.c 16 -rw-r--r-- 1 jcid jcid 15023 2008-02-29 14:40 png.c 16 -rw-r--r-- 1 jcid jcid 15318 2008-05-25 18:24 prefs.c 20 -rw-r--r-- 1 jcid jcid 16619 2008-06-01 21:59 uicmd.cc 20 -rw-r--r-- 1 jcid jcid 17543 2008-03-29 12:04 url.c 20 -rw-r--r-- 1 jcid jcid 17962 2008-06-01 21:59 capi.c 28 -rw-r--r-- 1 jcid jcid 26697 2008-05-21 18:56 ui.cc 32 -rw-r--r-- 1 jcid jcid 29415 2008-03-15 14:24 gif.c 36 -rw-r--r-- 1 jcid jcid 35558 2008-06-01 22:00 cache.c 64 -rw-r--r-- 1 jcid jcid 59540 2008-06-11 12:01 form.cc 132 -rw-r--r-- 1 jcid jcid 130045 2008-06-10 10:47 html.cc I'd say go with table and that's it. -- Cheers Jorge.-

June 11, 2008

form.cc: refactor DilloHtmlForm::eventHandler()

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 05:38:42PM +0100, Jeremy Henty wrote: > > Three small patches that clean up form event handling: > > 1: refactor file loading into DilloHtmlInput::readFile() > 2: refactor form submission into DilloHtmlForm::submit() > 3: refactor the input logic into DilloHtmlInput::activate() Committed. -- Cheers Jorge.-

June 11, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* Daniel Lord <elektro_news(a)gmx.de> schrieb: Hi, > I like the idea of having dillo CLI operational. May I suggest > having a look at vimperator? It's (in my eyes) beautiful ;) yep, would be cool. But that I could use in my current project (I'm building an DE for unexperienced users). I'd prefer a more generic approach: making everything available via 9P and let separate programs work on that filesystem. This also allows lot's other funny things, eg. an HTML external editor which directly operates on an document within an dillo vierwer ;-) cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 11, 2008

RFC: removing the search dialog

by elektro_news＠gmx.de

Hi all, On Sun, 08 Jun 2008, Enrico Weigelt wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> schrieb: > > I believe one of the important things that we could support is > > custom keyboard shortcuts in dillorc. > > ACK. Maybe would should go the way Mutt does: it internally > works with commands, and keystrokes are mapped to commands. > > Such an simple command interpreter would be cool. If Dillo > also provides an 9P server which publishes internal states and > an command channel, it would be even cooler :) > > > * right-click context menus. > > * providing some keyboard shortcuts. > > Both should be configurable. > > > AFAICS multiple dillorc files are simpler. > > ACK I like the idea of having dillo CLI operational. May I suggest having a look at vimperator? It's (in my eyes) beautiful ;) Greetings Daniel

June 10, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote: > Johannes wrote: > > Comments welcome! I feel a bit uncomfortable proposing a > > pretty drastic change like this. > > Although obviously I don't know the code well, it seems like an improvement. After thinking some more about it, I believe this is the right way to go. My initial patch had some issues though: It was complete nonsense of course to make the destructor of the derived class (FltkFont and FltkColor) virtual. It only worked because Font and Color are derived from lout::Object which already has a virtual destructor. So in fact the change does not add any additional virtual methods. I also decided to keep the interface to dillo2 as it is (the now unused layout parameter in Style::create()). So attached is my official proposal to fix the style related segfaults that where introduced by my style caching patch. Cheers, Johannes

June 10, 2008

form.cc: refactor DilloHtmlForm::eventHandler()

by onepoint＠starurchin.org

Three small patches that clean up form event handling: 1: refactor file loading into DilloHtmlInput::readFile() 2: refactor form submission into DilloHtmlForm::submit() 3: refactor the input logic into DilloHtmlInput::activate() Regards, Jeremy Henty

June 10, 2008

form.cc: select and option classes

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 03:27:11PM +0100, Jeremy Henty wrote: > > Two patches here. > > The first patch turns DilloHtmlSelect and DilloHtmlOption into classes > and implements their constructors and destructors. It also makes > DilloHtmlInput::DilloHtmlInput() responsible for creating the select > object if necessary (as determined by examining the input type) and > removes the select argumentfrom DilloHtmlInput::DilloHtmlInput() and > DilloHtmlForm::addInput() . Committed. > The second patch is a small followup that simplifies select handling > elsewhere: instead of checking the input type we check if the input's > select is non-NULL. Not committed. The canonical way is more orthogonal. -- Cheers Jorge.-

June 10, 2008

form.cc: select and option classes

by onepoint＠starurchin.org

Two patches here. The first patch turns DilloHtmlSelect and DilloHtmlOption into classes and implements their constructors and destructors. It also makes DilloHtmlInput::DilloHtmlInput() responsible for creating the select object if necessary (as determined by examining the input type) and removes the select argumentfrom DilloHtmlInput::DilloHtmlInput() and DilloHtmlForm::addInput() . The second patch is a small followup that simplifies select handling elsewhere: instead of checking the input type we check if the input's select is non-NULL. Regards, Jeremy Henty

June 10, 2008