- Dillo-dev - lists.mailman3.com

[patch] fixup resizable of after tab removal

by Johannes.Hofmann＠gmx.de

Hi, I was seeing crashes when removing tabs. The reason is that when we accidentally remove and delete the resizable of the TabGroup, fltk still tries to access it. Attached patch fixes that. It also moves the hide/showLabel functionality into CustTabGroup. Cheers, Johannes

Sept. 19, 2008

Tabs!!!

by Johannes.Hofmann＠gmx.de

On Thu, Sep 18, 2008 at 11:22:24PM -0400, Jorge Arellano Cid wrote: > On Thu, Sep 18, 2008 at 05:39:43PM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Wed, Sep 17, 2008 at 06:14:58PM -0400, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > The tabs patch has grown to a quite usable state, so it was > > > committed for you to test. I know we're close to the release so > > > we can still rollback. It's just that I'd much like to have it in > > > the main tree before dillo2 goes out. > > > > > > The patch comes with several assorted cleanups and > > > normalizations. For instance: derived widgets now use the "Cust" > > > prefix instead of "New", the window->user_data() holds a pointer > > > to the current UI, and child widgets get it from there, etc. > > > > > > OK, so to the tabs... > > > > > > This implementation uses one UI per tab, and it's quite fast. > > > You can switch tabs with the mouse, Shift+{Left, Right} or > > > {Ctrl,Ctrl+Shift}+TAB. Use Ctrl+N, or middle click over a link to > > > open a new tab (just as it was with new windows). Ctrl+Q closes > > > the tab. > > > > > > The idea is that in the future the user can dillo2rc-choose > > > whether to use windows or tabs, and windows with tabs. > > > > Very nice! > > The whole tabs or the future dillo2rc idea? ;-) > The whole tabs. I'm not sure I understand the dillo2rc idea correctly (see below). > > > > > > > Some issues: > > > > > > 1.- Tab Tooltips are commented out because FLTK has problems > > > with them. > > > 2.- Shift+{Left, Right} work even when the location is focused. > > > In the latter case you may need to click the right key > > > twice for it to focus and work (don't know why, the Left > > > key works OK). > > > 3.- Currently there's no hidden tabs widget, when there's only > > > one tab (haven't even tried, it may be as simple as > > > hiding the group). > > > > Attached patch implements that. I don't like the global DilloTabs > > variable in uicmd.cc, but the static one > > a_UIcmd_browser_window_new() was not better. Perhaps DilloTabs > > should become member of some new class? > > Committed. > > The good thing of it being a simple variable is that no-tabs windows > is straightforward to implement. I'd say we should support multiple windows with one or more tabs each. In that case DilloTabs can not be a single global variable, as we need one tab widget per window. Cheers, Johannes

Sept. 19, 2008

[patch] switch to standard assert

by Johannes.Hofmann＠gmx.de

On Thu, Sep 18, 2008 at 11:03:32PM -0400, Jorge Arellano Cid wrote: > On Thu, Sep 18, 2008 at 06:29:33PM +0200, Johannes Hofmann wrote: > > On Wed, Sep 17, 2008 at 05:34:12PM -0400, Jorge Arellano Cid wrote: > > > On Wed, Sep 17, 2008 at 05:11:08PM +0200, Johannes Hofmann wrote: > > > > On Tue, Sep 16, 2008 at 09:21:45PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Tue, Sep 16, 2008 at 07:20:31PM +0000, corvid wrote: > > > > > > > Johannes wrote: > > > > > > > > On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > > > > > > > > > Turning off bounds checking for get and getRef does get rid of nearly > > > > > > > > > all of the assert()s, but I was just trying -Winline and discovered: > > > > > > > > > > > > > > > > > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > > > > > > > > > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > > > > > > > > > , ...)' can never be inlined because it uses variable argument lists > > > > > > > > > .. > > > > > > > > > > > > > > > > Ouch. A short grep shows that variable argument lists are not used > > > > > > > > (yet) in the code - just const strings. > > > > > > > > So we could change assert to use a const char* argument if I'm not > > > > > > > > missing something. > > > > > > > > > > > > > > For me, grep shows > > > > > > > layout.cc: misc::assert (anchor, "anchor '%s' not defined", name); > > > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > > > > > > > > > > > > > > Must have missed these... > > > > > > In that case we could get away with something as in attached patch, > > > > > > but we should also consider to just switch to standard assert(). > > > > > > At the moment I would actually prefer the latter. > > > > > > What do others think? > > > > > > > > > > Standard assert() sounds fine to me. > > > > > > > > > > > > > Ok. Here comes the patch. > > > > It also adds a missing check for negative values in SimpleVector > > > > methods. > > > > > > Does this patch show any performance improvement? > > > > > > If it does and has no portability problems, I'm for it too. > > > > > > > I've checked the major BSDs and Linux seems to be fine too. > > According to http://en.wikipedia.org/wiki/C_standard_library it's > > part of the ANSI C library header and was introduced with C99. > > The same holds for stdint.h btw. for which we introduced some macro > > stuff in style.hh. > > I think we should simply rely on C99 compatible headers and include > > those without any conditionals. > > OK, let's try... > > - Assert patch committed. > - Conditional switched to just include stdint.h. > - fail() function removed. Great. I will fix things if this breaks something ;-) Cheers, Johannes

Sept. 19, 2008

Confused by the comment to CustInput::handle()

by jcid＠dillo.org

On Thu, Sep 18, 2008 at 06:01:51AM +0100, Jeremy Henty wrote: > > In dillo2/src/ui.cc, CustInput::handle() has a comment saying that it > disables CTRL+{o,r,HomeKey,EndKey}, yet it only seems to disable > CTRL+o . I think CTRL+r used to be disabled too, so that CTRL+r would > reload the page even if the URL widget had the focus. Here's a > one-line patch to restore that. Yeah, CTRL+r wasn't explicity disabled but it worked. Committed the ignore code at CustInput though (it's cleaner). > > What should we do about CTRL+{HomeKey,EndKey}? I prefer HomeKey and > EndKey to scroll the main window even when the URL has the focus. > Wasn't that the behaviour originally? It certainly doesn't happen > now. AFAIR {HomeKey,EndKey} had always go to begin/end of the text in the Location (when focused), and that's the expected bahaviour. Committed Ctrl+{HomeKey,EndKey} to keep working on the main area even with Location focused. -- Cheers Jorge.-

Sept. 19, 2008

Tabs!!!

by jcid＠dillo.org

On Thu, Sep 18, 2008 at 05:39:43PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Sep 17, 2008 at 06:14:58PM -0400, Jorge Arellano Cid wrote: > > Hi there, > > > > The tabs patch has grown to a quite usable state, so it was > > committed for you to test. I know we're close to the release so > > we can still rollback. It's just that I'd much like to have it in > > the main tree before dillo2 goes out. > > > > The patch comes with several assorted cleanups and > > normalizations. For instance: derived widgets now use the "Cust" > > prefix instead of "New", the window->user_data() holds a pointer > > to the current UI, and child widgets get it from there, etc. > > > > OK, so to the tabs... > > > > This implementation uses one UI per tab, and it's quite fast. > > You can switch tabs with the mouse, Shift+{Left, Right} or > > {Ctrl,Ctrl+Shift}+TAB. Use Ctrl+N, or middle click over a link to > > open a new tab (just as it was with new windows). Ctrl+Q closes > > the tab. > > > > The idea is that in the future the user can dillo2rc-choose > > whether to use windows or tabs, and windows with tabs. > > Very nice! The whole tabs or the future dillo2rc idea? ;-) > > > > Some issues: > > > > 1.- Tab Tooltips are commented out because FLTK has problems > > with them. > > 2.- Shift+{Left, Right} work even when the location is focused. > > In the latter case you may need to click the right key > > twice for it to focus and work (don't know why, the Left > > key works OK). > > 3.- Currently there's no hidden tabs widget, when there's only > > one tab (haven't even tried, it may be as simple as > > hiding the group). > > Attached patch implements that. I don't like the global DilloTabs > variable in uicmd.cc, but the static one > a_UIcmd_browser_window_new() was not better. Perhaps DilloTabs > should become member of some new class? Committed. The good thing of it being a simple variable is that no-tabs windows is straightforward to implement. > > > 4.- There's no close tab icon in the tab label. > > 5.- No warning popup for close window with multiple open tabs. > > > > > > OK, please take it for a ride and test. > > Sometimes Shift-Arrow does not seem to work depending on where the > focus is. Ctrl-Tab seems to work always. Yes, that's what I tried to state in point 2. Well, I have an idea why it happens. The RightKey event gets to a group that handles it as widget navigation and that's why left and right are different. > The window title is not updated when switching between tabs. Is this > intended? Undecided. For tabs, I don't know whether it's a good idea. For single windows certainly it is. This is an open point. -- Cheers Jorge.-

Sept. 19, 2008

[patch] switch to standard assert

by jcid＠dillo.org

On Thu, Sep 18, 2008 at 06:29:33PM +0200, Johannes Hofmann wrote: > On Wed, Sep 17, 2008 at 05:34:12PM -0400, Jorge Arellano Cid wrote: > > On Wed, Sep 17, 2008 at 05:11:08PM +0200, Johannes Hofmann wrote: > > > On Tue, Sep 16, 2008 at 09:21:45PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Tue, Sep 16, 2008 at 07:20:31PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > > > > > > > > Turning off bounds checking for get and getRef does get rid of nearly > > > > > > > > all of the assert()s, but I was just trying -Winline and discovered: > > > > > > > > > > > > > > > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > > > > > > > > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > > > > > > > > , ...)' can never be inlined because it uses variable argument lists > > > > > > > > .. > > > > > > > > > > > > > > Ouch. A short grep shows that variable argument lists are not used > > > > > > > (yet) in the code - just const strings. > > > > > > > So we could change assert to use a const char* argument if I'm not > > > > > > > missing something. > > > > > > > > > > > > For me, grep shows > > > > > > layout.cc: misc::assert (anchor, "anchor '%s' not defined", name); > > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > > > > > > > > > > > Must have missed these... > > > > > In that case we could get away with something as in attached patch, > > > > > but we should also consider to just switch to standard assert(). > > > > > At the moment I would actually prefer the latter. > > > > > What do others think? > > > > > > > > Standard assert() sounds fine to me. > > > > > > > > > > Ok. Here comes the patch. > > > It also adds a missing check for negative values in SimpleVector > > > methods. > > > > Does this patch show any performance improvement? > > > > If it does and has no portability problems, I'm for it too. > > > > I've checked the major BSDs and Linux seems to be fine too. > According to http://en.wikipedia.org/wiki/C_standard_library it's > part of the ANSI C library header and was introduced with C99. > The same holds for stdint.h btw. for which we introduced some macro > stuff in style.hh. > I think we should simply rely on C99 compatible headers and include > those without any conditionals. OK, let's try... - Assert patch committed. - Conditional switched to just include stdint.h. - fail() function removed. -- Cheers Jorge.-

Sept. 19, 2008

Latest libpng fixes crashes

by onepoint＠starurchin.org

I recently looked at why dillo almost always crashed when viewing http://www.packtpub.com/article/transaction-model-of-postgresql and discovered it was happening in the depths of libpng. Luckily libpng-1.2.32 fixes this problem, so if you have been seeing unexpected crashes that might be due to PNG images then I recommend upgrading libpng. Regards, Jeremy Henty

Sept. 18, 2008

[patch] switch to standard assert

by Johannes.Hofmann＠gmx.de

On Wed, Sep 17, 2008 at 05:34:12PM -0400, Jorge Arellano Cid wrote: > On Wed, Sep 17, 2008 at 05:11:08PM +0200, Johannes Hofmann wrote: > > On Tue, Sep 16, 2008 at 09:21:45PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Tue, Sep 16, 2008 at 07:20:31PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > > > > > > > Turning off bounds checking for get and getRef does get rid of nearly > > > > > > > all of the assert()s, but I was just trying -Winline and discovered: > > > > > > > > > > > > > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > > > > > > > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > > > > > > > , ...)' can never be inlined because it uses variable argument lists > > > > > > > .. > > > > > > > > > > > > Ouch. A short grep shows that variable argument lists are not used > > > > > > (yet) in the code - just const strings. > > > > > > So we could change assert to use a const char* argument if I'm not > > > > > > missing something. > > > > > > > > > > For me, grep shows > > > > > layout.cc: misc::assert (anchor, "anchor '%s' not defined", name); > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > > > > > > > > Must have missed these... > > > > In that case we could get away with something as in attached patch, > > > > but we should also consider to just switch to standard assert(). > > > > At the moment I would actually prefer the latter. > > > > What do others think? > > > > > > Standard assert() sounds fine to me. > > > > > > > Ok. Here comes the patch. > > It also adds a missing check for negative values in SimpleVector > > methods. > > Does this patch show any performance improvement? > > If it does and has no portability problems, I'm for it too. > I've checked the major BSDs and Linux seems to be fine too. According to http://en.wikipedia.org/wiki/C_standard_library it's part of the ANSI C library header and was introduced with C99. The same holds for stdint.h btw. for which we introduced some macro stuff in style.hh. I think we should simply rely on C99 compatible headers and include those without any conditionals. Cheers, Johannes

Sept. 18, 2008

Tabs!!!

by corvid＠lavabit.com

Sometimes the window closes when I click on a page. A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, and then HIDE. (I only had one tab, in case that matters.)

Sept. 18, 2008

Tabs!!!

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Wed, Sep 17, 2008 at 06:14:58PM -0400, Jorge Arellano Cid wrote: > Hi there, > > The tabs patch has grown to a quite usable state, so it was > committed for you to test. I know we're close to the release so > we can still rollback. It's just that I'd much like to have it in > the main tree before dillo2 goes out. > > The patch comes with several assorted cleanups and > normalizations. For instance: derived widgets now use the "Cust" > prefix instead of "New", the window->user_data() holds a pointer > to the current UI, and child widgets get it from there, etc. > > OK, so to the tabs... > > This implementation uses one UI per tab, and it's quite fast. > You can switch tabs with the mouse, Shift+{Left, Right} or > {Ctrl,Ctrl+Shift}+TAB. Use Ctrl+N, or middle click over a link to > open a new tab (just as it was with new windows). Ctrl+Q closes > the tab. > > The idea is that in the future the user can dillo2rc-choose > whether to use windows or tabs, and windows with tabs. Very nice! > > Some issues: > > 1.- Tab Tooltips are commented out because FLTK has problems > with them. > 2.- Shift+{Left, Right} work even when the location is focused. > In the latter case you may need to click the right key > twice for it to focus and work (don't know why, the Left > key works OK). > 3.- Currently there's no hidden tabs widget, when there's only > one tab (haven't even tried, it may be as simple as > hiding the group). Attached patch implements that. I don't like the global DilloTabs variable in uicmd.cc, but the static one a_UIcmd_browser_window_new() was not better. Perhaps DilloTabs should become member of some new class? > 4.- There's no close tab icon in the tab label. > 5.- No warning popup for close window with multiple open tabs. > > > OK, please take it for a ride and test. Sometimes Shift-Arrow does not seem to work depending on where the focus is. Ctrl-Tab seems to work always. The window title is not updated when switching between tabs. Is this intended? Cheers, Johannes

Sept. 18, 2008