- Dillo-dev - lists.mailman3.com

SEGFAULT with mouse click

by jcid＠dillo.org

On Sat, Sep 27, 2008 at 07:59:11PM +0000, corvid wrote: > Is that middle-click crash gone as well now? Yes! The problematic middle-click was generating a button 1 and 2 press, not middle (similar to fast clicking them). -- Cheers Jorge.-

Sept. 27, 2008

SEGFAULT with mouse click

by corvid＠lavabit.com

Is that middle-click crash gone as well now?

Sept. 27, 2008

Dillo in OSX

by Johannes.Hofmann＠gmx.de

On Thu, Sep 04, 2008 at 04:09:30PM -0400, Jorge Arellano Cid wrote: > On Wed, Sep 03, 2008 at 06:28:49PM +0200, Johannes Hofmann wrote: > > On Tue, Sep 02, 2008 at 09:20:03AM -0400, Jorge Arellano Cid wrote: > > > On Mon, Sep 01, 2008 at 01:42:26PM +0200, Johannes Hofmann wrote: > > > > Hi Jorge, > > > > > > > > how did You setup the OSX box to get a compiler and header files? > > > > Did You install that huge XCode stuff, or is there another way? > > > > I may get access to an OSX box to try dillo on it. > > > > > > How do I disable the double-buffer? > > > > Use the --disable-doublebuffer option when configuring dw2. > > Oh, yes, I forgot... > (tried running ./configure --help in dillo2 not dw2) > > > > I tried dillo "as is" with clear_double_buffer() and without it, > > > and the result is the same... > > > > Yeah, dw2 implements doublebuffering internally, so that does not > > make a difference. > > I'll have access to that machine again sarting on September 12. > Just tried current dillo on OSX with --disable-doublebuffer. It works ok with some issues: * Some of the buttens disapear from time to time (Back button for example). * The font size seems a bit too large so that there is not enough space between words and lines. * Incoming data does not reliably trigger a page update. An additional event like a mouse movement is necessary. Apart from that it's quite nice. Tabs are working fine. Cheers, Johannes

Sept. 27, 2008

SEGFAULT with mouse click

by jcid＠dillo.org

On Fri, Sep 26, 2008 at 09:29:00PM +0000, corvid wrote: > I wrote: > > Jorge wrote: > > > This hinted me towards a timing issue and found this way to > > > crash dillo (most probably akin to the "middle-click" bug): > > > > > > 1.- Left click over a remote URL link > > > (to have some time while DNS is resolving) > > > 2.- Move the mouse pointer out of the link and right-click > > > to get the popup menu, before the new page starts downloading. > > > 3.- Once the new page starts to show, click again to get rid of > > > the popup, and it'll crash. > > > > What a coincidence! I finally got around to making a patch for that > > last night. (I'd known about that one for a while...) > > Here, you can give it a try. > > It took until yesterday to finally poke at it long enough to > find the problem because the backtrace you get is very misleading. > It dies down below Widget::buttonPress (EventButton *event), and of > course you just pressed the button to get rid of the popup -- but > it's really the old button press that popped up the menu. > First it went down buttonPressImpl and caused the popup, which doesn't > return until the menu goes away, and second it goes down > eventEmitter.emitButtonPress...but the widget and its emitter are gone. > > So I threw timeout at it and made copies of things in popup_*. > OK, committed with some minor changes and comments. Please check. After reading the patch, it seems the timeout helps to get rid of the events that popped it up, so they're not obsolete after a page change. This avoids the segfault, and also cuts the execute on button-release feature. I wondered what was the "FLTK-way" of doing it, and experimented a bit, but after finding this warning, I decided to commit: Menu_popup.cxx: // Implementation of popup menus. These are called by using the // Menu::popup and Menu::pulldown methods. See also the // Menu base class in Menu.cxx. Warning: this code is // quite a mess! Also, the classes defined here are private and // may change in the future! :-) BTW, It looks as though FLTK-1.3 may be a good option after all... -- Cheers Jorge.-

Sept. 27, 2008

what crashes remain?

by Johannes.Hofmann＠gmx.de

On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > It's still possible to crash dillo if you click on a remote link and > quickly click on some images to load them. Doesn't crash every time, > but typically within four tries or so. I had assumed it was the same > thing as whatever was wrong with the menu crash, so I'd ignored it. > > If I stick > a_Bw_stop_clients(bw, BW_Img); > in the DilloHtml destructor, I can no longer get it to crash, but > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > earlier today, so there's something wrong with just doing that. > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > I can't think of any other crashes, but I don't remember whether > Johannes still gets bus errors. No, they got fixed with http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-July/004649.html The only issues I'm seeing are the 128 tabs limit from fltk and the redraw storms related to the MenuTabPager. Cheers, Johannes

Sept. 27, 2008

what crashes remain?

by corvid＠lavabit.com

It's still possible to crash dillo if you click on a remote link and quickly click on some images to load them. Doesn't crash every time, but typically within four tries or so. I had assumed it was the same thing as whatever was wrong with the menu crash, so I'd ignored it. If I stick a_Bw_stop_clients(bw, BW_Img); in the DilloHtml destructor, I can no longer get it to crash, but I randomly got a "Cache_process_queue Caught busy!!!" while browsing earlier today, so there's something wrong with just doing that. (Assuming it's related; I'm not in the habit of getting that MSG.) I can't think of any other crashes, but I don't remember whether Johannes still gets bus errors.

Sept. 27, 2008

SEGFAULT with mouse click

by Johannes.Hofmann＠gmx.de

On Fri, Sep 26, 2008 at 09:29:00PM +0000, corvid wrote: > I wrote: > > Jorge wrote: > > > This hinted me towards a timing issue and found this way to > > > crash dillo (most probably akin to the "middle-click" bug): > > > > > > 1.- Left click over a remote URL link > > > (to have some time while DNS is resolving) > > > 2.- Move the mouse pointer out of the link and right-click > > > to get the popup menu, before the new page starts downloading. > > > 3.- Once the new page starts to show, click again to get rid of > > > the popup, and it'll crash. > > > > What a coincidence! I finally got around to making a patch for that > > last night. (I'd known about that one for a while...) > > Here, you can give it a try. > > It took until yesterday to finally poke at it long enough to > find the problem because the backtrace you get is very misleading. > It dies down below Widget::buttonPress (EventButton *event), and of > course you just pressed the button to get rid of the popup -- but > it's really the old button press that popped up the menu. > First it went down buttonPressImpl and caused the popup, which doesn't > return until the menu goes away, and second it goes down > eventEmitter.emitButtonPress...but the widget and its emitter are gone. Ah right. I thought it was related to the old popup, but I could not figure out where the buttonPress() came from, it showed button 3 pressed where I had pressed button 1 to get rid of the popup. Thanks for the explanation. Johannes

Sept. 27, 2008

Icon for Dillo window

by jcid＠dillo.org

On Sat, Sep 27, 2008 at 03:44:01PM +0100, Jeremy Henty wrote: > On Sat, Sep 27, 2008 at 09:36:40AM -0400, Jorge Arellano Cid wrote: > > > Jeremy: I can't get the window icon during Alt+Tab with icewm > > nor xfce. How did you set it? > > In ~/.icewm/winoptions I have a line > > Dillo.icon: dillo > > In ~/.icewm/icons I have files > > dillo_16x16.xpm > dillo_32x32.xpm > dillo_48x48.xpm > dillo_64x64.xpm > > I think Alt+Tab looks for one of the larger sized icons. Thanks, now it works for me. -- Cheers Jorge.-

Sept. 27, 2008

Icon for Dillo window

by onepoint＠starurchin.org

On Sat, Sep 27, 2008 at 09:36:40AM -0400, Jorge Arellano Cid wrote: > Jeremy: I can't get the window icon during Alt+Tab with icewm > nor xfce. How did you set it? I don't use xfce but http://wiki.xfce.org/faq says Is it possible to change the icon used by the icon box or task bar for a given application? It's not possible. This setting has to be managed by the application itself. which is not encouraging. Regards, Jeremy Henty

Sept. 27, 2008

Icon for Dillo window

by onepoint＠starurchin.org

On Sat, Sep 27, 2008 at 09:36:40AM -0400, Jorge Arellano Cid wrote: > Jeremy: I can't get the window icon during Alt+Tab with icewm > nor xfce. How did you set it? In ~/.icewm/winoptions I have a line Dillo.icon: dillo In ~/.icewm/icons I have files dillo_16x16.xpm dillo_32x32.xpm dillo_48x48.xpm dillo_64x64.xpm I think Alt+Tab looks for one of the larger sized icons. Regards, Jeremy Henty

Sept. 27, 2008

Icon for Dillo window

by jcid＠dillo.org

On Thu, Sep 25, 2008 at 06:05:37PM +0100, Jeremy Henty wrote: > > Replying to myself: > > On Thu, Sep 25, 2008 at 04:33:57PM +0100, Jeremy Henty wrote: > > On Thu, Sep 25, 2008 at 04:14:48PM +0200, Johannes Hofmann wrote: > > > On Thu, Sep 25, 2008 at 03:11:55PM +0100, Jeremy Henty wrote: > > > > > > > > If we're concerned about dillo2 playing properly with X11 and > > > > window managers then I'd say that it should set WM_CLASS to > > > > '"Dillo2", "dillo2"' on general principle. > > > > > > Yes that sounds right. > > > > I'll propose a patch later today for comments. > > Heh, it's a one liner. I HAZ DILLLO EICONZ NAOW!!! > > Jeremy Henty > diff -pru -- 00_pre/src/dillo.cc 01_post/src/dillo.cc > --- 00_pre/src/dillo.cc 2008-09-25 17:57:43.000000000 +0100 > +++ 01_post/src/dillo.cc 2008-09-25 17:57:43.000000000 +0100 > @@ -101,6 +101,8 @@ int main(int argc, char **argv) > a_Bw_init(); > a_Cookies_init(); > > + fltk::Window::xclass("dillo2"); // sets WM_CLASS hint on X11 > + > // Create a new UI/bw pair > BrowserWindow *bw = a_UIcmd_browser_window_new(0, 0, NULL, 0); > Committed as "dillo". Jeremy: I can't get the window icon during Alt+Tab with icewm nor xfce. How did you set it? -- Cheers Jorge.-

Sept. 27, 2008

SEGFAULT with mouse click

by corvid＠lavabit.com

I wrote: > @@ -280,20 +284,19 @@ void a_Menu_page_popup(BrowserWindow *bw > pm->end(); > } > > - if (bugs_txt == NULL) > + if (bugs == TRUE) > view_page_bugs_item->deactivate(); view_page_bugs_item->activate(); > else > view_page_bugs_item->activate(); view_page_bugs_item->deactivate(); Ooh, a bug! I was trying to get this out relatively quickly because it was on topic and because we know a freeze will be coming at some point here...ah well...

Sept. 27, 2008

SEGFAULT with mouse click

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > This hinted me towards a timing issue and found this way to > > crash dillo (most probably akin to the "middle-click" bug): > > > > 1.- Left click over a remote URL link > > (to have some time while DNS is resolving) > > 2.- Move the mouse pointer out of the link and right-click > > to get the popup menu, before the new page starts downloading. > > 3.- Once the new page starts to show, click again to get rid of > > the popup, and it'll crash. > > What a coincidence! I finally got around to making a patch for that > last night. (I'd known about that one for a while...) Here, you can give it a try. It took until yesterday to finally poke at it long enough to find the problem because the backtrace you get is very misleading. It dies down below Widget::buttonPress (EventButton *event), and of course you just pressed the button to get rid of the popup -- but it's really the old button press that popped up the menu. First it went down buttonPressImpl and caused the popup, which doesn't return until the menu goes away, and second it goes down eventEmitter.emitButtonPress...but the widget and its emitter are gone. So I threw timeout at it and made copies of things in popup_*.

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by jcid＠dillo.org

On Fri, Sep 26, 2008 at 09:52:25PM +0200, Johannes Hofmann wrote: > On Fri, Sep 26, 2008 at 07:50:58PM +0000, corvid wrote: > > Johannes wrote: > > > On Fri, Sep 26, 2008 at 07:14:05PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > Here comes a complete patch to disable label parsing for labels set > > > > > > > from html. I hope I didn't miss one. > > > > > > > > > > > > Does the UI's label need it in principle? > > > > > > (It didn't seem to require escaping the other day, but...) > > > > > > > > > > > > > > > > I tried it with > > > > > > > > > > <html> > > > > > <body> > > > > > <form> > > > > > <select> > > > > > <option>&a</option> > > > > > <option>&b</option> > > > > > <option>&c</option> > > > > > </select> > > > > > </form> > > > > > </body> > > > > > </html> > > > > > > > > > > Without the patch there is no & and > > > > > Alt a/b/c seem to be working as shortcut on the open select. > > > > > > > > Oh, I mean the UI label text that is shown in a tab. > > > > > > > > > > Oh I see. I missed that one. It is also needed: > > > > > > <html> > > > <head> > > > <title>&foo</title> > > > </head> > > > <body>bar</body> > > > </html> > > > > > > but set_flag(RAW_LABEL) does seem to help here :-( > > > > Oh, I see what you mean. I was just trying it with a space following the > > &, which seems to help it appear. > > > > I'd say we set RAW_LABEL for in UI::UI() and wait for fltk people to > fix the problem. I've filed a bug report. Committed. -- Cheers Jorge.-

Sept. 26, 2008

PATCH: select new tabs

by jcid＠dillo.org

On Fri, Sep 26, 2008 at 07:43:44PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Sep 25, 2008 at 06:51:14PM -0400, Jorge Arellano Cid wrote: > > 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! :-) > > > > Excellent! I like how you avoided to make DilloTabs a member > of BrowserWindow. Good you like it. Just committed this: - Made the history popups use "focus_new_tab" & "middle_click_opens_new_tab" -- Cheers Jorge.-

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by Johannes.Hofmann＠gmx.de

On Fri, Sep 26, 2008 at 07:50:58PM +0000, corvid wrote: > Johannes wrote: > > On Fri, Sep 26, 2008 at 07:14:05PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > Here comes a complete patch to disable label parsing for labels set > > > > > > from html. I hope I didn't miss one. > > > > > > > > > > Does the UI's label need it in principle? > > > > > (It didn't seem to require escaping the other day, but...) > > > > > > > > > > > > > I tried it with > > > > > > > > <html> > > > > <body> > > > > <form> > > > > <select> > > > > <option>&a</option> > > > > <option>&b</option> > > > > <option>&c</option> > > > > </select> > > > > </form> > > > > </body> > > > > </html> > > > > > > > > Without the patch there is no & and > > > > Alt a/b/c seem to be working as shortcut on the open select. > > > > > > Oh, I mean the UI label text that is shown in a tab. > > > > > > > Oh I see. I missed that one. It is also needed: > > > > <html> > > <head> > > <title>&foo</title> > > </head> > > <body>bar</body> > > </html> > > > > but set_flag(RAW_LABEL) does seem to help here :-( > > Oh, I see what you mean. I was just trying it with a space following the > &, which seems to help it appear. > I'd say we set RAW_LABEL for in UI::UI() and wait for fltk people to fix the problem. I've filed a bug report. Cheers, Johannes

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by corvid＠lavabit.com

Johannes wrote: > On Fri, Sep 26, 2008 at 07:14:05PM +0000, corvid wrote: > > Johannes wrote: > > > On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > Here comes a complete patch to disable label parsing for labels set > > > > > from html. I hope I didn't miss one. > > > > > > > > Does the UI's label need it in principle? > > > > (It didn't seem to require escaping the other day, but...) > > > > > > > > > > I tried it with > > > > > > <html> > > > <body> > > > <form> > > > <select> > > > <option>&a</option> > > > <option>&b</option> > > > <option>&c</option> > > > </select> > > > </form> > > > </body> > > > </html> > > > > > > Without the patch there is no & and > > > Alt a/b/c seem to be working as shortcut on the open select. > > > > Oh, I mean the UI label text that is shown in a tab. > > > > Oh I see. I missed that one. It is also needed: > > <html> > <head> > <title>&foo</title> > </head> > <body>bar</body> > </html> > > but set_flag(RAW_LABEL) does seem to help here :-( Oh, I see what you mean. I was just trying it with a space following the &, which seems to help it appear.

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by Johannes.Hofmann＠gmx.de

On Fri, Sep 26, 2008 at 07:14:05PM +0000, corvid wrote: > Johannes wrote: > > On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote: > > > Johannes wrote: > > > > Here comes a complete patch to disable label parsing for labels set > > > > from html. I hope I didn't miss one. > > > > > > Does the UI's label need it in principle? > > > (It didn't seem to require escaping the other day, but...) > > > > > > > I tried it with > > > > <html> > > <body> > > <form> > > <select> > > <option>&a</option> > > <option>&b</option> > > <option>&c</option> > > </select> > > </form> > > </body> > > </html> > > > > Without the patch there is no & and > > Alt a/b/c seem to be working as shortcut on the open select. > > Oh, I mean the UI label text that is shown in a tab. > Oh I see. I missed that one. It is also needed: <html> <head> <title>&foo</title> </head> <body>bar</body> </html> but set_flag(RAW_LABEL) does seem to help here :-(

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by corvid＠lavabit.com

Johannes wrote: > On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote: > > Johannes wrote: > > > Here comes a complete patch to disable label parsing for labels set > > > from html. I hope I didn't miss one. > > > > Does the UI's label need it in principle? > > (It didn't seem to require escaping the other day, but...) > > > > I tried it with > > <html> > <body> > <form> > <select> > <option>&a</option> > <option>&b</option> > <option>&c</option> > </select> > </form> > </body> > </html> > > Without the patch there is no & and > Alt a/b/c seem to be working as shortcut on the open select. Oh, I mean the UI label text that is shown in a tab.

Sept. 26, 2008

SEGFAULT with mouse click

by corvid＠lavabit.com

Jorge wrote: > This hinted me towards a timing issue and found this way to > crash dillo (most probably akin to the "middle-click" bug): > > 1.- Left click over a remote URL link > (to have some time while DNS is resolving) > 2.- Move the mouse pointer out of the link and right-click > to get the popup menu, before the new page starts downloading. > 3.- Once the new page starts to show, click again to get rid of > the popup, and it'll crash. What a coincidence! I finally got around to making a patch for that last night. (I'd known about that one for a while...)

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by jcid＠dillo.org

On Fri, Sep 26, 2008 at 07:36:30PM +0200, Johannes Hofmann wrote: > On Mon, Sep 22, 2008 at 03:31:58PM +0000, corvid wrote: > > Johannes wrote: > > > On Mon, Sep 22, 2008 at 05:06:35AM +0000, corvid wrote: > > > > I wrote: > > > > > Johannes wrote: > > > > > > 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... > > > > > > > > > > I finally sat down and worked out what the problem is. > > > > > It's not only click-space, but that's the most common case. > > > > > > > > > > <title>...&[character]...</title> > > > > > > > > > > causes click-[character] to close it. > > > > > > > > > > So fltk must think that's a shortcut in > > > > > the tab text, and it tries to do whatever > > > > > it does with shortcuts -- but there's a > > > > > shortcut-handling piece missing, so it > > > > > just closes the window. > > > > > > > > It doesn't care about the tab text. > > > > It's the UI->window() label stuff that's causing the problem. > > > > It appears that you can escape &-as-shortcut in general > > > > by doubling them, but I end up with doubled && in the > > > > title bar. > > > > Why wasn't this a problem in the past? I don't know; maybe it > > > > _was_ regarded as a shortcut but handle() took care of it. > > > > > > > > > > Thanks for tracking this down! > > > I could also reproduce it with pre-tabs versions. > > > > I have a dillo from Sept. 5 around, and space doesn't > > close the window for me. > > > > > Please try attached patch. > > > > It works! RAW_LABEL is so much better than trying to escape &. > > > > Here comes a complete patch to disable label parsing for labels set > from html. I hope I didn't miss one. Committed. -- Cheers Jorge.-

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by Johannes.Hofmann＠gmx.de

On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote: > Johannes wrote: > > Here comes a complete patch to disable label parsing for labels set > > from html. I hope I didn't miss one. > > Does the UI's label need it in principle? > (It didn't seem to require escaping the other day, but...) > I tried it with <html> <body> <form> <select> <option>&a</option> <option>&b</option> <option>&c</option> </select> </form> </body> </html> Without the patch there is no & and Alt a/b/c seem to be working as shortcut on the open select. Cheers, Johannes

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by corvid＠lavabit.com

Johannes wrote: > Here comes a complete patch to disable label parsing for labels set > from html. I hope I didn't miss one. Does the UI's label need it in principle? (It didn't seem to require escaping the other day, but...)

Sept. 26, 2008

SEGFAULT with mouse click

by jcid＠dillo.org

On Thu, Sep 25, 2008 at 11:14:28PM -0700, Donald Chai wrote: > On Thu, Sep 25, 2008 at 3:58 PM, Jorge Arellano Cid <jcid(a)dillo.org> 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. > > [...] > > I see this problem as well. If I very quickly press the left then > right mouse button (NOT at the same time), then I get a segfault. > Dillo seems to try to select some text on the old page, after the new > page is loaded. This hinted me towards a timing issue and found this way to crash dillo (most probably akin to the "middle-click" bug): 1.- Left click over a remote URL link (to have some time while DNS is resolving) 2.- Move the mouse pointer out of the link and right-click to get the popup menu, before the new page starts downloading. 3.- Once the new page starts to show, click again to get rid of the popup, and it'll crash. -- Cheers Jorge.-

Sept. 26, 2008

PATCH: select new tabs

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Thu, Sep 25, 2008 at 06:51:14PM -0400, Jorge Arellano Cid wrote: > 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! :-) > Excellent! I like how you avoided to make DilloTabs a member of BrowserWindow. Cheers, Johannes

Sept. 26, 2008

[patch] raw labels, was Re: [Dillo-dev] Tabs!!!

by Johannes.Hofmann＠gmx.de

On Mon, Sep 22, 2008 at 03:31:58PM +0000, corvid wrote: > Johannes wrote: > > On Mon, Sep 22, 2008 at 05:06:35AM +0000, corvid wrote: > > > I wrote: > > > > Johannes wrote: > > > > > 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... > > > > > > > > I finally sat down and worked out what the problem is. > > > > It's not only click-space, but that's the most common case. > > > > > > > > <title>...&[character]...</title> > > > > > > > > causes click-[character] to close it. > > > > > > > > So fltk must think that's a shortcut in > > > > the tab text, and it tries to do whatever > > > > it does with shortcuts -- but there's a > > > > shortcut-handling piece missing, so it > > > > just closes the window. > > > > > > It doesn't care about the tab text. > > > It's the UI->window() label stuff that's causing the problem. > > > It appears that you can escape &-as-shortcut in general > > > by doubling them, but I end up with doubled && in the > > > title bar. > > > Why wasn't this a problem in the past? I don't know; maybe it > > > _was_ regarded as a shortcut but handle() took care of it. > > > > > > > Thanks for tracking this down! > > I could also reproduce it with pre-tabs versions. > > I have a dillo from Sept. 5 around, and space doesn't > close the window for me. > > > Please try attached patch. > > It works! RAW_LABEL is so much better than trying to escape &. > Here comes a complete patch to disable label parsing for labels set from html. I hope I didn't miss one. Cheers, Johannes

Sept. 26, 2008

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

by jcid＠dillo.org

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

Sept. 26, 2008

SEGFAULT with mouse click

by corvid＠lavabit.com

Jorge wrote: > On Thu, Sep 25, 2008 at 11:33:09PM +0000, corvid wrote: > > 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. > > If I middle-click with an external three button mouse, it works > perfectly. Here in my laptop I have three "mice": a usb external, > a trackpoint with a couple of buttons (like the thinkpads) and a > touch pad with another pair of buttons. Pressing both touchpad > buttons works OK, but pressing the buttons belonging to the > trackpoint produces a segfault. Trackpoint is what I have. I tried commenting out the 3-button emulation in xorg.conf and restarting X, but it still worked the same (which surprised me, btw).

Sept. 26, 2008

SEGFAULT with mouse click

by jcid＠dillo.org

On Thu, Sep 25, 2008 at 11:33:09PM +0000, corvid wrote: > 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. If I middle-click with an external three button mouse, it works perfectly. Here in my laptop I have three "mice": a usb external, a trackpoint with a couple of buttons (like the thinkpads) and a touch pad with another pair of buttons. Pressing both touchpad buttons works OK, but pressing the buttons belonging to the trackpoint produces a segfault. -- Cheers Jorge.-

Sept. 26, 2008

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

Icon for Dillo window

by jcid＠dillo.org

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: > > > > Replying to myself: > > > > On Thu, Sep 25, 2008 at 04:33:57PM +0100, Jeremy Henty wrote: > > > On Thu, Sep 25, 2008 at 04:14:48PM +0200, Johannes Hofmann wrote: > > > > On Thu, Sep 25, 2008 at 03:11:55PM +0100, Jeremy Henty wrote: > > > > > > > > > > If we're concerned about dillo2 playing properly with X11 and > > > > > window managers then I'd say that it should set WM_CLASS to > > > > > '"Dillo2", "dillo2"' on general principle. > > > > > > > > Yes that sounds right. > > > > > > I'll propose a patch later today for comments. > > > > 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. Yes, it can be "Dillo". BTW, where does the WM get the icon from? -- Cheers Jorge.-

Sept. 25, 2008

patch: show_msg=NO disable debug messages

by jcid＠dillo.org

On Thu, Sep 25, 2008 at 03:53:22PM +0000, corvid wrote: > tried turning off show_msg and saw how dillo is still somewhat > chatty thanks to DEBUG_MSG. > > (Or would you prefer a show_debug_messages pref as suggested in dillo2rc? > Hmm... thinking about the sentence "Generic messages (mainly for debugging > specific parts)", I'd have to say that we use MSG for plenty of debugging > messages and DEBUG_MSG for plenty of of-more-general-interest messages.) > This is a good question that I don't have a solid answer for. In the beginning, we thought of DEBUG_MSG and its levels as a good platform. OTOH, through the years, MSG has proved to be all I need. YMMV. In other words, for me, its OK to get rid of DEBUG_MSG unless somebody else finds good use for it. -- Cheers Jorge.-

Sept. 25, 2008

Icon for Dillo window

by onepoint＠starurchin.org

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

Sept. 25, 2008

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

by jcid＠dillo.org

On Thu, Sep 25, 2008 at 05:24:57PM +0200, Johannes Hofmann wrote: > On Thu, Sep 25, 2008 at 03:16:30PM +0000, corvid wrote: > > Johannes 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. > > > 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? > > > > Oh yeah, multiple views... > > Multiple views are hard to think about when we don't know how they're > > supposed to behave, can't make them, and don't know whether there's > > any real need/use for them. > > Maybe we should enable that fltkpreview stuff somehow - just to > verify that we don't break the multiple view feature. > And making a Postscript view for printing could be fun! That would be amazing! Well, I've read that FLTK2 can use cairo for images, and that text and clipping are the missing link to full cairo output. If we can use this to be able to print, it'd be great. -- Cheers Jorge.-

Sept. 25, 2008

Icon for Dillo window

by Johannes.Hofmann＠gmx.de

On Thu, Sep 25, 2008 at 06:28:38PM +0100, Jeremy Henty wrote: > On Thu, Sep 25, 2008 at 06:04:07PM +0200, Johannes Hofmann wrote: > > > Maybe you know that already, but the fltk2 method from the > > test/image.cxx example also sets the _NET_WM_ICON hint: > > No, I missed that. Thanks for pointing it out! It seems that > window.icon() sets the hint. I don't know what to do if you wanted to > set _NET_WM_ICON to a list of icons (of different sizes) rather than > just one. But maybe that's not necessary: test/image specifies a > large icon (64x64) so perhaps it's relying on the desktop to scale it > down as necessary. IIRC the freedesktop.org docs say that the window > manager MAY do that. > > BTW, how do fltk::Window::xclass() and fltk::Window::icon() work? All > they do is set private variables. Somewhere those variables must be > sent to X11 so that something actually happens on the desktop, but I'm > darned if I can see where the FLTK code does it. It seems to be > happening by voodoo. Are we meddling with forces that humanity was > not meant to wield? :-) They hide that stuff in deep in their source tree. It's in src/x11/run.cxx ;-) Johannes

Sept. 25, 2008

Icon for Dillo window

by jcid＠dillo.org

On Thu, Sep 25, 2008 at 03:11:55PM +0100, Jeremy Henty wrote: > On Thu, Sep 25, 2008 at 12:12:26PM +0200, Johannes Hofmann wrote: > > -------- Original-Nachricht -------- > > > Datum: Thu, 25 Sep 2008 08:03:52 +0100 > > > Von: Jeremy Henty <onepoint(a)starurchin.org> > > > An: dillo-dev(a)dillo.org > > > Betreff: Re: [Dillo-dev] Icon for Dillo window > > > > > On Wed, Sep 24, 2008 at 06:48:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > I was thinking it'd be good to provide an icon for the WM to > > > > use. Does anybody know how to do it with FLTK2? > > > > > > It appears not to be possible. In X Windows you set the > > > _NET_WM_ICON hint > > > > test/image.cxx has from the fltk2 tarball shows how to do it. > > That doesn't work on my system (my window manager is icewm). For me > test/image gets the standard X icon in its window frame and in its > taskbar box when miminised (icewm doesn't use desktop icons). Does it > work with any other window managers? It doesn't work here with XFCE. > Icewm sets icons by reading the WM_CLASS hint, interpreting it as the > root of the icon file names and searching for the files in its icon > directories. Unfortunately dillo2 sets WM_CLASS to '"Fltk", "fltk"'. > If it set it to '"Dillo2", "dillo2"' I could configure its icons. Could be. > If we're concerned about dillo2 playing properly with X11 and window > managers then I'd say that it should set WM_CLASS to '"Dillo2", > "dillo2"' on general principle. > > (The weird thing is that my icewm finds the right Firefox icons, yet I > can't find any Firefox icon files in the icon directories. I'm still > trying to figure out where it gets them from.) > > Also, the _NET_WM_ICON hint has the advantage that it can provide a > list of icons of different sizes so that window managers can use a > larger icon eg. when switching between applications with Alt+Tab. If you know a good way to do it, please go ahead. -- Cheers Jorge.-

Sept. 25, 2008

Icon for Dillo window

by onepoint＠starurchin.org

On Thu, Sep 25, 2008 at 06:04:07PM +0200, Johannes Hofmann wrote: > Maybe you know that already, but the fltk2 method from the > test/image.cxx example also sets the _NET_WM_ICON hint: No, I missed that. Thanks for pointing it out! It seems that window.icon() sets the hint. I don't know what to do if you wanted to set _NET_WM_ICON to a list of icons (of different sizes) rather than just one. But maybe that's not necessary: test/image specifies a large icon (64x64) so perhaps it's relying on the desktop to scale it down as necessary. IIRC the freedesktop.org docs say that the window manager MAY do that. BTW, how do fltk::Window::xclass() and fltk::Window::icon() work? All they do is set private variables. Somewhere those variables must be sent to X11 so that something actually happens on the desktop, but I'm darned if I can see where the FLTK code does it. It seems to be happening by voodoo. Are we meddling with forces that humanity was not meant to wield? :-) Regards, Jeremy Henty

Sept. 25, 2008

Icon for Dillo window

by Johannes.Hofmann＠gmx.de

On Thu, Sep 25, 2008 at 06:05:37PM +0100, Jeremy Henty wrote: > > Replying to myself: > > On Thu, Sep 25, 2008 at 04:33:57PM +0100, Jeremy Henty wrote: > > On Thu, Sep 25, 2008 at 04:14:48PM +0200, Johannes Hofmann wrote: > > > On Thu, Sep 25, 2008 at 03:11:55PM +0100, Jeremy Henty wrote: > > > > > > > > If we're concerned about dillo2 playing properly with X11 and > > > > window managers then I'd say that it should set WM_CLASS to > > > > '"Dillo2", "dillo2"' on general principle. > > > > > > Yes that sounds right. > > > > I'll propose a patch later today for comments. > > 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. Cheers, Johannes

Sept. 25, 2008

Icon for Dillo window

by onepoint＠starurchin.org

Replying to myself: On Thu, Sep 25, 2008 at 04:33:57PM +0100, Jeremy Henty wrote: > On Thu, Sep 25, 2008 at 04:14:48PM +0200, Johannes Hofmann wrote: > > On Thu, Sep 25, 2008 at 03:11:55PM +0100, Jeremy Henty wrote: > > > > > > If we're concerned about dillo2 playing properly with X11 and > > > window managers then I'd say that it should set WM_CLASS to > > > '"Dillo2", "dillo2"' on general principle. > > > > Yes that sounds right. > > I'll propose a patch later today for comments. Heh, it's a one liner. I HAZ DILLLO EICONZ NAOW!!! Jeremy Henty

Sept. 25, 2008

Icon for Dillo window

by Johannes.Hofmann＠gmx.de

On Thu, Sep 25, 2008 at 04:33:57PM +0100, Jeremy Henty wrote: > On Thu, Sep 25, 2008 at 04:14:48PM +0200, Johannes Hofmann wrote: > > On Thu, Sep 25, 2008 at 03:11:55PM +0100, Jeremy Henty wrote: > > > > That doesn't work on my system (my window manager is icewm). For > > > me test/image gets the standard X icon in its window frame and in > > > its taskbar box when miminised (icewm doesn't use desktop icons). > > > Does it work with any other window managers? > > > > It worked for me with fvwm. > > OK, then it's worth doing even if it doesn't work everywhere > (especially since the FLTK docs make it clear that nothing will work > everywhere). > > > > If we're concerned about dillo2 playing properly with X11 and > > > window managers then I'd say that it should set WM_CLASS to > > > '"Dillo2", "dillo2"' on general principle. > > > > Yes that sounds right. > > I'll propose a patch later today for comments. > > > > Also, the _NET_WM_ICON hint has the advantage that it can provide > > > a list of icons of different sizes so that window managers can use > > > a larger icon eg. when switching between applications with > > > Alt+Tab. > > > > Hm, no idea what is currently the best way to do this. > > Any X11 specialists here? > > I already have code to set the _NET_WM_ICON hint. It's very > straightforward (I just modified the sample code from one of the bug > reports I linked to earlier). I can verify (using xprop) that the > hint is but I can't check that it will actually affect the icon > (because icewm ignores the hint), and I haven't figured out how to > translate images into the right format. The freedesktop.org > documentation is not completely specific about this. Maybe you know that already, but the fltk2 method from the test/image.cxx example also sets the _NET_WM_ICON hint: from xprop: WM_COMMAND(STRING) = { "./image" } WM_HINTS(WM_HINTS): Client accepts input or input focus: True _NET_WM_ICON(CARDINAL) = 64, 64, 0, 0, 0, 0, 0 ... Regards, Johannes

Sept. 25, 2008

patch: show_msg=NO disable debug messages

by corvid＠lavabit.com

tried turning off show_msg and saw how dillo is still somewhat chatty thanks to DEBUG_MSG. (Or would you prefer a show_debug_messages pref as suggested in dillo2rc? Hmm... thinking about the sentence "Generic messages (mainly for debugging specific parts)", I'd have to say that we use MSG for plenty of debugging messages and DEBUG_MSG for plenty of of-more-general-interest messages.)

Sept. 25, 2008