- Dillo-dev - lists.mailman3.com

HTML5

by corvid＠lavabit.com

Rob wrote: > [...] I thought I might raise this issue, and see what sort of mind the devs have about implementing HTML5 in dillo. ?Of course, I realise you fellows are probably up to your ears in the FLTK 1.3 port, but I thought this might make for an interesting discussion, if nothing else. ?To start off, I suppose the danger in implementing any of the new html stuff is that it is not standardised at all yet. ?See here for more: > http://en.wikipedia.org/wiki/HTML5#W3C_standardization_process > I guess the worry is that it could possibly be a bit of a moving target. There is that, and the general immensity of the thing. I'm guessing that Dillo will someday have to start recognizing the names of some new elements, form types, etc., as they become common.

April 20, 2011

1.3 port

by corvid＠lavabit.com

higuita wrote: > On Tue, 19 Apr 2011 01:20:04 +0000, "corvid" <corvid(a)lavabit.com> wrote: > > Jorge wrote: > > > The 1% remaining is the ability to switch panel sizes > > > on-the-fly, which could take me 1 day of work aprox. > > Looks like we still need > > - xembed > > - the preferred font code in dillo.cc. > > add the bug forward button bug (ie: it doesnt work, as i just > found out) :) What's wrong, exactly?

April 20, 2011

1.3 port

by itsme_410＠yahoo.com

Is this release going to depend on when fltk1.3 gets released? because judging by the look of things there, it may well be never....is there any official at-least-tentative release date? --- On Sat, 4/16/11, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > From: Jorge Arellano Cid <jcid(a)dillo.org> > Subject: [Dillo-dev] 1.3 port > To: "Dillo mailing list" <dillo-dev(a)dillo.org> > Date: Saturday, April 16, 2011, 4:54 PM > Hi there, > > ? FWIW,? I've? been? using? the > 1.3 branch for months now with no > problems? (i.e.? as? stable? as 2.0). > It's more or less 99% done, > with some new features (as improved tabs).? ? ! > :-) ! > > ? The???1%? remaining? > is? the? ability? to? switch? > panel? sizes > on-the-fly, which could take me 1 day of work aprox. > > ? I'd? like? to get your feedback on this > browser because it will > sooner than later become the official branch. > > ? Comments? > > -- > ? Cheers > ? Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

April 20, 2011

1.3 port

by higuita7＠yahoo.co.uk

Hi all On Tue, 19 Apr 2011 01:20:04 +0000, "corvid" <corvid(a)lavabit.com> wrote: > Jorge wrote: > > The 1% remaining is the ability to switch panel sizes > > on-the-fly, which could take me 1 day of work aprox. > Looks like we still need > - xembed > - the preferred font code in dillo.cc. add the bug forward button bug (ie: it doesnt work, as i just found out) :) 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

April 20, 2011

1.3 port

by corvid＠lavabit.com

Jorge wrote: > On Tue, Apr 19, 2011 at 06:04:14PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Apr 17, 2011 at 03:13:44PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sat, Apr 16, 2011 at 11:30:33PM -0800, Roger wrote: > > > > > > 1) I have "&File" for the "File" button. > > > > > > > > > > At some point corvid disabled FLTK's internal character > > > > > escaping on labels. Although I'd prefer to have the underlined > > > > > 'F' as in most menu APIs, rather than a bare 'F', I'm sure > > > > > there's a reason behind this (e.g. I remember setting labels with > > > > > strings taken from HTML pages could have side effects). > > > > > > > > > > We should nail this down easily (at least removing the '&' is > > > > > trivial). > > > > > > > > FLTK2 had public widget flags, so when we needed to set RAW_LABEL all > > > > over the place in FLTK2, it was easy (except when a workaround was > > > > necessary for tooltips). FLTK 1.3 has protected widget flags, making it > > > > rather more trouble to clear SHORTCUT_LABEL all over the place. > > > > It didn't seem at all worth the trouble of making lots and lots of derived > > > > classes so that File could still have an underline. > > > > > > Ah, OK. > > > > > > I just committed a fix that uses FL_NORMAL_LABEL to not > > > interpret special symbols, and sets FL_FREE_LABELTYPE to > > > interpret them (e.g. for "File" menu). > > > > My recollection is that the situation is something like the attached. > > > > (That said, I played with symbols one day because it comes with a little > > language to let you draw arbitrary shapes in different colors and so forth, > > which I mention because maybe someday we will find it useful to interpret > > symbols when, say, we want to use some Unicode character that we can't > > trust the font to have.) > > It looks quite clear as you propose. > > I was thinking of using FL_FREE_LABELTYPE for FLTK's default... > please feel free to commit. Putting some externs in dillo.cc and then calling fl_normal_label() and fl_normal_measure()? I wonder whether fl_draw_shortcut is supposed to be 1 ordinarily, and only switched to other values temporarily while drawing some label.

April 20, 2011

1.3 port

by jcid＠dillo.org

On Tue, Apr 19, 2011 at 06:04:14PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Apr 17, 2011 at 03:13:44PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sat, Apr 16, 2011 at 11:30:33PM -0800, Roger wrote: > > > > > 1) I have "&File" for the "File" button. > > > > > > > > At some point corvid disabled FLTK's internal character > > > > escaping on labels. Although I'd prefer to have the underlined > > > > 'F' as in most menu APIs, rather than a bare 'F', I'm sure > > > > there's a reason behind this (e.g. I remember setting labels with > > > > strings taken from HTML pages could have side effects). > > > > > > > > We should nail this down easily (at least removing the '&' is > > > > trivial). > > > > > > FLTK2 had public widget flags, so when we needed to set RAW_LABEL all > > > over the place in FLTK2, it was easy (except when a workaround was > > > necessary for tooltips). FLTK 1.3 has protected widget flags, making it > > > rather more trouble to clear SHORTCUT_LABEL all over the place. > > > It didn't seem at all worth the trouble of making lots and lots of derived > > > classes so that File could still have an underline. > > > > Ah, OK. > > > > I just committed a fix that uses FL_NORMAL_LABEL to not > > interpret special symbols, and sets FL_FREE_LABELTYPE to > > interpret them (e.g. for "File" menu). > > My recollection is that the situation is something like the attached. > > (That said, I played with symbols one day because it comes with a little > language to let you draw arbitrary shapes in different colors and so forth, > which I mention because maybe someday we will find it useful to interpret > symbols when, say, we want to use some Unicode character that we can't > trust the font to have.) It looks quite clear as you propose. I was thinking of using FL_FREE_LABELTYPE for FLTK's default... please feel free to commit. -- Cheers Jorge.-

April 19, 2011

1.3 port

by corvid＠lavabit.com

Jorge wrote: > On Sun, Apr 17, 2011 at 03:13:44PM +0000, corvid wrote: > > Jorge wrote: > > > On Sat, Apr 16, 2011 at 11:30:33PM -0800, Roger wrote: > > > > 1) I have "&File" for the "File" button. > > > > > > At some point corvid disabled FLTK's internal character > > > escaping on labels. Although I'd prefer to have the underlined > > > 'F' as in most menu APIs, rather than a bare 'F', I'm sure > > > there's a reason behind this (e.g. I remember setting labels with > > > strings taken from HTML pages could have side effects). > > > > > > We should nail this down easily (at least removing the '&' is > > > trivial). > > > > FLTK2 had public widget flags, so when we needed to set RAW_LABEL all > > over the place in FLTK2, it was easy (except when a workaround was > > necessary for tooltips). FLTK 1.3 has protected widget flags, making it > > rather more trouble to clear SHORTCUT_LABEL all over the place. > > It didn't seem at all worth the trouble of making lots and lots of derived > > classes so that File could still have an underline. > > Ah, OK. > > I just committed a fix that uses FL_NORMAL_LABEL to not > interpret special symbols, and sets FL_FREE_LABELTYPE to > interpret them (e.g. for "File" menu). My recollection is that the situation is something like the attached. (That said, I played with symbols one day because it comes with a little language to let you draw arbitrary shapes in different colors and so forth, which I mention because maybe someday we will find it useful to interpret symbols when, say, we want to use some Unicode character that we can't trust the font to have.)

April 19, 2011

1.3 port

by jcid＠dillo.org

On Sun, Apr 17, 2011 at 03:13:44PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Apr 16, 2011 at 11:30:33PM -0800, Roger wrote: > > > 1) I have "&File" for the "File" button. > > > > At some point corvid disabled FLTK's internal character > > escaping on labels. Although I'd prefer to have the underlined > > 'F' as in most menu APIs, rather than a bare 'F', I'm sure > > there's a reason behind this (e.g. I remember setting labels with > > strings taken from HTML pages could have side effects). > > > > We should nail this down easily (at least removing the '&' is > > trivial). > > FLTK2 had public widget flags, so when we needed to set RAW_LABEL all > over the place in FLTK2, it was easy (except when a workaround was > necessary for tooltips). FLTK 1.3 has protected widget flags, making it > rather more trouble to clear SHORTCUT_LABEL all over the place. > It didn't seem at all worth the trouble of making lots and lots of derived > classes so that File could still have an underline. Ah, OK. I just committed a fix that uses FL_NORMAL_LABEL to not interpret special symbols, and sets FL_FREE_LABELTYPE to interpret them (e.g. for "File" menu). -- Cheers Jorge.-

April 19, 2011

1.3 port

by corvid＠lavabit.com

Jorge wrote: > FWIW, I've been using the 1.3 branch for months now with no > problems (i.e. as stable as 2.0). It's more or less 99% done, > with some new features (as improved tabs). ! :-) ! > > The 1% remaining is the ability to switch panel sizes > on-the-fly, which could take me 1 day of work aprox. Looks like we still need - xembed - the preferred font code in dillo.cc.

April 19, 2011

1.3 port

by rogerx.oss＠gmail.com

>> BTW, almost forgot to mention, I get full GUI flashing when something like >> news.google.com loads. > > Try buffered_drawing=2 in dillorc. > $HOME/.dillo/dillorc -- buffered_drawing=1 ++ buffered_drawing=2 No more flashing. (But comparing dillo_fltk2 and dillo_fltk1.3, this wasn't an issue previously. And, isn't the default "1"?) Seems a bit slower set to 2? I'm guessing, more memory is required for buffering each window instead of just a single window? -- Roger http://rogerx.freeshell.org/

April 17, 2011