- Dillo-dev - lists.mailman3.com

[PATCH 1 of 3] Use event_button() instead of event_key() since we're dealing with mouse events

by 4winter＠informatik.uni-hamburg.de

# HG changeset patch # User Justus Winter <justus.winter(a)informatik.uni-hamburg.de> # Date 1236615471 -3600 # Node ID 9638f05098cf2687dbb863f47fd82461c5417403 # Parent cc974615ae3906d4e36fb1d30a90e8be056d497a Use event_button() instead of event_key() since we're dealing with mouse events diff -r cc974615ae39 -r 9638f05098cf src/ui.cc --- a/src/ui.cc Fri Mar 06 18:35:40 2009 +0000 +++ b/src/ui.cc Mon Mar 09 17:17:51 2009 +0100 @@ -279,7 +279,7 @@ static void b1_cb(Widget *wid, void *cb_data) { int bn = VOIDP2INT(cb_data); - int k = event_key(); + int k = event_button(); if (k && k <= 7) { _MSG("[%s], mouse button %d was pressed\n", button_names[bn], k); _MSG("mouse button %d was pressed\n", k);

March 9, 2009

[PATCH 3 of 3] Easy panning with the left mouse button

by 4winter＠informatik.uni-hamburg.de

# HG changeset patch # User Justus Winter <justus.winter(a)informatik.uni-hamburg.de> # Date 1236616924 -3600 # Node ID 46c62dde8967ae87914d0fbcc0ba7df61853750c # Parent 78c0fa261c84df53da7f69cc8f33dc85fa152f9c Easy panning with the left mouse button This is particulary useful for embedded devices with touch screens. In order to select text you have to double click and drag the pointer. Note that this functionality is disabled by default and can be enabled by the easy_panning directive in the configuration file with the exception of the selection behavior which is located in dw/selection.cc and lacks a reference to the prefs struct by design (dw is a toolkit and frontend agnostic). I think that dw needs an interface to tweak it's behaviour ie dw_config(DW_DOUBLECLICK_TO_SELECT, true). Any ideas? diff -r 78c0fa261c84 -r 46c62dde8967 dillorc --- a/dillorc Mon Mar 09 17:21:32 2009 +0100 +++ b/dillorc Mon Mar 09 17:42:04 2009 +0100 @@ -223,6 +223,8 @@ # (Such as "TAB character inside <PRE>"). #show_extra_warnings=NO +# Finger panning for embedded devices +#easy_panning=NO # ----------------------------------------------------------------------- # dillorc ends here. diff -r 78c0fa261c84 -r 46c62dde8967 dw/fltkviewport.cc --- a/dw/fltkviewport.cc Mon Mar 09 17:21:32 2009 +0100 +++ b/dw/fltkviewport.cc Mon Mar 09 17:42:04 2009 +0100 @@ -1,3 +1,4 @@ + /* * Dillo Widget * @@ -59,6 +60,8 @@ gadgets = new container::typed::List <object::TypedPointer < ::fltk::Widget> > (true); + + easyPanning = 0; } FltkViewport::~FltkViewport () @@ -140,6 +143,18 @@ scroll (0, vscrollbar->value () - scrollY); } +void FltkViewport::setEasyPanning(int value) +{ + easyPanning = value; + if (easyPanning) { + hscrollbar->hide(); + vscrollbar->hide(); + } else { + hscrollbar->show(); + vscrollbar->show(); + } +} + void FltkViewport::vscrollbarCallback (Widget *vscrollbar, void *viewportPtr) { ((FltkViewport*)viewportPtr)->vscrollbarChanged (); @@ -235,8 +250,9 @@ case ::fltk::PUSH: take_focus(); - if (::fltk::event_button() == ::fltk::MiddleButton) { - /* pass event so that middle click can open link in new window */ + if (::fltk::event_button() == ::fltk::MiddleButton || + (easyPanning && ::fltk::event_button() == ::fltk::LeftButton)) { + /* pass event so that the click can interact with any widgets */ if (FltkWidgetView::handle (event) == 0) { dragScrolling = 1; dragX = ::fltk::event_x(); @@ -248,7 +264,8 @@ break; case ::fltk::DRAG: - if (::fltk::event_button() == ::fltk::MiddleButton) { + if (::fltk::event_button() == ::fltk::MiddleButton || + (easyPanning && ::fltk::event_button() == ::fltk::LeftButton)) { if (dragScrolling) { scroll(dragX - ::fltk::event_x(), dragY - ::fltk::event_y()); dragX = ::fltk::event_x(); @@ -263,7 +280,8 @@ break; case ::fltk::RELEASE: - if (::fltk::event_button() == ::fltk::MiddleButton) { + if (::fltk::event_button() == ::fltk::MiddleButton || + (easyPanning && ::fltk::event_button() == ::fltk::LeftButton)) { dragScrolling = 0; setCursor (core::style::CURSOR_DEFAULT); } diff -r 78c0fa261c84 -r 46c62dde8967 dw/fltkviewport.hh --- a/dw/fltkviewport.hh Mon Mar 09 17:21:32 2009 +0100 +++ b/dw/fltkviewport.hh Mon Mar 09 17:42:04 2009 +0100 @@ -21,7 +21,7 @@ int scrollX, scrollY; int scrollDX, scrollDY; - int dragScrolling, dragX, dragY; + int easyPanning, dragScrolling, dragX, dragY; ::fltk::Scrollbar *vscrollbar, *hscrollbar; @@ -68,6 +68,7 @@ void setGadgetOrientation (bool hscrollbarVisible, bool vscrollbarVisible, GadgetOrientation gadgetOrientation); void addGadget (::fltk::Widget *gadget); + void setEasyPanning(int value); }; } // namespace fltk diff -r 78c0fa261c84 -r 46c62dde8967 dw/selection.cc --- a/dw/selection.cc Mon Mar 09 17:21:32 2009 +0100 +++ b/dw/selection.cc Mon Mar 09 17:42:04 2009 +0100 @@ -141,7 +141,7 @@ } } else { // normal selection handling - if (event && event->button == 1) { + if (event && event->button == 1 && event->numPressed == 2) { highlight (false, 0); resetSelection (); diff -r 78c0fa261c84 -r 46c62dde8967 src/prefs.c --- a/src/prefs.c Mon Mar 09 17:21:32 2009 +0100 +++ b/src/prefs.c Mon Mar 09 17:42:04 2009 +0100 @@ -153,6 +153,7 @@ { "allow_white_bg", &prefs.allow_white_bg, PREFS_BOOL }, { "buffered_drawing", &prefs.buffered_drawing, PREFS_INT32 }, { "contrast_visited_color", &prefs.contrast_visited_color, PREFS_BOOL }, + { "easy_panning", &prefs.easy_panning, PREFS_BOOL }, { "enterpress_forces_submit", &prefs.enterpress_forces_submit, PREFS_BOOL }, { "focus_new_tab", &prefs.focus_new_tab, PREFS_BOOL }, { "font_cursive", &prefs.font_cursive, PREFS_STRING }, diff -r 78c0fa261c84 -r 46c62dde8967 src/prefs.h --- a/src/prefs.h Mon Mar 09 17:21:32 2009 +0100 +++ b/src/prefs.h Mon Mar 09 17:42:04 2009 +0100 @@ -71,6 +71,7 @@ bool_t show_msg; bool_t show_extra_warnings; bool_t middle_click_drags_page; + bool_t easy_panning; }; /* Global Data */ diff -r 78c0fa261c84 -r 46c62dde8967 src/uicmd.cc --- a/src/uicmd.cc Mon Mar 09 17:21:32 2009 +0100 +++ b/src/uicmd.cc Mon Mar 09 17:42:04 2009 +0100 @@ -427,6 +427,10 @@ Layout *layout = new Layout (platform); FltkViewport *viewport = new FltkViewport (0, 0, 1, 1); + if (prefs.easy_panning) { + viewport->setEasyPanning (true); + fprintf(stderr, "easy panning enabled"); + } if (prefs.buffered_drawing == 1) viewport->setBufferedDrawing (true); else

March 9, 2009

Holiday week

by corvid＠lavabit.com

Jorge wrote: > [ ] "-fno-rtti -fno-exceptions" gcc: 64KB less. > Enabling this switches reduces the binary size. Is there more to this than the following:

March 9, 2009

[patch]: remove the BW_* flags

by onepoint＠starurchin.org

a_Bw_stop_clients() is always called with the BW_Root and BW_Img flags set, so we can remove those flags. That leaves only the BW_Force flag, so we can remove that too and change the flags argument to a boolean that indicates whether to force. Regards, Jeremy Henty

March 7, 2009

Server-side CSS detection?

by Johannes.Hofmann＠gmx.de

Hi Richard, On Sat, Mar 07, 2009 at 01:13:11AM +0000, Richard Neill wrote: > Dear All, > > I've just joined this list, so I hope I'm posting this in the right place. > > I'm a webmaster, and I want to make sure that my site works properly in > all browsers including dillo. However, some of the new code (*) in my > site relies on CSS properties such as display:none and does not > gracefully degrade. > > If a browser has no CSS support, the newest stuff breaks in a very ugly > manner, whereas most of the CSS I've written to date fails gracefully > (we don't really care if some text-colour is wrong). > > So my question is, how can I detect CSS support server-side? > I don't need to know precise details of the CSS-support; I just want a > simple yes/no. So Netscape 4.6 would be "yes", whereas Dillo 0.8, and > links/lynx/w3m/googlebot would be "no". > > I don't want to do it by user-agent sniffing, and, if at all possible, I > don't want to rely on javascript (there are plenty of people who have > CSS-capable browsers with JS turned off). > > I've had no luck from google, so I thought I'd ask here, as you'll know > the best way to do this. I don't think there is a way to detect CSS support other than checking the reported user agent, as CSS only changes the appearance on the client side. However dillo is currently getting some initial CSS support, so for dillo this problem may just disappear in the future. Regards, Johannes

March 7, 2009

Server-side CSS detection?

by rn214＠cam.ac.uk

Dear All, I've just joined this list, so I hope I'm posting this in the right place. I'm a webmaster, and I want to make sure that my site works properly in all browsers including dillo. However, some of the new code (*) in my site relies on CSS properties such as display:none and does not gracefully degrade. If a browser has no CSS support, the newest stuff breaks in a very ugly manner, whereas most of the CSS I've written to date fails gracefully (we don't really care if some text-colour is wrong). So my question is, how can I detect CSS support server-side? I don't need to know precise details of the CSS-support; I just want a simple yes/no. So Netscape 4.6 would be "yes", whereas Dillo 0.8, and links/lynx/w3m/googlebot would be "no". I don't want to do it by user-agent sniffing, and, if at all possible, I don't want to rely on javascript (there are plenty of people who have CSS-capable browsers with JS turned off). I've had no luck from google, so I thought I'd ask here, as you'll know the best way to do this. Thank you for your help, Regards, Richard (*) for example, I display HTML tooltips like this: span.tool { position: relative; cursor: help; } span.tool span.tip { display: none;} span.tool:hover span.tip { display: block; z-index: 100; position: absolute; top: 1.6em; left: 0; width: auto; padding: 6px; border: #F00;} <span class='tool'>this is the link <span class='tip'>Here is some <b>html</b> for the tooltip </span> </span> i.e. the tool.tip is normally hidden by display:none, but is displayed as result of the hover action. If a browser doesn't support the CSS display:none property, that will render in a very ugly way, with the tooltip contents displayed inline. So I want to have a way to fall-back (server-side) to: <span title='this is the tooltip, without html'>this is the link </span> My intention is to do this server-side, using a session-variable after testing whether the client supports CSS. But how?

March 7, 2009

[patch]: typo fix

by Johannes.Hofmann＠gmx.de

On Fri, Mar 06, 2009 at 06:55:16PM +0000, Jeremy Henty wrote: > > Nothing else to say, really. Attached. Committed.

March 6, 2009

Css_next_token() bug

by Johannes.Hofmann＠gmx.de

On Fri, Mar 06, 2009 at 05:57:09PM +0000, corvid wrote: > Johannes wrote: > > can someone (corvid?) please have a look at attached patch that > > fixes a bug in Css_next_token() (at least I think so). > > > > Consider: > > > > <div style="font-family: '\''; background-color: red;">foo bar</div> > > > > In firefox the background is red, in current dillo not, because the > > string '\'' is not parsed properly. > > As I'm still uncertain whether to go the re2c way (there the problem > > does not exist), I'd like to have this fixed in the standard version. > > However as the code is pretty subtle it would be nice if someone > > could have a look. > > It seems right to me. Thanks! Committed.

March 6, 2009

[patch]: typo fix

by onepoint＠starurchin.org

Nothing else to say, really. Attached. Regards, Jeremy Henty

March 6, 2009

Css_next_token() bug

by corvid＠lavabit.com

Johannes wrote: > can someone (corvid?) please have a look at attached patch that > fixes a bug in Css_next_token() (at least I think so). > > Consider: > > <div style="font-family: '\''; background-color: red;">foo bar</div> > > In firefox the background is red, in current dillo not, because the > string '\'' is not parsed properly. > As I'm still uncertain whether to go the re2c way (there the problem > does not exist), I'd like to have this fixed in the standard version. > However as the code is pretty subtle it would be nice if someone > could have a look. It seems right to me.

March 6, 2009

Css_next_token() bug

by Johannes.Hofmann＠gmx.de

Hi, can someone (corvid?) please have a look at attached patch that fixes a bug in Css_next_token() (at least I think so). Consider: <div style="font-family: '\''; background-color: red;">foo bar</div> In firefox the background is red, in current dillo not, because the string '\'' is not parsed properly. As I'm still uncertain whether to go the re2c way (there the problem does not exist), I'd like to have this fixed in the standard version. However as the code is pretty subtle it would be nice if someone could have a look. Cheers, Johannes

March 6, 2009

allow_white_bg and contrast_visited_color

by Johannes.Hofmann＠gmx.de

On Thu, Mar 05, 2009 at 10:39:23PM +0000, corvid wrote: Committed. Thanks, Johannes

March 6, 2009

RFC: Dillo presentation

by furaisanjin＠gmail.com

2009/3/6 corvid <corvid(a)lavabit.com>: > furaisanjin wrote: >> 2009/3/5 Jorge Arellano Cid <jcid(a)dillo.org>: >> > ? ?- Low bandwidth requirement (very important in rural areas) >> >> Is there any plan to limit simultaneous HTTP connections? If the page >> contains lots of pictures, dillo generates simultaneous HTTP >> connections to fetch them and those occupy certain amount of >> bandwidth. > > Speaking of which, it would be nice to use Connection: Keep-Alive as > part of this. I agree. Major browsers support this feature. Regards, furaisanjin

March 6, 2009

allow_white_bg and contrast_visited_color

by Johannes.Hofmann＠gmx.de

On Thu, Mar 05, 2009 at 08:24:42PM +0000, corvid wrote: > Johannes wrote: > > standard_widget_colors: > > > > Not sure about this one. On the one hand I think that CSS support > > broke this. > > On the other hand CSS allows the page author to directly set colors > > of form widgets. > > corvid, can you please have a look? > > I see that non-form inputs get a background color if I put > html->styleEngine->inheritBackgroundColor () > in open_body. I thought I didn't need that for elements that > have a widget -- or is it different when the widget already exists? No, I think the problem is that fltk widgets are not transparent. So even if the parent widget has drawn the background properly, it won't shine through the fltk widgets. > > (and presumably I would just have to add another inheritBackgroundColor > in open_form...) I would rather suggest using styleEnginge::backgroundStyle() for non-transparent widgets. I haven't tested it though. To sum it up, inheritBackgroundColor() should be set if an element does not create a widget and therefore does not draw a background (e.g. <span>). backgroundStyle() can be used for widgets that need to have style->backgroundColor set to something non-NULL. Cheers, Johannes

March 5, 2009

allow_white_bg and contrast_visited_color

by corvid＠lavabit.com

Johannes wrote: > standard_widget_colors: > > Not sure about this one. On the one hand I think that CSS support > broke this. > On the other hand CSS allows the page author to directly set colors > of form widgets. > corvid, can you please have a look? I see that non-form inputs get a background color if I put html->styleEngine->inheritBackgroundColor () in open_body. I thought I didn't need that for elements that have a widget -- or is it different when the widget already exists? (and presumably I would just have to add another inheritBackgroundColor in open_form...)

March 5, 2009

clipping image inputs

by corvid＠lavabit.com

Johannes wrote: > On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > > With > > > > <input type="image" name="name1" src="whatever" > > WIDTH="80" HEIGHT="14" > > alt="name1name1name1name1"> > > <input type="image" name="name2" src="whatever" > > width="9" height="14" > > alt="name2name2name2name2"> > > > > the long alt text doesn't clip. > > It looks like the embed knows that it's 80 pixels wide > > (at least the child widget area stuff in Textblock::drawLine > > seemed to have the right idea), > > but the image thinks it's 188 (in my case). > > Can you please test attached patch? Not sure if it covers all > related cases, but for me it fixes the above example. Seems to be working for me, too. Thanks...

March 5, 2009

allow_white_bg and contrast_visited_color

by Johannes.Hofmann＠gmx.de

Hi, as we seem to have agreed on using CSS for style customization intead of dillorc settings, I'm trying to get rid of these: link_color: visited_color: text_color: bg_color: force_my_colors: The same thing can more or less be expressed with a custom user stylesheet, so I want to remove them. The problem is non-HTML pages (plain). I would propose to simulate <body><pre> in this case and use the corresponding style. allow_white_bg: This can't be expressed with CSS. We could detect a white background in StyleEngine (like we detect font sizes smaller than font_min_size), but what color should we use instead in this case (note that it must be different enough from the text color)? contrast_visited_color: This one is hard. Consider we want to render a visited link. >From StyleEngine we get a background and a text color, but we don't know what the text color would have been if the link would not be visited. So we can't enforce a color that is different from that. Generally (and even more with CSS), background- and text-colors can change arbitrarily within a page. So there is not a background and a text color per page. standard_widget_colors: Not sure about this one. On the one hand I think that CSS support broke this. On the other hand CSS allows the page author to directly set colors of form widgets. corvid, can you please have a look? Cheers, Johannes

March 5, 2009

clipping image inputs

by Johannes.Hofmann＠gmx.de

On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > With > > <input type="image" name="name1" src="whatever" > WIDTH="80" HEIGHT="14" > alt="name1name1name1name1"> > <input type="image" name="name2" src="whatever" > width="9" height="14" > alt="name2name2name2name2"> > > the long alt text doesn't clip. > It looks like the embed knows that it's 80 pixels wide > (at least the child widget area stuff in Textblock::drawLine > seemed to have the right idea), > but the image thinks it's 188 (in my case). Can you please test attached patch? Not sure if it covers all related cases, but for me it fixes the above example. Cheers, Johannes

March 5, 2009

RFC: Dillo presentation

by corvid＠lavabit.com

furaisanjin wrote: > 2009/3/5 Jorge Arellano Cid <jcid(a)dillo.org>: > > ? ?- Low bandwidth requirement (very important in rural areas) > > Is there any plan to limit simultaneous HTTP connections? If the page > contains lots of pictures, dillo generates simultaneous HTTP > connections to fetch them and those occupy certain amount of > bandwidth. Speaking of which, it would be nice to use Connection: Keep-Alive as part of this.

March 5, 2009

clipping image inputs

by Johannes.Hofmann＠gmx.de

On Thu, Mar 05, 2009 at 12:03:48AM +0000, corvid wrote: > Johannes wrote: > > On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > > > With > > > > > > <input type="image" name="name1" src="whatever" > > > WIDTH="80" HEIGHT="14" > > > alt="name1name1name1name1"> > > > <input type="image" name="name2" src="whatever" > > > width="9" height="14" > > > alt="name2name2name2name2"> > > > > > > the long alt text doesn't clip. > > > It looks like the embed knows that it's 80 pixels wide > > > (at least the child widget area stuff in Textblock::drawLine > > > seemed to have the right idea), > > > but the image thinks it's 188 (in my case). > > > > > > > > > PS I have "white-space: nowrap" pretty much working, > > > but I don't know what I'm doing in Textblock very well, > > > so it's definitely not going into this release. > > > > Can you explain the issue your are working on? At least > > > > <div style="white-space: nowrap">foo bar foo bar foo bar</div> > > > > seems to work already (the line is not wrapped). > > First I noticed that the boxes at the bottoms of the pages about > web browser stuff in en.wikipedia weren't wrapping (including > Dillo's page) because they go <..nowrap>...</span> <span..nowrap>...</span> > and it wasn't taking spaceStyle->whiteSpace into account. > Not handling its own wikipedia page well is sort of unfortunate. > > and then I found that if you have a line that goes: > some normal text <span ...nowrap>really really long stretch of nowrap</span>, > it wouldn't break before the span. I see.

March 5, 2009

improving CSS performance

by Johannes.Hofmann＠gmx.de

Hi, I just commited http://hg.dillo.org/dillo?cs=11c6f887d649 which improves CSS performance by avoiding unnecessary style computations. Please give it a thorough testing. Cheers, Johannes

March 5, 2009

RFC: Dillo presentation

by furaisanjin＠gmail.com

Hi, 2009/3/5 Jorge Arellano Cid <jcid(a)dillo.org>: > ? ?- Low bandwidth requirement (very important in rural areas) Is there any plan to limit simultaneous HTTP connections? If the page contains lots of pictures, dillo generates simultaneous HTTP connections to fetch them and those occupy certain amount of bandwidth. Regards, furaisanjin

March 5, 2009

RFC: Dillo presentation

by onepoint＠starurchin.org

Many thanks, Jorge! Updated checklist attached. Regards, Jeremy Henty

March 5, 2009

clipping image inputs

by corvid＠lavabit.com

Johannes wrote: > On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > > With > > > > <input type="image" name="name1" src="whatever" > > WIDTH="80" HEIGHT="14" > > alt="name1name1name1name1"> > > <input type="image" name="name2" src="whatever" > > width="9" height="14" > > alt="name2name2name2name2"> > > > > the long alt text doesn't clip. > > It looks like the embed knows that it's 80 pixels wide > > (at least the child widget area stuff in Textblock::drawLine > > seemed to have the right idea), > > but the image thinks it's 188 (in my case). > > > > > > PS I have "white-space: nowrap" pretty much working, > > but I don't know what I'm doing in Textblock very well, > > so it's definitely not going into this release. > > Can you explain the issue your are working on? At least > > <div style="white-space: nowrap">foo bar foo bar foo bar</div> > > seems to work already (the line is not wrapped). First I noticed that the boxes at the bottoms of the pages about web browser stuff in en.wikipedia weren't wrapping (including Dillo's page) because they go <..nowrap>...</span> <span..nowrap>...</span> and it wasn't taking spaceStyle->whiteSpace into account. Not handling its own wikipedia page well is sort of unfortunate. and then I found that if you have a line that goes: some normal text <span ...nowrap>really really long stretch of nowrap</span>, it wouldn't break before the span. There may be other cases as well.

March 5, 2009

clipping image inputs

by Johannes.Hofmann＠gmx.de

On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > With > > <input type="image" name="name1" src="whatever" > WIDTH="80" HEIGHT="14" > alt="name1name1name1name1"> > <input type="image" name="name2" src="whatever" > width="9" height="14" > alt="name2name2name2name2"> > > the long alt text doesn't clip. > It looks like the embed knows that it's 80 pixels wide > (at least the child widget area stuff in Textblock::drawLine > seemed to have the right idea), > but the image thinks it's 188 (in my case). > > > PS I have "white-space: nowrap" pretty much working, > but I don't know what I'm doing in Textblock very well, > so it's definitely not going into this release. Can you explain the issue your are working on? At least <div style="white-space: nowrap">foo bar foo bar foo bar</div> seems to work already (the line is not wrapped). Cheers, Johannes

March 4, 2009

clipping image inputs

by corvid＠lavabit.com

With <input type="image" name="name1" src="whatever" WIDTH="80" HEIGHT="14" alt="name1name1name1name1"> <input type="image" name="name2" src="whatever" width="9" height="14" alt="name2name2name2name2"> the long alt text doesn't clip. It looks like the embed knows that it's 80 pixels wide (at least the child widget area stuff in Textblock::drawLine seemed to have the right idea), but the image thinks it's 188 (in my case). PS I have "white-space: nowrap" pretty much working, but I don't know what I'm doing in Textblock very well, so it's definitely not going into this release.

March 4, 2009

RFC: Dillo presentation

by jcid＠dillo.org

Hi Jeremy, On Tue, Mar 03, 2009 at 08:36:59PM +0000, Jeremy Henty wrote: > > I have agreed to give presentation on Dillo to my local Linux Users > Group this Thursday. Naturally I'm leaving it until the last minute > to write anything! :-) I am attaching my crib list of essential points > to cover. > > My aim is to give a very short talk covering > > * project goals > * history (Dillo-1, Dillo-2.0, Dillo-2.1, soon) > * development model > * supported features > * architecture (DPI, Dw) > * future > > I'd very much appreciate any comments people have, particularly if you > think there's anything important I have missed out. This is your > chance to tell me what to tell them. (Just bear in mind that I aim to > be brief, so I can't go into large amounts of detail.) OK, here go mine. > > Dillo > > Fast, light, graphical browser. (stats?) > > No dependencies on heavyweight desktop environments. ... and you can statically link FLTK2. > Used in many lightweight distros. > One of the big names in this niche. > > Aims to democratise data. Data access: - Low HW requirement - Low bandwidth requirement (very important in rural areas) - Encourages standards (very important to be able to display the data). and privacy. > History > > Dillo-1 > C, Gtk-1 > developed internally > Developers attempted to find funding, failed > stalled Not really developed internally. It was always an open project. Some patches didn't get in though. Stalled when we realized GTK1 was a dead end. > Dillo-2 > Ported to FLTK-2 (GTK-2 is too bulky) > Development opened up > Dillo-2.0 This one was developed internally (Sebastian and I), and opened later for all to see. The idea was to attract more developers, and to let it evolve from there (very good documentation for developers was included). You can find a good summary in its splash page: "Our users will surely enjoy this new release as it will give them the same things they're accustomed plus tabbed browsing, antialiasing, different character sets, accepting compressed pages, control over image loading, smaller footprint, fewer dependencies, better table rendering, bugfixes, improved GUI, ... In brief, a better dillo." > > Dillo-2.1 (coming soon) - CSS (fonts and colours) Now we have more developers too! > VCS, originally CVS, now Mercurial > > DPI architecture (so Dillo is really a suite of programs) > - implements https, cookies Future: * It'd be great to have dillo included as a help browser in the main distros (e.g. Debian). Do you remember the times when applications came with a help button that popped information on how to use the program? There were even context-sensitive help buttons. All that vanished with the bloated browser (no time and no memory to launch it, and to find it useful). Those times may be back; dillo can be launched in less than a second and its memory footprint is really small. It provides support for standard HTML documentation with images. An API for context sensitive help is simple to develop (its basically pushing a passed URL). * Improve rendering: especially floating objects and the already good-looking CSS. * Dillo with Framebuffer support. This can be very useful for embedded devices. * Improve functionality so more sites can be used quickly! (we all know the nice feel of a site that can be used with Dillo) -- Cheers Jorge.-

March 4, 2009

Holiday week

by jorl17.8＠gmail.com

S?b, 2009-02-21 ?s 11:47 -0300, Jorge Arellano Cid escreveu: > Hi there, > > I happen to be enjoying a much needed holiday week! :-) > > The plan is to come back around near wednesday 25. > > In the meanwhile, I leave you with the following issues lurking > in my list to be considered. Maybe all of them can be left to the > release after 2.1, but maybe not: > > [ ] https dialog bombing issue. BUG#868 > When enabled, multiple https requests to the same site result > in dialog bombing. The https dpi is disabled by default in > Dillo. Anyway, in Debian, there's a security warning against > dillo for not checking certificates (I don't know what > version of dillo they use, nor why they enable https.) > > [ ] Jump to #anchor doesn't work correctly. > The idle timeout doesn't work reliably (an old bug). > > [ ] Implement @import statement in STYLE element. > > [ ] What will we do with xhtml? FF doesn't validate. BUG#732 > This would be interesting to define. > (already suggested as discussion material in another thread). > > [ ] "-fno-rtti -fno-exceptions" gcc: 64KB less. > Enabling this switches reduces the binary size. > > [ ] dpi for "view page source" (it re-uses search capability). > Waiting since a long time... > > [-] BUG#892 prefs bg_color is not working > Johannes was working on related things... > > [ ] META refresh: "instant client-side redirect". > [ ] META refresh: URL='<URI>' case. > I plan to implement both when I'm back (and to include them > in dillo-2.1). > > BTW, I want to welcome Tim Nieradzik as a new developer and to > tell Joao that the bug in the find-text iterator is not that much > important. Just focus on something more urgent. > I'm glad you had fun! I have been quite away and felt like I had to explain my absence. It's exam period over here, exams coming from every direction and barely any time to program. The iterator bug seems to effectively be a bug in the way iterators treat whitespace, but I'm leaving that for later, right now I will try to use my time to focus on understanding dillo's internals to a deeper degree. Anyway, once I am fully free, I'll be sure to note that here. Good luck everyone, Jo?o P.S: And welcome Tim Nieradzik!

March 4, 2009

RFC: Dillo presentation

by onepoint＠starurchin.org

I have agreed to give presentation on Dillo to my local Linux Users Group this Thursday. Naturally I'm leaving it until the last minute to write anything! :-) I am attaching my crib list of essential points to cover. My aim is to give a very short talk covering * project goals * history (Dillo-1, Dillo-2.0, Dillo-2.1, soon) * development model * supported features * architecture (DPI, Dw) * future I'd very much appreciate any comments people have, particularly if you think there's anything important I have missed out. This is your chance to tell me what to tell them. (Just bear in mind that I aim to be brief, so I can't go into large amounts of detail.) Regards, Jeremy Henty

March 3, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Tue, Mar 03, 2009 at 08:34:09AM -0300, Jorge Arellano Cid wrote: > On Mon, Mar 02, 2009 at 09:54:43PM +0100, Hofmann Johannes wrote: > > On Mon, Mar 02, 2009 at 01:06:52PM -0300, Jorge Arellano Cid wrote: > > > On Sun, Mar 01, 2009 at 12:31:18PM +0100, Hofmann Johannes wrote: > > > > On Sat, Feb 28, 2009 at 12:22:32AM +0100, Hofmann Johannes wrote: > > > > > On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > > > > > > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > > > > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > > > > > > could not find a reasonable solution... > > > > > > > > > > > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > > > > > > for negative numbers... > > > > > > > > > > > > > > > > Exactly. I started my simplification attempts, added negative number > > > > > > > > support - and blew it all up :) > > > > > > > > I'm really considering a flex based scanner now. What do you think? > > > > > > > > > > > > > > I only touched flex very briefly for a class at school long ago, > > > > > > > and I don't remember anything from the experience, but the > > > > > > > idea interests me since it has to be less trouble than trying > > > > > > > to do it by hand... > > > > > > > > > > > > > > > > > > > > > > > This turned out to be easier than expected. Attached patch adds a flex > > > > > based scanner for CSS data. > > > > > It's not optimized or polished but seems to work here. > > > > > > > > To make reviewing easier I created a repo for the flex experiment: > > > > http://freehg.org/u/dillo/flex/ > > > > I think the use of flex makes the code simpler and more > > > > maintainable. For some reason rendering is a bit different, e.g. on > > > > wikipedia.org maybe because negative numbers are supported. > > > > It would be nice if people could test it regarding the performance > > > > impact. > > > > > > > > What do you think. Is it worth to add the flex dependency? > > > > > > I'm a bit worried about the flex dependency. > > > > > > It's being a long time since I saw/used flex/bison/yacc & > > > friends. AFAIR, there was a myriad of slightly incompatible > > > flavours. > > > > > > It may be safer to generate a C-source parser with the tool, > > > and to include it as a source file. > > > > I'm currently checking re2c (http://re2c.org/) as a flex alternative > > and it looks pretty cool. It does not need a lib and produces > > pretty clean C code. So we might ship the generated code in the > > release tarballs. > > > > I'll post a prototype when I'm ready. > > Great. > C code looks like the more portable way to go. > > BTW, quoting from the description of Flex > ('aptitude show flex'): > > <q> > [...] > The behaviour of Flex has undergone a major change since version > 2.5.4a. Flex scanners are now reentrant, and it is now possible > to have multiple scanners in the same program with differing sets > of defaults, and the scanners play nicer with modern C and C++ > compilers. The Flip side is that Flex no longer conforms to the > POSIX lex behaviour, and the scanners require conforming > implementations when flex is used in ANSI C mode. The package > flex-old provides the older behaviour. > </q> > > OTOH, re2c looks like a suitable tool we may use in other areas > too. Go ahead! The re2c version now more or less works (escaped characters are not yet supported). You can find the code at http://freehg.org/u/dillo/flex/ Cheers, Johannes

March 3, 2009

Re: css parsing numbers

by jcid＠dillo.org

On Mon, Mar 02, 2009 at 09:54:43PM +0100, Hofmann Johannes wrote: > On Mon, Mar 02, 2009 at 01:06:52PM -0300, Jorge Arellano Cid wrote: > > On Sun, Mar 01, 2009 at 12:31:18PM +0100, Hofmann Johannes wrote: > > > On Sat, Feb 28, 2009 at 12:22:32AM +0100, Hofmann Johannes wrote: > > > > On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > > > > > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > > > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > > > > > could not find a reasonable solution... > > > > > > > > > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > > > > > for negative numbers... > > > > > > > > > > > > > > Exactly. I started my simplification attempts, added negative number > > > > > > > support - and blew it all up :) > > > > > > > I'm really considering a flex based scanner now. What do you think? > > > > > > > > > > > > I only touched flex very briefly for a class at school long ago, > > > > > > and I don't remember anything from the experience, but the > > > > > > idea interests me since it has to be less trouble than trying > > > > > > to do it by hand... > > > > > > > > > > > > > > > > > > > This turned out to be easier than expected. Attached patch adds a flex > > > > based scanner for CSS data. > > > > It's not optimized or polished but seems to work here. > > > > > > To make reviewing easier I created a repo for the flex experiment: > > > http://freehg.org/u/dillo/flex/ > > > I think the use of flex makes the code simpler and more > > > maintainable. For some reason rendering is a bit different, e.g. on > > > wikipedia.org maybe because negative numbers are supported. > > > It would be nice if people could test it regarding the performance > > > impact. > > > > > > What do you think. Is it worth to add the flex dependency? > > > > I'm a bit worried about the flex dependency. > > > > It's being a long time since I saw/used flex/bison/yacc & > > friends. AFAIR, there was a myriad of slightly incompatible > > flavours. > > > > It may be safer to generate a C-source parser with the tool, > > and to include it as a source file. > > I'm currently checking re2c (http://re2c.org/) as a flex alternative > and it looks pretty cool. It does not need a lib and produces > pretty clean C code. So we might ship the generated code in the > release tarballs. > > I'll post a prototype when I'm ready. Great. C code looks like the more portable way to go. BTW, quoting from the description of Flex ('aptitude show flex'): <q> [...] The behaviour of Flex has undergone a major change since version 2.5.4a. Flex scanners are now reentrant, and it is now possible to have multiple scanners in the same program with differing sets of defaults, and the scanners play nicer with modern C and C++ compilers. The Flip side is that Flex no longer conforms to the POSIX lex behaviour, and the scanners require conforming implementations when flex is used in ANSI C mode. The package flex-old provides the older behaviour. </q> OTOH, re2c looks like a suitable tool we may use in other areas too. Go ahead! -- Cheers Jorge.-

March 3, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Mon, Mar 02, 2009 at 01:06:52PM -0300, Jorge Arellano Cid wrote: > On Sun, Mar 01, 2009 at 12:31:18PM +0100, Hofmann Johannes wrote: > > On Sat, Feb 28, 2009 at 12:22:32AM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > > > > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > > > > could not find a reasonable solution... > > > > > > > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > > > > for negative numbers... > > > > > > > > > > > > Exactly. I started my simplification attempts, added negative number > > > > > > support - and blew it all up :) > > > > > > I'm really considering a flex based scanner now. What do you think? > > > > > > > > > > I only touched flex very briefly for a class at school long ago, > > > > > and I don't remember anything from the experience, but the > > > > > idea interests me since it has to be less trouble than trying > > > > > to do it by hand... > > > > > > > > > > > > > > > This turned out to be easier than expected. Attached patch adds a flex > > > based scanner for CSS data. > > > It's not optimized or polished but seems to work here. > > > > To make reviewing easier I created a repo for the flex experiment: > > http://freehg.org/u/dillo/flex/ > > I think the use of flex makes the code simpler and more > > maintainable. For some reason rendering is a bit different, e.g. on > > wikipedia.org maybe because negative numbers are supported. > > It would be nice if people could test it regarding the performance > > impact. > > > > What do you think. Is it worth to add the flex dependency? > > I'm a bit worried about the flex dependency. > > It's being a long time since I saw/used flex/bison/yacc & > friends. AFAIR, there was a myriad of slightly incompatible > flavours. > > It may be safer to generate a C-source parser with the tool, > and to include it as a source file. I'm currently checking re2c (http://re2c.org/) as a flex alternative and it looks pretty cool. It does not need a lib and produces pretty clean C code. So we might ship the generated code in the release tarballs. I'll post a prototype when I'm ready. Cheers, Johannes

March 2, 2009

minor leak with CustShrinkTabPager

by jcid＠dillo.org

On Mon, Mar 02, 2009 at 09:02:18AM +0100, Hofmann Johannes wrote: > Hi, > > thanks to Jeremy's valgrind log at > http://starurchin.org/dillo/valgrind.html > I noticed a minor leak with CustShrinkTabPager(). > > The TabGroup::pager() method internally clones the passed pager, so > it must be deleted afterwards, e.g. like this: > [...] Committed. -- Cheers Jorge.-

March 2, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Mon, Mar 02, 2009 at 01:06:52PM -0300, Jorge Arellano Cid wrote: > On Sun, Mar 01, 2009 at 12:31:18PM +0100, Hofmann Johannes wrote: > > On Sat, Feb 28, 2009 at 12:22:32AM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > > > > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > > > > could not find a reasonable solution... > > > > > > > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > > > > for negative numbers... > > > > > > > > > > > > Exactly. I started my simplification attempts, added negative number > > > > > > support - and blew it all up :) > > > > > > I'm really considering a flex based scanner now. What do you think? > > > > > > > > > > I only touched flex very briefly for a class at school long ago, > > > > > and I don't remember anything from the experience, but the > > > > > idea interests me since it has to be less trouble than trying > > > > > to do it by hand... > > > > > > > > > > > > > > > This turned out to be easier than expected. Attached patch adds a flex > > > based scanner for CSS data. > > > It's not optimized or polished but seems to work here. > > > > To make reviewing easier I created a repo for the flex experiment: > > http://freehg.org/u/dillo/flex/ > > I think the use of flex makes the code simpler and more > > maintainable. For some reason rendering is a bit different, e.g. on > > wikipedia.org maybe because negative numbers are supported. > > It would be nice if people could test it regarding the performance > > impact. > > > > What do you think. Is it worth to add the flex dependency? > > I'm a bit worried about the flex dependency. > > It's being a long time since I saw/used flex/bison/yacc & > friends. AFAIR, there was a myriad of slightly incompatible > flavours. I think what the patch uses is pretty standard and automake takes care of the detection and correct parameters. > > It may be safer to generate a C-source parser with the tool, > and to include it as a source file. The problem is that we also need to (statically) link libfl.a, so we actually need lex/flex installed on the build system. > > AFAIU the patch feeds a CSS grammar to libflex, and it acts as > an interpreter that parses. In it's current form only the scanner/tokenizer is replaced by a flex-generated one. The parsing is still done using the hand-written code. > > You should consider the performance, the complexity (against > tunning our current parser), and if the dependency can be > avoided. > Until recently Css_next_token() was small and simple enough so that it was certainly not worth the additional dependency. However even adding support for floats that start with '.' increased it's complexity. Next is negative numbers, urls and maybe more. Does anyone know whether there are still compatibility/integration issues with flex on exotic platforms? Cheers, Johannes

March 2, 2009

[bgreer101@earthlink.net: Dillo2 working great with Crux-PPC!]

by jcid＠dillo.org

-- Cheers Jorge.-

March 2, 2009

Re: css parsing numbers

by jcid＠dillo.org

On Sun, Mar 01, 2009 at 12:31:18PM +0100, Hofmann Johannes wrote: > On Sat, Feb 28, 2009 at 12:22:32AM +0100, Hofmann Johannes wrote: > > On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > > > could not find a reasonable solution... > > > > > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > > > for negative numbers... > > > > > > > > > > Exactly. I started my simplification attempts, added negative number > > > > > support - and blew it all up :) > > > > > I'm really considering a flex based scanner now. What do you think? > > > > > > > > I only touched flex very briefly for a class at school long ago, > > > > and I don't remember anything from the experience, but the > > > > idea interests me since it has to be less trouble than trying > > > > to do it by hand... > > > > > > > > > > > This turned out to be easier than expected. Attached patch adds a flex > > based scanner for CSS data. > > It's not optimized or polished but seems to work here. > > To make reviewing easier I created a repo for the flex experiment: > http://freehg.org/u/dillo/flex/ > I think the use of flex makes the code simpler and more > maintainable. For some reason rendering is a bit different, e.g. on > wikipedia.org maybe because negative numbers are supported. > It would be nice if people could test it regarding the performance > impact. > > What do you think. Is it worth to add the flex dependency? I'm a bit worried about the flex dependency. It's being a long time since I saw/used flex/bison/yacc & friends. AFAIR, there was a myriad of slightly incompatible flavours. It may be safer to generate a C-source parser with the tool, and to include it as a source file. AFAIU the patch feeds a CSS grammar to libflex, and it acts as an interpreter that parses. You should consider the performance, the complexity (against tunning our current parser), and if the dependency can be avoided. -- Cheers Jorge.-

March 2, 2009

[PATCH] Replace the FSF Address in GPL v3 files [try 2]

by jcid＠dillo.org

On Wed, Feb 25, 2009 at 05:39:13PM +0100, Detlef Riekenberg wrote: > The license notice in GPL v3 source files use an outdated FSF Address. > This version use the suggestions from Place (corvid) Good! Committed. > Things to do: > dw/fltkcomplexbutton.hh: GNU Library General Public License v2 (or > later) > dw/fltkcomplexbutton.cc: GNU Library General Public License v3 (or > later) > Such licenses does not exits. > LGPL is GNU Lesser General Public License > > Some Files mention GPL v3, but the license Note is incomplete. > Some Files are missing a copyright / license Note OK, if you can submit a patch that addresses those problems, please do so. -- Cheers Jorge.-

March 2, 2009

[patch]: remove the workaround for FLTK bug #2084.

by jcid＠dillo.org

On Fri, Feb 27, 2009 at 08:29:08PM +0000, Jeremy Henty wrote: > > The dillo source includes a workaround for FLTK bug #2084[1] which was > fixed in revision 6507. We currently recommend[2] revision 6525 or > later. There's no need to include this workaround any more, so let's > remove it. Committed. -- Cheers Jorge.-

March 2, 2009

minor leak with CustShrinkTabPager

by Johannes.Hofmann＠gmx.de

Hi, thanks to Jeremy's valgrind log at http://starurchin.org/dillo/valgrind.html I noticed a minor leak with CustShrinkTabPager(). The TabGroup::pager() method internally clones the passed pager, so it must be deleted afterwards, e.g. like this: diff -r 9b0b8ae9b06a src/uicmd.cc --- a/src/uicmd.ccSun Mar 01 12:34:00 2009 +0100 +++ b/src/uicmd.ccMon Mar 02 08:57:02 2009 +0100 @@ -225,7 +225,9 @@ public: CustTabGroup (int x, int y, int ww, int wh, const char *lbl=0) : TabGroup(x,y,ww,wh,lbl) { - this->pager(new CustShrinkTabPager()); + CustShrinkTabPager *cp = new CustShrinkTabPager(); + this->pager(cp); + delete cp; toolTip = new Tooltip; tooltipEnabled = false; buttonPushed = false; Alternatively we could keep one copy around in a static member. Cheers, Johannes

March 2, 2009

[patch]: fix a memory leak in a_Klist_free()

by jcid＠dillo.org

On Sat, Feb 28, 2009 at 06:54:36PM +0000, Jeremy Henty wrote: > > Subject line speaks for itself! Patch attached. Committed. -- Cheers Jorge.-

March 2, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

Hi there, > [Tim wrote] > It took longer to write this patch than I expected. You will find it > in the attachment but I do not recommend using it before somebody > else has verified it (I am new to C/C++). It's great to see this much needed feature in the process of making its way into the source tree! :) After cosidering the raised issues, I believe it'd be good to make our next release (2.1), with what we have in the repo (plus bug fixes) and to leave the new stuff for 2.2. That allows time to polish and test. Here go my comments. > [Corvid wrote] > - I haven't looked at this in any detail yet -- this is just my > paging-through-the-patch response -- but I notice a_Nav_push_forced > in there. Patches should be kept separate. The smaller they are, > the better for review. > > - Lines should not be longer than 79 chars. Fully agreed. > [Corvid wrote] > I lean toward not adding features to this patch yet. > > (Continuing to add features before getting anything into the > tree caused dillo not to get frames support, and that was > an unfortunate incident all around.) Very good advice. I'd like to have the bare functionality merged first, and to improve on that basis when necessary. BTW, if Corvid agrees, I'd like him to be your adviser on preparing this patch until he sends me something for an inclusion review. > [Tim wrote] > I had to re-implement the parsing routine. This is mainly because a > new line format was introduced which allows you to configure key > bindings in your dillorc. Otherwise we would have needed > unnecessarily a second file. This is the only thing that changes for > the user. The new format looks like this: "set option value" > [Tim wrote] > The downside of this patch is that currently there is an issue with > the line parser, which claims to find syntax errors even though the > lines look alright for me. This needs to be fixed before this patch > can go into mainline. > [Diego wrote] > I disagree about changing the dillorc format: > > - This change is not backwards compatible. Do not read old dillorc > format and it is a big inconvenience for users. > [Diego wrote] > - There are compatible ways to add this preferences (key_save = "...", > key_find = "CTRL + f", ...) > [Tim wrote] > Sure, but options were not initially thought of as being used for > key bindings. When using a special keyword which is only valid for > one preferences type (bindings), it is possible to add further > parameters such as groups (useful when having lots of key bindings). > The other advantage of this implementation is that we could easily > modify it to allow multiple key bindings for one symbol. > [Diego wrote] > - If the number of key bindings increase much another config file can > be convenient. With another config file some example files can be > suplied (vim keys, firefox keys, ...) and end user only need to copy > the prefered file. > [Corvid wrote] > That's a good point. This is an important issue. After giving it some tought, it looks like we can handle it like icewm and others (i.e. with multiple files for different configuration areas). BTW, this is already the case with style.css (CSS configuration file) and cookiesrc. We'd have: dillorc, style.css, keyboardrc and cookiesrc. In the future we may add others (e.g. addblock, read.css). This allows for backwards compatibility, easy separation of tasks, isolation/flexibility of configuration parsers and simple example configuration files for the user. BTW, dillorc has grown a long file to read, and will most probably end being managed by an external app. > [Corvid wrote] > - I'm sure that Jorge isn't going to want exception handling. Good guess! > [Tim wrote] > Why not? Exceptions are more flexible when it comes to longer and > more complicated functions. Of course, we could also return an > integer status code but sometimes it is necessary to return > non-integer values. We're using return codes and for the non-integer return value case we use a pointer argument. > [Johannes wrote] > I'm definately against adding exceptions. > If we would start a new project, we could discuss pros and cons of > using exceptions - I would probabely still vote against using them > in that case... > But as all current dillo code and also fltk does not use exceptions > it would get a real mess if parts of new code would start to > use exceptions for error handling while other code is using > return values. Right. Please modify the patch to use return codes. -- Cheers Jorge.-

March 1, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Sat, Feb 28, 2009 at 12:22:32AM +0100, Hofmann Johannes wrote: > On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > > could not find a reasonable solution... > > > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > > for negative numbers... > > > > > > > > Exactly. I started my simplification attempts, added negative number > > > > support - and blew it all up :) > > > > I'm really considering a flex based scanner now. What do you think? > > > > > > I only touched flex very briefly for a class at school long ago, > > > and I don't remember anything from the experience, but the > > > idea interests me since it has to be less trouble than trying > > > to do it by hand... > > > > > > > This turned out to be easier than expected. Attached patch adds a flex > based scanner for CSS data. > It's not optimized or polished but seems to work here. To make reviewing easier I created a repo for the flex experiment: http://freehg.org/u/dillo/flex/ I think the use of flex makes the code simpler and more maintainable. For some reason rendering is a bit different, e.g. on wikipedia.org maybe because negative numbers are supported. It would be nice if people could test it regarding the performance impact. What do you think. Is it worth to add the flex dependency? Cheers, Johannes

March 1, 2009

[patch]: fix a memory leak in a_Klist_free()

by onepoint＠starurchin.org

Subject line speaks for itself! Patch attached. Jeremy Henty

Feb. 28, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > could not find a reasonable solution... > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > for negative numbers... > > > > > > Exactly. I started my simplification attempts, added negative number > > > support - and blew it all up :) > > > I'm really considering a flex based scanner now. What do you think? > > > > I only touched flex very briefly for a class at school long ago, > > and I don't remember anything from the experience, but the > > idea interests me since it has to be less trouble than trying > > to do it by hand... > > > This turned out to be easier than expected. Attached patch adds a flex based scanner for CSS data. It's not optimized or polished but seems to work here. Cheers, Johannes

Feb. 28, 2009

[patch]: remove the workaround for FLTK bug #2084.

by onepoint＠starurchin.org

The dillo source includes a workaround for FLTK bug #2084[1] which was fixed in revision 6507. We currently recommend[2] revision 6525 or later. There's no need to include this workaround any more, so let's remove it. Regards, Jeremy Henty [1] http://www.fltk.org/str.php?L2084 [2] http://www.dillo.org/source.html

Feb. 27, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > could not find a reasonable solution... > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > for negative numbers... > > > > Exactly. I started my simplification attempts, added negative number > > support - and blew it all up :) > > I'm really considering a flex based scanner now. What do you think? > > I only touched flex very briefly for a class at school long ago, > and I don't remember anything from the experience, but the > idea interests me since it has to be less trouble than trying > to do it by hand... > I think we just need to try it. Attached is a minimal standalone example based on the "Lexical scanner" from the appendix of the CSS 2.1 spec. To compile it use: flex cssscanner.l gcc -o cssscanner lex.yy.c -lfl It reads from stdin. Cheers, Johannes

Feb. 27, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Thu, Feb 19, 2009 at 12:30:34AM +0000, corvid wrote: > Johannes wrote: > > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > > I tried > > > font-size: .6in > > > (we still love archaic measurements here) > > > and it didn't work. > > > > > > The grammar says > > > num [0-9]+|[0-9]*"."[0-9]+ > > > > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > > float... > > Attached. > > I'm too much of a css newbie to promise great testing, but I did cobble together > the following and the right things seemed to happen: > > <html> > <head> > <style type="text/css"> > hr.aaaaa {width: 1.5in} > bbbbb {width: 2 in} > </style> > </head> > <body> > <hr style="width: 0.3in"> > <hr style="width: .6in"> > <hr style="width: 1 in"> > <hr class="aaaaa"> > <hr class="bbbbb"> > </body > </html> Committed. I hoped to be able to make that code a bit shorter, but could not find a reasonable solution... Cheers, Johannes

Feb. 27, 2009

libDw_fltk_a-fltk*.o naming

by onepoint＠starurchin.org

On Tue, Feb 24, 2009 at 05:51:32PM +0000, corvid wrote: > Is there any reason not to shorten them to fltk*.o? Two I can think of: 1. The current names are correct: libDw_fltk_a-fltk*.o are the *.o files that are used to build libDw_fltk.a, which is the *.a file that implements Dw_fltk, which is the FLTK backend for Dw. 2. The current names are created by automake, so to change them you would have to delve into the guts of automake, which you don't want to do without a really good reason. I understand wanting to shorten bloated file names, but in this case I vote to leave well alone. Regards, Jeremy Henty

Feb. 26, 2009

[PATCH] Replace the FSF Address in GPL v3 files [try 2]

by wine.dev＠web.de

The license notice in GPL v3 source files use an outdated FSF Address. This version use the suggestions from Place (corvid) Things to do: dw/fltkcomplexbutton.hh: GNU Library General Public License v2 (or later) dw/fltkcomplexbutton.cc: GNU Library General Public License v3 (or later) Such licenses does not exits. LGPL is GNU Lesser General Public License Some Files mention GPL v3, but the license Note is incomplete. Some Files are missing a copyright / license Note -- By by ... Detlef

Feb. 25, 2009

[patch] Configurable key bindings

by Johannes.Hofmann＠gmx.de

Hi Tim, thanks for working on the keybinding feature! On Mon, Feb 23, 2009 at 08:17:13PM +0000, corvid wrote: > > Wow that was quick! > > - I personally am open to the idea of changing the dillorc format > for existing options, but we'll see what the consensus is. The proposed format looks like the muttrc format. I would not change dillorc to yet another arbitrary format, but if the muttrc style is commonly used - why not. How does vimrc compare to that btw? Would it be possible to make it backward compatible by interpreting [_a-Z0-9]+\s?= the same as if there was a "set " in front? > > - I haven't looked at this in any detail yet -- this is just my > paging-through-the-patch response -- but I notice a_Nav_push_forced > in there. Patches should be kept separate. The smaller they are, > the better for review. > > - Lines should not be longer than 79 chars. > > - I'm sure that Jorge isn't going to want exception handling. I'm definately against adding exceptions. If we would start a new project, we could discuss pros and cons of using exceptions - I would probabely still vote against using them in that case... But as all current dillo code and also fltk does not use exceptions it would get a real mess if parts of new code would start to use exceptions for error handling while other code is using return values. Cheers, Johannes > > I'll add something about that last point to the website, since > it's not mentioned currently. > > PS Are you sure that fltk doesn't allow modifiers to be combined? > Grepping through fltk/test, it looks like they're combining them > in menubar.cxx. > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 25, 2009