- Dillo-dev - lists.mailman3.com

Confused by the comment to CustInput::handle()

by onepoint＠starurchin.org

On Thu, Sep 18, 2008 at 06:01:51AM +0100, Jeremy Henty wrote: > 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. Patch attached. Regards, Jeremy Henty

Sept. 18, 2008

Confused by the comment to CustInput::handle()

by onepoint＠starurchin.org

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. 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. Regards, Jeremy Henty

Sept. 18, 2008

[patch] switch to standard assert

by corvid＠lavabit.com

Jorge 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: > > > > 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. Inlining succeeds now. 8% isn't enough to really notice, but gprof seems consistent with that time being saved. And we should probably rip out fail() as well so that no one ever makes the mistake of using it.

Sept. 18, 2008

Tabs!!!

by jcid＠dillo.org

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. 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). 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. Comments, fixes and patches are welcomed. -- Cheers Jorge.-

Sept. 18, 2008

patch: scroll upon resize

by jcid＠dillo.org

On Mon, Sep 15, 2008 at 05:20:01PM +0200, Johannes Hofmann wrote: > Hi, > > On Mon, Sep 15, 2008 at 02:57:27AM +0000, corvid wrote: > > You know how > > - you are scrolled down or to the right > > - you make the viewport larger > > - the scrollbar disappears > > - you can only get the rest of the document back by hitting some > > arrow keys or something > > Yes, I know... > > > > > This seems to fix it, although my usual dw disclaimer applies: > > I don't know whether this is necessarily the right place for > > the change. > > I was thinking about something like this before. > The only problem I see is with tiling window managers like e.g. dwm: > With these windows often get resized, then resized back to their old > size. Currently such a resize cycle does not change the scrolling > position, which is quite nice. > But as most people use ordinary window managers, I'd say we should > commit this fix. Committed. > Perhaps we will find something later that also > keeps the scrolling position after resizing back to the original > size. ACK. > > > > > PS When making the viewport very narrow and then maximizing, I notice > > that the location bar does not go back to showing the whole address. > > I don't know whether that's dillo's fault or fltk's fault. > > > > PPS Amazing how much code we need for dealing with scrolling and scrollbars... > > Yes, that's true. Quite a lot of code actually handles hiding and > showing of the scrollbars and their influence on the size of the viewable > area. > I had proposed a quite radical patch some time ago that moved the > scrollbars from the viewport to the gui (and thereby from dw2 to > dillo2). > This would eliminate all scrollbar related code from dw2. > However as I'm not confident enough that I did not miss any subtle > effects and the current code works fine I would keep things as they > are for the release. > I can update my patch and put it up for discussion after the > release. Yes, it would be good to reconsider it. AFAIR the main reasons it wan't committed were the author wasn't 100% confident, and we were expecting some comments. It can be re-considered after the release. -- Cheers Jorge.-

Sept. 17, 2008

[patch] switch to standard assert

by jcid＠dillo.org

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. -- Cheers Jorge.-

Sept. 17, 2008

[patch] switch to standard assert

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes

Sept. 17, 2008

8.68% of my time in assert()?

by corvid＠lavabit.com

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.

Sept. 16, 2008

8.68% of my time in assert()?

by Johannes.Hofmann＠gmx.de

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? Cheers, Johannes PS: I don't see any speed difference with attached patch when loading the huge mysql manual page.

Sept. 16, 2008

8.68% of my time in assert()?

by corvid＠lavabit.com

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",

Sept. 16, 2008