September 2011 - Dillo-dev - lists.mailman3.com

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