- Dillo-dev - lists.mailman3.com

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