- Dillo-dev - lists.mailman3.com

pasting URL

by thomas-forum＠orgis.org

Hi there, I'm wondering if it would be difficult to add a neat little feature that other browsers usuall implement: X11 Mouse-mid-click pasting of an url in the body of the dillo window as a shortcut to x-ing the url field and pasting there, then type enter. ...or does someone already have a patch handy? ;-) And: Don't let you be distracted from CSS support by this... Alrighty then, Thomas.

Oct. 22, 2008

issues & suggestions

by jcid＠dillo.org

On Sun, Oct 19, 2008 at 06:19:30PM +0300, Tomas R wrote: > > > [...] > > > 2) With the latest dillo2 version (I think this bug was introduced > > > only recently, as I tested dillo2 from cvs not so long ago & it > > > wasn't present) the menu is "teared off" when pressed. Here is a > > > screenshot: > > > http://img410.imageshack.us/img410/5211/dillomenuxu9.png > > > and dillorc I use: > > > http://pastebin.com/f42244f75 > > > > Not a bug but a feature! > > > > The detached menu allows for two things: > > > > 1.- Popup menu working with Alt-F shortcut even when the "File" > > item is hidden. > > 2.- Simpler code and improved panel configuraion flexibility. > Even from dev's perspective it might seem as a feature but from user's > - it's an ugly bug. Please try current CVS. -- Cheers Jorge.-

Oct. 22, 2008

css

by Johannes.Hofmann＠gmx.de

Hi, here comes my proposal to get css support started. Note that I'm new to this stuff so I will probabely simplify things a lot and miss many issues that will have to be addressed later on. * Separate out the style handling from html.cc in a new class StyleEngine (better name welcome). This class will be fed the html tree via a SAX like interface as the document is parsed and will hand out the current Style object. * Initially StyleEngine will be implemented to just mimic the current behaviour of html.cc. So after this step everything should work as currently. * Then we can design the data structures to hold parsed css data and make StyleEngine use these structures which will be statically filled initially. Again dillo should work as it does now. * Next we can implement a css parser that is able to fill the data structures from the last step. Now we should already be able to set a fixed user style sheet. * Hooking up the css parser to automatically load css information as referenced in html pages would be next. * In parallel to all this we would need to make floating objects work in dw/textblock.cc. This approach has some issues. In contrast to http://www.dillo.org/CSS.html it would only be possible to apply style information that is available when starting parsing of a document. However we could start rendering with what style information is available and reload once all css files have been loaded. Currently dillo parses attributes on demand. So we don't have a complete list of attributes and their values. As StyleEngine might access any attribute, we might need to change this. Comments or more advanced plans would be more than welcome! Cheers, Johannes

Oct. 22, 2008

patch: prefs.vw_fontname as fltk ui's default font

by Johannes.Hofmann＠gmx.de

On Wed, Oct 22, 2008 at 04:09:42PM +0000, corvid wrote: > Johannes wrote: > > On Wed, Oct 22, 2008 at 02:27:23PM +0000, corvid wrote: > > > I was changing the font in a few more places that > > > can take arbitrary user text -- and then having > > > to change it for neighbouring things so that > > > the difference isn't too jarring -- and I reached > > > the point where it seemed like it may be best > > > just to change the font for everything. > > > > > > > I like it! > > We could also remove the places where the font has been set already. > > Yeah, I figured I'd rip out the existing ones later in a patch to Jorge > if this one goes over well. (except source, which I'm accustomed to seeing > in a fixed-width font) > > For me, there's no change by default because dejavu sans is my default > sans-serif font in fontconfig and I use it for dillo unless I want to > view Asian characters for some reason. > > > PS: In case someone needs it we could add a ui font option in dillorc > > and default to fw_fontname. > > Why fw? I meant vw...

Oct. 22, 2008

patch: prefs.vw_fontname as fltk ui's default font

by corvid＠lavabit.com

Johannes wrote: > On Wed, Oct 22, 2008 at 02:27:23PM +0000, corvid wrote: > > I was changing the font in a few more places that > > can take arbitrary user text -- and then having > > to change it for neighbouring things so that > > the difference isn't too jarring -- and I reached > > the point where it seemed like it may be best > > just to change the font for everything. > > > > I like it! > We could also remove the places where the font has been set already. Yeah, I figured I'd rip out the existing ones later in a patch to Jorge if this one goes over well. (except source, which I'm accustomed to seeing in a fixed-width font) For me, there's no change by default because dejavu sans is my default sans-serif font in fontconfig and I use it for dillo unless I want to view Asian characters for some reason. > PS: In case someone needs it we could add a ui font option in dillorc > and default to fw_fontname. Why fw?

Oct. 22, 2008

patch: prefs.vw_fontname as fltk ui's default font

by Johannes.Hofmann＠gmx.de

On Wed, Oct 22, 2008 at 02:27:23PM +0000, corvid wrote: > I was changing the font in a few more places that > can take arbitrary user text -- and then having > to change it for neighbouring things so that > the difference isn't too jarring -- and I reached > the point where it seemed like it may be best > just to change the font for everything. > I like it! We could also remove the places where the font has been set already. Cheers, Johannes PS: In case someone needs it we could add a ui font option in dillorc and default to fw_fontname.

Oct. 22, 2008

dillo-2.0 compilation failure

by Johannes.Hofmann＠gmx.de

On Wed, Oct 22, 2008 at 08:44:48AM -0300, Jorge Arellano Cid wrote: > On Wed, Oct 22, 2008 at 12:09:10AM +0200, Ben de Groot wrote: > > Jorge Arellano Cid wrote: > > > On Tue, Oct 21, 2008 at 07:39:51PM +0200, Ben de Groot wrote: > > > > >> % grep inbuf_t work/dillo-2.0/config.log > > >> #define inbuf_t const char > > > > > > It looks like the test in configure.in detects iconv() in > > > a strange way. > > > > Indeed, something seems to go wrong there. My glibc version is > > 2.8_p20080602. > > > > > What's inconv's signature in your OS? > > > > extern size_t iconv (iconv_t __cd, char **__restrict __inbuf, > > size_t *__restrict __inbytesleft, > > char **__restrict __outbuf, > > size_t *__restrict __outbytesleft); > > OK. > > A "char **" not a "const char **". > > > > Just for testing try setting [char] instead of [const char] in > > > configure.in:348. > > > > In our bugtracker another patch was proposed, which makes dillo compile > > for me. https://bugs.gentoo.org/show_bug.cgi?id=242774 > > > > --- src/form.cc 2008-10-21 21:02:31 +0000 > > +++ src/form.cc 2008-10-21 21:02:53 +0000 > > @@ -1240,8 +1240,9 @@ > > int rc = 0; > > Dstr *output; > > const int bufsize = 128; > > - inbuf_t *inPtr; > > - char *buffer, *outPtr; > > + //inbuf_t *inPtr; > > + //char *buffer, *outPtr; > > + char *buffer, *outPtr, *inPtr; > > size_t inLeft, outRoom; > > bool bad_chars = false; > > > > Does this patch look good to you? > > No. > > It seems to be enough for Gentoo, but I'd prefer to detect the > type of inbuf_t correctly in configure.in, so it compiles out of > the box. One could think that using char* for inPtr would work for both cases (char ** and const char ** in the declaration of iconv), but it doesn't: void test(const char **s) {}; int main(int argc, char **argv) { char *s; test(&s); } fails with const.cc: In function 'int main(int, char**)': const.cc:5: error: invalid conversion from 'char**' to 'const char**' const.cc:5: error: initializing argument 1 of 'void test(const char**)' See e.g. http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17 for the reason why this does not work. Cheers, Johannes

Oct. 22, 2008

[patch]: change the default tab label to "Dillo"

by Johannes.Hofmann＠gmx.de

On Tue, Oct 21, 2008 at 09:12:02PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Oct 20, 2008 at 12:21:49PM +0100, Jeremy Henty wrote: > > > > > > *ahem*, replying to myself. > > > > > > > ... I think it looks a little sad when a new tab pops up with the > > > > pointless label "Label", so I changed it to "Dillo". > > > > > > No comments on this? It seems to have vanished without trace. > > > > It doesn't seem to make much difference (and we have no > > comments so far). > > > > Although I see one point with the "Label" label ;), > > it suggests that there goes a label that's yet unset. > > I didn't say anything because I didn't care too much, > but I suppose I like Dillo better than Label. Same here. Cheers, Johannes

Oct. 22, 2008

patch: prefs.vw_fontname as fltk ui's default font

by corvid＠lavabit.com

I was changing the font in a few more places that can take arbitrary user text -- and then having to change it for neighbouring things so that the difference isn't too jarring -- and I reached the point where it seemed like it may be best just to change the font for everything.

Oct. 22, 2008

dillo-2.0 compilation failure

by jcid＠dillo.org

On Wed, Oct 22, 2008 at 12:09:10AM +0200, Ben de Groot wrote: > Jorge Arellano Cid wrote: > > On Tue, Oct 21, 2008 at 07:39:51PM +0200, Ben de Groot wrote: > > >> % grep inbuf_t work/dillo-2.0/config.log > >> #define inbuf_t const char > > > > It looks like the test in configure.in detects iconv() in > > a strange way. > > Indeed, something seems to go wrong there. My glibc version is > 2.8_p20080602. > > > What's inconv's signature in your OS? > > extern size_t iconv (iconv_t __cd, char **__restrict __inbuf, > size_t *__restrict __inbytesleft, > char **__restrict __outbuf, > size_t *__restrict __outbytesleft); OK. A "char **" not a "const char **". > > Just for testing try setting [char] instead of [const char] in > > configure.in:348. > > In our bugtracker another patch was proposed, which makes dillo compile > for me. https://bugs.gentoo.org/show_bug.cgi?id=242774 > > --- src/form.cc 2008-10-21 21:02:31 +0000 > +++ src/form.cc 2008-10-21 21:02:53 +0000 > @@ -1240,8 +1240,9 @@ > int rc = 0; > Dstr *output; > const int bufsize = 128; > - inbuf_t *inPtr; > - char *buffer, *outPtr; > + //inbuf_t *inPtr; > + //char *buffer, *outPtr; > + char *buffer, *outPtr, *inPtr; > size_t inLeft, outRoom; > bool bad_chars = false; > > Does this patch look good to you? No. It seems to be enough for Gentoo, but I'd prefer to detect the type of inbuf_t correctly in configure.in, so it compiles out of the box. Please try the tweak-test in configure.in. If it works, we'll be sure proper detection will fix the bug. -- Cheers Jorge.-

Oct. 22, 2008