Hi there, After: [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] default search engine [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ok] margin-bottom + some margin collapse [ok] fix doctree leak Today the rc2 was packaged. Please get it here: http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball http://dillo.org/download/dillo-3.0-pre.tar.bz2.asc // signature The idea is to test the package in different OS/HW-Platforms and to report how the build process went, and how it works. Hopefully it'll become dillo-3.0. Afterall, it has been for a long enough time in testing phase. TIA for your feedback. -- Last but not the least: [ok] valgrind logs: cancel expected url I can't reproduce this anymore (after the committed fix). If somebody can still reproduce it, please report it. Details are in this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008810.html (the "expected url" is the one you've asked for but whose data bytes haven't started to arrive. If during this period of time you stop the request --e.g. by pressing Stop or clicking another URL, it's cancelled--). -- Cheers Jorge.-
Hi, On Mon, Aug 29, 2011 at 05:07:39PM -0300, Jorge Arellano Cid wrote:
Today the rc2 was packaged. Please get it here:
Hrm, the tar ball doesn't contain the autogen.sh script I used for the Debian packaging. (I build the last two package against the hg checkout. Not sure if was in earlier dillo packages, i.e. 0.8.6 or so) Is that file not included on purpose? At least in the README, the instructions still say: tar jxvf dillo-3.0.tar.bz2 cd dillo-3.0 ./autogen.sh; ./configure; make sudo make install-strip OTOH the INSTALL document skips that step, but AFAICS it never has been changed since the import into the Mercurial repository while the README has changed a lot in the "Minor changes for dillo-3.0-rc2" commit. Looks inconsistent to me. Not sure which variant is the intended one. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe@deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe@noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)
On Tue, Aug 30, 2011 at 12:01:41AM +0200, Axel Beckert wrote:
Hi,
On Mon, Aug 29, 2011 at 05:07:39PM -0300, Jorge Arellano Cid wrote:
Today the rc2 was packaged. Please get it here:
Hrm, the tar ball doesn't contain the autogen.sh script I used for the Debian packaging. (I build the last two package against the hg checkout. Not sure if was in earlier dillo packages, i.e. 0.8.6 or so) Is that file not included on purpose?
Yes, autogen.sh uses auto* tools to rebuild the configure script, but the configure script is included in the tarball. It is not in the repository because different auto*tools in different platforms generate slightly different configure scripts leading to almost one configure update per commit...
At least in the README, the instructions still say:
tar jxvf dillo-3.0.tar.bz2 cd dillo-3.0 ./autogen.sh; ./configure; make sudo make install-strip
OTOH the INSTALL document skips that step, but AFAICS it never has been changed since the import into the Mercurial repository while the README has changed a lot in the "Minor changes for dillo-3.0-rc2" commit.
Looks inconsistent to me. Not sure which variant is the intended one.
Right. Fixed in the repo to read: tar jxvf dillo-3.0.tar.bz2 cd dillo-3.0 ./configure; make sudo make install-strip -- Cheers Jorge.-
We'll need to make a point of mentioning -- at least in the release announcement, and maybe in README -- how specifying fonts is a little trickier now with fltk-1.3. I wouldn't be surprised if we end up having to try to get fltk to add another interface of some sort so that those of us who care about fonts and have a lot of them (i.e., not me) can have font-family work more consistently.
On Tue, Aug 30, 2011 at 05:47:36PM +0000, corvid wrote:
We'll need to make a point of mentioning -- at least in the release announcement, and maybe in README -- how specifying fonts is a little trickier now with fltk-1.3.
OK. Please go ahead and write some directions. It looks like dillorc and the README file are the best places for it.
I wouldn't be surprised if we end up having to try to get fltk to add another interface of some sort so that those of us who care about fonts and have a lot of them (i.e., not me) can have font-family work more consistently.
Ack. -- Cheers Jorge.-
Hi Compiles on slackware64 without problem, but...
[ok] resize problems when tabs overflow
open new tabs takes longer and there is a longer pause until i can open one more... also, close a tab is also slower. I also found that slashdot was removed from the default page... any special reason? i use it alot :) 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
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
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?
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
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?
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
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.
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
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
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/vncviewer.cxx?revision=4669&view=markup -- -- Rogut?s Sparnuotos
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.-
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 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.
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.-
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.
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.-
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.htm... Any opinions?
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.htm...
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
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
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...
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
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/
participants (9)
-
abe＠deuxchevaux.org -
corvid＠lavabit.com -
higuita7＠yahoo.co.uk -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de
-
obeythepenguin＠gmail.com -
rogerx.oss＠gmail.com -
rogutes＠googlemail.com