- Dillo-dev - lists.mailman3.com

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