- Dillo-dev - lists.mailman3.com

Alternate bookmarks interface

by obeythepenguin＠gmail.com

Hey everyone, Here's my latest patch if anyone's interested. As nice as the bookmarks DPI is, I personally prefer a more traditional interface (and since Windows doesn't run DPI anyway, I had a good excuse to code one). The patch itself is here: http://dillo-win32.sourceforge.net/patches/31-bookmarks.diff Some basics: - Clicking on the bookmarks button now displays the bookmarks menu. - Unclassified bookmarks are displayed at the bottom of the bookmarks menu; other sections are displayed as submenus. - Right-clicking a bookmark or section (submenu) lets you edit that bookmark or section. - Middle-clicking a bookmark opens it in a new window or tab, depending on your preferences. (I may also add the ability to middle-click a section to open all the bookmarks in separate tabs.) Right now the code's a little rough around the edges, and the "Bookmark this ____" right-click option doesn't work (the bookmarks menu itself is fine), but it seems to be fairly stable if you want to try it out and let me know what you think. Cheers, ~Benjamin

Sept. 12, 2011

system colors

by Johannes.Hofmann＠gmx.de

On Sun, Sep 11, 2011 at 06:03:46AM +0000, corvid wrote: > Benjamin wrote: > > As it happens, I have a patch that does both: > > http://dillo-win32.sourceforge.net/patches/24-colors.diff > > Here's some more assorted ripping-out of hardcoded colors added to that. +1 Cheers, Johannes

Sept. 11, 2011

Updated Dillo pages on the Beyond Linux From Scratch wiki

by corvid＠lavabit.com

Jeremy wrote: > > If you are interested: > > http://wiki.linuxfromscratch.org/blfs/wiki/dillo3 > http://wiki.linuxfromscratch.org/blfs/wiki/dillo2 > > I added a note at the top of the Dillo2 page saying it is no longer > under development and linking to Dillo3. I hope that is an accurate > comment. I will update it if people think it is misleading. Seems good to me!

Sept. 11, 2011

system colors

by corvid＠lavabit.com

Benjamin wrote: > As it happens, I have a patch that does both: > http://dillo-win32.sourceforge.net/patches/24-colors.diff Here's some more assorted ripping-out of hardcoded colors added to that. As for X, I found out that I can set the secondary background color (e.g., background of Fl_Input) as well if I do something like dillo.foreground: purple dillo.background: green *Text.background: brown There's a big comment in fltk that goes: // XGetDefault does not do the expected thing: it does not like // periods in either word. Therefore it cannot match class.Text.background. // However *.Text.background is matched by pretending the program is "Text". // But this will also match *.background if there is no *.Text.background // entry, requiring users to put in both (unless they want the text fields // the same color as the windows).

Sept. 11, 2011

Printing support

by obeythepenguin＠gmail.com

On Sat, 10 Sep 2011 16:54:26 -0400, corvid <corvid at lavabit.com> wrote: > Benjamin wrote: >> I figured since we've got all that Fl_Printer stuff anyway, maybe we >> should put it to good use. So here's a (very early) patch to add >> printing support to Dillo: >> http://dillo-win32.sourceforge.net/patches/30-print.diff >> >> It's turned on with a ./configure option (and disabled by default), >> so you don't need to link in Fl_Printer if you don't want to. I'm >> not looking to get it into mainline yet, mostly I just want to show >> what I've got so far in case anyone is interested. >> >> Here's an example of its output: >> http://dillo-win32.sourceforge.net/files/dilloprint.pdf >> >> Let me know what you think! > > That is an intriguingly small amount of code. It's a lot smaller than I expected. The main problem is it has to resize the viewport to the printable page area, and the viewport apparently doesn't like resizing smaller than the browser window. This results in clipping, as you can see in the linked PDF. (Admittedly it's a little ugly printing the viewport directly to Fl_Printer anyway, since we have to do nasty things to it so it will fit the page, but after four or five hours of experimentation this seemed to be the only thing that worked. And this way, we at least get *everything* that's visible on screen, including form contents, etc.) ~Benjamin

Sept. 11, 2011

Printing support

by rogerx.oss＠gmail.com

FYI: http://www.fltk.org/doc-1.3/classFl__Printer.html -- Roger http://rogerx.freeshell.org/

Sept. 11, 2011

Printing support

by rogerx.oss＠gmail.com

> On Sat, Sep 10, 2011 at 08:54:26PM +0000, corvid wrote: >Benjamin wrote: >> I figured since we've got all that Fl_Printer stuff anyway, maybe we >> should put it to good use. So here's a (very early) patch to add >> printing support to Dillo: >> http://dillo-win32.sourceforge.net/patches/30-print.diff >> >> It's turned on with a ./configure option (and disabled by default), >> so you don't need to link in Fl_Printer if you don't want to. I'm >> not looking to get it into mainline yet, mostly I just want to show >> what I've got so far in case anyone is interested. >> >> Here's an example of its output: >> http://dillo-win32.sourceforge.net/files/dilloprint.pdf >> >> Let me know what you think! > >That is an intriguingly small amount of code. Doesn't surprise me. Seamonkey and Abiword, from what I think I just learned, use cairo for printing. -- Roger http://rogerx.freeshell.org/

Sept. 10, 2011

Updated Dillo pages on the Beyond Linux From Scratch wiki

by onepoint＠starurchin.org

If you are interested: http://wiki.linuxfromscratch.org/blfs/wiki/dillo3 http://wiki.linuxfromscratch.org/blfs/wiki/dillo2 I added a note at the top of the Dillo2 page saying it is no longer under development and linking to Dillo3. I hope that is an accurate comment. I will update it if people think it is misleading. Regards, Jeremy Henty

Sept. 10, 2011

Printing support

by corvid＠lavabit.com

Benjamin wrote: > I figured since we've got all that Fl_Printer stuff anyway, maybe we > should put it to good use. So here's a (very early) patch to add > printing support to Dillo: > http://dillo-win32.sourceforge.net/patches/30-print.diff > > It's turned on with a ./configure option (and disabled by default), > so you don't need to link in Fl_Printer if you don't want to. I'm > not looking to get it into mainline yet, mostly I just want to show > what I've got so far in case anyone is interested. > > Here's an example of its output: > http://dillo-win32.sourceforge.net/files/dilloprint.pdf > > Let me know what you think! That is an intriguingly small amount of code.

Sept. 10, 2011

Printing support

by obeythepenguin＠gmail.com

I figured since we've got all that Fl_Printer stuff anyway, maybe we should put it to good use. So here's a (very early) patch to add printing support to Dillo: http://dillo-win32.sourceforge.net/patches/30-print.diff It's turned on with a ./configure option (and disabled by default), so you don't need to link in Fl_Printer if you don't want to. I'm not looking to get it into mainline yet, mostly I just want to show what I've got so far in case anyone is interested. Here's an example of its output: http://dillo-win32.sourceforge.net/files/dilloprint.pdf Let me know what you think! Cheers, ~Benjamin

Sept. 10, 2011

system colors

by obeythepenguin＠gmail.com

On Sat, 10 Sep 2011 01:35:38 -0400, corvid <corvid at lavabit.com> wrote: > If it should happen that many of the various desktop environments set > these values, getting this all to work reasonably correctly might be > pleasing to everyone nowadays who expects all of their windows to > look similar. People are very first-impression ("It's ugly!" > *deletes*)... I agree; appearances are important. I'd also recommend using the system colors for tabs, rather than a hard-coded scheme. Teal is nice, but it might clash with some people's desktops. As it happens, I have a patch that does both: http://dillo-win32.sourceforge.net/patches/24-colors.diff I also have a patch that vastly improves the tabbar appearance with just a couple small tweaks: http://dillo-win32.sourceforge.net/patches/23-tabs.diff Compare the tabs in these two screenshots: http://www.dillo.org/screenshots/source.png (mainline) http://dillo-win32.sourceforge.net/screenshots/Z02-dillo3-homepage.png (patched) Take a look and tell me what you think. Cheers, ~Benjamin

Sept. 10, 2011

FLTK scheme

by mailbox＠georgpotthast.de

There is an environment variable that FLTK reads and which allows the user to select the scheme he likes best. I set it to: FLTK_SCHEME=grad1 With this variable you can also select the scheme to use with Dillo, since it is based on FLTK (tested with 3.0pre). This gradient scheme, which is my favorite, looks like this: http://www.imgplace.com/viewimg39/5411/88fluidgradient.png Georg

Sept. 10, 2011

Close dillo with multiple tabs open

by rogerx.oss＠gmail.com

> On Sat, Sep 10, 2011 at 10:25:43AM +0200, Alexander Voigt wrote: >Dear Dillo developers, > >I just noticed a small misbehaviour when trying to close a Dillo >window (using ALT+F4 or CTRL+q) with more than one tab open: A window >pops up and asks wether I am sure to close. At this point I >unfortunately can't use the ENTER key to confirm. I think I would be >very convenient for the user to make the ENTER key work. spacebar. Ditto corvid, I'm prone to using enter/return as well. >Another question here: Please tell me if I'm wrong, but there seems to >be no dillorc option to omit the mentioned popup window completely. >Do you think it would be convenient to have one? you mean, "confirm to exit prompt". Ditto. Rarely, if ever accidentally quit. -- Roger http://rogerx.freeshell.org/

Sept. 10, 2011

Close dillo with multiple tabs open

by corvid＠lavabit.com

Alexander wrote: > I just noticed a small misbehaviour when trying to close a Dillo > window (using ALT+F4 or CTRL+q) with more than one tab open: A window > pops up and asks wether I am sure to close. At this point I > unfortunately can't use the ENTER key to confirm. I think I would be > very convenient for the user to make the ENTER key work. fltk-1.3 is very into using Space to trigger buttons, and not Enter. I am accustomed to pressing Enter, so I would be happy to go through and make Enter work wherever it can be done without a lot of trouble. I mentioned the issue on the list a few months back, and no one had a word to say, but unless there's a lot of strenuous objection from the others for some reason, that's what I'll do.

Sept. 10, 2011

Close dillo with multiple tabs open

by Hole.destructor＠gmx.de

Dear Dillo developers, I just noticed a small misbehaviour when trying to close a Dillo window (using ALT+F4 or CTRL+q) with more than one tab open: A window pops up and asks wether I am sure to close. At this point I unfortunately can't use the ENTER key to confirm. I think I would be very convenient for the user to make the ENTER key work. Another question here: Please tell me if I'm wrong, but there seems to be no dillorc option to omit the mentioned popup window completely. Do you think it would be convenient to have one? Kind regards, Alexander

Sept. 10, 2011

system colors

by corvid＠lavabit.com

I wrote: > As an aside to the scheme issue, I just found that if I add in a > > Fl::get_system_colors(); > > (I put it after the make_current()) > > and then added the following to .Xdefaults: > > dillo*background: red > dillo*foreground: yellow > > Then dillo's dialogs, and certain parts of the UI, and -- interestingly -- > the default text color on pages, well, it all turns rather red&yellow in > general. > > The src talks about KDE, at least, setting those values in xrdb. > > If it should happen that many of the various desktop environments set > these values, getting this all to work reasonably correctly might be > pleasing to everyone nowadays who expects all of their windows to > look similar. People are very first-impression ("It's ugly!" *deletes*)... For that matter, I will say that all of the grey in fltk by default is not very nice.

Sept. 10, 2011

system colors

by corvid＠lavabit.com

As an aside to the scheme issue, I just found that if I add in a Fl::get_system_colors(); (I put it after the make_current()) and then added the following to .Xdefaults: dillo*background: red dillo*foreground: yellow Then dillo's dialogs, and certain parts of the UI, and -- interestingly -- the default text color on pages, well, it all turns rather red&yellow in general. The src talks about KDE, at least, setting those values in xrdb. If it should happen that many of the various desktop environments set these values, getting this all to work reasonably correctly might be pleasing to everyone nowadays who expects all of their windows to look similar. People are very first-impression ("It's ugly!" *deletes*)...

Sept. 10, 2011

No subject

by bogus＠does.not.exist.com

(ie. addons, passwords, ...) is now opening in a browser tab/window instead of a widget/applet. Which is how I think it should be. The only downside that I see with dpid, it's not easy to upgrade, quit & start dillo. One first needs to kill dpid and all dpi processes before restarting an upgraded Dillo. -- Roger http://rogerx.freeshell.org/

Sept. 10, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

Jorge wrote: > On Fri, Sep 09, 2011 at 10:03:29AM +0200, Johannes Hofmann wrote: > > On Fri, Sep 09, 2011 at 12:00:31AM +0000, corvid wrote: > > > higuita wrote: > > > > I even like more the FL_PLASTIC_UP_BOX look :) > > > > > > I think I do too... > > > > BTW, what about not specifying the box type at all and having a > > Fl::scheme("plastic") call in main()? > > Or even better having an option in dillorc to specify the scheme. > > Long ago, after searching for a window manager theme that suits > my needs, in specialized sites, it became quite clear it's > impossible to get something that pleases everybody. > > WRT dillo, there're several buttton variants for either > "plastic" and "gtk+", so I'm more inclined to have a dillorc > option for the tab button style. > > A gtk+/plastic selector may also help (I have vague memories of > some form widgets being less clear to read, but this is personal > taste anyway :). The code in Fl_get_system_colors.cxx goes: int Fl::scheme(const char *s) { if (!s) { if ((s = getenv("FLTK_SCHEME")) == NULL) { #if !defined(WIN32) && !defined(__APPLE__) const char* key = 0; if (Fl::first_window()) key = Fl::first_window()->xclass(); if (!key) key = "fltk"; fl_open_display(); s = XGetDefault(fl_display, key, "scheme"); #endif // !WIN32 && !__APPLE__ } } [...] } so if we stick a Fl::scheme(NULL) into dillo.cc, then $ export FLTK_SCHEME=plastic $ dillo works (Why doesn't "FLTK_SCHEME=plastic dillo" work?) and "dillo*scheme: gtk+" in .Xdefaults works.

Sept. 10, 2011

dillo-3.0 is on site for testing!

by Johannes.Hofmann＠gmx.de

On Thu, Sep 08, 2011 at 03:33:09PM -0300, Jorge Arellano Cid wrote: > On Tue, Sep 06, 2011 at 06:26:15PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > [...] > > dillo-3.0 is available from: > > > > http://www.dillo.org/download/ > > > > > > This should be our last release candidate, unless something major > > appears. Please download, build, test and report how it goes. > > > > If there's no show stopper in a couple of days, the announcement > > to the outside world will be made. ;) > > Thanks a lot to those that took the time to build and check > this tarball. > > I just finished submitting the release announcement to > freshmeat; it tipically takes much less than 24 hours to make its > way into the front page. > > So, finally, our dillo-3.0 release is now official! Hurray! As always, it took longer than expected, but I think it's an important milestone. Cheers and thanks to all that helped, Johannes

Sept. 9, 2011

dillo-3.0 is on site for testing!

by rogerx.oss＠gmail.com

> On Thu, Sep 08, 2011 at 12:07:01AM -0800, Roger wrote: >> On Wed, Sep 07, 2011 at 11:33:33PM -0400, Walter Dnes wrote: >>On Tue, Sep 06, 2011 at 08:08:31PM -0800, Roger wrote >> >>> Appears to compile & execute fine on i686 Gentoo (Intel P3 2x750). >> >> Also on 64-bit Gentoo on an Intel i3. Thanks to whomever opened the bug. Opening the bug seems like half the battle to creating the updated ebuild, in my case, I already had the ebuild on my system. (Likely just a copy of an older Dillo ebuild.) Here's a Gentoo EBuild for Dillo-3.0 for testing: https://bugs.gentoo.org/show_bug.cgi?id=382359 Instructions on masking fltk-2 until Gentoo Developers slot the fltk ebuild versions correctly are posted. Notes are also posted concerning fltk version numbers. -- Roger http://rogerx.freeshell.org/

Sept. 9, 2011

dillo-3.0-rc2 is out

by jcid＠dillo.org

On Fri, Sep 09, 2011 at 10:03:29AM +0200, Johannes Hofmann wrote: > On Fri, Sep 09, 2011 at 12:00:31AM +0000, corvid wrote: > > higuita wrote: > > > I even like more the FL_PLASTIC_UP_BOX look :) > > > > I think I do too... > > BTW, what about not specifying the box type at all and having a > Fl::scheme("plastic") call in main()? > Or even better having an option in dillorc to specify the scheme. Long ago, after searching for a window manager theme that suits my needs, in specialized sites, it became quite clear it's impossible to get something that pleases everybody. WRT dillo, there're several buttton variants for either "plastic" and "gtk+", so I'm more inclined to have a dillorc option for the tab button style. A gtk+/plastic selector may also help (I have vague memories of some form widgets being less clear to read, but this is personal taste anyway :). -- Cheers Jorge.-

Sept. 9, 2011

dillo-3.0-rc2 is out

by rogutes＠googlemail.com

Johannes Hofmann (2011-09-09 10:03): > On Fri, Sep 09, 2011 at 12:00:31AM +0000, corvid wrote: > > higuita wrote: > > > I even like more the FL_PLASTIC_UP_BOX look :) > > > > I think I do too... > > BTW, what about not specifying the box type at all and having a > Fl::scheme("plastic") call in main()? > Or even better having an option in dillorc to specify the scheme. > > Cheers, > Johannes +1 for either of Johannes' suggestions. tigervnc's vncviewer uses Fl::scheme("gtk+") and I like that look more than dillo's [1] (though I didn't see the plastic scheme). [1] http://tigervnc.svn.sourceforge.net/viewvc/tigervnc/trunk/vncviewer/vncview… -- -- Rogut?s Sparnuotos

Sept. 9, 2011

dillo-3.0-rc2 is out

by johannes.hofmann＠gmx.de

On Fri, Sep 09, 2011 at 12:00:31AM +0000, corvid wrote: > higuita wrote: > > I even like more the FL_PLASTIC_UP_BOX look :) > > I think I do too... BTW, what about not specifying the box type at all and having a Fl::scheme("plastic") call in main()? Or even better having an option in dillorc to specify the scheme. Cheers, Johannes

Sept. 9, 2011

dillo-3.0 is on site for testing!

by abe＠deuxchevaux.org

Hi Jorge, On Thu, Sep 08, 2011 at 09:07:22PM -0300, Jorge Arellano Cid wrote: > > So I just renamed the RC3 tar ball (without redownloading it again) > > and packaged it as "3.0" and uploaded it Debian Unstable. Should be > > available on all platforms within the next half day. > > Thanks a lot for the quick packaging. > > BTW, more or less how long could it take to make it into testing? The common delay is 10 days if no so called "release critical bugs" pop up. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 9, 2011

dillo-3.0 is on site for testing!

by jcid＠dillo.org

On Fri, Sep 09, 2011 at 01:31:44AM +0200, Axel Beckert wrote: > Hi Jorge and corvid, > > thanks for the prompt answers. > > On Thu, Sep 08, 2011 at 07:34:37PM -0300, Jorge Arellano Cid wrote: > > > > I just finished submitting the release announcement to > > > > freshmeat; it tipically takes much less than 24 hours to make its > > > > way into the front page. > > > > > > Is the tar ball now the same then with 3.0 RC3 or has the link fix > > > from corvid been included? > > > > > > http://hg.dillo.org/dillo/rev/55d964c61877 > > > > > > I'd prefer the latter. > > ... because I'm a perfectionist. :-) > > > It has the typo. > > Ok, that's the main thing I wanted to know. > > So I just renamed the RC3 tar ball (without redownloading it again) > and packaged it as "3.0" and uploaded it Debian Unstable. Should be > available on all platforms within the next half day. Thanks a lot for the quick packaging. BTW, more or less how long could it take to make it into testing? > > After all these years I've been bitten more than once by the > > one-liner fix that carries another problem, so I preferred to err > > on the safe side (with all the testing given to the tarball) and > > release it. > > I see. And I understand that. Looking forward to the 3.0.1 release > then. ;-) Ack. -- Cheers Jorge.-

Sept. 9, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

higuita wrote: > I even like more the FL_PLASTIC_UP_BOX look :) I think I do too...

Sept. 9, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

higuita wrote: > On Thu, 8 Sep 2011 08:35:52 +0000, "corvid" <corvid at lavabit.com> wrote: > > Hmm. Well, if you go into src/uicmd.cc and change the instances of > > FL_PLASTIC_ROUND_UP_BOX to FL_PLASTIC_UP_BOX, or FL_FLAT_BOX, or > > FL_NO_BOX, does tab behaviour get better? > > Yes, changing it to FL_PLASTIC_UP_BOX i get the normal speed > and FL_FLAT_BOX put it even faster (but not that much). I even like more > the FL_PLASTIC_UP_BOX look :) > > So is this a problem of fltk or from dillo, or both? :) I guess it must be something in the world of fltk or the video driver or something. I'd expected us drawing lots of circles for bullets to make a difference, but then I see that fltk's fl_plastic.cxx needs a _lot_ of fl_arc()s and fl_pie()s to make round boxes, so that may magnify the effect quite a bit.

Sept. 8, 2011

dillo-3.0 is on site for testing!

by abe＠deuxchevaux.org

Hi Jorge and corvid, thanks for the prompt answers. On Thu, Sep 08, 2011 at 07:34:37PM -0300, Jorge Arellano Cid wrote: > > > I just finished submitting the release announcement to > > > freshmeat; it tipically takes much less than 24 hours to make its > > > way into the front page. > > > > Is the tar ball now the same then with 3.0 RC3 or has the link fix > > from corvid been included? > > > > http://hg.dillo.org/dillo/rev/55d964c61877 > > > > I'd prefer the latter. ... because I'm a perfectionist. :-) > It has the typo. Ok, that's the main thing I wanted to know. So I just renamed the RC3 tar ball (without redownloading it again) and packaged it as "3.0" and uploaded it Debian Unstable. Should be available on all platforms within the next half day. > After all these years I've been bitten more than once by the > one-liner fix that carries another problem, so I preferred to err > on the safe side (with all the testing given to the tarball) and > release it. I see. And I understand that. Looking forward to the 3.0.1 release then. ;-) Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 8, 2011

dillo-3.0-rc2 is out

by higuita7＠yahoo.co.uk

On Thu, 8 Sep 2011 08:35:52 +0000, "corvid" <corvid at lavabit.com> wrote: > Hmm. Well, if you go into src/uicmd.cc and change the instances of > FL_PLASTIC_ROUND_UP_BOX to FL_PLASTIC_UP_BOX, or FL_FLAT_BOX, or > FL_NO_BOX, does tab behaviour get better? Yes, changing it to FL_PLASTIC_UP_BOX i get the normal speed and FL_FLAT_BOX put it even faster (but not that much). I even like more the FL_PLASTIC_UP_BOX look :) So is this a problem of fltk or from dillo, or both? :) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Sept. 8, 2011

dillo-3.0 is on site for testing!

by jcid＠dillo.org

On Thu, Sep 08, 2011 at 10:21:00PM +0200, Axel Beckert wrote: > Hi, > > On Thu, Sep 08, 2011 at 03:33:09PM -0300, Jorge Arellano Cid wrote: > > I just finished submitting the release announcement to > > freshmeat; it tipically takes much less than 24 hours to make its > > way into the front page. > > Is the tar ball now the same then with 3.0 RC3 or has the link fix > from corvid been included? > > http://hg.dillo.org/dillo/rev/55d964c61877 > > I'd prefer the latter. It has the typo. After all these years I've been bitten more than once by the one-liner fix that carries another problem, so I preferred to err on the safe side (with all the testing given to the tarball) and release it. -- Cheers Jorge.-

Sept. 8, 2011

dillo-3.0 is on site for testing!

by corvid＠lavabit.com

Axel wrote: > On Thu, Sep 08, 2011 at 03:33:09PM -0300, Jorge Arellano Cid wrote: > > I just finished submitting the release announcement to > > freshmeat; it tipically takes much less than 24 hours to make its > > way into the front page. > > Is the tar ball now the same then with 3.0 RC3 or has the link fix > from corvid been included? > > http://hg.dillo.org/dillo/rev/55d964c61877 > > I'd prefer the latter. I didn't make the fix until after the announcement, reasoning that it wasn't worth delaying release, changing tags, etc., for something in the doc/ directory where no one ever ventures anyway.

Sept. 8, 2011

dillo-3.0 is on site for testing!

by abe＠deuxchevaux.org

Hi, On Thu, Sep 08, 2011 at 03:33:09PM -0300, Jorge Arellano Cid wrote: > I just finished submitting the release announcement to > freshmeat; it tipically takes much less than 24 hours to make its > way into the front page. Is the tar ball now the same then with 3.0 RC3 or has the link fix from corvid been included? http://hg.dillo.org/dillo/rev/55d964c61877 I'd prefer the latter. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 8, 2011

dillo-3.0 is on site for testing!

by jcid＠dillo.org

On Tue, Sep 06, 2011 at 06:26:15PM -0300, Jorge Arellano Cid wrote: > Hi there, > [...] > dillo-3.0 is available from: > > http://www.dillo.org/download/ > > > This should be our last release candidate, unless something major > appears. Please download, build, test and report how it goes. > > If there's no show stopper in a couple of days, the announcement > to the outside world will be made. ;) Thanks a lot to those that took the time to build and check this tarball. I just finished submitting the release announcement to freshmeat; it tipically takes much less than 24 hours to make its way into the front page. So, finally, our dillo-3.0 release is now official! Thanks again to every single person that has contributed to make this release possible, and along the years the existence of the project possible. Cheers! -- Cheers Jorge.-

Sept. 8, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

higuita wrote: > > > problem comes from the fltk... bisect it i found that fltk 1.3 > > > revision 9023 makes the openning/close of the tabs slower in my > > > machine. > > Do pages with lots of circles for unordered list items give you > > any trouble? > > testing with this page: > > http://www.stylegala.com/features/bulletmadness/ > > i dont see any difference before and after that commit. Hmm. Well, if you go into src/uicmd.cc and change the instances of FL_PLASTIC_ROUND_UP_BOX to FL_PLASTIC_UP_BOX, or FL_FLAT_BOX, or FL_NO_BOX, does tab behaviour get better?

Sept. 8, 2011

dillo-3.0-rc2 is out

by higuita7＠yahoo.co.uk

Hi again > > problem comes from the fltk... bisect it i found that fltk 1.3 > > revision 9023 makes the openning/close of the tabs slower in my > > machine. > Do pages with lots of circles for unordered list items give you > any trouble? testing with this page: http://www.stylegala.com/features/bulletmadness/ i dont see any difference before and after that commit. higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Sept. 8, 2011

dillo-3.0 is on site for testing!

by rogerx.oss＠gmail.com

> On Wed, Sep 07, 2011 at 11:33:33PM -0400, Walter Dnes wrote: >On Tue, Sep 06, 2011 at 08:08:31PM -0800, Roger wrote > >> Appears to compile & execute fine on i686 Gentoo (Intel P3 2x750). > > Also on 64-bit Gentoo on an Intel i3. > >> If nobody else has published a Gentoo EBuild script for packaging, >> I'll try to publish an updated dillo-3.0 ebuild via bugs.gentoo.org. > > Is it possible for the ebuild to force fltk-1.3? Yes. This is exactly what I was thinking, but doing something like requires =x11-libs/fltk-1.3* if Gentoo's EBuild versioning system allows it. (I'm guessing FLTK-1.3 updates will progress something like 1.3.0, 1.3.1, 1.3.2, ... until FLTK-1.3 and FLTK-2.0 are combined into FLTK-3.0.) I'm going to be stumped if the EBuild versioning system doesn't allow globbing versions with the equals sign. :-/ > And while we're at >it, you may need to put an explanation about that into the comments >stored in the ebuild log, maybe even an ewarn. Otherwise, people will >be asking on the Gentoo forum about the "downgrade to fltk-1.3" <G>. Some great ideas there. I'm a perfectionist at heart and would likely document comments in both the ebuild and filed bug comments. ;-) -- Roger http://rogerx.freeshell.org/

Sept. 8, 2011

dillo-3.0 is on site for testing!

by waltdnes＠waltdnes.org

On Tue, Sep 06, 2011 at 08:08:31PM -0800, Roger wrote > Appears to compile & execute fine on i686 Gentoo (Intel P3 2x750). Also on 64-bit Gentoo on an Intel i3. > If nobody else has published a Gentoo EBuild script for packaging, > I'll try to publish an updated dillo-3.0 ebuild via bugs.gentoo.org. Is it possible for the ebuild to force fltk-1.3? And while we're at it, you may need to put an explanation about that into the comments stored in the ebuild log, maybe even an ewarn. Otherwise, people will be asking on the Gentoo forum about the "downgrade to fltk-1.3" <G>. -- Walter Dnes <waltdnes at waltdnes.org>

Sept. 8, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

higuita wrote: > But anyway, as yesterday i tried to bisect the dialog > problem, i tried to do the same for this one... and found that the > problem comes from the fltk... bisect it i found that fltk 1.3 > revision 9023 makes the openning/close of the tabs slower in my > machine. > > here is the 9023 commit: > > $ svn diff -c 9023 > Index: src/fl_arci.cxx > =================================================================== > --- src/fl_arci.cxx (revision 9022) > +++ src/fl_arci.cxx (revision 9023) > @@ -77,6 +77,7 @@ > if (w <= 0 || h <= 0) return; > > #if defined(USE_X11) > + XDrawArc(fl_display, fl_window, fl_gc, x,y,w-1,h-1, int(a1*64),int((a2-a1)*64)); > XFillArc(fl_display, fl_window, fl_gc, x,y,w-1,h-1, int(a1*64),int((a2-a1)*64)); > #elif defined(WIN32) > if (a1 == a2) return; This is interesting and strange. In our drawArc() code, I have fl_arc(x, y, width, height, angle1, angle2); if (filled) fl_pie(x, y, width, height, angle1, angle2); as a workaround for the problem that they fixed there (that is, instead of doing if (filled) fl_pie(); else fl_arc();). Do pages with lots of circles for unordered list items give you any trouble?

Sept. 8, 2011

ipv6 addresses

by higuita7＠yahoo.co.uk

Hi > Is it possible to specify ipv6 addresses into dillo's address bar? Yes, i use dillo with ipv6 and works fine... for a url with a ipv6 address, you need to do the normal ipv6 trick, enclose it with [], like: http://[2001:200:dff:fff1:216:3eff:feb1:44d7] Of course, this doesnt work right with many sites because they use virtual hosts. example, check this: http://[2001:960:800::2] This is because they require the hostname to know what site to show... but that is a server issue, not a browser problem. good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Sept. 8, 2011

dillo-3.0-rc2 is out

by higuita7＠yahoo.co.uk

Hi > > open new tabs takes longer and there is a longer pause > > until i can open one more... also, close a tab is also slower. > Interesting. Do you know how to use gprof? Not really... i tried to take a quick look but at very least i need more research and examples to see if it's under my limited knowledge. But anyway, as yesterday i tried to bisect the dialog problem, i tried to do the same for this one... and found that the problem comes from the fltk... bisect it i found that fltk 1.3 revision 9023 makes the openning/close of the tabs slower in my machine. here is the 9023 commit: $ svn diff -c 9023 Index: src/fl_arci.cxx =================================================================== --- src/fl_arci.cxx (revision 9022) +++ src/fl_arci.cxx (revision 9023) @@ -77,6 +77,7 @@ if (w <= 0 || h <= 0) return; #if defined(USE_X11) + XDrawArc(fl_display, fl_window, fl_gc, x,y,w-1,h-1, int(a1*64),int((a2-a1)*64)); XFillArc(fl_display, fl_window, fl_gc, x,y,w-1,h-1, int(a1*64),int((a2-a1)*64)); #elif defined(WIN32) if (a1 == a2) return; Index: CHANGES =================================================================== --- CHANGES (revision 9022) +++ CHANGES (revision 9023) @@ -1,6 +1,7 @@ CHANGES IN FLTK 1.3.1 + - Fixed fl_pie() drawing too small on X11 (STR #2703) - Fixed Fl_Menu issue with unusual menu flags (STR #2680) - Fixed Windows DLL import of fl_xid() (STR #2670) Looks one more issue to present to fltk. Again, thanks for the help. higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Sept. 8, 2011

dillo close dialog and fluxbox on dual head

by higuita7＠yahoo.co.uk

Hi again > FWIW, these commits *may* be related: > > http://fltk.org/newsgroups.php?s6264+gfltk.commit+v6272+T0 > http://fltk.org/newsgroups.php?s6264+gfltk.commit+v6274+T0 > http://fltk.org/newsgroups.php?s6224+gfltk.commit+v6225+T0 Thanks!! i will take a look and talk with the fltk as more and more this looks like a fltk problem higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Sept. 8, 2011

ipv6 addresses

by dennisn＠dennisn.dyndns.org

Is it possible to specify ipv6 addresses into dillo's address bar?

Sept. 7, 2011

dillo-3.0 is on site for testing!

by Hole.destructor＠gmx.de

On Tue, Sep 06, 2011 at 06:26:15PM -0300, Jorge Arellano Cid wrote: > Hi there, > > After a long list of fixes and features: > > [ok] moveToWidget(). Jorge has code for this. > [ok] downloads dpi string escaping. > [ok] alt text wrapping (which looks like a nice feature). > [ok] remove large panel. > [ok] https dialog storm (BUG#868). > [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. > [ok] something other than "ctab%d" for initial tab label. > [ok] single close tab button with tooltip. > [ok] valgrind logs: close window > [ok] valgrind logs: cancel expected url > [ok] segfault with Ctrl-s (web search) > [ok] UI_TEMPORARILY_SHOW_PANELS > [ok] leave link into a native FLTK widget > [ok] remove pointeronlink(), panelmode_cb_i() > [ok] the panel problems when resizing from very small. > [ok] resize problems when tabs overflow > [ok] URL_ILLEGAL_CHARS > [ok] Fixed CustLightButton "light" color deactivation. > [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). > [ok] tab overflow (code a handler) > [ok] valgrind error for first tab close, then resize(). > [ok] update the Changelog > [ok] update links in splash page > [ok] default search engine > [ok] new-tab and window title > [ok] CSS adjacent sibling selectors > [ok] margin-bottom + some margin collapse > [ok] fix doctree leak > [ok] first click on a link missed after middle-click on a scrollbar > [ok] Fix redraw loops and reenable limit_text_width dillorc option > > > dillo-3.0 is available from: > > http://www.dillo.org/download/ > > > This should be our last release candidate, unless something major > appears. Please download, build, test and report how it goes. > > If there's no show stopper in a couple of days, the announcement > to the outside world will be made. ;) It compiles and runs fine under Scientific Linux 6.0 (= RHEL 6.0 plus some extras). Kind regards, Alexander

Sept. 7, 2011

dillo close dialog and fluxbox on dual head

by jcid＠dillo.org

On Wed, Sep 07, 2011 at 03:28:31AM +0000, corvid wrote: > higuita wrote: > > On Mon, 22 Aug 2011 02:44:52 +0100, higuita <higuita7 at yahoo.co.uk> wrote: > > > >> if i do the same thing for all other dillo dialogs, like open > > > >> file, search (title ask), etc , i fluxbox puts the window in the > > > >> configured head. If i try to set the position and head, fluxbox puts > > > >> the dialog in the right position, but in the wrong head. > > > > i have done a bisect and found this commit was the one > > that introduced the problem: > > > > The first bad revision is: > > changeset: 2104:4ea703ed7f15 > > user: Jorge Arellano Cid <jcid at dillo.org> > > date: Fri Jun 10 12:19:14 2011 -0400 > > summary: Set modal for a_Dialog_choice5 > > > > not sure if it really helps :) > > Since a_Dialog_input() also has a set_modal() call, this is indeed > still mysterious... FWIW, these commits *may* be related: http://fltk.org/newsgroups.php?s6264+gfltk.commit+v6272+T0 http://fltk.org/newsgroups.php?s6264+gfltk.commit+v6274+T0 http://fltk.org/newsgroups.php?s6224+gfltk.commit+v6225+T0 -- Cheers Jorge.-

Sept. 7, 2011

dillo close dialog and fluxbox on dual head

by jcid＠dillo.org

On Wed, Sep 07, 2011 at 03:28:31AM +0000, corvid wrote: > higuita wrote: > > On Mon, 22 Aug 2011 02:44:52 +0100, higuita <higuita7 at yahoo.co.uk> wrote: > > > >> if i do the same thing for all other dillo dialogs, like open > > > >> file, search (title ask), etc , i fluxbox puts the window in the > > > >> configured head. If i try to set the position and head, fluxbox puts > > > >> the dialog in the right position, but in the wrong head. > > > > i have done a bisect and found this commit was the one > > that introduced the problem: > > > > The first bad revision is: > > changeset: 2104:4ea703ed7f15 > > user: Jorge Arellano Cid <jcid at dillo.org> > > date: Fri Jun 10 12:19:14 2011 -0400 > > summary: Set modal for a_Dialog_choice5 > > > > not sure if it really helps :) > > Since a_Dialog_input() also has a set_modal() call, this is indeed > still mysterious... I remember some patches in FLTK-1.3 repo with regard to window position and screen counting [1], but unfortunately couldn't find the respective thread. [1] http://fltk.org/articles.php?L1101 -- Cheers Jorge.-

Sept. 7, 2011

dillo-3.0 is on site for testing!

by rogerx.oss＠gmail.com

> On Tue, Sep 06, 2011 at 06:26:15PM -0300, Jorge Arellano Cid wrote: >Hi there, > > After a long list of fixes and features: ... > dillo-3.0 is available from: > > http://www.dillo.org/download/ > > > This should be our last release candidate, unless something major >appears. Please download, build, test and report how it goes. > > If there's no show stopper in a couple of days, the announcement >to the outside world will be made. ;) > > >-- > Cheers > Jorge.- Appears to compile & execute fine on i686 Gentoo (Intel P3 2x750). If nobody else has published a Gentoo EBuild script for packaging, I'll try to publish an updated dillo-3.0 ebuild via bugs.gentoo.org. -- Roger http://rogerx.freeshell.org/

Sept. 7, 2011

Query dpid or running dillos

by dennisn＠dennisn.dyndns.org

On Tue, 6 Sep 2011 20:40:44 +0200, Johannes Hofmann wrote: > On Tue, Sep 06, 2011 at 12:55:57PM -0400, Dennis Nezic wrote: > > Is there a way to query dillo (or dpid?) for the links it currently > > has open? (dpidc/dillo don't seem to have such an option :p) > > Not quite sure what you mean. > Are you interested in all URLs a dillo process is currently > displaying in all it's windows or tabs? Yes :-). > > "dillo --xid XID" is able to access a specific window... but I guess > > there is no way to currently read that "property" (link). > > Hm, the --xid option is used to embed a dillo window into another > one. This needs a program that knows how to do that. We implemented > it for use with the claws mail program and I also tested it with > tabbed (http://tools.suckless.org/tabbed) > In which context are you using the --xid option? > > > > > (Oh, speaking of which, the "--xid XID" feature is buggy here ... it > > loads the link, but renders with a wide (200pixel-ish?) margin on > > the left, which doesn't match the actual clickable > > button/link-areas on the page. Dillo version 2.2.1, fltk-1.3.0.) > > Again, in which context are you using the --xid option? Oh, I see. I thought it was a way to "remote control" an existing dillo window.

Sept. 7, 2011

dillo close dialog and fluxbox on dual head

by corvid＠lavabit.com

higuita wrote: > On Mon, 22 Aug 2011 02:44:52 +0100, higuita <higuita7 at yahoo.co.uk> wrote: > > >> if i do the same thing for all other dillo dialogs, like open > > >> file, search (title ask), etc , i fluxbox puts the window in the > > >> configured head. If i try to set the position and head, fluxbox puts > > >> the dialog in the right position, but in the wrong head. > > i have done a bisect and found this commit was the one > that introduced the problem: > > The first bad revision is: > changeset: 2104:4ea703ed7f15 > user: Jorge Arellano Cid <jcid at dillo.org> > date: Fri Jun 10 12:19:14 2011 -0400 > summary: Set modal for a_Dialog_choice5 > > not sure if it really helps :) Since a_Dialog_input() also has a set_modal() call, this is indeed still mysterious...

Sept. 7, 2011

dillo close dialog and fluxbox on dual head

by higuita7＠yahoo.co.uk

hi again On Mon, 22 Aug 2011 02:44:52 +0100, higuita <higuita7 at yahoo.co.uk> wrote: > >> if i do the same thing for all other dillo dialogs, like open > >> file, search (title ask), etc , i fluxbox puts the window in the > >> configured head. If i try to set the position and head, fluxbox puts > >> the dialog in the right position, but in the wrong head. i have done a bisect and found this commit was the one that introduced the problem: The first bad revision is: changeset: 2104:4ea703ed7f15 user: Jorge Arellano Cid <jcid at dillo.org> date: Fri Jun 10 12:19:14 2011 -0400 summary: Set modal for a_Dialog_choice5 not sure if it really helps :) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Sept. 7, 2011