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

SEGFAULT with mouse click

by corvid＠lavabit.com

Jorge wrote: > I just came accross an easy to reproduce segfault, that's > present since long ago. > > Middle-clicking works OK right? > > Well, try middle-clicking a link with a two mouse button (i.e. > pressing both at the same time). The link menu stays open and > after a second click (e.g. left click to make it dissapear) > it segfaults. If I "middle-click" a link by pressing both buttons, it just opens a new tab.

Sept. 26, 2008

SEGFAULT with mouse click

by jcid＠dillo.org

Hi, I just came accross an easy to reproduce segfault, that's present since long ago. Middle-clicking works OK right? Well, try middle-clicking a link with a two mouse button (i.e. pressing both at the same time). The link menu stays open and after a second click (e.g. left click to make it dissapear) it segfaults. -- Cheers Jorge.-

Sept. 26, 2008

PATCH: select new tabs

by jcid＠dillo.org

Hi there, On Mon, Sep 22, 2008 at 10:03:32AM -0700, bf wrote: > > > > --- On Mon, 9/22/08, corvid <corvid(a)lavabit.com> wrote: > > > From: corvid <corvid(a)lavabit.com> > > Subject: Re: [Dillo-dev] PATCH: select new tabs > > To: dillo-dev(a)dillo.org > > Date: Monday, September 22, 2008, 11:41 AM > > Jeremy wrote: > > > On Mon, Sep 22, 2008 at 12:06:27AM +0000, corvid > > wrote: > > > > Jeremy wrote: > > > > > > > > > This patch is more of a call for > > discussion than a fix as it > > > > > fiddles with the UI. It makes Dillo > > select the new tab after > > > > > creating it. As a special case, > > middle-clicking a link does not > > > > > select the new tab unless the Shift key > > is down. (This is the > > > > > same behaviour as Firefox which saves > > learning a new set of > > > > > reflexes.) What do people think? > > > > > > > > It does seem that "I want to see this in a > > new tab/window now" has > > > > been more common for me than "I want to > > look at this in a different > > > > tab/window later". > > > > > > So do you think that a middle button click on a > > link should always > > > select the new tab? I often go down a list opening > > up new tabs to > > > look at later so I get frustrated when I have to > > switch back each > > > time. On the other hand when I create a new blank > > tab I always want > > > to switch to it immediately so I prefer Dillo to do > > that for me. > > > > Well, I've never been in the habit of using tabs, so I > > don't have too much > > of an opinion about the particulars yet. I will agree that > > allowing > > both "see this now" and "see this > > later" in some way is good. > > > > Yes, please make it possible for users to choose both via keyboard or mouse -- I find it very useful to alternate between both behaviors -- sometimes I want to switch immediately to new content in a new tab, and other times I want to open a new tab, but > remain in the current tab, and look at the new tab "in a minute". You don't want to have to either backtrack in a webpage or navigate back to a tab unnecessarily. Some other glitches(?) I've noticed: > [...] Considering the feedback, there's a new patch in CVS. It adds: "New Tab Ctrl+T" in the File menu "Open Link in new Tab" in the Link menu "Open Image in new Tab" in the Image menu It also adds two dillo2rc options: (don't forget to add them to your local dillo2rc) # A mouse's middle click over a link opens a new Tab. # If you prefer to open a new Window instead, set it to NO. #middle_click_opens_new_tab=YES # Focus follows new Tabs. # You can hold SHIFT to temporarily revert this behaviour. #focus_new_tab=YES Note that Ctrl+T always focus the new Tab, but you can use SHIFT while clicking to revert the focus_new_tab setting! It also adds Johannes fixup for the resizable in case we just removed it. Please give it some test and enjoy! :-) -- Cheers Jorge.-

Sept. 26, 2008

Icon for Dillo window

by onepoint＠starurchin.org

Replying to myself *again*, this is getting to be a bad habit! :-) On Thu, Sep 25, 2008 at 06:57:48PM +0100, Jeremy Henty wrote: > On Thu, Sep 25, 2008 at 07:04:05PM +0200, Johannes Hofmann wrote: > > > > Cool! But perhaps it should even be "Dillo" instead of "Dillo2". > > It's still dillo after all. > > I thought about that, then I decided that since we now use dillo2rc > I would go with dillo2 for consistency. After more thought I now agree with Johannes. WM_CLASS should tell the desktop whether the window is running Dillo, Firefox, XChat, GnuCash, GIMP or whatever. It should not make the user worry whether they're running dillo1 or dillo2. That's precisely the kind of detail that the desktop should be hiding from the user. So WM_CLASS should be just "Dillo", whatever the dillo executable is called. Regards, Jeremy Henty

Sept. 26, 2008

Icon for Dillo window

by corvid＠lavabit.com

Jorge wrote: > Yes, it's time to change the binary name. > > I like dillo2 because that way it's possible to have dillo1 and > dillo2 installed without trouble. OTOH, dillo2 is still dillo and > dillo1 is obsolete. > > Maybe "dillo" is the best option. What do others think? This came up in May when updating the FAQ: Justus and I said that we like "dillo" rather than "dillo2", and nobody else expressed an opinion.

Sept. 26, 2008

patch: Re: [Dillo-dev] cut off word ends with italic fonts

by Johannes.Hofmann＠gmx.de

On Thu, Sep 25, 2008 at 08:25:12PM +0000, corvid wrote: > Johannes wrote: > > somtimes the end of italic words get cut off e.g. in > > > > <html> > > <body> > > <i><a href="foo">FUU</a>BAR</i> > > </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? > > This > - reverts all of the style->backgroundColor to current_bg_color > - sets backgroundColor for fltk widgets because NULL is already > taken to mean standard_widget_colors > - sets backgroundColor for image inputs and <button>s since they use a > new Layout. > - changes table_cell_style's backgroundColor at the bottom of > Html_tag_open_tr() if the TR specifies one. I don't know why the original > code didn't need that. Maybe it was broken. Very nice! Thanks. I think this step would have become necessary anyway if we would try to support background images. > > I wasn't feeling too sure about doing this before release, but Johannes > says "currently an unnecessary XFillRectangle() command is sent to the X > Server for every word" and I haven't had problems running on it so far, > so it seems worthy of putting on the list for consideration. > > PS How do you monitor X to get an idea of what a client might be > spending too much time on? I use xtrace (http://xtrace.alioth.debian.org/) In one window I call: xtrace In the other: export DISPLAY=:9 ./dillo-fltk Cheers, Johannes

Sept. 25, 2008

patch: Re: [Dillo-dev] 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> > <i><a href="foo">FUU</a>BAR</i> > </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? This - reverts all of the style->backgroundColor to current_bg_color - sets backgroundColor for fltk widgets because NULL is already taken to mean standard_widget_colors - sets backgroundColor for image inputs and <button>s since they use a new Layout. - changes table_cell_style's backgroundColor at the bottom of Html_tag_open_tr() if the TR specifies one. I don't know why the original code didn't need that. Maybe it was broken. I wasn't feeling too sure about doing this before release, but Johannes says "currently an unnecessary XFillRectangle() command is sent to the X Server for every word" and I haven't had problems running on it so far, so it seems worthy of putting on the list for consideration. PS How do you monitor X to get an idea of what a client might be spending too much time on?

Sept. 25, 2008

patch: Re: [Dillo-dev] what's next

by Johannes.Hofmann＠gmx.de

On Thu, Sep 25, 2008 at 02:11:09PM -0400, Jorge Arellano Cid wrote: > On Thu, Sep 25, 2008 at 04:25:20PM +0200, Johannes Hofmann wrote: > > On Thu, Sep 25, 2008 at 03:24:55AM +0000, corvid wrote: > > > Johannes wrote (way back in June!): > > > > * The cursor is not always updated properly when over a link. This > > > > happens while page is rendered and also when drag-scrolling with > > > > the middle mouse button. > > > > > > How about updating it from layout()? > > > > > > > Yes, I think something like that is necessary. I also worked a bit on > > that problem (see attached patch), but got confused about how > > to handle multiple views. > > Is this patch ready for CVS? > No, it isn't. Cheers, Johannes

Sept. 25, 2008

Icon for Dillo window

by jcid＠dillo.org

On Thu, Sep 25, 2008 at 06:57:48PM +0100, Jeremy Henty wrote: > On Thu, Sep 25, 2008 at 07:04:05PM +0200, Johannes Hofmann wrote: > > On Thu, Sep 25, 2008 at 06:05:37PM +0100, Jeremy Henty wrote: > > > > > > Heh, it's a one liner. I HAZ DILLLO EICONZ NAOW!!! > > > > Cool! But perhaps it should even be "Dillo" instead of "Dillo2". > > It's still dillo after all. > > I thought about that, then I decided that since we now use dillo2rc I > would go with dillo2 for consistency. But it's no big deal, I'd be as > happy with "dillo" as "dillo2" because icewm can map any given value > of WM_CLASS to any icon name. > > Incidentally, we could alternatively call fltk::Window::show() with > argc and argv as arguments (it's overloaded). That would do the > default thing of taking WM_CLASS from argv[0], so we would get > "dillo-fltk". I decided not to because it means passing argc and argv > from main() in dillo.cc to the call to fltk::Window::show() in > uicmd.cc and I wanted the shortest patch that could possibly work. > But maybe there's a case for doing it that way. (Perhaps it's time to > rename the executable to dillo2, or even dillo?) I don't care as long > as we change WM_CLASS from the default of "fltk" to *something* that I > can map to the dillo icons in my icewm configuration. Yes, it's time to change the binary name. I like dillo2 because that way it's possible to have dillo1 and dillo2 installed without trouble. OTOH, dillo2 is still dillo and dillo1 is obsolete. Maybe "dillo" is the best option. What do others think? -- Cheers Jorge.-

Sept. 25, 2008

patch: Re: [Dillo-dev] what's next

by jcid＠dillo.org

On Thu, Sep 25, 2008 at 04:25:20PM +0200, Johannes Hofmann wrote: > On Thu, Sep 25, 2008 at 03:24:55AM +0000, corvid wrote: > > Johannes wrote (way back in June!): > > > * The cursor is not always updated properly when over a link. This > > > happens while page is rendered and also when drag-scrolling with > > > the middle mouse button. > > > > How about updating it from layout()? > > > > Yes, I think something like that is necessary. I also worked a bit on > that problem (see attached patch), but got confused about how > to handle multiple views. Is this patch ready for CVS? > The mouse could be over a link in one view and somewhere else in > another one (with overlapping windows). > Is the mouse pointer a per view or a per platform thing? I don't know. -- Cheers Jorge.-

Sept. 25, 2008