- Dillo-dev - lists.mailman3.com

Close dillo with multiple tabs open

by obeythepenguin＠gmail.com

On Sat, 17 Sep 2011 01:04:49 -0400, corvid <corvid at lavabit.com> wrote: > Just occurred to me that everyone's been saying that they don't need this > dialog box. I checked firefox and it doesn't warn when quitting. Maybe we > don't need it at all. Of course, Firefox has the ability to restore the last open session when it starts up; accidentally quitting isn't so bad when you can just restart and resume where you left off. (Out of curiosity, does it do that by default?) Speaking of restoring sessions, one of my own users had the very clever idea to implement that feature using bookmarks -- save all the open tabs in a certain bookmarks section, then load all the bookmarks in that section on startup. I haven't coded it yet, but I wanted to share since it was such a neat solution to that problem. Cheers, ~Benjamin

Sept. 17, 2011

Close dillo with multiple tabs open

by Johannes.Hofmann＠gmx.de

On Sat, Sep 17, 2011 at 05:04:49AM +0000, corvid wrote: > Roger wrote: > > >> > you mean, "confirm to exit prompt". Ditto. Rarely, if ever accidentally quit. > > >> > > >> I wasn't sure what my opinion was on this at first, but now I think an > > >> option sounds reasonable. > > > > > >Why not, if there is demand for it and the default is safe > > >(i.e. off). > > > > Ditto. I've never accidentally quit. > > > > Oh, I've used File > Quit once in a while, but with that many key sequences or > > clicks, it's tough to accidentally quit. Also, few options under the File > > menu. Most times, I just halt -p. > > Just occurred to me that everyone's been saying that they don't need this > dialog box. I checked firefox and it doesn't warn when quitting. Maybe we > don't need it at all. Safari has it and given the fact that we only recently switched from Ctrl-Q to Crtl-W for closing tabs, people might accidentally hit Ctrl-Q when they want to close just the tab. It happend to me at least. So for now I would keep it. Cheers, Johannes

Sept. 17, 2011

Close dillo with multiple tabs open

by corvid＠lavabit.com

Roger wrote: > >> > you mean, "confirm to exit prompt". Ditto. Rarely, if ever accidentally quit. > >> > >> I wasn't sure what my opinion was on this at first, but now I think an > >> option sounds reasonable. > > > >Why not, if there is demand for it and the default is safe > >(i.e. off). > > Ditto. I've never accidentally quit. > > Oh, I've used File > Quit once in a while, but with that many key sequences or > clicks, it's tough to accidentally quit. Also, few options under the File > menu. Most times, I just halt -p. Just occurred to me that everyone's been saying that they don't need this dialog box. I checked firefox and it doesn't warn when quitting. Maybe we don't need it at all.

Sept. 17, 2011

Close dillo with multiple tabs open

by rogerx.oss＠gmail.com

>> > you mean, "confirm to exit prompt". Ditto. Rarely, if ever accidentally quit. >> >> I wasn't sure what my opinion was on this at first, but now I think an >> option sounds reasonable. > >Why not, if there is demand for it and the default is safe >(i.e. off). Ditto. I've never accidentally quit. Oh, I've used File > Quit once in a while, but with that many key sequences or clicks, it's tough to accidentally quit. Also, few options under the File menu. Most times, I just halt -p. -- Roger http://rogerx.freeshell.org/

Sept. 17, 2011

system colors

by corvid＠lavabit.com

Here's one with preferences as well as some code to ensure that FL_SELECTION_COLOR has contrast:

Sept. 17, 2011

dillo-3.0-rc2 is out

by obeythepenguin＠gmail.com

On Fri, 16 Sep 2011 16:04:47 -0400, corvid <corvid at lavabit.com> wrote: > Since the consensus seems to be rectangles, I changed them to rectangles. > > As for color, it does seem that plastic vs regular have somewhat > different > ideas about button coloration. Guess I'll try to make it > greenish-and-grayish > again... The thing that bothers me most about the tabs isn't the shape, but the lack of padding. Adding a couple pixels to the tab height drastically improves the appearance and readability. And it's probably better to use the system colors for tabs, since green-and-gray could clash with someone's desktop. (Although I *do* like that particular shade of green.) ~Benjamin

Sept. 16, 2011

dillo-3.0-rc2 is out

by Johannes.Hofmann＠gmx.de

On Thu, Sep 15, 2011 at 07:35:28PM +0000, corvid wrote: > Jorge wrote: > > OK, but current-tree tabs looks ugly (IMHO) here: > > > > http://www.dillo.org/test/dillo-tabs.png > > > > when compared with (previous): > > > > http://www.dillo.org/screenshots/source.png > > > > > > please don't leave it that way. > > We could use, or borrow from, Benjamin's tabs diff mentioned in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-September/008896.ht… > > Any opinions? For now I would just put back the hardcoded FL_PLASTIC_ROUND_UP_BOX. It looks so much better even if it would be nice to have the tabs also themeable. Cheers, Johannes

Sept. 16, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

Rogut?s wrote: > Jorge Arellano Cid (2011-09-15 16:07): > <...> > > OK, but current-tree tabs looks ugly (IMHO) here: > > > > http://www.dillo.org/test/dillo-tabs.png > > > > when compared with (previous): > > > > http://www.dillo.org/screenshots/source.png > > > > > > please don't leave it that way. > > In my humble opinion, rounded tabs do not fit in with the rest of the > rectangular theme (but I agree that tabs in the second screenshot look > better). Since the consensus seems to be rectangles, I changed them to rectangles. As for color, it does seem that plastic vs regular have somewhat different ideas about button coloration. Guess I'll try to make it greenish-and-grayish again...

Sept. 16, 2011

Close dillo with multiple tabs open

by Johannes.Hofmann＠gmx.de

On Wed, Sep 14, 2011 at 10:28:59PM +0000, corvid wrote: > Roger wrote: > > > On Sat, Sep 10, 2011 at 10:25:43AM +0200, Alexander Voigt wrote: > > >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. > > I wasn't sure what my opinion was on this at first, but now I think an > option sounds reasonable. Why not, if there is demand for it and the default is safe (i.e. off). Cheers, Johannes

Sept. 16, 2011

Preferences GUI

by itsme_410＠yahoo.com

--- On Thu, 9/15/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote: > From: Benjamin Johnson <obeythepenguin at gmail.com> > Subject: [Dillo-dev] Preferences GUI > To: "dillo-dev at dillo.org" <dillo-dev at dillo.org> > Date: Thursday, September 15, 2011, 9:53 PM > Hello again, > > I've finally updated my preferences GUI patch for Dillo > 3.0.? (It's 2011 -- nobody should have to manually edit > configuration files, especially for a graphical > program!)? If you want to try it out, here it is: > ? http://dillo-win32.sourceforge.net/patches/33-prefsgui.diff > > And here's some screenshots: > ? http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=Z08-dillo3… The screenshot looks very good! Thanks! T

Sept. 16, 2011

Preferences GUI

by obeythepenguin＠gmail.com

Hello again, I've finally updated my preferences GUI patch for Dillo 3.0. (It's 2011 -- nobody should have to manually edit configuration files, especially for a graphical program!) If you want to try it out, here it is: http://dillo-win32.sourceforge.net/patches/33-prefsgui.diff And here's some screenshots: http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=Z08-dillo3… Right now it implements about half the possible dillorc options; I'm planning to add the others once I figure out where they'll fit best in the interface. By the way, fair warning: this does assume you've applied the other 32 Dillo-Win32 patches before it, so you may need to edit a couple files to use it on stock Dillo. Cheers, ~Benjamin

Sept. 16, 2011

how to open links etc

by itsme_410＠yahoo.com

--- On Thu, 9/15/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote: > From: Benjamin Johnson <obeythepenguin at gmail.com> > Subject: Re: [Dillo-dev] how to open links etc > To: dillo-dev at dillo.org > Date: Thursday, September 15, 2011, 1:21 PM > On Wed, 14 Sep 2011 23:34:33 -0400, > Roger <rogerx.oss at gmail.com> > wrote: > > >> On Wed, Sep 14, 2011 at 08:16:43PM -0400, Benjamin > Johnson wrote: > > > >> Easy solution: ask the user whether to open the > file, or just save it to > >> disk. > > > > So, the prompt saves my butt 5% of the time, the other > 95% of the time I'm > > harassed by a prompt like in Windows. > > > > IMO, configuring for the fewest clicks possible is > best.? And like you said, > > provide a file with an option to to link in external > apps if the user so > > wishes.? (ie mutt's $HOME/.mutt/mailcap is a good > example) > > > > Keeping a file type pointing to null or commented, > gets default (download) > > action? > > > > I didn't want to say much more without being able to > help code it, but I don't > > want to see another prompt popping-up. (ie. Dillo quit > prompt) :-/ > > Then add a "Remember this choice" option so it won't prompt > you again. > > I disagree that all prompts are automatically bad.? > After a while they do get annoying (and there should be some > way to disable them), but for new users the verbosity can be > helpful.? More importantly, it avoids surprising the > user when the program doesn't behave as expected -- it opens > instead of downloads, or vice-versa -- and of course, > different users will have different expectations for which > behavior is "correct." > > (In my own software, I always err on the side of verbosity, > no matter how annoying it is to me personally -- because as > the developer, I know how to disable it on my own machine!) Is it possible to get either option (or both) into dillo3? Best!

Sept. 15, 2011

choice5 [Re: patch for UI and font_factor]

by corvid＠lavabit.com

I wrote: > - Choice5 does not handle it well. I made a nicer choice5 a few > months ago, but Jorge didn't like it. I looked around for the old patch and made it apply cleanly. It _is_ charmless, but maybe it can be used for raw materials at some point, since at least the text fits. So far as I can recall, I made it squarish because I was thinking that dealing with long narrow boxes on handhelds was probably suboptimal. (Speaking of which, remember how Andreas and Justus would talk about usability on handhelds, and then we didn't really proceed to make any decisions about anything? Has anyone tried dillo on handhelds of late?)

Sept. 15, 2011

dillo-3.0-rc2 is out

by rogutes＠googlemail.com

Jorge Arellano Cid (2011-09-15 16:07): <...> > OK, but current-tree tabs looks ugly (IMHO) here: > > http://www.dillo.org/test/dillo-tabs.png > > when compared with (previous): > > http://www.dillo.org/screenshots/source.png > > > please don't leave it that way. In my humble opinion, rounded tabs do not fit in with the rest of the rectangular theme (but I agree that tabs in the second screenshot look better). -- -- Rogut?s Sparnuotos

Sept. 15, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

Jorge wrote: > OK, but current-tree tabs looks ugly (IMHO) here: > > http://www.dillo.org/test/dillo-tabs.png > > when compared with (previous): > > http://www.dillo.org/screenshots/source.png > > > please don't leave it that way. We could use, or borrow from, Benjamin's tabs diff mentioned in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-September/008896.ht… Any opinions?

Sept. 15, 2011

dillo-3.0-rc2 is out

by jcid＠dillo.org

On Tue, Sep 13, 2011 at 06:34:49PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Sep 13, 2011 at 03:31:14AM +0000, corvid wrote: > > > I wrote: > > > > Jorge wrote: > > > > > On Fri, Sep 09, 2011 at 10:03:29AM +0200, Johannes Hofmann wrote: > > > > > > 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. > > > > > > I was having a look around the web to see what reaction there was > > > to the 3.0 release, and the Puppy Linux folks were having a thread > > > that went something like "Pity it's so ugly" "Here, try these other > > > FLTK schemes" "Hey, that's great!" -- which is evidence that adding > > > a preference would be welcomed by users. > > > > The canonical solution to this problem seems to be to pack a > > few "themes" selectable from preferences, and also allow some > > fine tunning via rc preferences or so. > > > > I also read a good sign on this because people usually start to > > customize the look of an app only after they find it useful. > > > > Would you mind handling this task? > > Added a theme preference. > For now, you can specify an arbitrary string and get whatever weird > mixture fltk gives you in that case. I asked on fltk.general whether > it should do that rather than treat an unknown scheme as the default > scheme. Obviously it would be trivial to deal with for ourselves. > > If anyone gets ambitious enough or bored enough one day to want to > make additional themes, you can look in fltk's Fl_get_system_colors.cxx > at Fl::reload_scheme(). It mostly amounts to defining frame and box > types. OK, but current-tree tabs looks ugly (IMHO) here: http://www.dillo.org/test/dillo-tabs.png when compared with (previous): http://www.dillo.org/screenshots/source.png please don't leave it that way. -- Cheers Jorge.-

Sept. 15, 2011

patch history menu positioning

by jcid＠dillo.org

On Thu, Sep 15, 2011 at 03:17:13PM +0000, corvid wrote: > > I was just thinking that it would be nice if the history menus were > positioned like the tools menu. +1 for the idea. BTW, it'd be good to have back/forw/tools do it the same way. This is: either with (v_wid) or (x,y) as parameters. -- Cheers Jorge.-

Sept. 15, 2011

patch history menu positioning

by corvid＠lavabit.com

I was just thinking that it would be nice if the history menus were positioned like the tools menu.

Sept. 15, 2011

how to open links etc

by obeythepenguin＠gmail.com

On Wed, 14 Sep 2011 23:34:33 -0400, Roger <rogerx.oss at gmail.com> wrote: >> On Wed, Sep 14, 2011 at 08:16:43PM -0400, Benjamin Johnson wrote: > >> Easy solution: ask the user whether to open the file, or just save it to >> disk. > > So, the prompt saves my butt 5% of the time, the other 95% of the time > I'm > harassed by a prompt like in Windows. > > IMO, configuring for the fewest clicks possible is best. And like you > said, > provide a file with an option to to link in external apps if the user so > wishes. (ie mutt's $HOME/.mutt/mailcap is a good example) > > Keeping a file type pointing to null or commented, gets default > (download) > action? > > I didn't want to say much more without being able to help code it, but I > don't > want to see another prompt popping-up. (ie. Dillo quit prompt) :-/ Then add a "Remember this choice" option so it won't prompt you again. I disagree that all prompts are automatically bad. After a while they do get annoying (and there should be some way to disable them), but for new users the verbosity can be helpful. More importantly, it avoids surprising the user when the program doesn't behave as expected -- it opens instead of downloads, or vice-versa -- and of course, different users will have different expectations for which behavior is "correct." (In my own software, I always err on the side of verbosity, no matter how annoying it is to me personally -- because as the developer, I know how to disable it on my own machine!) ~Benjamin

Sept. 15, 2011

how to open links etc

by rogerx.oss＠gmail.com

> On Wed, Sep 14, 2011 at 08:16:43PM -0400, Benjamin Johnson wrote: >On Wed, 14 Sep 2011 20:11:14 -0400, Roger <rogerx.oss at gmail.com> wrote: > >> times, it's a pain because I can't do anything until the resource hog >> applications complete after their execution process. (Oh, including the >> wait >> for download because I thought it was an HTML page.) >> >> Seems the only middle-of-the-road solution for me, disable the auto-open >> feature for PDF files and use Google "view as HTML" links (if my eye >> catches them!). >Easy solution: ask the user whether to open the file, or just save it to >disk. So, the prompt saves my butt 5% of the time, the other 95% of the time I'm harassed by a prompt like in Windows. IMO, configuring for the fewest clicks possible is best. And like you said, provide a file with an option to to link in external apps if the user so wishes. (ie mutt's $HOME/.mutt/mailcap is a good example) Keeping a file type pointing to null or commented, gets default (download) action? I didn't want to say much more without being able to help code it, but I don't want to see another prompt popping-up. (ie. Dillo quit prompt) :-/ -- Roger http://rogerx.freeshell.org/

Sept. 15, 2011

how to open links etc

by itsme_410＠yahoo.com

--- On Wed, 9/14/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote: > From: Benjamin Johnson <obeythepenguin at gmail.com> > Subject: Re: [Dillo-dev] how to open links etc > To: dillo-dev at dillo.org > Date: Wednesday, September 14, 2011, 8:16 PM > On Wed, 14 Sep 2011 20:11:14 -0400, > Roger <rogerx.oss at gmail.com> > wrote: > > > On the flip, I just love accidentally clicking on a > link/URL within Google > > thinking it's going to spawn a new tab with an HTML > page, only to find-out > > acroread or epdfview trying to start on my > short-of-resources computers. > > > > Half the time, it's nice to see Seamonkey > automatically open PDF's, other > > times, it's a pain because I can't do anything until > the resource hog > > applications complete after their execution > process.? (Oh, including the wait > > for download because I thought it was an HTML page.) > > > > Seems the only middle-of-the-road solution for me, > disable the auto-open > > feature for PDF files and use Google "view as HTML" > links (if my eye catches them!). > > > > As far as opening other file types such as > > text/diffs/patches/any_thing_else_you_can_think_of, > etc., I'm all for it. > > Easy solution: ask the user whether to open the file, or > just save it to disk. I agree. I also agree with the Roger about the pain caused by things just opening up on their own with major action required to stop it...... T

Sept. 15, 2011

how to open links etc

by obeythepenguin＠gmail.com

On Wed, 14 Sep 2011 20:11:14 -0400, Roger <rogerx.oss at gmail.com> wrote: > On the flip, I just love accidentally clicking on a link/URL within > Google > thinking it's going to spawn a new tab with an HTML page, only to > find-out > acroread or epdfview trying to start on my short-of-resources computers. > > Half the time, it's nice to see Seamonkey automatically open PDF's, other > times, it's a pain because I can't do anything until the resource hog > applications complete after their execution process. (Oh, including the > wait > for download because I thought it was an HTML page.) > > Seems the only middle-of-the-road solution for me, disable the auto-open > feature for PDF files and use Google "view as HTML" links (if my eye > catches them!). > > As far as opening other file types such as > text/diffs/patches/any_thing_else_you_can_think_of, etc., I'm all for it. Easy solution: ask the user whether to open the file, or just save it to disk. ~Benjamin

Sept. 15, 2011

how to open links etc

by rogerx.oss＠gmail.com

> On Wed, Sep 14, 2011 at 03:37:22PM -0700, Globe Trotter wrote: > >--- On Wed, 9/14/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote: > >> From: Benjamin Johnson <obeythepenguin at gmail.com> >> Subject: Re: [Dillo-dev] how to open links etc >> To: dillo-dev at dillo.org >> Date: Wednesday, September 14, 2011, 6:07 PM >> On Wed, 14 Sep 2011 17:50:06 -0400, >> Globe Trotter <itsme_410 at yahoo.com> >> wrote: >> >> > Is this something that is easily done? If so, where? >> > >> > Many thanks! >> >> It's not in Dillo yet -- it's something we'd have to code >> and add in.? But it wouldn't be too hard to do. >> >> In the meantime, you can just download the file normally >> and open it from your computer; it's a little less >> convenient, but that at least should work for now. > >Yes, of course! But it would be nice to have this little feature because that would make it easier to use dillo for routine things. I have been trying to adopt it increasingly, despite the absence of frames, and I find this to be somewhat disconcerting. On the flip, I just love accidentally clicking on a link/URL within Google thinking it's going to spawn a new tab with an HTML page, only to find-out acroread or epdfview trying to start on my short-of-resources computers. Half the time, it's nice to see Seamonkey automatically open PDF's, other times, it's a pain because I can't do anything until the resource hog applications complete after their execution process. (Oh, including the wait for download because I thought it was an HTML page.) Seems the only middle-of-the-road solution for me, disable the auto-open feature for PDF files and use Google "view as HTML" links (if my eye catches them!). As far as opening other file types such as text/diffs/patches/any_thing_else_you_can_think_of, etc., I'm all for it. -- Roger http://rogerx.freeshell.org/

Sept. 15, 2011

how to open links etc

by itsme_410＠yahoo.com

--- On Wed, 9/14/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote: > From: Benjamin Johnson <obeythepenguin at gmail.com> > Subject: Re: [Dillo-dev] how to open links etc > To: dillo-dev at dillo.org > Date: Wednesday, September 14, 2011, 6:07 PM > On Wed, 14 Sep 2011 17:50:06 -0400, > Globe Trotter <itsme_410 at yahoo.com> > wrote: > > > Is this something that is easily done? If so, where? > > > > Many thanks! > > It's not in Dillo yet -- it's something we'd have to code > and add in.? But it wouldn't be too hard to do. > > In the meantime, you can just download the file normally > and open it from your computer; it's a little less > convenient, but that at least should work for now. Yes, of course! But it would be nice to have this little feature because that would make it easier to use dillo for routine things. I have been trying to adopt it increasingly, despite the absence of frames, and I find this to be somewhat disconcerting. My minor annoyance at this minor lack of feature aside, thanks for all your hard work!! Best wishes, T

Sept. 14, 2011

how to open links etc

by corvid＠lavabit.com

Benjamin wrote: > On Wed, 14 Sep 2011 15:41:48 -0400, Jeremy Henty wrote: > >Globe Trotter wrote: > > > >>Sorry to ask something perhaps really dumb, but when I click on some > >>links, eg a pdf file, I get prompted to save the file. Is it > >>possible for me to transfer the file to some external program (say > >>/usr/bin/epdfview) to open after download? Does this have to > >>programmed in somewhere? Where? As a dpi? If the latter, where are > >>the instructions? > > > >I think that the DPI interface is perhaps overly complicated for the > >common case where we just want to save the data to a temporary file > >and point some external program at it. Perhaps the config could > >specify a map from MIME types to helper functions, eg: > > > > application/pdf = epdfview %s > > Seconded. The DPI itself is just an external program anyway, so we > may as well cut out the middleman. I, for one, am at least open to this in principle, for what that's worth.

Sept. 14, 2011

Close dillo with multiple tabs open

by corvid＠lavabit.com

Roger wrote: > > On Sat, Sep 10, 2011 at 10:25:43AM +0200, Alexander Voigt wrote: > >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. I wasn't sure what my opinion was on this at first, but now I think an option sounds reasonable.

Sept. 14, 2011

how to open links etc

by obeythepenguin＠gmail.com

On Wed, 14 Sep 2011 17:50:06 -0400, Globe Trotter <itsme_410 at yahoo.com> wrote: > Is this something that is easily done? If so, where? > > Many thanks! It's not in Dillo yet -- it's something we'd have to code and add in. But it wouldn't be too hard to do. In the meantime, you can just download the file normally and open it from your computer; it's a little less convenient, but that at least should work for now. ~Benjamin

Sept. 14, 2011

how to open links etc

by itsme_410＠yahoo.com

--- On Wed, 9/14/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote: > From: Benjamin Johnson <obeythepenguin at gmail.com> > Subject: Re: [Dillo-dev] how to open links etc > To: dillo-dev at dillo.org > Date: Wednesday, September 14, 2011, 4:18 PM > On Wed, 14 Sep 2011 15:41:48 -0400, > Jeremy Henty <onepoint at starurchin.org>? > > wrote: > > > Globe Trotter wrote: > > > >> Sorry to ask something perhaps really dumb, but > when I click on some > >> links,? eg a? pdf? file, I? > get prompted? to? save the? file. Is? > it > >> possible for me? to transfer the file > to? some external program (say > >> /usr/bin/epdfview)? to? open? > after? download?? Does? this? have? > to > >> programmed in somewhere?? Where? As a dpi? > If? the latter, where are > >> the instructions? > > > > I think that? the DPI interface is perhaps? > overly complicated for the > > common case? where we just want to? save the > data to? a temporary file > > and? point some? external program? > at? it.? Perhaps? the config? could > > specify a map from MIME types to helper functions, > eg: > > > >? ???application/pdf = epdfview %s > > > > Thoughts? > > > > Regards, > > > > Jeremy Henty > > Seconded.? The DPI itself is just an external program > anyway, so we may as? > well cut out the middleman. Is this something that is easily done? If so, where? Many thanks!

Sept. 14, 2011

how to open links etc

by obeythepenguin＠gmail.com

On Wed, 14 Sep 2011 15:41:48 -0400, Jeremy Henty <onepoint at starurchin.org> wrote: > Globe Trotter wrote: > >> Sorry to ask something perhaps really dumb, but when I click on some >> links, eg a pdf file, I get prompted to save the file. Is it >> possible for me to transfer the file to some external program (say >> /usr/bin/epdfview) to open after download? Does this have to >> programmed in somewhere? Where? As a dpi? If the latter, where are >> the instructions? > > I think that the DPI interface is perhaps overly complicated for the > common case where we just want to save the data to a temporary file > and point some external program at it. Perhaps the config could > specify a map from MIME types to helper functions, eg: > > application/pdf = epdfview %s > > Thoughts? > > Regards, > > Jeremy Henty Seconded. The DPI itself is just an external program anyway, so we may as well cut out the middleman. ~Benjamin

Sept. 14, 2011

how to open links etc

by onepoint＠starurchin.org

Globe Trotter wrote: > Sorry to ask something perhaps really dumb, but when I click on some > links, eg a pdf file, I get prompted to save the file. Is it > possible for me to transfer the file to some external program (say > /usr/bin/epdfview) to open after download? Does this have to > programmed in somewhere? Where? As a dpi? If the latter, where are > the instructions? I think that the DPI interface is perhaps overly complicated for the common case where we just want to save the data to a temporary file and point some external program at it. Perhaps the config could specify a map from MIME types to helper functions, eg: application/pdf = epdfview %s Thoughts? Regards, Jeremy Henty

Sept. 14, 2011

configure message?

by obeythepenguin＠gmail.com

On Wed, 14 Sep 2011 01:08:12 -0400, Roger <rogerx.oss at gmail.com> wrote: > It sounds like they need to upgrade their present libpng from > libpng-1.2.46 to > libpng-1.4.* though. > > (No, the mingw32 is something ming windows related. Cygwin related??) Not Cygwin -- MinGW's the native GNU compiler for Windows (what I use for Dillo-Win32). Fedora ships MinGW -- and some popular libraries compiled for it -- to allow cross-compiling Windows software from Linux. > On Gentoo, libpng-1.4.8 is marked stable. And the old version here on > Gentoo is > libpng-1.2.44 & libpng-1.2.45. (libpng-1.4.7 is masked and libpng-1.4.5 > is the > old stable version here.) I don't know about Fedora, since they're typically more bleeding edge, but RHEL usually lags a couple major versions behind on most packages, and backports critical security and other fixes to the old version as necessary. It's an extremely expensive and time-consuming system, but it's the only way they can ensure stability when the prevailing culture is against backwards compatibility and stable API's. At least Red Hat's big enough they can get away with it. ~Benjamin

Sept. 14, 2011

configure message?

by rogerx.oss＠gmail.com

> On Tue, Sep 13, 2011 at 07:03:43PM -0700, Globe Trotter wrote: >What does this message mean? I am running fedora 15 and I have both pkg-config as well as the following packages installed: > > >libpng-1.2.46-1.fc15.x86_64 >libpng10-devel-1.0.55-1.fc15.x86_64 >libpng-devel-1.2.46-1.fc15.x86_64 >libpng10-1.0.55-1.fc15.x86_64 > > >Here is the relevant portion: there is no libpng14 on fedora, but there is >mingw32-libpng-1.4.8-1.fc15.noarch which puts libpng14-config strangely into /usr/i686-pc-mingw32/sys-root/mingw/bin/libpng14-config. > > checking for libpng-config... which: no libpng14-config in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin) >/usr/bin/libpng12-config >checking for libpng version... 1.2.46 (newer version) >..... > >everything else compiles "fine".... It sounds like they need to upgrade their present libpng from libpng-1.2.46 to libpng-1.4.* though. (No, the mingw32 is something ming windows related. Cygwin related??) A quick email to them might get your dependency problem solved, as Dillo is quite popular. On Gentoo, libpng-1.4.8 is marked stable. And the old version here on Gentoo is libpng-1.2.44 & libpng-1.2.45. (libpng-1.4.7 is masked and libpng-1.4.5 is the old stable version here.) -- Roger http://rogerx.freeshell.org/

Sept. 14, 2011

how to open links etc

by itsme_410＠yahoo.com

Hi, Sorry to ask something perhaps really dumb, but when I click on some links, eg a pdf file, I get prompted to save the file. Is it possible for me to transfer the file to some external program (say /usr/bin/epdfview) to open after download? Does this have to programmed in somewhere? Where? As a dpi? If the latter, where are the instructions? I looked at hello.c for an example but I was no sure what to do with the C program. Where do i compile it and how? Thanks for the help! Best wishes, T

Sept. 14, 2011

configure message?

by obeythepenguin＠gmail.com

On Tue, 13 Sep 2011 22:03:43 -0400, Globe Trotter <itsme_410 at yahoo.com> wrote: > Here is the relevant portion: there is no libpng14 on fedora, but there > is > mingw32-libpng-1.4.8-1.fc15.noarch which puts libpng14-config strangely > into /usr/i686-pc-mingw32/sys-root/mingw/bin/libpng14-config. The mingw32-libpng package is used for cross-compiling code for Windows. Offhand I'm not sure why it's a different version than your system libpng. > checking for libpng-config... which: no libpng14-config in > (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin) > /usr/bin/libpng12-config > checking for libpng version... 1.2.46 (newer version) > ..... > > everything else compiles "fine".... The message just means Dillo's checking for libpng 1.4, then falling back on 1.2 if that's not found. Fedora probably ships 1.2.46 for stability, since a lot of applications are still coded for the older version. As long as Dillo's compiling fine, I wouldn't be too worried about it -- that message is purely informational. ~Benjamin

Sept. 14, 2011

configure message?

by itsme_410＠yahoo.com

What does this message mean? I am running fedora 15 and I have both pkg-config as well as the following packages installed: libpng-1.2.46-1.fc15.x86_64 libpng10-devel-1.0.55-1.fc15.x86_64 libpng-devel-1.2.46-1.fc15.x86_64 libpng10-1.0.55-1.fc15.x86_64 Here is the relevant portion: there is no libpng14 on fedora, but there is mingw32-libpng-1.4.8-1.fc15.noarch which puts libpng14-config strangely into /usr/i686-pc-mingw32/sys-root/mingw/bin/libpng14-config. checking for libpng-config... which: no libpng14-config in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin) /usr/bin/libpng12-config checking for libpng version... 1.2.46 (newer version) ..... everything else compiles "fine"....

Sept. 14, 2011

dillo-3.0-rc2 is out

by rogerx.oss＠gmail.com

>I was having a look around the web to see what reaction there was >to the 3.0 release, and the Puppy Linux folks were having a thread >that went something like "Pity it's so ugly" "Here, try these other >FLTK schemes" "Hey, that's great!" -- which is evidence that adding >a preference would be welcomed by users. Ugly? I think it looks just fine and dandy. I've rarely switched to other then the default theme a GUI gives because the default is usually has the best color contrast and themed conservatively. Of course, I'm more concerned about functionality then how something "looks". At most, think a "color picker" for choosing default frame and button colors, or empty boxes for manually stating a color number... similar to what color terminals do for theming. But these are just my random thoughts here, trying to save you from a mess of work that will only benefit a few. ;-) -- Roger http://rogerx.freeshell.org/

Sept. 14, 2011

dillo-3.0-rc2 is out

by higuita7＠yahoo.co.uk

Hi again >>>bisect it i found that fltk 1.3 rvision 9023 makes the openning/close >>>of the tabs slower in my machine. >> So is this a problem of fltk or from dillo, or both? :) A new info... updating to the lastest version to try the themes, i found that my dillorc had this option set: buffered_drawing=2 it was probably one old test that i did forgot, but after removing it, i get the normal "new tab/close tab" speed... So the double buffer and that fltk commit are the ones that turn dillo strangely slower. Thanks 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. 14, 2011

cppcheck warnings

by corvid＠lavabit.com

Alexander wrote: > $ cd dillo/lout/ > $ cppcheck * > [misc.cc:194]: (error) Common realloc mistake: "bits" nulled but not freed upon failure I wonder why it doesn't care about the other realloc()s in container.cc.

Sept. 14, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

I wrote: > Added a theme preference. Even added a screenshot to show what fun we're up to.

Sept. 13, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

Jorge wrote: > On Tue, Sep 13, 2011 at 03:31:14AM +0000, corvid wrote: > > I wrote: > > > Jorge wrote: > > > > On Fri, Sep 09, 2011 at 10:03:29AM +0200, Johannes Hofmann wrote: > > > > > 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. > > > > I was having a look around the web to see what reaction there was > > to the 3.0 release, and the Puppy Linux folks were having a thread > > that went something like "Pity it's so ugly" "Here, try these other > > FLTK schemes" "Hey, that's great!" -- which is evidence that adding > > a preference would be welcomed by users. > > The canonical solution to this problem seems to be to pack a > few "themes" selectable from preferences, and also allow some > fine tunning via rc preferences or so. > > I also read a good sign on this because people usually start to > customize the look of an app only after they find it useful. > > Would you mind handling this task? Added a theme preference. For now, you can specify an arbitrary string and get whatever weird mixture fltk gives you in that case. I asked on fltk.general whether it should do that rather than treat an unknown scheme as the default scheme. Obviously it would be trivial to deal with for ourselves. If anyone gets ambitious enough or bored enough one day to want to make additional themes, you can look in fltk's Fl_get_system_colors.cxx at Fl::reload_scheme(). It mostly amounts to defining frame and box types.

Sept. 13, 2011

cppcheck warnings

by Hole.destructor＠gmx.de

Dear Dillo developers, I just ran cppcheck on the Dillo source and got some (pedantic) warning messages. I'd like to list them here just in case it might be something serious. $ cd dillo/src/ $ cppcheck * [ui.cc:1067]: (error) Possible null pointer dereference: StatusBar - otherwise it is redundant to check if StatusBar is null at line 1079 $ cd dillo/dpi/ $ cppcheck * [downloads.cc:512]: (error) Common realloc mistake: "log_text" nulled but not freed upon failure [file.c:549]: (error) Resource leak: fd $ cd dillo/lout/ $ cppcheck * [misc.cc:194]: (error) Common realloc mistake: "bits" nulled but not freed upon failure Kind regards, Alexander Voigt

Sept. 13, 2011

dillo-3.0-rc2 is out

by jcid＠dillo.org

On Tue, Sep 13, 2011 at 03:31:14AM +0000, corvid wrote: > I wrote: > > 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. > > I was having a look around the web to see what reaction there was > to the 3.0 release, and the Puppy Linux folks were having a thread > that went something like "Pity it's so ugly" "Here, try these other > FLTK schemes" "Hey, that's great!" -- which is evidence that adding > a preference would be welcomed by users. The canonical solution to this problem seems to be to pack a few "themes" selectable from preferences, and also allow some fine tunning via rc preferences or so. I also read a good sign on this because people usually start to customize the look of an app only after they find it useful. Would you mind handling this task? -- Cheers Jorge.-

Sept. 13, 2011

Alternate bookmarks interface

by darkspirit5000＠gmail.com

Only some problems of this alpha version: Do not compile in linux (fail trying to compile bookmarks.dpi. I compile it removing bookmarks lines from dpi/Makefile ) The menus do not trim bookmarks titles so you can have menus with long text. You do not see submenus with long text because go out the screen. FLTK problem? But it is interesting. (It is like in first versions of dillo) The bookmarks.dpi is better to work with various entries at same time. I will prefer a winDPI code instead of reimplement every dpi inside dillo. How can we do it? Diego. PD:sorry for my bad english. 2011/9/13, Benjamin Johnson <obeythepenguin at gmail.com>: > Just a quick update: > > I've fixed some bugs in the bookmarks code, and changed it so bookmarks > load on-demand rather than at startup. This keeps the browser startup > fast and saves some memory, at the expense of making the first bookmarks > operation slightly slower. > > I also added a new feature -- middle-clicking a section title will open > all the bookmarks in that section in background tabs. (It exposes some > interesting networking/rendering behavior, since apparently the engine > doesn't expect to handle that many simultaneous requests.) > > Here's the patch again if anyone wants to try it: > http://dillo-win32.sourceforge.net/patches/31-bookmarks.diff > > ~Benjamin > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 13, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

I wrote: > 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. I was having a look around the web to see what reaction there was to the 3.0 release, and the Puppy Linux folks were having a thread that went something like "Pity it's so ugly" "Here, try these other FLTK schemes" "Hey, that's great!" -- which is evidence that adding a preference would be welcomed by users.

Sept. 13, 2011

Alternate bookmarks interface

by obeythepenguin＠gmail.com

Just a quick update: I've fixed some bugs in the bookmarks code, and changed it so bookmarks load on-demand rather than at startup. This keeps the browser startup fast and saves some memory, at the expense of making the first bookmarks operation slightly slower. I also added a new feature -- middle-clicking a section title will open all the bookmarks in that section in background tabs. (It exposes some interesting networking/rendering behavior, since apparently the engine doesn't expect to handle that many simultaneous requests.) Here's the patch again if anyone wants to try it: http://dillo-win32.sourceforge.net/patches/31-bookmarks.diff ~Benjamin

Sept. 13, 2011

Alternate bookmarks interface

by obeythepenguin＠gmail.com

On 9/12/11, Roger <rogerx.oss at gmail.com> wrote: > Seamonkey's .config, and now addons and passwords all look like dillos > bookmarks. Looks like a regular HTML page. That sounds like terrible design to me, although at least Seamonkey has JavaScript, which kind of makes up for the limitations of HTML forms. The one thing bookmarks.dpi really has on the menu interface is it's easy to bulk-move bookmarks to a new section, and even then that wouldn't be too hard to do with a traditional dialog. Actually, with a dialog you could just drag-and-drop. Side note: my memory usage now (with one tab open to Gmail) is 7,912K, and dillo.exe is about 1,308K after stripping + UPX, still small enough to fit on a floppy disk. That's with bookmarks, downloads, cookies, HTTPS, printing, etc. all enabled and compiled in. Just thought I'd share :-) ~Benjamin

Sept. 12, 2011

Alternate bookmarks interface

by rogerx.oss＠gmail.com

>Does Seamonkey open it as a webpage, or is it a widget interface displayed >in a browser tab? For example, Opera's bookmark manager is the latter: > http://screenshots.oahermes.com/opera/large_2_opera_bookmarks_manager.png Seamonkey's .config, and now addons and passwords all look like dillos bookmarks. Looks like a regular HTML page. Opera's bookmarks, appears like files imo. -- Roger http://rogerx.freeshell.org/

Sept. 12, 2011

Alternate bookmarks interface

by obeythepenguin＠gmail.com

On Mon, 12 Sep 2011 01:54:56 -0400, Roger <rogerx.oss at gmail.com> wrote: >> - 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.) > > Personally, I like the middle-click in Seamonkey browser, opens the > pasted URL. > (Downside, anything in the paste buffer gets opened in the browser on > click.) I'm not sure what that has to do with the quoted text... > From what I'm seeing with the latest version of Seamonkey-2.3.3, > everything > (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. Does Seamonkey open it as a webpage, or is it a widget interface displayed in a browser tab? For example, Opera's bookmark manager is the latter: http://screenshots.oahermes.com/opera/large_2_opera_bookmarks_manager.png Personally, I think that just because you're developing a web browser, doesn't mean everything has to be a web page. In many cases, a traditional dialog interface works better. It's easier to figure out, because of standardized widgets and layouts, and it's a bit faster as well -- compare adding a bookmark in the DPI to my interface. (It also uses less code; more than half the lines in my patch are just removing the bookmarks DPI.) Anyway, all I'm saying is try it out and see how you like it -- you may be pleasantly surprised. Cheers, ~Benjamin

Sept. 12, 2011

patch for UI and font_factor

by corvid＠lavabit.com

I just tried changing the value of FL_NORMAL_SIZE, and I was very surprised by how well everything copes overall. If I had bad vision and needed, say, font_factor=1.4, I'd _strongly_ prefer this patch despite the various bits of UI size hardcoding that it reveals. - I think the Tools menu imperfection comes from "if (flags & (FL_MENU_TOGGLE|FL_MENU_RADIO)) w += 14;" in Fl_Menu.cxx, but I haven't taken the minute to verify that yet. - Choice5 does not handle it well. I made a nicer choice5 a few months ago, but Jorge didn't like it.

Sept. 12, 2011

Alternate bookmarks interface

by rogerx.oss＠gmail.com

> - 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.) Personally, I like the middle-click in Seamonkey browser, opens the pasted URL. (Downside, anything in the paste buffer gets opened in the browser on click.)

Sept. 12, 2011