- Dillo-dev - lists.mailman3.com

Compiling error

by ingwie2000＠googlemail.com

Hey. Now that FLTK is up and working?this happens: g++ -I/Applications/drag0n/drag0n.app/Contents/System/usr/local/include -I/Applications/drag0n/drag0n.app/Contents/System/usr/local/include/FL/images -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/Applications/drag0n/drag0n.app/Contents/System/usr/local/lib -lfltk -lpthread -framework Cocoa -lz -liconv duplicate symbol __ZN10Fl_Printer8class_idE in: ../dw/libDw-fltk.a(libDw_fltk_a-fltkplatform.o) /Applications/drag0n/drag0n.app/Contents/System/usr/local/lib/libfltk.a(Fl_Printer.o) ld: 1 duplicate symbol for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [dillo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 /Applications/drag0n/drag0n.app/Contents/System includes a copy of my toolchain, also meaning FLTK and others. What can I do to get rid of this duplicate error? From what I know, a function was declared twice somewhere, but then again I did not study the source code ^^. Kind regards, Ingwie

Nov. 20, 2013

FLTK won't build on Mac OS

by jcid＠dillo.org

On Wed, Nov 20, 2013 at 03:49:54PM +0100, Kevin Ingwersen wrote: > Hello there. Hi. > I just downloaded Dillo because I wanted to use it for > development, obviously. However, upon building FLTK, i had to > realize its not build-able - and that is more a conflict on > apple?s side. Once the Carbon headers are refferenced, i get a > miles-long error message (it took me a while to find the top of > all that O.o). Which FLTK version are you trying to build? Dillo uses 1.3.x AFAIK, FLTK is buildable on Macs since long ago. Even the newest 3.0 branch. You may ask FLTK developers shall the problem persist. (www.fltk.org) > Will Dillo stay with FLTK or are there plans to move on with a > newer GUI? Plans are to stay with FLTK. -- Cheers Jorge.-

Nov. 20, 2013

FLTK won't build on Mac OS

by ingwie2000＠googlemail.com

Hello there. I just downloaded Dillo because I wanted to use it for development, obviously. However, upon building FLTK, i had to realize its not build-able - and that is more a conflict on apple?s side. Once the Carbon headers are refferenced, i get a miles-long error message (it took me a while to find the top of all that O.o). Will Dillo stay with FLTK or are there plans to move on with a newer GUI? Kind regards, Ingwie

Nov. 20, 2013

FLTK won't build on Mac OS

by dev＠frign.de

On Wed, 20 Nov 2013 15:49:54 +0100 Kevin Ingwersen <ingwie2000 at googlemail.com> wrote: > Hello there. > > I just downloaded Dillo because I wanted to use it for development, obviously. However, upon building FLTK, i had to realize its not build-able - and that is more a conflict on apple?s side. Once the Carbon headers are refferenced, i get a miles-long error message (it took me a while to find the top of all that O.o). > > Will Dillo stay with FLTK or are there plans to move on with a newer GUI? > > Kind regards, > Ingwie Hey Ingwie, always keep in mind: newer =!= better! It would be great if you could provide these "miles-long" error-logs to us so we get an idea what the problem is. It could as well be a problem limited to your system. Back in the old days when I used Mac OS X, it was a daily struggle to even get the simplest program to compile. Now I'm on Gentoo for good reasons. MacPorts offers a build for dillo [1]. You might want to try that out before suggesting us to rewrite big parts of the software or switching toolkits! Cheers FRIGN [1]: https://trac.macports.org/browser/trunk/dports/www/dillo/Portfile -- FRIGN <dev at frign.de>

Nov. 20, 2013

Image backgrounds

by sgeerken＠dillo.org

On Di, Nov 19, 2013, Johannes Hofmann wrote: > On Tue, Nov 19, 2013 at 03:59:01PM +0100, Sebastian Geerken wrote: > > I'd like to bring image backgrounds to a (temporary) end; before, I'd > > like to finish these tasks (see also doxygen documentation): > > Cool! It looks really nice. > > > - Configurability: Should there be new options, additional to > > "load_image"? If yes, there have to be: > > > > 1. a new option, "load_background_image", > > 2. a new entry in the configuration menu, and > > 3. a new entry in the context menu. > > > > The latter will be quite tricky, when applied to single areas for > > which a background image is assigned to, but an entry "load *ALL* > > background images" (emphasis mine) should be simple. > > I think there should be an option to switch off background image > loading, so that by switching it off one can basically get the > current bahavior. > Not sure if we need 2. and 3. I've added 1, and also 2, which was rather simple. Should be enough for now. BTW: I've copied the code from Menu_remote_css_cb, but found out that changing "Use remote CSS" in the tools menu (as well as "Load image backgrounds") is only applied to the current tab, while the change is actually global (which is visible when reloading another tab). That's somewhat confusing. > > - Security/privacy (cookies?): I'm not sure whether there is anything > > left to do. > > It should respect the rules from domainrc, but as far as I tested > it does that. OK. > > > > - Displaying image backgrounds at once, not line by line: there is > > already an hardcoded option, so changing is simple, even make it a > > user option. > > > > "background-attachment" is postponed. Furthermore, other features are > > missing, which make background images look strange, e. g. that you > > only see a part of the logo at <http://google.com>. > > Do you know what missing features cause this? As far as I see, it is the "height" attribute. Often, an area (<div>) is assigned a background image as well as width and height of the image itself. This way, the image (which is regarded as presentation detail) is only defined by CSS, not in HTML. Sebastian

Nov. 20, 2013

Image backgrounds

by Johannes.Hofmann＠gmx.de

Hi Sebastian, On Tue, Nov 19, 2013 at 03:59:01PM +0100, Sebastian Geerken wrote: > Hi! > > I'd like to bring image backgrounds to a (temporary) end; before, I'd > like to finish these tasks (see also doxygen documentation): Cool! It looks really nice. > > - Configurability: Should there be new options, additional to > "load_image"? If yes, there have to be: > > 1. a new option, "load_background_image", > 2. a new entry in the configuration menu, and > 3. a new entry in the context menu. > > The latter will be quite tricky, when applied to single areas for > which a background image is assigned to, but an entry "load *ALL* > background images" (emphasis mine) should be simple. I think there should be an option to switch off background image loading, so that by switching it off one can basically get the current bahavior. Not sure if we need 2. and 3. > > - Security/privacy (cookies?): I'm not sure whether there is anything > left to do. It should respect the rules from domainrc, but as far as I tested it does that. > > - Displaying image backgrounds at once, not line by line: there is > already an hardcoded option, so changing is simple, even make it a > user option. > > "background-attachment" is postponed. Furthermore, other features are > missing, which make background images look strange, e. g. that you > only see a part of the logo at <http://google.com>. Do you know what missing features cause this? Cheers, Johannes

Nov. 19, 2013

Image backgrounds

by sgeerken＠dillo.org

Hi! I'd like to bring image backgrounds to a (temporary) end; before, I'd like to finish these tasks (see also doxygen documentation): - Configurability: Should there be new options, additional to "load_image"? If yes, there have to be: 1. a new option, "load_background_image", 2. a new entry in the configuration menu, and 3. a new entry in the context menu. The latter will be quite tricky, when applied to single areas for which a background image is assigned to, but an entry "load *ALL* background images" (emphasis mine) should be simple. - Security/privacy (cookies?): I'm not sure whether there is anything left to do. - Displaying image backgrounds at once, not line by line: there is already an hardcoded option, so changing is simple, even make it a user option. "background-attachment" is postponed. Furthermore, other features are missing, which make background images look strange, e. g. that you only see a part of the logo at <http://google.com>. Did I forget something important? Sebastian

Nov. 19, 2013

Last couple of patches

by jcid＠dillo.org

On Mon, Nov 18, 2013 at 06:56:04PM +0100, Sebastian Geerken wrote: > Hi! > > On Mo, Nov 18, 2013, Jorge Arellano Cid wrote: > > After changeset 1a8661485c0b and e40f77531b5e, the bookmarks > > page is rendered with the largest width I've seen. As the patches > > deal with table apportioning, probably there's a small bug lurking > > there. > > > > I've also found another couple of test pages of mine (from my > > table apportioning test set) that also show the effect. It happens with > > tables using "width=AUTO with cells widths in percentages". > > This was actually meant as a "cosmetic" change, without changing > functionality. Nevertheless, the recent commit should fix it, at > least, the attached page works now. Yes, I thought so. I'll let you know if something else springs, as now works ok with the last patch. Thanks for the quick fix! BTW, you may s/depricicated/deprecated/ -- Cheers Jorge.-

Nov. 18, 2013

Last couple of patches

by sgeerken＠dillo.org

Hi! On Mo, Nov 18, 2013, Jorge Arellano Cid wrote: > After changeset 1a8661485c0b and e40f77531b5e, the bookmarks > page is rendered with the largest width I've seen. As the patches > deal with table apportioning, probably there's a small bug lurking > there. > > I've also found another couple of test pages of mine (from my > table apportioning test set) that also show the effect. It happens with > tables using "width=AUTO with cells widths in percentages". This was actually meant as a "cosmetic" change, without changing functionality. Nevertheless, the recent commit should fix it, at least, the attached page works now. Sebastian

Nov. 18, 2013

Last couple of patches

by jcid＠dillo.org

Hi Sebastian, After changeset 1a8661485c0b and e40f77531b5e, the bookmarks page is rendered with the largest width I've seen. As the patches deal with table apportioning, probably there's a small bug lurking there. I've also found another couple of test pages of mine (from my table apportioning test set) that also show the effect. It happens with tables using "width=AUTO with cells widths in percentages". Attached it goes. -- Cheers Jorge.-

Nov. 18, 2013