May 2009 - Dillo-dev - lists.mailman3.com

[patch] GCC v4.4

by tim.nieradzik＠gmx.de

> [...] please try to get to a solution that keeps Html_get_attr2() > const and that avoids C++ const_casts by declaring const char* > locals. See the attachments for the patch. It works fine here. Anyway, there are still some warnings when compiling the source: html.cc: In function ?void Html_tag_open_meta(DilloHtml*, const char*, int)?: html.cc:2792: attention : deprecated conversion from string constant to ?char*? form.cc: In member function ?Dstr* DilloHtmlForm::buildQueryData(DilloHtmlInput*)?: form.cc:1065: attention : deprecated conversion from string constant to ?char*? --Tim

May 15, 2009

[patch] GCC v4.4

by jcid＠dillo.org

On Thu, May 14, 2009 at 11:59:45PM +0200, Johannes Hofmann wrote: > Hi Tim, > > On Thu, May 14, 2009 at 08:55:25PM +0000, Tim Nieradzik wrote: > > Dillo does not compile with GCC v4.4.0. A patch is attached. > > Cool. Thanks for the patch! > One thing I don't see immediately is why a_Html_get_attr() must be > changed to return char* instead of const char*. > I would prefer to fix the callers of a_Html_get_attr() instead. I Agree. Tim: can you provide access to a machine with gcc-4.4 to give this problem a hands-on try. If not, please try to get to a solution that keeps Html_get_attr2() const and that avoids C++ const_casts by declaring const char* locals. -- Cheers Jorge.-

May 15, 2009

[patch] GCC v4.4

by jcid＠dillo.org

On Fri, May 15, 2009 at 03:32:47PM +0000, corvid wrote: > Tim wrote: > > > I would prefer to fix the callers of a_Html_get_attr() instead. > > > > Thanks, you are right. My patch was just a quick-and-dirty solution > > though. Certainly it can be done better. > > > > > Could you please post the compiler errors you get with current tip? > > > > Yes, but I only can give you the first error. Otherwise I would need > > to apply the patch partially. But to get an idea of the issue, this > > should be sufficient yet (the other errors were quite similar). > > > > [...] > > mv -f .deps/table.Tpo .deps/table.Po > > g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -g -O2 -Wall -W > > -Wno-unused-parameter -fno-rtti -fno-exceptions -MT tablecell.o -MD > > -MP -MF .deps/tablecell.Tpo -c -o tablecell.o tablecell.cc > > tablecell.cc: In member function ???virtual void > > dw::TableCell::wordWrap(int)???: > > tablecell.cc:55: error: invalid conversion from ???const char*??? to > > ???char*??? > > make[2]: *** [tablecell.o] Error 1 > > [...] > > So these all boil down to GCC 4.4 wanting strchr and strrchr to > return const char* when passed a const char* ? Yes. It's concisely explained here: http://gcc.gnu.org/gcc-4.4/porting_to.html -- Cheers Jorge.-

May 15, 2009

[patch] GCC v4.4

by corvid＠lavabit.com

Tim wrote: > > I would prefer to fix the callers of a_Html_get_attr() instead. > > Thanks, you are right. My patch was just a quick-and-dirty solution > though. Certainly it can be done better. > > > Could you please post the compiler errors you get with current tip? > > Yes, but I only can give you the first error. Otherwise I would need > to apply the patch partially. But to get an idea of the issue, this > should be sufficient yet (the other errors were quite similar). > > [...] > mv -f .deps/table.Tpo .deps/table.Po > g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -g -O2 -Wall -W > -Wno-unused-parameter -fno-rtti -fno-exceptions -MT tablecell.o -MD > -MP -MF .deps/tablecell.Tpo -c -o tablecell.o tablecell.cc > tablecell.cc: In member function ?virtual void > dw::TableCell::wordWrap(int)?: > tablecell.cc:55: error: invalid conversion from ?const char*? to > ?char*? > make[2]: *** [tablecell.o] Error 1 > [...] So these all boil down to GCC 4.4 wanting strchr and strrchr to return const char* when passed a const char* ?

May 15, 2009

[patch] GCC v4.4

by tim.nieradzik＠gmx.de

> I would prefer to fix the callers of a_Html_get_attr() instead. Thanks, you are right. My patch was just a quick-and-dirty solution though. Certainly it can be done better. > Could you please post the compiler errors you get with current tip? Yes, but I only can give you the first error. Otherwise I would need to apply the patch partially. But to get an idea of the issue, this should be sufficient yet (the other errors were quite similar). [...] mv -f .deps/table.Tpo .deps/table.Po g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT tablecell.o -MD -MP -MF .deps/tablecell.Tpo -c -o tablecell.o tablecell.cc tablecell.cc: In member function ?virtual void dw::TableCell::wordWrap(int)?: tablecell.cc:55: error: invalid conversion from ?const char*? to ?char*? make[2]: *** [tablecell.o] Error 1 [...] --Tim

May 15, 2009

JavaScript support experiment

by Johannes.Hofmann＠gmx.de

Hi, On Fri, May 15, 2009 at 02:35:10AM +0800, ?? ? wrote: > Hello all > > After I successful build and running dillo-2. I pay more attention on how JavaScript support on dillo. > There are some discussion on mailing list and useful information. > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005065.html > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-April/006280.html > > As dillo is fast and small footprint. Things like JavaScript should not be affect overall performence. > > What we need ? > 1.JavaScript parse engine. > I personally prefer SEE (simple ECMAScript Engine). > Light weight and seems maintained > > 2.Document Object Model. > We have to all objects and that's relate with engine and browser. > An really huge task ... > More important how to combine it into dillo ? I guess it could be combined with the Doctree (src/doctree.hh) which is currently used for CSS only. Note, that it's actually just a stack atm. > hard code into or by DPI ? > > As I'm new to dillo, I don't know you guys interesting about this. > So I decide to do an small experiment to implement JavaScript support with libSEE + Boehm-GC. > Get patch here > > http://tw.myblog.yahoo.com/stevegigijoe/article?mid=145&prev=-1&next=138 > > ****** > > Modify configure.in to check libsee and gc > > DOM Supports > > document.write() > document.getElementById() > document.forms.length > document.[form name].length > document.[form name].method > document.[form name].reset() > document.[form name].[input name].value > > Input HTML scripts and *.js from url > > run onClick script before submit > > ****** > > Take it as an study case. Any discussion & suggestion is welcome Excellent! I couldn't look into it in detail yet, but it's great that you have some real code here so we can get a picture of how it could work in the future. Cheers, Johannes

May 15, 2009

[patch] GCC v4.4

by Johannes.Hofmann＠gmx.de

Hi Tim, On Thu, May 14, 2009 at 08:55:25PM +0000, Tim Nieradzik wrote: > Dillo does not compile with GCC v4.4.0. A patch is attached. Cool. Thanks for the patch! One thing I don't see immediately is why a_Html_get_attr() must be changed to return char* instead of const char*. I would prefer to fix the callers of a_Html_get_attr() instead. Could you please post the compiler errors you get with current tip? Cheers, Johannes

May 15, 2009

[patch] GCC v4.4

by tim.nieradzik＠gmx.de

Dillo does not compile with GCC v4.4.0. A patch is attached. --Tim

May 14, 2009

change FLTK scheme for in dillo2

by corvid＠lavabit.com

Jorge wrote: > On Thu, May 14, 2009 at 03:29:24PM +0000, corvid wrote: > > Jorge wrote: > > > Here, for some reason, xterm didn't react to *foreground nor > > > *background, but honored "*cursorColor". At the same time Xpdf > > > reacted to *background though. > > > > Are you starting xterm from the cmdline > > cmdline. > > > or from some menu that > > has -fg and -bg specified in a config file? > > Besides ~/.xterm what other config file it has? Oh well. It didn't work the first time I tried it because terminals are the one thing that I start from an fvwm menu, and my fvwm2rc has the colors specified using flags...

May 14, 2009

change FLTK scheme for in dillo2

by Johannes.Hofmann＠gmx.de

On Thu, May 14, 2009 at 10:32:25AM -0400, Jorge Arellano Cid wrote: > On Wed, May 13, 2009 at 10:46:36PM +0200, Johannes Hofmann wrote: > > On Wed, May 13, 2009 at 04:33:26PM -0400, Jorge Arellano Cid wrote: > > > On Wed, May 13, 2009 at 07:11:10PM +0200, Johannes Hofmann wrote: > > > > On Wed, May 13, 2009 at 01:02:22PM -0400, Jorge Arellano Cid wrote: > > > > > On Mon, May 11, 2009 at 12:18:34AM +0200, Johannes Hofmann wrote: > > > > > > On Fri, May 08, 2009 at 12:37:50AM +0200, Johannes Hofmann wrote: > > > > > > > On Thu, May 07, 2009 at 03:44:19PM +0000, corvid wrote: > > > > > > > > IL'dar wrote: > > > > > > > > > Can I change colours of dialogues and scrollbar in dillo2? > > > > > > > > > I would like to gets something less bright. > > > > > > > > > Even something like fluid2's -bg option will be ok. > > > > > > > > > > > > > > > > Not currently. > > > > > > > > > > > > > > > > I would not necessarily be opposed to making ui_fg and ui_bg prefs and > > > > > > > > adding a bunch of [class]::default_style->[whatever]color() > > > > > > > > to dillo.cc, although I wouldn't be surprised if we ran into our > > > > > > > > share of places where fltk hardcodes things to, say, GRAY75. > > > > > > > > > > > > > > What do people think about reading X resources as in attached patch > > > > > > > (mainly copied from commented fltk2 code)? > > > > > > > It allows to specify e.g. > > > > > > > > > > > > > > dillo.background:red > > > > > > > dillo.foreground:white > > > > > > > > > > > > > > in your .Xdefaults > > > > > > > > > > > > Jorge, what do you think about this. I actually like it more and > > > > > > more after using it for some days. > > > > > > > > > > The ability to set colors as a theme is a good one. > > > > > Unfortunately I've tried the patch here and saw no difference. > > > > > Am I doing something wrong? (Just applied the patch and set my > > > > > ~/.Xdefaults to what you suggested. No difference in "open file", > > > > > nor "web search" dialogs). > > > > > > > > Hm, did you restart X or use xrdb -merge to load the new config? > > > > > > > > You could also set the colors for all clients like this: > > > > > > > > *foreground: #ffffff > > > > *background: #555555 > > > > *selectForeground: #000000 > > > > *selectBackground: orange > > > > *cursorColor: orange > > > > > > > > > > > > and verify that other programs (e.g. xterm) have the color set properly. > > > > > > Logged out into GDM, and also tried rebooting with the suggested > > > file and nothing happens. > > > > > > xserver-xorg-core Version: 2:1.6.0-0ubuntu14 (Jaunty) > > > > Weird. Can you try "xrdb -merge ~/.Xdefaults" with the settings > > above and then start an xterm? > > Here, for some reason, xterm didn't react to *foreground nor > *background, but honored "*cursorColor". At the same time Xpdf > reacted to *background though. Hm, maybe you have xterm specific resources set somewhere in your system. I guess these would overwrite the wildcard ones. With "appres xterm" you can get all matching resources for "xterm". > > Sometimes dillo changed its colors after a "xrdb -merge ~/.Xdefaults". > Others a xserver restart was needed. In a nutshell, here, > sometimes it works, and sometimes it doesn't. Very strange. The X resources mechanism is quite old and normally works reliably. > > That, and considering dillo running native in OSX, left me > wondering why not just making theme-colors plain dillorc options. > AFAIS it would work more reliably and in more platforms. I strongly prefer to use the standard mechanism for theming on each platform. On X11 this is X resources. That way you can consistently theme all your applications (at least the well behaved ones) with just a few lines in a central file. Also I think it is a great advantage of X resources that they are stored server side. So even applictions that are running remotely will use the consistent set of colors. Nevertheless I agree that this theme code actually belongs in the fltk library. I can try to send a patch to the fltk list that reenables the currently commented out X resources code. Cheers, Johannes

May 14, 2009