- Dillo-dev - lists.mailman3.com

1.3 port

by rogerx.oss＠gmail.com

> On Sun, Apr 24, 2011 at 07:36:17PM -0300, Jorge Arellano Cid wrote: >On Sat, Apr 23, 2011 at 09:57:29AM +0200, Thomas Orgis wrote: >> Am Fri, 22 Apr 2011 20:48:03 -0400 >> schrieb Rob S. <mr_semantics(a)hotmail.com>: >> [...] >> For the middle or right click: Well, I just observed Firefox >> closing a tab on middle-clicking on the handle. I don't think I >> like that. There's a close button on that handle. Middle-Click >> action onto a browser for has the connotation of pasting a URL >> into it ... and when I do it on a tab handle, I expect the URL >> being loaded in that tab. Not closing. Even worse for right >> click, though: That really is wired to the appearance of a >> context menu from countless other GUIs -- and no immediate >> action on its own. >> >> So, if a click has to close a tab, it should be the middle >> click, but it's the lesser of two evils, IMHO;-) > > I understand... > > >> And now, since there seems to be a "standard" >> set by other browsers about closing a tab with middle click, >> why has dillo have to choose the right click for the same >> action? > > Because it is surprisingly easy to use right-click! > >> Isn't that a guarantee to annoy any converts? > > No. See the two posts above (and my preference). > >> For what gain? > > Middle click is not handy with a scroll wheel middle button. > > Now, given that middle click became the standard, we can set it >as default and also add a dillorc preference for those of us that >really enjoy right click. No problem. You are somewhat correct here Jorge. I too have a scroll wheel for a middle button and find the right-mouse-click much easier to close tabs! (In Seamonkey browsers, I think the middle button is paste-and-open-url-in-window action.) However, as I mentioned, the other are right about the ctrl-q & ctrl-w being somewhat a standard. The only time I mind is when I use a standard browser, as I end up accidentally quiting the standard browser after using ctrl-q. Maybe I should complain to the Standard Browsers that they're not following the Dillo Standard? -- Roger http://rogerx.freeshell.org/

April 25, 2011

Debug build

by mr_semantics＠hotmail.com

> To: dillo-dev(a)dillo.org > Subject: Re: [Dillo-dev] Debug build > Date: Sun, 24 Apr 2011 21:52:18 -0400 > From: obeythepenguin(a)gmail.com > > On Sun, 24 Apr 2011 21:41:04 -0400, Rob S. <mr_semantics(a)hotmail.com> > wrote: > > > Is there a way to turn on a debug mode when building? I have done > > ./configure --help, and don't see much there. Basically I am stuck - I > > built dillo 1.3 on my opensuse machine, and it was segfaulting. I won't > > fill in the details of a long story, but I went and built it on a Fedora > > 14 machine (actually the same machine, just booted into Fedora), and the > > segfault did not happen. Built it on Linux Mint (Debian edition) and > > the same segfault is back. It is showing the problem as being in libc, > > but when I do a backtrace, there is not much meaningful stuff there. I > > would basically like to see more information - starting with turning off > > the optimisation, and possibly cranking the level of the debug from -g > > to -ggdb3. I just wanted to ask before I started monkeying with the > > configure files... > > This patch might help: > http://dillo-win32.sourceforge.net/files/01-dillo-r1785.configure.in.diff > > It adds an --enable-debug option, among other things (it also has some > fixes for building on Windows). You'll have to run ./autogen.sh to > re-generate your configure script after applying it. Thank you very much. ?This gave me an idea of where to start (the patch was good enough, but I wanted to tweak things, and now I know where. ? Before that I was thinking I would have to learn about how to use autotools ::shudders::. ?

April 25, 2011

Debug build

by obeythepenguin＠gmail.com

On Sun, 24 Apr 2011 21:41:04 -0400, Rob S. <mr_semantics(a)hotmail.com> wrote: > Is there a way to turn on a debug mode when building? I have done > ./configure --help, and don't see much there. Basically I am stuck - I > built dillo 1.3 on my opensuse machine, and it was segfaulting. I won't > fill in the details of a long story, but I went and built it on a Fedora > 14 machine (actually the same machine, just booted into Fedora), and the > segfault did not happen. Built it on Linux Mint (Debian edition) and > the same segfault is back. It is showing the problem as being in libc, > but when I do a backtrace, there is not much meaningful stuff there. I > would basically like to see more information - starting with turning off > the optimisation, and possibly cranking the level of the debug from -g > to -ggdb3. I just wanted to ask before I started monkeying with the > configure files... This patch might help: http://dillo-win32.sourceforge.net/files/01-dillo-r1785.configure.in.diff It adds an --enable-debug option, among other things (it also has some fixes for building on Windows). You'll have to run ./autogen.sh to re-generate your configure script after applying it. Cheers, ~Benjamin

April 25, 2011

Debug build

by mr_semantics＠hotmail.com

Is there a way to turn on a debug mode when building? I have done ./configure --help, and don't see much there. Basically I am stuck - I built dillo 1.3 on my opensuse machine, and it was segfaulting. I won't fill in the details of a long story, but I went and built it on a Fedora 14 machine (actually the same machine, just booted into Fedora), and the segfault did not happen. Built it on Linux Mint (Debian edition) and the same segfault is back. It is showing the problem as being in libc, but when I do a backtrace, there is not much meaningful stuff there. I would basically like to see more information - starting with turning off the optimisation, and possibly cranking the level of the debug from -g to -ggdb3. I just wanted to ask before I started monkeying with the configure files...

April 25, 2011

1.3 port

by mr_semantics＠hotmail.com

> Now, given that middle click became the standard, we can set it > as default and also add a dillorc preference for those of us that > really enjoy right click. No problem. This makes me happy - at least have the option to change it (which I will) to using right click to close. ^_^

April 25, 2011

1.3 port

by jcid＠dillo.org

On Sat, Apr 23, 2011 at 09:57:29AM +0200, Thomas Orgis wrote: > Am Fri, 22 Apr 2011 20:48:03 -0400 > schrieb Rob S. <mr_semantics(a)hotmail.com>: > [...] > For the middle or right click: Well, I just observed Firefox > closing a tab on middle-clicking on the handle. I don't think I > like that. There's a close button on that handle. Middle-Click > action onto a browser for has the connotation of pasting a URL > into it ... and when I do it on a tab handle, I expect the URL > being loaded in that tab. Not closing. Even worse for right > click, though: That really is wired to the appearance of a > context menu from countless other GUIs -- and no immediate > action on its own. > > So, if a click has to close a tab, it should be the middle > click, but it's the lesser of two evils, IMHO;-) I understand... > And now, since there seems to be a "standard" > set by other browsers about closing a tab with middle click, > why has dillo have to choose the right click for the same > action? Because it is surprisingly easy to use right-click! > Isn't that a guarantee to annoy any converts? No. See the two posts above (and my preference). > For what gain? Middle click is not handy with a scroll wheel middle button. Now, given that middle click became the standard, we can set it as default and also add a dillorc preference for those of us that really enjoy right click. No problem. -- Cheers Jorge.-

April 25, 2011

1.3 port

by thomas-forum＠orgis.org

Am Sun, 24 Apr 2011 11:57:52 -0800 schrieb Roger <rogerx.oss(a)gmail.com>: > Looking at this from a coding perspective, the ctrl+q combo will close tabs, > ***as well as*** quit the application. Yes, that's the case with dillo... I don't think that this is the best way. I'd have to look up whatever the "official" GUIdeline should be, but in NEdit (as well as xpdf) ctrl+w only closes open documents (which may be tabs, or some of the multiple windows of the app), where ctrl+q is needed to close the application... oh; in xpdf you need simple "q" for closing the app, ctrl+q won't do it. Lame. So much for a standard. Hm. You checked Seamonkey ... Let's look at another behemoth: OpenOffice (a reason to start it once in a month;-). Yup. The same: Ctrl+w closes files, but also the app when no file open. Ctrl+q closes the app right away. > So maybe ctrl+w should be assigned to close tabs within Dillo? (I've noticed > too, when I go to close a tab within Seamonkey I would accidentally press > ctrl+q to close a window -- and watch in horror as Seamonkey quit 5+ tabs of > active research! ;-) Yeah, it seems that using ctrl+w for closing tabs and dillo would be what others do (though I would prefer to limit the closing to ctrl+q). But then, re-defining ctrl+q to close dillo right away would mean a big change from the existing function. Anyhow, my comment was mainly about introducing yet another shift with the different working of the right or middle mouse buttons... the answer to the keyboard shortcuts might be user-configurable mappings anyway -- which still leaves open the question for the sane default. Alrighty then, Thomas.

April 25, 2011

1.3 port

by jcid＠dillo.org

On Sun, Apr 24, 2011 at 11:57:52AM -0800, Roger wrote: > > On Sat, Apr 23, 2011 at 09:57:29AM +0200, Thomas Orgis wrote: > >Am Fri, 22 Apr 2011 20:48:03 -0400 > >schrieb Rob S. <mr_semantics(a)hotmail.com>: > > > >> > The right-click close tab works far easier then ctrl-q... and I'm a keyboard > >> > fanatic! > >> > >> I am in 100% Agreement here - I know Ben mentioned the same functionality can be had with a middle click on some other browsers, but with my mouse, it is not nearly as nice clicking a middle mouse button to close tabs (I tested this on some other browsers) as it is right clicking. > > > > ... > > >But then... given the precedence of Ctrl+w / Ctrl+q being in place for GUI apps since ages (heck, even xpdf closes the file with Ctrl+w and the whole app with Ctrl+q) ... why does dillo have to have a slightly different idea about the workins of these shortcuts? And now, since there seems to be a "standard" set by other browsers about closing a tab with middle click, why has dillo have to choose the right click for the same action? Isn't that a guarantee to annoy any converts? For what gain? > > Looking at this from a coding perspective, the ctrl+q combo will close tabs, > ***as well as*** quit the application. Seems to be a dual purpose. > Checking Seamonkey, so OK, ctrl+w does quit the browser while closing > tabs/windows, too! > > So maybe ctrl+w should be assigned to close tabs within Dillo? (I've noticed > too, when I go to close a tab within Seamonkey I would accidentally press > ctrl+q to close a window -- and watch in horror as Seamonkey quit 5+ tabs of > active research! ;-) Don't worry, this is quite easy to change... And today it looks like Ctrl-w has won as the "de facto" tab closer for browsers. We can follow suit easily. -- Cheers Jorge.-

April 25, 2011

1.3 port

by rogerx.oss＠gmail.com

> On Sat, Apr 23, 2011 at 09:57:29AM +0200, Thomas Orgis wrote: >Am Fri, 22 Apr 2011 20:48:03 -0400 >schrieb Rob S. <mr_semantics(a)hotmail.com>: > >> > The right-click close tab works far easier then ctrl-q... and I'm a keyboard >> > fanatic! >> >> I am in 100% Agreement here - I know Ben mentioned the same functionality can be had with a middle click on some other browsers, but with my mouse, it is not nearly as nice clicking a middle mouse button to close tabs (I tested this on some other browsers) as it is right clicking. > ... >But then... given the precedence of Ctrl+w / Ctrl+q being in place for GUI apps since ages (heck, even xpdf closes the file with Ctrl+w and the whole app with Ctrl+q) ... why does dillo have to have a slightly different idea about the workins of these shortcuts? And now, since there seems to be a "standard" set by other browsers about closing a tab with middle click, why has dillo have to choose the right click for the same action? Isn't that a guarantee to annoy any converts? For what gain? Looking at this from a coding perspective, the ctrl+q combo will close tabs, ***as well as*** quit the application. Seems to be a dual purpose. Checking Seamonkey, so OK, ctrl+w does quit the browser while closing tabs/windows, too! So maybe ctrl+w should be assigned to close tabs within Dillo? (I've noticed too, when I go to close a tab within Seamonkey I would accidentally press ctrl+q to close a window -- and watch in horror as Seamonkey quit 5+ tabs of active research! ;-) -- Roger http://rogerx.freeshell.org/

April 24, 2011

1.3 port

by itsme_410＠yahoo.com

I am in agreement with the notion that we should stick to standard behaviour of window GUI design as much as possible. I know that there is a lot of deviations nowadays but we do not need to contribute more to this: I refer to the following for some nice thoughts on this... http://www.techeye.net/software/software-gui-design-going-to-hell-in-a-bask… Best, T --- On Sat, 4/23/11, Thomas Orgis <thomas-forum(a)orgis.org> wrote: > From: Thomas Orgis <thomas-forum(a)orgis.org> > Subject: Re: [Dillo-dev] 1.3 port > To: dillo-dev(a)dillo.org > Date: Saturday, April 23, 2011, 3:57 AM > Am Fri, 22 Apr 2011 20:48:03 -0400 > schrieb Rob S. <mr_semantics(a)hotmail.com>: > > > > > The right-click close tab works far easier then > ctrl-q... and I'm a keyboard > > > fanatic! > > > > I am in 100% Agreement here - I know Ben mentioned the > same functionality can be had with a middle click on some > other browsers, but with my mouse, it is not nearly as nice > clicking a middle mouse button to close tabs (I tested this > on some other browsers) as it is right clicking. > ??? > ???????? > ?????? ??? > ? > > I do wonder if it's a good idea to play so subtly different > to the "standard" behaviour set by other browsers. It always > bugged me that Ctrl+q closes a tab in dillo. It closes the > whole application for nearly everything else! OK, in > terminal emulators, Ctrl+q has a different meaning, but that > has some decades of history and doesn't apply to GUI. > > The behaviour of closing sub-windows / tabs (open files) > with Ctrl+w works on vintage NEdit with Motif as well es > with modern-day Firefox. It works the same way with mail > view windows in Claws Mail. And: Ctrl+q closes the whole > application. For all of them. > > For the middle or right click: Well, I just observed > Firefox closing a tab on middle-clicking on the handle. I > don't think I like that. There's a close button on that > handle. Middle-Click action onto a browser for has the > connotation of pasting a URL into it ... and when I do it on > a tab handle, I expect the URL being loaded in that tab. Not > closing. Even worse for right click, though: That really is > wired to the appearance of a context menu from countless > other GUIs -- and no immediate action on its own. > > So, if a click has to close a tab, it should be the middle > click, but it's the lesser of two evils, IMHO;-) > > But then... given the precedence of Ctrl+w / Ctrl+q being > in place for GUI apps since ages (heck, even xpdf closes the > file with Ctrl+w and the whole app with Ctrl+q) ... why does > dillo have to have a slightly different idea about the > workins of these shortcuts? And now, since there seems to be > a "standard" set by other browsers about closing a tab with > middle click, why has dillo have to choose the right click > for the same action? Isn't that a guarantee to annoy any > converts? For what gain? > > > Alrighty then, > > Thomas. > > -----Inline Attachment Follows----- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 23, 2011

1.3 port

by thomas-forum＠orgis.org

Am Fri, 22 Apr 2011 20:48:03 -0400 schrieb Rob S. <mr_semantics(a)hotmail.com>: > > The right-click close tab works far easier then ctrl-q... and I'm a keyboard > > fanatic! > > I am in 100% Agreement here - I know Ben mentioned the same functionality can be had with a middle click on some other browsers, but with my mouse, it is not nearly as nice clicking a middle mouse button to close tabs (I tested this on some other browsers) as it is right clicking. I do wonder if it's a good idea to play so subtly different to the "standard" behaviour set by other browsers. It always bugged me that Ctrl+q closes a tab in dillo. It closes the whole application for nearly everything else! OK, in terminal emulators, Ctrl+q has a different meaning, but that has some decades of history and doesn't apply to GUI. The behaviour of closing sub-windows / tabs (open files) with Ctrl+w works on vintage NEdit with Motif as well es with modern-day Firefox. It works the same way with mail view windows in Claws Mail. And: Ctrl+q closes the whole application. For all of them. For the middle or right click: Well, I just observed Firefox closing a tab on middle-clicking on the handle. I don't think I like that. There's a close button on that handle. Middle-Click action onto a browser for has the connotation of pasting a URL into it ... and when I do it on a tab handle, I expect the URL being loaded in that tab. Not closing. Even worse for right click, though: That really is wired to the appearance of a context menu from countless other GUIs -- and no immediate action on its own. So, if a click has to close a tab, it should be the middle click, but it's the lesser of two evils, IMHO;-) But then... given the precedence of Ctrl+w / Ctrl+q being in place for GUI apps since ages (heck, even xpdf closes the file with Ctrl+w and the whole app with Ctrl+q) ... why does dillo have to have a slightly different idea about the workins of these shortcuts? And now, since there seems to be a "standard" set by other browsers about closing a tab with middle click, why has dillo have to choose the right click for the same action? Isn't that a guarantee to annoy any converts? For what gain? Alrighty then, Thomas.

April 23, 2011

1.3 port

by mr_semantics＠hotmail.com

> The right-click close tab works far easier then ctrl-q... and I'm a keyboard > fanatic! I am in 100% Agreement here - I know Ben mentioned the same functionality can be had with a middle click on some other browsers, but with my mouse, it is not nearly as nice clicking a middle mouse button to close tabs (I tested this on some other browsers) as it is right clicking.

April 23, 2011

1.3 port

by rogerx.oss＠gmail.com

> On Fri, Apr 22, 2011 at 01:55:23PM -0300, Jorge Arellano Cid wrote: >On Thu, Apr 21, 2011 at 02:07:50PM -0300, Jorge Arellano Cid wrote: >> On Wed, Apr 20, 2011 at 07:22:56PM -0800, Roger wrote: >> > >> > Oh BTW. >> > >> > When I select a new link on a page with the mouse right click, >> > and select "open in new tab", the darn tab takes focus >> > instead of opening in the back ground like dillo-fltk-2 port >> > does. :-/ >> >> Please try the just-committed-patch (I had almost no time to >> test it). >> >> Here it works along "focus_new_tab" preference, left-click, >> middle-click and SHIFT to revert behaviour. > > BTW, I also noticed new tabs&windows were not following the >style of the calling UI, and committed a fix for it too. Posting this out of order, but when you mentioned how to promote right-click close tab feature; Think you're right on with a tip window. And/Or better yet, a comment within the dillorc config file concerning mouse buttons. I almost always read the config file (when forced too) vs the tip windows, I just close before reading them completely. ;-) Current Mercurial pull seems to be working really well so far! The right-click close tab works far easier then ctrl-q... and I'm a keyboard fanatic!

April 23, 2011

1.3 port

by jcid＠dillo.org

On Thu, Apr 21, 2011 at 02:07:50PM -0300, Jorge Arellano Cid wrote: > On Wed, Apr 20, 2011 at 07:22:56PM -0800, Roger wrote: > > > > Oh BTW. > > > > When I select a new link on a page with the mouse right click, > > and select "open in new tab", the darn tab takes focus > > instead of opening in the back ground like dillo-fltk-2 port > > does. :-/ > > Please try the just-committed-patch (I had almost no time to > test it). > > Here it works along "focus_new_tab" preference, left-click, > middle-click and SHIFT to revert behaviour. BTW, I also noticed new tabs&windows were not following the style of the calling UI, and committed a fix for it too. -- Cheers Jorge.-

April 22, 2011

1.3 port

by rogerx.oss＠gmail.com

> On Thu, Apr 21, 2011 at 02:07:50PM -0300, Jorge Arellano Cid wrote: >On Wed, Apr 20, 2011 at 07:22:56PM -0800, Roger wrote: >> >> Oh BTW. >> >> When I select a new link on a page with the mouse right click, >> and select "open in new tab", the darn tab takes focus >> instead of opening in the back ground like dillo-fltk-2 port >> does. :-/ > > Please try the just-committed-patch (I had almost no time to >test it). > > Here it works along "focus_new_tab" preference, left-click, >middle-click and SHIFT to revert behaviour. Works great now. ;-)

April 22, 2011

1.3 port

by obeythepenguin＠gmail.com

On Thu, 21 Apr 2011 18:17:17 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > A feature. > > The new tabs are custom widgets, which means now we have > complete control over them. > > I hooked right-click to close tabs as a quick convenience, and > only after using it regularly, realized it was more comfortable > than a per tab close icon. :) > > The question is how to make it "visible" to a new user. A tab > tooltip perhaps (like the bug-meter). I don't know. I'm not sure you need to worry too much since it's pretty common, although most browsers use the middle button. Opera does it, and I think Firefox does on Windows (I remember it as kind of weird on Linux). ~Benjamin

April 22, 2011

1.3 port

by jcid＠dillo.org

On Thu, Apr 21, 2011 at 06:03:36PM -0400, Rob S. wrote: > > So someone mentioned the funky new tab buttons, which caused me > to realise that I did not have the port of dillo, but actually > the old one. ? Anyway, I figured it out (had to look at the > repository to get the right directory or whatever) and am now > using the new port. ?One thing that I really like is how when > you right click on a tab, it closes it. ?Is that a feature, or > a "feature"? ?:P A feature. The new tabs are custom widgets, which means now we have complete control over them. I hooked right-click to close tabs as a quick convenience, and only after using it regularly, realized it was more comfortable than a per tab close icon. :) The question is how to make it "visible" to a new user. A tab tooltip perhaps (like the bug-meter). I don't know. -- Cheers Jorge.-

April 22, 2011

1.3 port

by mr_semantics＠hotmail.com

So someone mentioned the funky new tab buttons, which caused me to realise that I did not have the port of dillo, but actually the old one. ? Anyway, I figured it out (had to look at the repository to get the right directory or whatever) and am now using the new port. ?One thing that I really like is how when you right click on a tab, it closes it. ?Is that a feature, or a "feature"? ?:P

April 22, 2011

1.3 port

by jcid＠dillo.org

On Wed, Apr 20, 2011 at 07:22:56PM -0800, Roger wrote: > > Oh BTW. > > When I select a new link on a page with the mouse right click, > and select "open in new tab", the darn tab takes focus > instead of opening in the back ground like dillo-fltk-2 port > does. :-/ Please try the just-committed-patch (I had almost no time to test it). Here it works along "focus_new_tab" preference, left-click, middle-click and SHIFT to revert behaviour. -- Cheers Jorge.-

April 21, 2011

1.3 port

by obeythepenguin＠gmail.com

On Thu, 21 Apr 2011 12:27:08 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Although practical, the right-click-over-search-button hook to > change the panel size was a bit off an "easter egg". Now this > option is under the tools menu (much easier to find ;). I actually kind of liked it on the search button -- it was helpful for conserving space without having to hide the panels completely. Oh well, maybe I should get with the times ;-) ~Benjamin

April 21, 2011

1.3 port

by jcid＠dillo.org

Hi, On Sat, Apr 16, 2011 at 05:54:00PM -0300, Jorge Arellano Cid wrote: > [...] > The 1% remaining is the ability to switch panel sizes > on-the-fly, which could take me 1 day of work aprox. Just committed some patches to fix this. Although practical, the right-click-over-search-button hook to change the panel size was a bit off an "easter egg". Now this option is under the tools menu (much easier to find ;). -- Cheers Jorge.-

April 21, 2011

1.3 port

by rogerx.oss＠gmail.com

> 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? Oh BTW. When I select a new link on a page with the mouse right click, and select "open in new tab", the darn tab takes focus instead of opening in the back ground like dillo-fltk-2 port does. :-/

April 21, 2011

1.3 port

by corvid＠lavabit.com

higuita wrote: > > > add the bug forward button bug (ie: it doesnt work, as i just > > > found out) :) > > What's wrong, exactly? > > oops, i talked too soon... > > It works, just stays greyed out, as it hadn't any page to forward > (and i had judge it by the look, i didnt even try to used it, until now). > > The back button behaves fine, its grey on the first page, after > that its red. the forward button never "turn red"... so its a cosmetic > bug, not a "real" bug! Hmm, my forward button seems to turn green properly when there are other pages to go forward to...

April 21, 2011

1.3 port

by higuita7＠yahoo.co.uk

Hi again > > add the bug forward button bug (ie: it doesnt work, as i just > > found out) :) > What's wrong, exactly? oops, i talked too soon... It works, just stays greyed out, as it hadn't any page to forward (and i had judge it by the look, i didnt even try to used it, until now). The back button behaves fine, its grey on the first page, after that its red. the forward button never "turn red"... so its a cosmetic bug, not a "real" bug! Sorry for the noise :) 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 21, 2011

1.3 port

by jcid＠dillo.org

On Tue, Apr 19, 2011 at 10:03:28PM +0000, corvid wrote: > 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()? No. I meant as done in the committed patch. > I wonder whether fl_draw_shortcut is supposed > to be 1 ordinarily, and only switched to other values temporarily while > drawing some label. My main concern was removing the '&', and if possible draw the shortcut. Both patches solve this, and, FWIW, I find the second one a bit clearer to read. -- Cheers Jorge.-

April 20, 2011

1.3 port

by jcid＠dillo.org

On Tue, Apr 19, 2011 at 06:49:54PM -0700, Globe Trotter wrote: > 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? Near January 2011. It didn't happen, but at least they're doing the rc dance now (release candidates). -- Cheers Jorge.-

April 20, 2011

Linked image borders.

by corvid＠lavabit.com

I wrote: > Rob wrote: > > On this page,?http://www3.sympatico.ca/rsquared/gdb/, there are two images at the bottom which link to the W3C HTML and CSS validation pages. ?The inline style for the images is as follows: > > style="border:0;width:88px;height:31px" > > On every browser I have used, including Dillo 2.2, the blue link box around the images has not been displayed. ?Under the Dillo FLTK 1.3 port, it shows them. ?My question is, why? ?Which is the correct behaviour? > > Must be a parsing problem. It works if I change border:0 to > border:0px, but the unit is optional after 0. My impression is that we broke it when implementing line-height, with the length type changing from CSS_LENGTH_TYPE_PX to CSS_LENGTH_TYPE_NONE, and computeValue() not expecting that. I'll leave this to Johannes, since he'll know what he'll want to do about it.

April 20, 2011

Linked image borders.

by corvid＠lavabit.com

Rob wrote: > On this page,?http://www3.sympatico.ca/rsquared/gdb/, there are two images at the bottom which link to the W3C HTML and CSS validation pages. ?The inline style for the images is as follows: > style="border:0;width:88px;height:31px" > On every browser I have used, including Dillo 2.2, the blue link box around the images has not been displayed. ?Under the Dillo FLTK 1.3 port, it shows them. ?My question is, why? ?Which is the correct behaviour? Must be a parsing problem. It works if I change border:0 to border:0px, but the unit is optional after 0.

April 20, 2011

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

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

1.3 port

by rogerx.oss＠gmail.com

> 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. -- Roger http://rogerx.freeshell.org/

April 17, 2011

Large Panel

by jcid＠dillo.org

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? -- Cheers Jorge.-

April 17, 2011

Large Panel

by rogerx.oss＠gmail.com

> 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> -- Roger http://rogerx.freeshell.org/

April 17, 2011

1.3 port

by rogerx.oss＠gmail.com

> 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. -- Roger http://rogerx.freeshell.org/

April 17, 2011

1.3 port

by jcid＠dillo.org

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.-

April 16, 2011

Large Panel

by jcid＠dillo.org

On Sat, Apr 16, 2011 at 09:59:03AM -0700, Andrew Harris wrote: > On Sat, Apr 16, 2011 at 8:04 AM, Jorge Arellano Cid <jcid(a)dillo.org> 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. > > > Like Rob, I only just now knew about this. I agree with your decision, > if there's only one pulldown menu, why have it on a separate bar? > > Kind of confused as to why it's called "File" though. I realize that's > common for the first pulldown menu to be called 'File', but it doesn't > make a whole lot of sense here. Why not just "Menu" like Opera? Could be. It may be a matter of taste too. IMO, lots of people have the "File" menu hardcoded in their brains. Now, if we manage to make the widget printing feature of fltk-1.3 work in dillo, it could make good sense to add it under a "Menu" label instead of "File". Comments? -- Cheers Jorge.-

April 16, 2011

Large Panel

by jcid＠dillo.org

On Sat, Apr 16, 2011 at 11:29:36AM -0400, Rob S. wrote: > > > > > > Date: Sat, 16 Apr 2011 12:04:26 -0300 > > From: jcid(a)dillo.org > > To: dillo-dev(a)dillo.org > > Subject: [Dillo-dev] Large Panel > >? > > 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.My apologies for sending that last email to your address, Jorge. ?I am part of another mailing list, where when I hit reply it goes to the list, instead of the sender. ?I should look into changing this somehow with my email, as this is not the first time I have made this mistake. ?Anyway, as to my thoughts on the large panel size... > > I had actually been using the default, and had completely > forgotten that you could change this. ?Now that you brought it > up, I think I will be using the "tiny" setting. ?Long story > short, you would have no objection from me if you got rid of > the large setting. Thanks for the feedback. BTW, I just committed a couple of fixes for tiny and large in the 1.3 branch. -- Cheers Jorge.-

April 16, 2011

Linked image borders.

by mr_semantics＠hotmail.com

On this page,?http://www3.sympatico.ca/rsquared/gdb/, there are two images at the bottom which link to the W3C HTML and CSS validation pages. ?The inline style for the images is as follows: style="border:0;width:88px;height:31px" On every browser I have used, including Dillo 2.2, the blue link box around the images has not been displayed. ?Under the Dillo FLTK 1.3 port, it shows them. ?My question is, why? ?Which is the correct behaviour? Rob

April 16, 2011