- Dillo-dev - lists.mailman3.com

MINIX3 wants to port Dillo for GSOC...

by corvid＠lavabit.com

..in case that should interest anyone out there. (http://www.minix3.org/soc-2009/) They have fltk2, libiconv, openssl, zlib, wget, libpng, libjpeg. Not sure about pthreads for DNS...

March 22, 2009

http authentication: shred passwords

by corvid＠lavabit.com

Justus wrote: > I've been working on http digest authentication (mostly done, needs some > more testing) and I noticed that sensitive information like passwords > aren't cleared before freeing the memory. > > I know this is kind of pointless for basic authentication since > realm->authentication holds the base64 encoded password anyway, but at > least it isn't stored in plain text. It is however very useful for the > http digest authentication which only stores the hashed password. > > There is a small problem with the attached patch (at least I think that > there is): it modifies a member variable of fltk::Input that is declared > const char *. I *think* that this does not cause any problems in > practice since the widget is destroyed shortly after this anyway and I > believe that doing this right requires patching fltk. What do you think? So far as I know (for whatever that's worth), it should be all right since the value wasn't set with static_text().

March 22, 2009

http authentication: shred passwords

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

March 22, 2009

[bug]: more CSS margin problems

by onepoint＠starurchin.org

On Sat, Mar 21, 2009 at 10:25:32AM +0100, Hofmann Johannes wrote: > It seems that dw/* is not designed to handle overlapping widgets. > Maybe we should just disable negative margins for now. Or at least > ensure that only margins overlap but not widget contents. Other > ideas? No ideas, I'm afraid. I haven't really looked at Dillo's CSS or layout code. Regards Jeremy Henty

March 22, 2009

Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by Johannes.Hofmann＠gmx.de

On Fri, Mar 20, 2009 at 07:05:24PM +0100, Andreas Kemnade wrote: > Hi, > > On Tue, 24 Feb 2009 20:21:52 +0100 > Detlef Riekenberg <wine.dev(a)web.de> wrote: > > > Hi. > > Thanks for working on Dillo. > > > > I tried to update the Dillo Project Page on Ohloh, > > but the the repository failed on the id command. > > > > ...$hd id http://hg.dillo.org/dillo > > abort: cannot look up remote revision; remote repository does not > > support the 'lookup' capability! > > > $ hg id http://hg.dillo.org/dillo > f4d5923de127 > Thanks Andreas!

March 21, 2009

[bug]: more CSS margin problems

by Johannes.Hofmann＠gmx.de

On Sat, Mar 21, 2009 at 06:54:30AM +0000, Jeremy Henty wrote: > > This looks like a horizontal version of the previous problem I > reported. The online example is > > http://rest-client.heroku.com/rdoc/fr_class_index.html > > The text that sticks out of the left of the coloured area is dead: you > can't select it or click it, and if you drag another window over it > slowly from from left to right then it doesn't redisplay properly. > Minimal example attached. It seems that dw/* is not designed to handle overlapping widgets. Maybe we should just disable negative margins for now. Or at least ensure that only margins overlap but not widget contents. Other ideas? Cheers, Johannes

March 21, 2009

[bug]: more CSS margin problems

by onepoint＠starurchin.org

This looks like a horizontal version of the previous problem I reported. The online example is http://rest-client.heroku.com/rdoc/fr_class_index.html The text that sticks out of the left of the coloured area is dead: you can't select it or click it, and if you drag another window over it slowly from from left to right then it doesn't redisplay properly. Minimal example attached. Regards, Jeremy Henty

March 21, 2009

bookmark dpi - cleanups

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

March 20, 2009

Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by akemnade＠tzi.de

Hi, On Tue, 24 Feb 2009 20:21:52 +0100 Detlef Riekenberg <wine.dev(a)web.de> wrote: > Hi. > Thanks for working on Dillo. > > I tried to update the Dillo Project Page on Ohloh, > but the the repository failed on the id command. > > ...$hd id http://hg.dillo.org/dillo > abort: cannot look up remote revision; remote repository does not > support the 'lookup' capability! > $ hg id http://hg.dillo.org/dillo f4d5923de127 Greetings Andreas Kemnade

March 20, 2009

[bug]: CSS strangeness: disappearing text

by Johannes.Hofmann＠gmx.de

On Fri, Mar 20, 2009 at 05:50:49AM +0000, Jeremy Henty wrote: > > Something funny is happening with this URL > > http://marcofrasca.wordpress.com/2009/03/18/updated-paper/ > > In Dillo, all of the first paragraph except for the last line has > disappeared. Also, if you click and drag around that line you can > make it disappear too. It reappears as soon as you drag the window > anywhere. > > I have stripped this down to a minimal example (attached). Both lines > of the style file have to be present to get the effect. > Interestingly, in Firefox this example also only shows the bottom line > of the paragraph, but it puts it right at the top of the screen. So > it looks as though Dillo sort of understands that most of the > paragraph is invisible, but does not put it in the right place? uh, that one is hard... It has to do with how Textblock places child widgets. It seems that reverting fa7a0bd75ff1 fixes this specific issue, but that causes a lot of other glitches e.g. on google.com. I'll see if I can find a fix. Regards, Johannes

March 20, 2009

[bug]: CSS strangeness: disappearing text

by onepoint＠starurchin.org

Something funny is happening with this URL http://marcofrasca.wordpress.com/2009/03/18/updated-paper/ In Dillo, all of the first paragraph except for the last line has disappeared. Also, if you click and drag around that line you can make it disappear too. It reappears as soon as you drag the window anywhere. I have stripped this down to a minimal example (attached). Both lines of the style file have to be present to get the effect. Interestingly, in Firefox this example also only shows the bottom line of the paragraph, but it puts it right at the top of the screen. So it looks as though Dillo sort of understands that most of the paragraph is invisible, but does not put it in the right place? Regards, Jeremy Henty

March 20, 2009

Re: patch: media_type pref

by Johannes.Hofmann＠gmx.de

On Wed, Mar 18, 2009 at 02:25:55PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > It makes more sense to have a pref that the user can > > > control than for us to guess what they might like > > > based on screen size or whatever, I think. > > > > I hesitate on this. For instance: if media_type is defined to > > "handheld" and there's no such remote CSS, at least it should > > fallback to "screen". > > If there is a handheld style sheet available and dillo is running > on a handheld, it would be a shame not to use it. I'm hoping that > the page author would have the sense to supply something for type "all". Agreed. I think we should first add an option to switch to "handheld" and only apply "handheld" and "all" media styles. Later we can decide whether we want a fallback to "screen". > > > Maybe it's more practical to provide custom stylesheets (as the > > current "style.css". e.g. small_screen.css, print.css) and to > > allow switching among them from the "Tools" menu. > > > > What do you think? > > I think someone using handheld would want to use both the page > author's handheld-specific code and a user style suitable for > their device. Yes, that's the general idea in CSS. We might add a menu item to make it easy for the user to switch between several user stylesheets. But I would only do this if someone really needs/wants it. > > I'll send this to the list in case anyone with experience using > such devices with the web has opinions to share. Unfortunately not me yet :( Cheers, Johannes

March 19, 2009

[patch]: fix compiler warning in CustShrinkTabPager

by onepoint＠starurchin.org

On Thu, Mar 19, 2009 at 08:20:35AM -0400, Jorge Arellano Cid wrote: > On Wed, Mar 18, 2009 at 09:03:18PM +0000, Jeremy Henty wrote: > > > > The CustShrinkTabPager class generates a gcc warning because it > > has virtual functions but its destructor is not virtual. > > What warning do you get? uicmd.cc:68: warning: 'class CustShrinkTabPager' has virtual functions but non-virtual destructor > What version of gcc are you using? 4.1.2 > I'm using gcc version 4.3.2, which is silent on this. Yes, a bit of Googling confirms that this warning disappeared. An unusual case of gcc becoming more permissive in later versions! The issue appears to be that your destructor must be virtual if you are ever going to delete an object of a derived class via a pointer to the base type, otherwise your object won't get properly cleaned up. My gcc seems to be assuming that this is going to happen, since the class has virtual functions. It looks as though your gcc is smart enough to see that we don't actually do this. I'm finding mixed opinions as to what is the right behaviour, but if the latest gcc is happy then it's probably best to take no action. Sorry for the noise. (Time to upgrade again, I think.) Regards, Jeremy Henty

March 19, 2009

sessions [was: Approval]

by rogutes＠googlemail.com

Jorge Arellano Cid (2009-03-18 10:36): > On Sun, Mar 15, 2009 at 10:34:53PM +0000, Tim Nieradzik wrote: <...> > > What really annoys me is that when Dillo crashes, the CPU usage > > climbs onto 100%. The only way I can fix this is to kill all > > Dillo-related processes. This way, I lose my tabs. A session-saver > > like in Mozilla Firefox would be a useful feature but I am not sure > > whether it is worth the "bloatage". > > AFAIS, one of the main features of Dillo is its stability, so > please give us more information on this. Even if dillo is stable, it can crash. Xorg can crash too, or power could be lost, all of which leads to lost sessions. And since dillo has tabs, one session can contain a lot of information. Thus, even if one of the main features is stability, it would still be good to know what the developers think about session saving... Keeping history, contents of forms, i.e. the whole browsing state like Firefox does is not necessary, but a list of opened URLs could be kept in a file, which would be removed on clean exit, no? -- -- Rogut?s Sparnuotos

March 19, 2009

[patch]: fix compiler warning in CustShrinkTabPager

by jcid＠dillo.org

On Wed, Mar 18, 2009 at 09:03:18PM +0000, Jeremy Henty wrote: > > The CustShrinkTabPager class generates a gcc warning because it has > virtual functions but its destructor is not virtual. This patch adds > the virtual destructor and stops the warning. > > NB: there may be a case for rejecting this patch if we're really > concerned about the performance of virtual functions (one extra > indirection per call). FLTK deliberately avoids virtual destructors > whenever possible for just this reason. I seriously doubt that this > patch makes any impact on Dillo, but that's just IMHO. What warning do you get? What version of gcc are you using? I'm using gcc version 4.3.2, which is silent on this. -- Cheers Jorge.-

March 19, 2009

[patch]: remove the BW_* flags

by onepoint＠starurchin.org

On Wed, Mar 18, 2009 at 09:26:14AM -0400, Jorge Arellano Cid wrote: > On Fri, Mar 13, 2009 at 05:52:07PM +0000, Jeremy Henty wrote: > > Yes, there is a case for keeping the flags for future development. > > I'd prefer to keep the flags. OK, I'll drop the patch and work on the rest. > > Just so you know, the cleanups I have pending refactor a lot of > > code that calls the dList_* API in convoluted and inefficient > > ways. [...] > [...] > dList API was designed with a minimal working function set in > mind. This keeps the API easy to remmeber and use. I'm sure that's right but there's a lot of repeated code wherever dLists are cleaned up. That makes me think that the current API is a little *too* minimal. > Please try to get some performance numbers, and in the meanwhile > send me a summary of the API changes. I will. Regards, Jeremy Henty

March 19, 2009

[patch]: fix compiler warning in CustShrinkTabPager

by onepoint＠starurchin.org

The CustShrinkTabPager class generates a gcc warning because it has virtual functions but its destructor is not virtual. This patch adds the virtual destructor and stops the warning. NB: there may be a case for rejecting this patch if we're really concerned about the performance of virtual functions (one extra indirection per call). FLTK deliberately avoids virtual destructors whenever possible for just this reason. I seriously doubt that this patch makes any impact on Dillo, but that's just IMHO. Regards, Jeremy Henty

March 18, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

On Mon, Mar 09, 2009 at 04:54:57PM +0100, Tim Nieradzik wrote: > [...] > PS: I would like to port some C files to C++ in order to achieve > more consistency. What is your opinion on this? Please don't. C++ is an unfortunate compromise we had to make to be able to use FLTK2. It has increased complexity, reduced portability and we'd like to confine it to a minimum (in size and features). > Submitting a patch > for each changed file to the list might be a bit inconvenient. That's not the idea. One changeset (which can touch several files) per email is the standard. > Therefore, I am considering creating a repository on FreeHg.org > which only deals with refactoring code. Separate repos. are suggested for major changes (as the CSS branch). -- Cheers Jorge.-

March 18, 2009

Re: Approval

by jcid＠dillo.org

Hi, On Sun, Mar 15, 2009 at 10:34:53PM +0000, Tim Nieradzik wrote: > Hi Jorge, > > > Please send it to me and I'll send you a dillo.org based URL > > so you can refer to it. > > Unfortunately I had already deleted the mail but here are some > information from my maildrop log that might be useful for you: > > Date: Mon Mar 9 17:00:12 2009 > From: dillo-dev-bounces(a)dillo.org > Subj: Your message to Dillo-dev awaits moderator approval > Size: 1902 Message found and approved. > By the way, I think I have found three bugs in Dillo. Whenever I > visit the site https://oss.gonicus.de/labs/gosa/wiki, it asks me > whether I want to accept the certificate about 10 times (probably > for each picture and CSS file). A way to solve it would be to > remember the selection for all links on this page but this could > become to a big security risk as people could misuse this behaviour > for phishing sites. This is BUG#868 in the tracker. The solution is to turn the https dpi into a server (it's a filter now). This is not complex but takes time. I don't want to delay the next release even more so most probably it will be in the release after dillo-2.1. > The other bug appears on http://urldecode.info/ where no pictures > are displayed. My vague assumption is that Dillo cannot handle > images whose headers contain a "Location" header. Dillo just checks > whether the Content-Length header contains anything (this is why it > works for 0). It seems to me that Dillo downloads the picture > properly but does not show it because it thinks the size is supposed > to be 0. Yes, historically dillo doesn't follow image redirections. Over time this has helped to reduce advertising (most image redirections are advertising). > [...] > A possible solution would be to overwrite all headers by the ones > from the redirected URL ("Location" header). Or would it be better > to delete all available headers when a "Location" headers was found? For "root" URLs, redirection is working, the same/similar method my be re-used for images. The point is whether it's desirable to do it. For instance, with a load_remote_images pref, it would work, but lot's of advertising would pass too. When disabled, sites as the one you cite won't work. If we let the user toggle this pref from "Tools" it would feel clumsy to do it for a favorite site. Now, we may solve all this with URL filtering. Let's say filtering has higher priority, and we have "allow" and "deny" options (just think of hosts not RE by now to discard performance issues). In the above described case I'd choose to set: allow file content = urldecode.info load_image_redirections = NO meaning that when visiting urldecode.info, remote image redirections will be loaded. The API should allow setting this automatically from the tools menu (e.g. "allow remote images" option with a short dialog: Do you want to enable remote image loading permanently for site xxx.yyy.zzz? [Allow] [Cancel]) URL filtering based on regular expressions is expensive in CPU terms, that's why I like the idea of HOST-based filtering. With it you can deny as a general rule and have some allow exceptions. (BTW, as a last resource if all this is not enough, RE support may be added on top). > The third issue (which only occurs in the Hg tree) looks like a > timing bug. When visiting http://www.golem.de/0903/65726.html not > all of the pictures are shown but when reloading the page, they are. > Interestingly, it works perfectly if I save the page to disk and > then view it manually in Dillo. This needs some ivestigation... > When is the final version planned to be released? I'll have more time in April, so probably April. > In my opinion we > should wait a few weeks because Dillo crashes regularly on my > machines (always running the trunk version). This is strange, I very seldom get a dillo crash. Can you post example URLs, more details of your OS/FLTK-version/settings? > Therefore a release > candidate every two would be useful for the users to give feedback > and to report further bugs. After all of the major bugs have been > fixed, we could announce the final version. That's the idea. > Is it planned to include > the key bindings patch into this version? This should not be a big > deal for the users as the configuration files are backward > compatible. No, it's not planned. Now if the patch is simple, clean and straightforward and I can review it before rc1, and behaves well in testing, then it may go in. > What really annoys me is that when Dillo crashes, the CPU usage > climbs onto 100%. The only way I can fix this is to kill all > Dillo-related processes. This way, I lose my tabs. A session-saver > like in Mozilla Firefox would be a useful feature but I am not sure > whether it is worth the "bloatage". AFAIS, one of the main features of Dillo is its stability, so please give us more information on this. > PS: What is the accurate way to find those memory leaks? I remember > Jeremy speaking about Valgrind which he used to create his "crash > reports". Valgrind is cetainly a great tool for the job. -- Cheers Jorge.-

March 18, 2009

Re: patch: media_type pref

by corvid＠lavabit.com

Jorge wrote: > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > It makes more sense to have a pref that the user can > > control than for us to guess what they might like > > based on screen size or whatever, I think. > > I hesitate on this. For instance: if media_type is defined to > "handheld" and there's no such remote CSS, at least it should > fallback to "screen". If there is a handheld style sheet available and dillo is running on a handheld, it would be a shame not to use it. I'm hoping that the page author would have the sense to supply something for type "all". > Maybe it's more practical to provide custom stylesheets (as the > current "style.css". e.g. small_screen.css, print.css) and to > allow switching among them from the "Tools" menu. > > What do you think? I think someone using handheld would want to use both the page author's handheld-specific code and a user style suitable for their device. I'll send this to the list in case anyone with experience using such devices with the web has opinions to share.

March 18, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

Here is an updated version of the patch. It aims to be fully backward compatible. You do not need to change anything in your dillorc (put the key bindings into ~/.dillo/keysrc). Changes: - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). - Split src/prefs.c (parser is now in src/prefsparser.c). - Changed method names in src/dillo.cc to use camel case. - Added meta-modifier and function keys F10-F12. - Key bindings are to be defined in keysrc (previously dillorc). - Fixed some inconsistent white spaces. - Shortened some license headers. - Minor code cleanups such as using "TODO:" instead of "\todo". - Removed a_Prefs_freeall because it was not used anywhere. PS: I would like to port some C files to C++ in order to achieve more consistency. What is your opinion on this? Submitting a patch for each changed file to the list might be a bit inconvenient. Therefore, I am considering creating a repository on FreeHg.org which only deals with refactoring code. --Tim

March 18, 2009

[patch]: remove the BW_* flags

by jcid＠dillo.org

Hi, On Fri, Mar 13, 2009 at 05:52:07PM +0000, Jeremy Henty wrote: > On Fri, Mar 13, 2009 at 08:40:45AM -0300, Jorge Arellano Cid wrote: > > > Anyway I reviewed the patch back then, and remembered that the > > current interface was meant for flexibility to experiment. > > Yes, there is a case for keeping the flags for future development. I > just wanted to point that they are currently redundant and we could > remove them if we wanted. I'd prefer to keep the flags. > > I have to give it a second review. Anyway, if there're more cleanups > > pending on this patch, it may be worth accepting them > > Just so you know, the cleanups I have pending refactor a lot of code > that calls the dList_* API in convoluted and inefficient ways. (Most > stuff that call dList_remove() are like this.) You get cleaner and > more efficient code by defining new dList_remove_* and dList_free_* > functions, because that lets you replace lots of convoluted code paths > that call dList_remove(), dList_nth_data() etc. with single API calls. dList API was designed with a minimal working function set in mind. This keeps the API easy to remmeber and use. Now, if there's a measurable performance gain with the added functions it may be worth adding them. > One function that gets refactored is a_Bw_stop_clients(), which is why > submitting the cleanup patches is waiting on the decision about the > BM_Flags patch. It won't be hard to fix the cleanup patches if the > BM_Flags patch does not go in, but until the decision is made I don't > know whether or not to do that. Please try to get some performance numbers, and in the meanwhile send me a summary of the API changes. -- Cheers Jorge.-

March 18, 2009

[patch]: fix comment for DLWin::del()

by jcid＠dillo.org

On Wed, Mar 18, 2009 at 06:27:17AM +0000, Jeremy Henty wrote: > > > The comment for DLWin::del() was copied and pasted from > > DLWin::new(), but never corrected! > > And here's the patch. D'oh! Committed. -- Cheers Jorge.-

March 18, 2009

Re: Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by akemnade＠tzi.de

Hi, On Tue, 17 Mar 2009 20:41:19 +0100 Detlef Riekenberg <wine.dev(a)web.de> wrote: > On Di, 2009-02-24 at 20:21 +0100, Detlef Riekenberg wrote: > > Hi. > > Thanks for working on Dillo. > > > > I tried to update the Dillo Project Page on Ohloh, > > but the the repository failed on the id command. > > > > ...$ hg id http://hg.dillo.org/dillo > > abort: cannot look up remote revision; remote repository does not > > support the 'lookup' capability! > > > > Which Mercurial version is used to serve dillo? > > Ohloh still can't accept the current dillo repository, because "hg id" > failed: > hg id http://hg.dillo.org/dillo > > Any Ideas, who can fix the repository configuration? > I have not updated the server yet (I'll to it at the weekend). I qoute myself: It is Mercurial Distributed SCM (version 0.9.1) Thats the version coming with debian etch. The id command works differently in the newer versions. I plan to upgrade at the end of march at the latest to the just-released stable. Greetings Andreas Kemnade

March 18, 2009

[patch]: fix comment for DLWin::del()

by onepoint＠starurchin.org

> The comment for DLWin::del() was copied and pasted from > DLWin::new(), but never corrected! And here's the patch. D'oh! Jeremy Henty

March 18, 2009

[patch]: fix comment for DLWin::del()

by onepoint＠starurchin.org

The comment for DLWin::del() was copied and pasted from DLWin::new(), but never corrected! Regards, Jeremy Henty

March 18, 2009

Re: Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by wine.dev＠web.de

On Di, 2009-02-24 at 20:21 +0100, Detlef Riekenberg wrote: > Hi. > Thanks for working on Dillo. > > I tried to update the Dillo Project Page on Ohloh, > but the the repository failed on the id command. > > ...$ hg id http://hg.dillo.org/dillo > abort: cannot look up remote revision; remote repository does not > support the 'lookup' capability! > > Which Mercurial version is used to serve dillo? Ohloh still can't accept the current dillo repository, because "hg id" failed: hg id http://hg.dillo.org/dillo Any Ideas, who can fix the repository configuration? -- By by ... Detlef

March 17, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Mon, Mar 16, 2009 at 10:49:41PM +0100, Hofmann Johannes wrote: > How long does it take you to get e.g. the image related leak > messages? Very hard to say. It never seems to happen after just a few minutes, but after a few hours it's pretty common. > Are you doing anything special? Not that I can tell, just surfing lots. Regards, Jeremy Henty

March 17, 2009

My valgrind logs, for all to see.

by Johannes.Hofmann＠gmx.de

On Mon, Mar 16, 2009 at 09:36:20PM +0000, Jeremy Henty wrote: > On Mon, Mar 16, 2009 at 07:18:14PM +0100, Hofmann Johannes wrote: > > > in your valgrind logs I see references to "dList_truncate_free_data" > > which I can't find anywhere in the sources. Do you have some > > uncommitted patches in your tree? > > Yes, this is part of the dList_* API cleanup I talked about elsewhere. > Unfortunately those patches are stuck in my (Mercurial) queue ahead of > the BW_* flags cleanup patch, which has been submitted and not > reviewed yet. > > I realise that it is unhelpful to anyone using my valgrind logs that > my Dillo is so heavily patched at the moment. Would it help if I push > the BW_* flags cleanup patch back up my queue and submit the dList_* > API patches instead? They might be easier to review (as they are just > refactorings) and once they were out of the way (whether accepted or > rejected) the divergence between my Dillo and the mainstream would be > small again. (BTW, there has always been some small divergence, but > this is the first time there has been a persistent large divergence > that has affected the valgrind logs.) I'd like to fix as many valgrind errors as possible before the release. But it's pretty hard as I can't reproduce them myself. How long does it take you to get e.g. the image related leak messages? Are you doing anything special? Regards, Johannes

March 16, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Mon, Mar 16, 2009 at 07:18:14PM +0100, Hofmann Johannes wrote: > in your valgrind logs I see references to "dList_truncate_free_data" > which I can't find anywhere in the sources. Do you have some > uncommitted patches in your tree? Yes, this is part of the dList_* API cleanup I talked about elsewhere. Unfortunately those patches are stuck in my (Mercurial) queue ahead of the BW_* flags cleanup patch, which has been submitted and not reviewed yet. I realise that it is unhelpful to anyone using my valgrind logs that my Dillo is so heavily patched at the moment. Would it help if I push the BW_* flags cleanup patch back up my queue and submit the dList_* API patches instead? They might be easier to review (as they are just refactorings) and once they were out of the way (whether accepted or rejected) the divergence between my Dillo and the mainstream would be small again. (BTW, there has always been some small divergence, but this is the first time there has been a persistent large divergence that has affected the valgrind logs.) Regards, Jeremy Henty

March 16, 2009

My valgrind logs, for all to see.

by Johannes.Hofmann＠gmx.de

Hi Jeremy, in your valgrind logs I see references to "dList_truncate_free_data" which I can't find anywhere in the sources. Do you have some uncommitted patches in your tree? Cheers, Johannes

March 16, 2009

Too busy...

by jcid＠dillo.org

Hi, Please excuse me for being silent these days. It's being full of activities for me. Besides the regular job, I'm moving to another place and have a trip out of the city the next weekend. Rolling a release needs more than a couple spare days so, it will have to wait. I'll surely have more time when April starts, if I have some time before that, I'll try to answer the pending emails. The current repo is almost rc1. After the "instant META redirection" patch goes in, it'll be rc1, and the release procedures will start. -- Cheers Jorge.-

March 15, 2009

[patch]: remove the BW_* flags

by onepoint＠starurchin.org

On Fri, Mar 13, 2009 at 08:40:45AM -0300, Jorge Arellano Cid wrote: > Anyway I reviewed the patch back then, and remembered that the > current interface was meant for flexibility to experiment. Yes, there is a case for keeping the flags for future development. I just wanted to point that they are currently redundant and we could remove them if we wanted. > I have to give it a second review. Anyway, if there're more cleanups > pending on this patch, it may be worth accepting them Just so you know, the cleanups I have pending refactor a lot of code that calls the dList_* API in convoluted and inefficient ways. (Most stuff that call dList_remove() are like this.) You get cleaner and more efficient code by defining new dList_remove_* and dList_free_* functions, because that lets you replace lots of convoluted code paths that call dList_remove(), dList_nth_data() etc. with single API calls. One function that gets refactored is a_Bw_stop_clients(), which is why submitting the cleanup patches is waiting on the decision about the BM_Flags patch. It won't be hard to fix the cleanup patches if the BM_Flags patch does not go in, but until the decision is made I don't know whether or not to do that. Regards, Jeremy Henty

March 13, 2009

[patch]: remove the BW_* flags

by jcid＠dillo.org

On Thu, Mar 12, 2009 at 08:38:21PM +0100, Hofmann Johannes wrote: > On Thu, Mar 12, 2009 at 10:36:08AM +0000, Jeremy Henty wrote: > > > > I wrote: > > > > > a_Bw_stop_clients() is always called with the BW_Root and BW_Img > > > flags set, so we can remove those flags. That leaves only the > > > BW_Force flag, so we can remove that too and change the flags > > > argument to a boolean that indicates whether to force. > > > > What's the verdict on this? I haven't seen any comments. I have some > > other cleanups and refactoring to propose and some of those patches > > depend on this one, so it would be good know whether or not it will go > > in so I can ready the rest for submission. > > Sorry, I can't comment on this one as I don't know the > relevant code enough. Let's wait for Jorge to comment. Sorry, I've had little time latelely... Anyway I reviewed the patch back then, and remembered that the current interface was meant for flexibility to experiment. The smantics for STOP were/are not well defined yet, and so the flags API lingered. I have to give it a second review. Anyway, if there're more cleanups pending on this patch, it may be worth accepting them and at worst to re-introduce the flags when STOP semantics get high priority (if ever). -- Cheers Jorge.-

March 13, 2009

[PATCH 0 of 3] tweaking the dillo ui for embedded devices

by jcid＠dillo.org

On Thu, Mar 12, 2009 at 11:07:58PM +0100, Andreas Kemnade wrote: > Hi, > > On Wed, 11 Mar 2009 08:41:20 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Tue, Mar 10, 2009 at 02:12:56AM +0100, Justus Winter wrote: > > > Hofmann Johannes wrote: > > >> Hi Justus, > > >> > > >> On Mon, Mar 09, 2009 at 05:59:31PM +0100, Justus Winter wrote: > > >>> Hey folks :) > > >>> > > >>> I've got a new toy (the Neo FreeRunner) and dillo2 runs quite nicely > > >>> on that little device, but there are some problems: > > >>> > > >>> * there is no way to create bookmarks > > >> > > >> What about the context menus in general? Is there no way to simulate > > >> a right mouse click? dillo uses context menus in many cases so we > > >> probabely need a general solution for this. > > > There is a module for gtk2 (libgtkstylus.so) that simulates a right > > > click when the user holds the left mouse button, that works quite nicely > > > in practice. > > > > Andreas suggestd the same, and it looks like a good solution. > > Even more if handheld users are accustomed to it. > > > > > That was actually what I wanted to implement at first. I looked through > > > the fltk2 event handling code (most thoroughly with respect to the > > > button widget) [...] > > > I have done a quick-hack for proof-of-concept purposes. > It is a really dirty patch. But maybe it is a starting point for experimenting. > If the button is released after pressing it more than two seconds, > the menu will popup on the page. > I have successfully added bookmarks without using the right mouse button. Good. Please continue working on this line into a clean patch. Also wrapping it with a pref switch looks right: e.g. emulate_right_click > > Maybe something like what's used for tooltip can be of help. > > This has to be asked in fltk general before discarding it. > > > > If there's no way, a right-click button may be of help. This is > > left-click on RCB and the next left-click will be processed as a > > right click. > > > A button like that does already exist. It is a matchbox-panel app > called xmonobut. > It toggles the button you hit when you touch the touchscreen. > I don't know why I don't get it work with the freerunner yet. > On my Ipaq I have no problems with it. Asking xmonobut developers may save some work. Anyway having the option in dillo doesn't hurt much. -- Cheers Jorge.-

March 13, 2009

[PATCH 0 of 3] tweaking the dillo ui for embedded devices

by akemnade＠tzi.de

Skipped content of type multipart/mixed

March 12, 2009

[patch]: remove the BW_* flags

by Johannes.Hofmann＠gmx.de

On Thu, Mar 12, 2009 at 10:36:08AM +0000, Jeremy Henty wrote: > > I wrote: > > > a_Bw_stop_clients() is always called with the BW_Root and BW_Img > > flags set, so we can remove those flags. That leaves only the > > BW_Force flag, so we can remove that too and change the flags > > argument to a boolean that indicates whether to force. > > What's the verdict on this? I haven't seen any comments. I have some > other cleanups and refactoring to propose and some of those patches > depend on this one, so it would be good know whether or not it will go > in so I can ready the rest for submission. Sorry, I can't comment on this one as I don't know the relevant code enough. Let's wait for Jorge to comment. Cheers, Johannes

March 12, 2009

[patch]: remove the BW_* flags

by onepoint＠starurchin.org

I wrote: > a_Bw_stop_clients() is always called with the BW_Root and BW_Img > flags set, so we can remove those flags. That leaves only the > BW_Force flag, so we can remove that too and change the flags > argument to a boolean that indicates whether to force. What's the verdict on this? I haven't seen any comments. I have some other cleanups and refactoring to propose and some of those patches depend on this one, so it would be good know whether or not it will go in so I can ready the rest for submission. Regards, Jeremy Henty

March 12, 2009

[PATCH 3 of 3] Easy panning with the left mouse button

by darirf＠yahoo.es

Hi! As this is my first post to the list: hello, I'm the one that ported (or broke, depending on your the point of view) dillo 0.8.6 for the iRex iLiad e-book reader; my alias in mobileread.com is Antartica. I've been reading the lists for some time now, but didn't thought I had anything to share yet. But... I agree with Justus in that panning is the easiest method to scroll in embedded devices; the scroll bar is very small and enlarging it wastes too much screen state. For the iliad port of dillo 0.8.6 I did exactly what Justus is proposing of left-button-does-panning (albeit in a hackish way, as I hardcoded that behaviour). For reference, the patch to old dillo 0.8.6 is in: http://projects.mobileread.com/iliad/users/antartica/dillo/dillo-patch-spli… I was actually doing the same for dillo2, but only have it partly-done (see attach). I would love to have Justus code merged in mainline, as it implements that functionality neatly and it would alleviate me from finishing my hack :). Right now I can't test Justus patch, but I had one error to fix in mine: it didn't pan when showing images. Its worth checking if Justus patch have that right. Anyway, you all are doing an excellent job in keeping dillo relevant. It is really a nice piece of work :). Congrats. Regards, Dario. --- El lun, 9/3/09, Justus Winter <4winter(a)informatik.uni-hamburg.de> escribi?: > De: Justus Winter <4winter(a)informatik.uni-hamburg.de> > Asunto: [Dillo-dev] [PATCH 3 of 3] Easy panning with the left mouse button > Para: dillo-dev(a)dillo.org > Fecha: lunes, 9 marzo, 2009 5:59 > # HG changeset patch > # User Justus Winter > <justus.winter(a)informatik.uni-hamburg.de> > # Date 1236616924 -3600 > # Node ID 46c62dde8967ae87914d0fbcc0ba7df61853750c > # Parent 78c0fa261c84df53da7f69cc8f33dc85fa152f9c > Easy panning with the left mouse button > > This is particulary useful for embedded devices with touch > screens. > In order to select text you have to double click and drag > the pointer. > > Note that this functionality is disabled by default and can > be enabled > by the easy_panning directive in the configuration file > with the > exception of the selection behavior which is located in > dw/selection.cc > and lacks a reference to the prefs struct by design (dw is > a toolkit and > frontend agnostic). > > I think that dw needs an interface to tweak it's > behaviour > ie dw_config(DW_DOUBLECLICK_TO_SELECT, true). Any ideas? > [...]

March 12, 2009

Holiday week

by jcid＠dillo.org

On Wed, Mar 11, 2009 at 06:28:22PM +0100, Hofmann Johannes wrote: > On Sat, Feb 21, 2009 at 11:47:56AM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > > I happen to be enjoying a much needed holiday week! :-) > > > > The plan is to come back around near wednesday 25. > > > > In the meanwhile, I leave you with the following issues lurking > > in my list to be considered. Maybe all of them can be left to the > > release after 2.1, but maybe not: > > > > [ ] https dialog bombing issue. BUG#868 > > When enabled, multiple https requests to the same site result > > in dialog bombing. The https dpi is disabled by default in > > Dillo. Anyway, in Debian, there's a security warning against > > dillo for not checking certificates (I don't know what > > version of dillo they use, nor why they enable https.) > > > > [ ] Jump to #anchor doesn't work correctly. > > The idle timeout doesn't work reliably (an old bug). > > > > [ ] Implement @import statement in STYLE element. > > > > [ ] What will we do with xhtml? FF doesn't validate. BUG#732 > > This would be interesting to define. > > (already suggested as discussion material in another thread). > > > > [ ] "-fno-rtti -fno-exceptions" gcc: 64KB less. > > Enabling this switches reduces the binary size. > > > > [ ] dpi for "view page source" (it re-uses search capability). > > Waiting since a long time... > > Do we really need a dpi for this? As long as we don't do syntax > highlighting (which would be nice) we could also do it in dillo > directly. The "View Stylesheets" code is really minimal. As far as I > can see we would need a way to force a certain mime type > (text/plain in this case). Any ideas how to do this? Yes, the dpi can easily add line numbers which are very handy to have. The extra code inside dillo is very small and the dpi too. -- Cheers Jorge.-

March 11, 2009

Holiday week

by Johannes.Hofmann＠gmx.de

On Sat, Feb 21, 2009 at 11:47:56AM -0300, Jorge Arellano Cid wrote: > Hi there, > > I happen to be enjoying a much needed holiday week! :-) > > The plan is to come back around near wednesday 25. > > In the meanwhile, I leave you with the following issues lurking > in my list to be considered. Maybe all of them can be left to the > release after 2.1, but maybe not: > > [ ] https dialog bombing issue. BUG#868 > When enabled, multiple https requests to the same site result > in dialog bombing. The https dpi is disabled by default in > Dillo. Anyway, in Debian, there's a security warning against > dillo for not checking certificates (I don't know what > version of dillo they use, nor why they enable https.) > > [ ] Jump to #anchor doesn't work correctly. > The idle timeout doesn't work reliably (an old bug). > > [ ] Implement @import statement in STYLE element. > > [ ] What will we do with xhtml? FF doesn't validate. BUG#732 > This would be interesting to define. > (already suggested as discussion material in another thread). > > [ ] "-fno-rtti -fno-exceptions" gcc: 64KB less. > Enabling this switches reduces the binary size. > > [ ] dpi for "view page source" (it re-uses search capability). > Waiting since a long time... Do we really need a dpi for this? As long as we don't do syntax highlighting (which would be nice) we could also do it in dillo directly. The "View Stylesheets" code is really minimal. As far as I can see we would need a way to force a certain mime type (text/plain in this case). Any ideas how to do this? Cheers, Johannes

March 11, 2009

My valgrind logs, for all to see.

by Johannes.Hofmann＠gmx.de

On Wed, Mar 11, 2009 at 01:54:00PM +0000, Jeremy Henty wrote: > On Wed, Mar 11, 2009 at 02:10:21PM +0100, Hofmann Johannes wrote: > > Hi Jeremy, > > > > in your valgrind there are still these massive DilloImage related > > leaks. > > My apologies, the version of your patch that I was using failed to > apply after a recent pull so I dropped it and never got round to > fixing it. So it's not been in my local Dillo for the past few days. > > > Can you please make sure that you are running the latest version of > > my img_ref patch (attached)? > > I just merged it. Thanks very much! Ah ok. Let's see if it helps. Cheers, Johannes

March 11, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Wed, Mar 11, 2009 at 02:10:21PM +0100, Hofmann Johannes wrote: > Hi Jeremy, > > in your valgrind there are still these massive DilloImage related > leaks. My apologies, the version of your patch that I was using failed to apply after a recent pull so I dropped it and never got round to fixing it. So it's not been in my local Dillo for the past few days. > Can you please make sure that you are running the latest version of > my img_ref patch (attached)? I just merged it. Thanks very much! Regards, Jeremy Henty

March 11, 2009

My valgrind logs, for all to see.

by Johannes.Hofmann＠gmx.de

Hi Jeremy, in your valgrind there are still these massive DilloImage related leaks. Can you please make sure that you are running the latest version of my img_ref patch (attached)? I add added prints to a_Image_new() and Image_free() and recorded them in a logfile. With the patch the numbers seem to match fine here. Cheers, Johannes

March 11, 2009

Holiday week

by jcid＠dillo.org

On Mon, Mar 09, 2009 at 01:16:10AM +0000, corvid wrote: > Jorge wrote: > > [ ] "-fno-rtti -fno-exceptions" gcc: 64KB less. > > Enabling this switches reduces the binary size. > > Is there more to this than the following: Not that I remember (my patch got lost somehow, it had some test for those options being already set, but maybe it's not worth doing it after all). Committed. @all: after this patch the binary size is smaller. e.g. -rwxr-xr-x 1 jcid jcid 983092 2009-03-11 09:11 dillo -- Cheers Jorge.-

March 11, 2009

[PATCH 0 of 3] tweaking the dillo ui for embedded devices

by jcid＠dillo.org

On Tue, Mar 10, 2009 at 02:12:56AM +0100, Justus Winter wrote: > Hofmann Johannes wrote: >> Hi Justus, >> >> On Mon, Mar 09, 2009 at 05:59:31PM +0100, Justus Winter wrote: >>> Hey folks :) >>> >>> I've got a new toy (the Neo FreeRunner) and dillo2 runs quite nicely >>> on that little device, but there are some problems: >>> >>> * there is no way to create bookmarks >> >> What about the context menus in general? Is there no way to simulate >> a right mouse click? dillo uses context menus in many cases so we >> probabely need a general solution for this. > There is a module for gtk2 (libgtkstylus.so) that simulates a right > click when the user holds the left mouse button, that works quite nicely > in practice. Andreas suggestd the same, and it looks like a good solution. Even more if handheld users are accustomed to it. > That was actually what I wanted to implement at first. I looked through > the fltk2 event handling code (most thoroughly with respect to the > button widget) [...] Maybe something like what's used for tooltip can be of help. This has to be asked in fltk general before discarding it. If there's no way, a right-click button may be of help. This is left-click on RCB and the next left-click will be processed as a right click. The idea is to try to reuse the UI as much as possible, and to just code the necessary hooks for it. Please contact Andreas K., he may have good ideas for handheld related issues. -- Cheers Jorge.-

March 11, 2009

[PATCH 0 of 3] tweaking the dillo ui for embedded devices

by 4winter＠informatik.uni-hamburg.de

Hofmann Johannes wrote: > Hi Justus, > > On Mon, Mar 09, 2009 at 05:59:31PM +0100, Justus Winter wrote: >> Hey folks :) >> >> I've got a new toy (the Neo FreeRunner) and dillo2 runs quite nicely >> on that little device, but there are some problems: >> >> * there is no way to create bookmarks > > What about the context menus in general? Is there no way to simulate > a right mouse click? dillo uses context menus in many cases so we > probabely need a general solution for this. There is a module for gtk2 (libgtkstylus.so) that simulates a right click when the user holds the left mouse button, that works quite nicely in practice. That was actually what I wanted to implement at first. I looked through the fltk2 event handling code (most thoroughly with respect to the button widget) and I am convinced that this behavior cannot be implemented without patching fltk2 since the widgets do not call the callback when the button is pressed but only when it's released. I prototyped a solution that abuses the DRAG events to detect PUSH events, but that didn't work very well since DRAG events are only emitted when the cursor moves. Patching fltk2 to also call the callback function on PUSH events is problematic since (at least in dillo2) many callback functions do not test properly whether they are actually interested in that particular event and just assume that it must have been a RELEASE event. >> Adressed in the second patch which adds an add bookmark button to >> the main toolbar. > > What about a dillorc option to make it optional like the other > buttons? Sure thing, that would be great. It shouldn't be too hard to make the toolbar content configurable. >> * the scrollbars are unusable without a stylus >> >> A more natural way of scrolling on embedded devices with touchscreens >> is finger scrolling. A proof of concept is attached as the third patch. > > Didn't look at the code yet, but the concept seems nice. > Maybe we could ship a "dillorc.handheld" or something like that... The changes are actually quite small since a similar functionality was already present, namely panning via the middle mouse button. My patch just adds a configuration option to do so with the left button and to fiddle with the event handling code (you have to pass some events to the page content or you end up with a browser with non functional links :)). Note that this is just a mockup that needs some cleanups (works only for the first tab, need to adjust the open tab functionality in uicmd, text selection works fine with a mouse but is next to impossible on the moko due to double click tolerances (at least thats what I think)). And the text selection part is not configurable at the moment, that's the most problematic part. Any thoughts on how to make dw configurable at runtime while keeping it implementation agnostic with respect to the frontend? Justus

March 10, 2009

[PATCH 0 of 3] tweaking the dillo ui for embedded devices

by Johannes.Hofmann＠gmx.de

Hi Justus, On Mon, Mar 09, 2009 at 05:59:31PM +0100, Justus Winter wrote: > Hey folks :) > > I've got a new toy (the Neo FreeRunner) and dillo2 runs quite nicely > on that little device, but there are some problems: > > * there is no way to create bookmarks What about the context menus in general? Is there no way to simulate a right mouse click? dillo uses context menus in many cases so we probabely need a general solution for this. > > Adressed in the second patch which adds an add bookmark button to > the main toolbar. What about a dillorc option to make it optional like the other buttons? > > * the scrollbars are unusable without a stylus > > A more natural way of scrolling on embedded devices with touchscreens > is finger scrolling. A proof of concept is attached as the third patch. Didn't look at the code yet, but the concept seems nice. Maybe we could ship a "dillorc.handheld" or something like that... > > Acceleration would be a nice feature for big pages. > > * buttons on dialogs are too small > > Proposed solution: There is code for creating dialogs in src/dialog.cc > for a_Dialog_choice5 that creates the dialog window without relying on > fltks choice(). We could generalize that and use it for all dialogs. That would be a good thing anyway so that all dialogs share a consistent look. > > This way we could resize the buttons and stack them vertically on top > of each other. Why not, if that's better for mobile devices and if it's configurable. Cheers, Johannes

March 9, 2009

[PATCH 2 of 3] Add a bookmark button to the toolbar

by 4winter＠informatik.uni-hamburg.de

# HG changeset patch # User Justus Winter <justus.winter(a)informatik.uni-hamburg.de> # Date 1236615692 -3600 # Node ID 78c0fa261c84df53da7f69cc8f33dc85fa152f9c # Parent 9638f05098cf2687dbb863f47fd82461c5417403 Add a bookmark button to the toolbar This is useful for embedded devices with touch screens which lack a proper keyboard and the ability to generate right click events. diff -r 9638f05098cf -r 78c0fa261c84 src/pixmaps.h --- a/src/pixmaps.h Mon Mar 09 17:17:51 2009 +0100 +++ b/src/pixmaps.h Mon Mar 09 17:21:32 2009 +0100 @@ -789,6 +789,34 @@ " . . "}; /* XPM */ +static const char * bm_add_xpm[] = { +"22 22 2 1", +" c None", +". c #FF0000", +" ", +" ", +" ", +" ... ", +" ... ", +" ... ", +" ... ", +" ... ", +" ... ", +" ............... ", +" ............... ", +" ............... ", +" ... ", +" ... ", +" ... ", +" ... ", +" ... ", +" ... ", +" ", +" ", +" ", +" "}; + +/* XPM */ static const char *const tools_xpm[] = { "22 22 25 1", " c #None", @@ -1373,6 +1401,28 @@ " .v. wx. "}; /* XPM */ +static const char * bm_add_s_xpm[] = { +"16 16 2 1", +" c None", +". c #FF0000", +" ", +" ", +" .. ", +" .. ", +" .. ", +" .. ", +" .. ", +" ........... ", +" ........... ", +" .. ", +" .. ", +" .. ", +" .. ", +" ", +" ", +" "}; + +/* XPM */ static const char *const tools_s_xpm[] = { "16 16 45 1", " c #7B127D1C7D08", diff -r 9638f05098cf -r 78c0fa261c84 src/ui.cc --- a/src/ui.cc Mon Mar 09 17:17:51 2009 +0100 +++ b/src/ui.cc Mon Mar 09 17:21:32 2009 +0100 @@ -28,6 +28,7 @@ #include "ui.hh" #include "msg.h" #include "timeout.hh" +#include "html_common.hh" // for DilloHtml using namespace fltk; @@ -38,7 +39,7 @@ struct iconset { Image *ImgMeterOK, *ImgMeterBug, - *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, + *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgBookAdd, *ImgTools, *ImgClear,*ImgSearch; MultiImage *ImgLeftMulti, *ImgRightMulti, *ImgStopMulti; }; @@ -50,6 +51,7 @@ new xpmImage(reload_xpm), new xpmImage(save_xpm), new xpmImage(bm_xpm), + new xpmImage(bm_add_xpm), new xpmImage(tools_xpm), new xpmImage(new_s_xpm), new xpmImage(search_xpm), @@ -68,6 +70,7 @@ new xpmImage(reload_s_xpm), new xpmImage(save_s_xpm), new xpmImage(bm_s_xpm), + new xpmImage(bm_add_s_xpm), new xpmImage(tools_s_xpm), new xpmImage(new_s_xpm), standard_icons.ImgSearch, @@ -324,6 +327,12 @@ a_UIcmd_book(a_UIcmd_get_bw_by_widget(wid)); } break; + case UI_BOOK_ADD: + if (k == 1) { + BrowserWindow *bw = a_UIcmd_get_bw_by_widget(wid); + a_UIcmd_add_bookmark(bw, ((DilloHtml *) a_Bw_get_current_doc(bw))->page_url); + } + break; case UI_TOOLS: if (k == 1 || k == 3) { a_UIcmd_tools(a_UIcmd_get_bw_by_widget(wid), wid); @@ -416,6 +425,12 @@ b->callback(b1_cb, (void *)UI_BOOK); b->clear_tab_to_focus(); + Bookmarks = b = new HighlightButton(xpos, 0, bw, bh, (lbl) ? "Add" : 0); + b->image(icons->ImgBookAdd); + b->tooltip("Add bookmark"); + b->callback(b1_cb, (void *)UI_BOOK_ADD); + b->clear_tab_to_focus(); + Tools = b = new HighlightButton(xpos, 0, bw, bh, (lbl) ? "Tools" : 0); b->image(icons->ImgTools); b->tooltip("Settings"); diff -r 9638f05098cf -r 78c0fa261c84 src/ui.hh --- a/src/ui.hh Mon Mar 09 17:17:51 2009 +0100 +++ b/src/ui.hh Mon Mar 09 17:21:32 2009 +0100 @@ -26,6 +26,7 @@ UI_SAVE, UI_STOP, UI_BOOK, + UI_BOOK_ADD, UI_TOOLS, UI_CLEAR, UI_SEARCH

March 9, 2009

[PATCH 1 of 3] Use event_button() instead of event_key() since we're dealing with mouse events

by 4winter＠informatik.uni-hamburg.de

# HG changeset patch # User Justus Winter <justus.winter(a)informatik.uni-hamburg.de> # Date 1236615471 -3600 # Node ID 9638f05098cf2687dbb863f47fd82461c5417403 # Parent cc974615ae3906d4e36fb1d30a90e8be056d497a Use event_button() instead of event_key() since we're dealing with mouse events diff -r cc974615ae39 -r 9638f05098cf src/ui.cc --- a/src/ui.cc Fri Mar 06 18:35:40 2009 +0000 +++ b/src/ui.cc Mon Mar 09 17:17:51 2009 +0100 @@ -279,7 +279,7 @@ static void b1_cb(Widget *wid, void *cb_data) { int bn = VOIDP2INT(cb_data); - int k = event_key(); + int k = event_button(); if (k && k <= 7) { _MSG("[%s], mouse button %d was pressed\n", button_names[bn], k); _MSG("mouse button %d was pressed\n", k);

March 9, 2009