September 2008 - Dillo-dev - lists.mailman3.com

Tabs!!!

by Johannes.Hofmann＠gmx.de

On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote: > I wrote: > > 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.) > > Okay, that was not accurate. > It looks like PUSH and FOCUS_CHANGE is from clicking > and HIDE is from pressing Space to page down. I'm also seeing that. No idea yet... Johannes

Sept. 19, 2008

cut off word ends with italic fonts

by Johannes.Hofmann＠gmx.de

On Fri, Sep 19, 2008 at 03:05:17PM +0000, corvid wrote: > Johannes wrote: > > somtimes the end of italic words get cut off e.g. in > > > > <html> > > <body> > > <a href="foo">FUU</a>BAR > > </body> > > </html> > > > > when seen with vw_fontname="helvetica". > > > > This is due to a change in html.cc (I think it was introduced with > > rev 1.36). This change sets the backgroundColor for all words which > > means that for each word, the bounding box get's drawn before the > > actual text. This obviously has a performance impact too. > > > > I'm not sure how to get back to the original behaviour > > (backgroundColor == NULL for normal words) without breaking anything. > > Can someone please have a look? > > I've had the idea lately (not yet explored) that maybe I could rip out all > of my backgroundColor setting and get the background color > for the fltk widgets if it should turn out that getEmbed()->getBgColor() > has what I want. I'll dig into it. > > PS Is this the same reason that the tops of bold 5's are thin and > the right edge of fixed-width %'s are cut off (using DejaVu fonts, at least)? Not sure. But you can easily check by completely disabling word backgrounds as in attached patch. Cheers, Johannes

Sept. 19, 2008

Tabs!!!

by corvid＠lavabit.com

I wrote: > 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.) Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down. Since they're very close to each other on my keyboard and I am so accustomed to the click-and-space sequence, it can come from muscle memory even when I'm paying enough attention to think I know what happened before dillo disappeared.

Sept. 19, 2008

cut off word ends with italic fonts

by corvid＠lavabit.com

Johannes wrote: > somtimes the end of italic words get cut off e.g. in > > <html> > <body> > <a href="foo">FUU</a>BAR > </body> > </html> > > when seen with vw_fontname="helvetica". > > This is due to a change in html.cc (I think it was introduced with > rev 1.36). This change sets the backgroundColor for all words which > means that for each word, the bounding box get's drawn before the > actual text. This obviously has a performance impact too. > > I'm not sure how to get back to the original behaviour > (backgroundColor == NULL for normal words) without breaking anything. > Can someone please have a look? I've had the idea lately (not yet explored) that maybe I could rip out all of my backgroundColor setting and get the background color for the fltk widgets if it should turn out that getEmbed()->getBgColor() has what I want. I'll dig into it. PS Is this the same reason that the tops of bold 5's are thin and the right edge of fixed-width %'s are cut off (using DejaVu fonts, at least)?

Sept. 19, 2008

cut off word ends with italic fonts

by Johannes.Hofmann＠gmx.de

Hi, somtimes the end of italic words get cut off e.g. in <html> <body> <a href="foo">FUU</a>BAR </body> </html> when seen with vw_fontname="helvetica". This is due to a change in html.cc (I think it was introduced with rev 1.36). This change sets the backgroundColor for all words which means that for each word, the bounding box get's drawn before the actual text. This obviously has a performance impact too. I'm not sure how to get back to the original behaviour (backgroundColor == NULL for normal words) without breaking anything. Can someone please have a look? Cheers, Johannes

Sept. 19, 2008

[patch] minor optimization in StyleAttrs::equals()

by Johannes.Hofmann＠gmx.de

Hi, this patch adds a missing optimization to StyleAttrs::equals(). Similar checks are already in place in other equals() methods. Cheers, Johannes

Sept. 19, 2008

[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