- Dillo-dev - lists.mailman3.com

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