- Dillo-dev - lists.mailman3.com

[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