April 2011 - Dillo-dev - lists.mailman3.com

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

1.3 port

by corvid＠lavabit.com

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.

April 17, 2011

Large Panel

by rogerx.oss＠gmail.com

> On Sun, Apr 17, 2011 at 08:49:26AM -0300, Jorge Arellano Cid wrote: >On Sat, Apr 16, 2011 at 11:38:25PM -0800, Roger wrote: >> > On Sat, Apr 16, 2011 at 12:04:26PM -0300, Jorge Arellano Cid wrote: >> >Hi there, >> > >> > Does anybody use "panel_size=large" in dillorc? >> > >> > I'd like to remove the option in the 1.3 branch, and keep >> >tiny, small and medium. >> >> mmm... that's why I got a big "&File" button. Usually, I like big fat buttons and >> can't stand tiny buttons. (Kiddies usually love the @#$@# tiny buttons along >> with all the funky 3D eye candy.) >> >> Just noticed the small sized buttons are sufficient, even the tiny size is OK >> too. >> >> <shrugs> > > IIUR, you had a "large" panel because of a lingering dillorc >option (because the default is "medium", and you didn't set it). > > Also, even though you like fat buttons, "large" mode has no >much value for you and and you agree to remove it. > > Did I get you right? Nope. I had panel_size=large set. I like big & fat buttons. However, I just tried tiny & small, but think medium is the best option for this current monitor resolution. -- Roger http://rogerx.freeshell.org/

April 17, 2011

1.3 port

by jcid＠dillo.org

On Sun, Apr 17, 2011 at 03:51:57AM -0800, Roger wrote: > > On Sat, Apr 16, 2011 at 11:30:33PM -0800, Roger wrote: > >> On Sat, Apr 16, 2011 at 05:54:00PM -0300, Jorge Arellano Cid wrote: > >>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? > > > >Been 1.3 port for the past months as well. > > > >1) I have "&File" for the "File" button. > > > >2) On "File > Exit", Dillo prompts with a full size window "Close All Tabs or > >Cancel" window. > > > >I'm guessing, this is because the window has the same name as the main dillo > >browser window, as such, DWM thinks this prompt window also needs to be full > >sized. Dillo on fltk-2 didn't do this. > > > >I like the bubble tabs at the top. > > BTW, almost forgot to mention, I get full GUI flashing when something like > news.google.com loads. Try buffered_drawing=2 in dillorc. -- Cheers Jorge.-

April 17, 2011

1.3 port

by jcid＠dillo.org

On Sat, Apr 16, 2011 at 11:30:33PM -0800, Roger wrote: > > On Sat, Apr 16, 2011 at 05:54:00PM -0300, Jorge Arellano Cid wrote: > >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? > > Been 1.3 port for the past months as well. > > 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). > 2) On "File > Exit", Dillo prompts with a full size window "Close All Tabs or > Cancel" window. > > I'm guessing, this is because the window has the same name as the main dillo > browser window, as such, DWM thinks this prompt window also needs to be full > sized. Dillo on fltk-2 didn't do this. Johannes uses(ed) DWM. He surely can shed some light here. > I like the bubble tabs at the top. Good. BTW, you can close a tab with a right-click. -- Cheers Jorge.-

April 17, 2011