- Dillo-dev - lists.mailman3.com

[patch] Do not change window title

by Johannes.Hofmann＠gmx.de

On Fri, May 15, 2009 at 03:28:12PM -0400, Jorge Arellano Cid wrote: > On Fri, May 15, 2009 at 08:49:01PM +0200, Christian Kellermann wrote: > > * Jorge Arellano Cid <jcid(a)dillo.org> [090515 20:32]: > > > > You will find a patch with this behaviour change attached to this > > > > email. > > > > > > Does the attached patch solve the problem? ;-) > > > > > > > Yes, that's great. Thanks! > > Committed. Very good!

May 15, 2009

[patch] Do not change window title

by jcid＠dillo.org

On Fri, May 15, 2009 at 08:49:01PM +0200, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [090515 20:32]: > > > You will find a patch with this behaviour change attached to this > > > email. > > > > Does the attached patch solve the problem? ;-) > > > > Yes, that's great. Thanks! Committed. -- Cheers Jorge.-

May 15, 2009

[patch] Do not change window title

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [090515 20:32]: > > You will find a patch with this behaviour change attached to this > > email. > > Does the attached patch solve the problem? ;-) > Yes, that's great. Thanks! Christian

May 15, 2009

[patch] Do not change window title

by jcid＠dillo.org

On Mon, May 11, 2009 at 09:32:57PM +0200, Christian Kellermann wrote: > Dear dillo fans, > > I have noticed the following behaviour: Dillo updates the title of > a window only when opening or loading a new page. I used tabbed > browsing a lot and I like to switch back and forth between page > tabs. The window title will not update and will show the latest > loaded window title. > > As I haven't found a way to update the window's title cleanly, I > would disable this behaviour if tabs are in use. For non tabbed > browsing updating the window title stays the same. > > You will find a patch with this behaviour change attached to this > email. Does the attached patch solve the problem? ;-) -- Cheers Jorge.-

May 15, 2009

[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