- Dillo-dev - lists.mailman3.com

[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