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.-
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/
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/
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.-
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/
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.-
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.
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.-
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.)
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.-
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.
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.-
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.
Hi all
On Tue, 19 Apr 2011 01:20:04 +0000, "corvid" <corvid@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
higuita wrote: > On Tue, 19 Apr 2011 01:20:04 +0000, "corvid" <corvid@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?
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
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...
On Sun, May 01, 2011 at 09:42:30PM +0000, corvid wrote:
I wrote:
Looks like we still need - xembed - the preferred font code in dillo.cc.
- The test/ programs have UI problems (scrollbars, PgUp, etc.). - The show_progress_box pref doesn't do anything.
Patch committed for the last one. -- Cheers Jorge.-
- xembed - the preferred font code in dillo.cc. - The test/ programs have UI problems (scrollbars, PgUp, etc.). - drawing with nested layouts (Amazing what you can get used to and forget about!)
On Mon, May 02, 2011 at 05:54:08PM +0000, corvid wrote:
[...] - The test/ programs have UI problems (scrollbars, PgUp, etc.).
Oh, right. I'll give it a look. BTW, your "check scrollbar visibility before sending it events" patch solved the too-many-redraws problem. Please elaborate on it. -- Cheers Jorge.-
Jorge wrote:
BTW, your "check scrollbar visibility before sending it events" patch solved the too-many-redraws problem. Please elaborate on it.
I didn't even know there was a too-many-redraws problem, so there's not much to say. I was just tired of the page not getting events along that bottom little bit of the screen when the horizontal scrollbar was not shown.
On Thu, May 05, 2011 at 04:14:52PM +0000, corvid wrote:
Jorge wrote:
BTW, your "check scrollbar visibility before sending it events" patch solved the too-many-redraws problem. Please elaborate on it.
I didn't even know there was a too-many-redraws problem, so there's not much to say.
Serendipity! http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-April/008164.html
I was just tired of the page not getting events along that bottom little bit of the screen when the horizontal scrollbar was not shown.
Ah, OK. -- Cheers Jorge.-
On Thu, May 05, 2011 at 09:17:22AM -0300, Jorge Arellano Cid wrote:
On Mon, May 02, 2011 at 05:54:08PM +0000, corvid wrote:
[...] - The test/ programs have UI problems (scrollbars, PgUp, etc.).
Oh, right. I'll give it a look.
I gave a more in depth review to the problem, and it originates in the lack of a layout() method in fltk-1.3 (fltk2 has it). The original viewport size change of many example programs is never called because fltk-1.3's Group doesn't have a layout() method. Dillo's UI doesn't have this problem since I made set_render_layout() correct the viewport size long ago. My guess is that resize() does all the work in fltk-1.3, but we need more in depth knowledge of the mechanism before making a patch. BTW, the current resize code in Dillo has comments stating it needs a review, so this looks fuzzy. I'm working on it now. Help is appreciated. -- Cheers Jorge.-
On Mon, May 09, 2011 at 03:46:21PM -0400, Jorge Arellano Cid wrote:
On Thu, May 05, 2011 at 09:17:22AM -0300, Jorge Arellano Cid wrote:
On Mon, May 02, 2011 at 05:54:08PM +0000, corvid wrote:
[...] - The test/ programs have UI problems (scrollbars, PgUp, etc.).
Oh, right. I'll give it a look.
I gave a more in depth review to the problem, and it originates in the lack of a layout() method in fltk-1.3 (fltk2 has it).
The original viewport size change of many example programs is never called because fltk-1.3's Group doesn't have a layout() method.
Dillo's UI doesn't have this problem since I made set_render_layout() correct the viewport size long ago.
My guess is that resize() does all the work in fltk-1.3, but we need more in depth knowledge of the mechanism before making a patch. BTW, the current resize code in Dillo has comments stating it needs a review, so this looks fuzzy.
I'm working on it now. Help is appreciated.
FWIW, I already have a simple patch that seems to work, but I need to investigate what's going on a bit more. -- Cheers Jorge.-
- xembed - the preferred font code in dillo.cc. - The test/ programs have UI problems (scrollbars, PgUp, etc.). - drawing with nested layouts - tab titles - scrollbar sometimes thinks the page is slightly larger than it is. - When scrolling with the keyboard, with buffered_drawing 0 or 1, tooltips leave grey boxes.
On Wed, May 11, 2011 at 07:30:33PM +0000, corvid wrote:
- xembed - the preferred font code in dillo.cc. - The test/ programs have UI problems (scrollbars, PgUp, etc.). - drawing with nested layouts - tab titles - scrollbar sometimes thinks the page is slightly larger than it is. - When scrolling with the keyboard, with buffered_drawing 0 or 1, tooltips leave grey boxes.
Just committed fixes for most test/ programs. BTW, this patches also contain scrollbar bugfixes. There's still work to do (e.g. dw-ui-test), which looks like this problem: - drawing with nested layouts Which seems to be a coordinates problem, as the textblock content draws at (0,0), which is widget relative (FLTK2) and not absolute (FLTK1.3). -- Cheers Jorge.-
On Thu, May 12, 2011 at 05:28:51PM +0000, corvid wrote:
Jorge wrote:
BTW, this patches also contain scrollbar bugfixes.
I see that the setSizeHints bug is also in dillo2. I wonder whether it had any effect that I just don't remember now.
FWIW I'm working on a patch that reduces redraw flicker dramatically. (just in case you want to look at the complex-button coordinate offset bug in dw-ui-test ;-) -- Cheers Jorge.-
On Thu, May 12, 2011 at 01:53:48PM -0400, Jorge Arellano Cid wrote:
On Thu, May 12, 2011 at 05:28:51PM +0000, corvid wrote:
Jorge wrote:
BTW, this patches also contain scrollbar bugfixes.
I see that the setSizeHints bug is also in dillo2. I wonder whether it had any effect that I just don't remember now.
FWIW I'm working on a patch that reduces redraw flicker dramatically.
Committed now. -- Cheers Jorge.-
- the preferred font code in dillo.cc. - drawing with nested layouts - page/tab titles - When scrolling with the keyboard, with buffered_drawing 0 or 1, tooltips leave grey boxes. - OSX. I believe Johannes tried it once, and there was something going wrong with iowatch.
On Sun, May 15, 2011 at 06:15:35PM +0000, corvid wrote:
- the preferred font code in dillo.cc. - drawing with nested layouts - page/tab titles - When scrolling with the keyboard, with buffered_drawing 0 or 1, tooltips leave grey boxes.
- OSX. I believe Johannes tried it once, and there was something going wrong with iowatch.
Yes, somehow the add_fd() and add_idle() stuff doesn't seem to work on OSX. Either it's an fltk bug or we use it ways that are not expected. Here are my current issues with the fltk-1.3 port: - The toolbar in the initial tab is too high (with dwm in tiling mode). Further tabs have correctly sized toolbars. - Ctrl-Tab doesn't cycle through tabs. I really miss that. - There is a tab title even if there is only one tab. - The keyboard shortcuts for text input fields have changed (I use Ctrl-A (jump to beginning) Ctrl-K (kill until end of line) and Ctrl-E (jump to end of line). This seems to be intentional from fltk side. Any opinions whether we should change this back to the fltk2 behaviour? - There are still a bit more redraws than with fltk2 dillo. Cheers, Johannes
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
On Sun, May 15, 2011 at 06:15:35PM +0000, corvid wrote:
- the preferred font code in dillo.cc.
Necessary.
- drawing with nested layouts
Just managed to make the complex button draw right. I'm testing now.
- page/tab titles
Simple.
- When scrolling with the keyboard, with buffered_drawing 0 or 1, tooltips leave grey boxes.
Also in dillo2.
- OSX. I believe Johannes tried it once, and there was something going wrong with iowatch.
Yes, somehow the add_fd() and add_idle() stuff doesn't seem to work on OSX. Either it's an fltk bug or we use it ways that are not expected.
FWIW, sometime ago I compiled and run dillo-2 in OSX with no such problem.
Here are my current issues with the fltk-1.3 port:
- The toolbar in the initial tab is too high (with dwm in tiling mode). Further tabs have correctly sized toolbars.
This puzzles me.
- Ctrl-Tab doesn't cycle through tabs. I really miss that.
Simple enough to fix. ;)
- There is a tab title even if there is only one tab.
Yeah, this could take a few days.
- The keyboard shortcuts for text input fields have changed (I use Ctrl-A (jump to beginning) Ctrl-K (kill until end of line) and Ctrl-E (jump to end of line). This seems to be intentional from fltk side. Any opinions whether we should change this back to the fltk2 behaviour?
I miss them badly and several times have considered re-adding those keybindings. :-) Maybe next week.
- There are still a bit more redraws than with fltk2 dillo.
Yes. BTW, have the last patches made a difference for you? -- Cheers Jorge.-
When using a captcha system, I am unable to select text in order to copy. ?For example, go here: http://dragcave.net/login Then click on the IFRAME link. ?Type the words of the challenge into the text field. ?Assuming you have managed to pass as a human, you will be given (on a new page) a key to copy and paste to a field seen on the intial login screen. ?The trouble is that the text cannot be selected. Rob
Rob wrote:
When using a captcha system, I am unable to select text in order to copy. ?For example, go here: http://dragcave.net/login Then click on the IFRAME link. ?Type the words of the challenge into the text field. ?Assuming you have managed to pass as a human, you will be given (on a new page) a key to copy and paste to a field seen on the intial login screen. ?The trouble is that the text cannot be selected.
Fix committed. In http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-March/007408.html , I didn't particularly want to check NumPendingStyleSheets directly from forms, but if anyone wants to make a more respectable interface someday, we can always use it.
Fix committed.
Thank you sir. As an aside, when I went to build I ran into some trouble. ?I think this might be an appropriate fix, though one of you fellows will have to confirm: ?All that C++ makes my head want to explode. ?:S --- old.fltkui.cc ? ? ? 2011-05-16 18:27:23.892000731 -0400+++ fltkui.cc ? 2011-05-16 18:24:59.000000000 -0400@@ -1022,7 +1022,7 @@??bool FltkOptionMenuResource::isSelected (int index)?{- ? return index == (int)((Fl_Choice *)widget)->mvalue()->user_data();+ ? return index == (long)((Fl_Choice *)widget)->mvalue()->user_data();?}??int FltkOptionMenuResource::getNumberOfItems() Sorry about the crappy patch - I hardly ever generate those things, and don't really know what the protocol is. ?I guess I should take some time to learn those things.
Thank you sir. As an aside, when I went to build I ran into some trouble. I think this might be an appropriate fix, though one of you fellows will have to confirm: All that C++ makes my head want to explode. :S --- old.fltkui.cc 2011-05-16 18:27:23.892000731 -0400+++ fltkui.cc 2011-05-16 18:24:59.000000000 -0400@@ -1022,7 +1022,7 @@ bool FltkOptionMenuResource::isSelected (int index) {- return index == (int)((Fl_Choice *)widget)->mvalue()->user_data();+ return index == (long)((Fl_Choice *)widget)->mvalue()->user_data(); } int FltkOptionMenuResource::getNumberOfItems()
Sorry about the crappy patch - I hardly ever generate those things, and don't really know what the protocol is. I guess I should take some time to learn those things.
Ouch - that is ugly. ?Have a look here: http://www3.sympatico.ca/rsquared/lib/patch
Rob wrote:
Thank you sir. As an aside, when I went to build I ran into some trouble. I think this might be an appropriate fix, though one of you fellows will have to confirm: All that C++ makes my head want to explode. :S --- old.fltkui.cc 2011-05-16 18:27:23.892000731 -0400+++ fltkui.cc 2011-05-16 18:24:59.000000000 -0400@@ -1022,7 +1022,7 @@ bool FltkOptionMenuResource::isSelected (int index) {- return index == (int)((Fl_Choice *)widget)->mvalue()->user_data();+ return index == (long)((Fl_Choice *)widget)->mvalue()->user_data(); } int FltkOptionMenuResource::getNumberOfItems()
Sorry about the crappy patch - I hardly ever generate those things, and don't really know what the protocol is. I guess I should take some time to learn those things.
Ouch - that is ugly. ?Have a look here: http://www3.sympatico.ca/rsquared/lib/patch
Patch committed.
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
Here are my current issues with the fltk-1.3 port: [...] - Ctrl-Tab doesn't cycle through tabs. I really miss that.
Committed. -- Cheers Jorge.-
On Tue, May 17, 2011 at 11:22:41PM +0000, Jorge Arellano Cid wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
Here are my current issues with the fltk-1.3 port: [...] - Ctrl-Tab doesn't cycle through tabs. I really miss that.
Committed.
Nice, thanks! Johannes
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now). Quick poll: What's your preferred mode? -- Cheers Jorge.-
Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab. I will feel surprise if anyone wants to have it visible when there's only one tab.
On Wed, May 25, 2011 at 03:13:54PM +0000, corvid wrote:
Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab.
I will feel surprise if anyone wants to have it visible when there's only one tab.
The patch "almost" works, but sometimes when resizing the window, strange resize problems arise, and things go wild. I'm glad I finally isolated and STRed a part of the problem: http://fltk.org/str.php?L2639+P0+S-2+C0+I0+E0+Q I hesitate to fight it much more before the resolution for STR#2639 comes out. It's like herding cats: you can make them all move, but not make them go where you want. -- Cheers Jorge.-
On Wed, May 25, 2011 at 01:37:26PM -0400, Jorge Arellano Cid wrote:
On Wed, May 25, 2011 at 03:13:54PM +0000, corvid wrote:
Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab.
I will feel surprise if anyone wants to have it visible when there's only one tab.
The patch "almost" works, but sometimes when resizing the window, strange resize problems arise, and things go wild. I'm glad I finally isolated and STRed a part of the problem:
http://fltk.org/str.php?L2639+P0+S-2+C0+I0+E0+Q
I hesitate to fight it much more before the resolution for STR#2639 comes out. It's like herding cats: you can make them all move, but not make them go where you want.
I'm currently working on a fix for the dwm resize issue. The idea is to get rid of Fl_Pack entirely. So that patch might also fix the issue you are now seeing with tabs and resizing. Cheers, Johannes
On Wed, May 25, 2011 at 08:41:35PM +0200, Johannes Hofmann wrote:
On Wed, May 25, 2011 at 01:37:26PM -0400, Jorge Arellano Cid wrote:
On Wed, May 25, 2011 at 03:13:54PM +0000, corvid wrote:
Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab.
I will feel surprise if anyone wants to have it visible when there's only one tab.
The patch "almost" works, but sometimes when resizing the window, strange resize problems arise, and things go wild. I'm glad I finally isolated and STRed a part of the problem:
http://fltk.org/str.php?L2639+P0+S-2+C0+I0+E0+Q
I hesitate to fight it much more before the resolution for STR#2639 comes out. It's like herding cats: you can make them all move, but not make them go where you want.
I'm currently working on a fix for the dwm resize issue. The idea is to get rid of Fl_Pack entirely.
Well, that's the way to go if Fl_Pack is not fixed in FLTK-1.3. Although I hope Fl_Pack is fixed, because things become much simpler with it.
So that patch might also fix the issue you are now seeing with tabs and resizing.
I'm trying a different approach now, and so far it works! :-o -- Cheers Jorge.-
On Wed, May 25, 2011 at 04:15:35PM -0400, Jorge Arellano Cid wrote:
On Wed, May 25, 2011 at 08:41:35PM +0200, Johannes Hofmann wrote:
On Wed, May 25, 2011 at 01:37:26PM -0400, Jorge Arellano Cid wrote:
On Wed, May 25, 2011 at 03:13:54PM +0000, corvid wrote:
Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab.
I will feel surprise if anyone wants to have it visible when there's only one tab.
The patch "almost" works, but sometimes when resizing the window, strange resize problems arise, and things go wild. I'm glad I finally isolated and STRed a part of the problem:
http://fltk.org/str.php?L2639+P0+S-2+C0+I0+E0+Q
I hesitate to fight it much more before the resolution for STR#2639 comes out. It's like herding cats: you can make them all move, but not make them go where you want.
I'm currently working on a fix for the dwm resize issue. The idea is to get rid of Fl_Pack entirely.
Well, that's the way to go if Fl_Pack is not fixed in FLTK-1.3.
Although I hope Fl_Pack is fixed, because things become much simpler with it.
I actually prefer not to use Fl_Pack, as it relayouts on every redraw which feels a bit like a hack. Please test attached patch. In my opinion it simplifies things and also fixes the dwm resize issues I was seeing. Cheers, Johannes
Hi Johannes, On Wed, May 25, 2011 at 08:41:35PM +0200, Johannes Hofmann wrote:
On Wed, May 25, 2011 at 01:37:26PM -0400, Jorge Arellano Cid wrote:
On Wed, May 25, 2011 at 03:13:54PM +0000, corvid wrote:
Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab.
I will feel surprise if anyone wants to have it visible when there's only one tab.
The patch "almost" works, but sometimes when resizing the window, strange resize problems arise, and things go wild. I'm glad I finally isolated and STRed a part of the problem:
http://fltk.org/str.php?L2639+P0+S-2+C0+I0+E0+Q
I hesitate to fight it much more before the resolution for STR#2639 comes out. It's like herding cats: you can make them all move, but not make them go where you want.
I'm currently working on a fix for the dwm resize issue. The idea is to get rid of Fl_Pack entirely. So that patch might also fix the issue you are now seeing with tabs and resizing.
The FLTK team made rc6 today [1], and decided to tackle the Fl_Pack bug after the release is done [2]. I guess that cuts our cake, so please commit the no-flpack patch when it passes your tests. I'll work the tabbar-hide patch on top of it (it works but needs some clean up). [1] http://fltk.org/articles.php?L1075 [2] http://fltk.org/str.php?L2639 BTW, does the tabbar-hide patch solve the dwm issue alone? (i.e. on top of Fl_Pack). Just to be able to provide that information to FLTK devs when necessary. -- Cheers Jorge.-
On Thu, May 26, 2011 at 01:09:30PM -0400, Jorge Arellano Cid wrote:
Hi Johannes,
On Wed, May 25, 2011 at 08:41:35PM +0200, Johannes Hofmann wrote:
On Wed, May 25, 2011 at 01:37:26PM -0400, Jorge Arellano Cid wrote:
On Wed, May 25, 2011 at 03:13:54PM +0000, corvid wrote:
Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab.
I will feel surprise if anyone wants to have it visible when there's only one tab.
The patch "almost" works, but sometimes when resizing the window, strange resize problems arise, and things go wild. I'm glad I finally isolated and STRed a part of the problem:
http://fltk.org/str.php?L2639+P0+S-2+C0+I0+E0+Q
I hesitate to fight it much more before the resolution for STR#2639 comes out. It's like herding cats: you can make them all move, but not make them go where you want.
I'm currently working on a fix for the dwm resize issue. The idea is to get rid of Fl_Pack entirely. So that patch might also fix the issue you are now seeing with tabs and resizing.
The FLTK team made rc6 today [1], and decided to tackle the Fl_Pack bug after the release is done [2]. I guess that cuts our cake, so please commit the no-flpack patch when it passes your tests.
Done. Please report any issues.
I'll work the tabbar-hide patch on top of it (it works but needs some clean up).
[1] http://fltk.org/articles.php?L1075 [2] http://fltk.org/str.php?L2639
BTW, does the tabbar-hide patch solve the dwm issue alone? (i.e. on top of Fl_Pack). Just to be able to provide that information to FLTK devs when necessary.
the tabbar-hide patch alone does not solve the dwm resizing issue. Cheers, Johannes
On Wed, May 25, 2011 at 03:13:54PM +0000, corvid wrote: Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab.
I will feel surprise if anyone wants to have it visible when there's only one tab.
Well, be surprised. I like to see a tab even though there's no more then one visible. Reason being, Firefox tends (or tended) to resize the webpage and toolbars when migrating from one to more then one tabs, it boggled my mind when comprehending, "Now what changed??" It would take a few seconds to regain field of view, etc. (No glasses, 20/20 here, no drugs or alcohol, etc) But I'm guessing with FLTK, it won't make such vast changes when going from tabs to no tabs. Also, the Title of the webpage is usually kept within the tab. <shrugs, for what it's worth> -- Roger http://rogerx.freeshell.org/
On Wed, May 25, 2011 at 04:37:33PM -0800, Roger wrote:
On Wed, May 25, 2011 at 03:13:54PM +0000, corvid wrote: Jorge wrote:
On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote:
- There is a tab title even if there is only one tab.
FYI, I'm testing a patch that does this. It uses a trick to receive events on a hidden tabbar and is designed so it's easy to set permanent tab buttons too (i.e. as now).
Quick poll: What's your preferred mode?
I prefer that the tab bar goes away when there's only one tab.
I will feel surprise if anyone wants to have it visible when there's only one tab.
Well, be surprised. I like to see a tab even though there's no more then one visible. Reason being, Firefox tends (or tended) to resize the webpage and toolbars when migrating from one to more then one tabs, it boggled my mind when comprehending, "Now what changed??" It would take a few seconds to regain field of view, etc. (No glasses, 20/20 here, no drugs or alcohol, etc)
But I'm guessing with FLTK, it won't make such vast changes when going from tabs to no tabs. Also, the Title of the webpage is usually kept within the tab. <shrugs, for what it's worth>
Fair enough. With Dillo you won't have such delays. Please test the just committed patch! -- Cheers Jorge.-
Jorge wrote:
On Sun, May 15, 2011 at 06:15:35PM +0000, corvid wrote:
- drawing with nested layouts
Any example besides dw-ui-test?
Any <button> or image input, I think. The youtube site, for instance, is filled with buttons.
On Mon, May 16, 2011 at 03:20:17AM +0000, corvid wrote:
Jorge wrote:
On Sun, May 15, 2011 at 06:15:35PM +0000, corvid wrote:
- drawing with nested layouts
Any example besides dw-ui-test?
Any <button> or image input, I think. The youtube site, for instance, is filled with buttons.
Fix committed. Note: there're still problems: 1) The complexbutton doesn't render as an inline element. 2) It takes the whole width. but these are inherited from dillo2. -- Cheers Jorge.-
On Wed, May 11, 2011 at 07:30:33PM +0000, corvid wrote:
[...] - When scrolling with the keyboard, with buffered_drawing 0 or 1, tooltips leave grey boxes.
FWIW, dillo-2.x also has this problem (trailing tooltip instead of grey box). -- Cheers Jorge.-
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@dillo.org> wrote:
From: Jorge Arellano Cid <jcid@dillo.org> Subject: [Dillo-dev] 1.3 port To: "Dillo mailing list" <dillo-dev@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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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.-
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. :-/
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.-
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. ;-)
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.-
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!
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.
Am Fri, 22 Apr 2011 20:48:03 -0400 schrieb Rob S. <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.
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.
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-baske... Best, T --- On Sat, 4/23/11, Thomas Orgis <thomas-forum@orgis.org> wrote:
From: Thomas Orgis <thomas-forum@orgis.org> Subject: Re: [Dillo-dev] 1.3 port To: dillo-dev@dillo.org Date: Saturday, April 23, 2011, 3:57 AM Am Fri, 22 Apr 2011 20:48:03 -0400 schrieb Rob S. <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. ??? ???????? ?????? ??? ?
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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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@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/
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@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.-
Am Sun, 24 Apr 2011 11:57:52 -0800 schrieb Roger <rogerx.oss@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.
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@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.-
On Sun, Apr 24, 2011 at 07:03:54PM -0400, Rob S. wrote:
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. ^_^
Patch committed. Now, middle-click closes tab by default. If you prefer right click, just add this line in ~/.dillo/dillorc: right_click_closes_tab=YES -- Cheers Jorge.-
Jorge wrote:
Patch committed.
Now, middle-click closes tab by default.
If you prefer right click, just add this line in ~/.dillo/dillorc:
right_click_closes_tab=YES
I wonder whether there's a decent way to stuff all of our "this mouse button does this, or maybe it does that, but then if you hold down SHIFT..." into keys and keysrc.
On Fri, Apr 29, 2011 at 12:33:41PM -0300, Jorge Arellano Cid wrote: On Sun, Apr 24, 2011 at 07:03:54PM -0400, Rob S. wrote:
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. ^_^
Patch committed.
Now, middle-click closes tab by default.
If you prefer right click, just add this line in ~/.dillo/dillorc:
right_click_closes_tab=YES
Taking an initial spin run with the default, now right click does nothing. Standard Browser such as Seamonkey/Firefox: Right Click on Tab = Open tab menu Middle Click on Tab/Page = Paste URL and load page Dillo_1.3 (Currently) Right Click on Tab = *Nothing* Middle Click on Tab/Page = Close tab (Right Click was much easier & scroll wheel makes it harder.) For now, I'll surely use right_click_closes_tab=YES for now.
Am Sat, 30 Apr 2011 12:20:37 -0800 schrieb Roger <rogerx.oss@gmail.com>:
Standard Browser such as Seamonkey/Firefox: Right Click on Tab = Open tab menu Middle Click on Tab/Page = Paste URL and load page
Middle-Click on the tab handle itself closes ... middle-click into the page area loads URL. Right? Alrighty then, Thomas.
On Sun, May 01, 2011 at 05:57:36AM +0200, Thomas Orgis wrote: Am Sat, 30 Apr 2011 12:20:37 -0800 schrieb Roger <rogerx.oss@gmail.com>:
Standard Browser such as Seamonkey/Firefox: Right Click on Tab = Open tab menu Middle Click on Tab/Page = Paste URL and load page
Middle-Click on the tab handle itself closes ... middle-click into the page area loads URL. Right?
No. Mozilla/Seamonkey -> Middle click on tab or page loads a URL from the copy/paste buffer.
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@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/
On Sun, Apr 24, 2011 at 10:10:49PM -0800, Roger wrote:
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: [...] 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?
I could answer with sarcasm but it is certainly not welcomed in this list [1]. The issue is already answered in this thread (patch pending): http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-April/008199.html [1] http://www.dillo.org/MList.html -- Cheers Jorge.-
Hi, On Sat, Apr 23, 2011 at 09:57:29AM +0200, Thomas Orgis wrote:
[...] 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.
Patch committed. Hereafter the default for close tab/window is ctrl-w. For those that have Ctrl-q hardwired in the brain, just: $ echo "<Ctrl>q = close-tab" >> ~/.dillo/keysrc -- Cheers Jorge.-
Jorge wrote:
On Sat, Apr 23, 2011 at 09:57:29AM +0200, Thomas Orgis wrote:
[...] 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.
Patch committed.
Hereafter the default for close tab/window is ctrl-w.
Will close-all change as well?
On Wed, Apr 27, 2011 at 07:51:28PM +0000, corvid wrote:
Jorge wrote:
On Sat, Apr 23, 2011 at 09:57:29AM +0200, Thomas Orgis wrote:
[...] 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.
Patch committed.
Hereafter the default for close tab/window is ctrl-w.
Will close-all change as well?
I guess so. Even though hitting ctrl-q is automatic for some of us, there's the multiple-open-tabs dialog protection, and if this is too much Alt-q can be set in keysrc. e.g. <Alt>q = close-all -- Cheers Jorge.-
On Wed, Apr 27, 2011 at 05:59:57PM -0300, Jorge Arellano Cid wrote:
On Wed, Apr 27, 2011 at 07:51:28PM +0000, corvid wrote:
Jorge wrote:
On Sat, Apr 23, 2011 at 09:57:29AM +0200, Thomas Orgis wrote:
[...] 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.
Patch committed.
Hereafter the default for close tab/window is ctrl-w.
Will close-all change as well?
I guess so.
Even though hitting ctrl-q is automatic for some of us, there's the multiple-open-tabs dialog protection, and if this is too much Alt-q can be set in keysrc. e.g.
<Alt>q = close-all
Committed. Hereafter the new default for "close-all" is Ctrl-q For those of us brainwired with Ctrl-q, adding these lines to ~/.dillo/keysrc helps to retrain the neural network: <Ctrl>q = nop <Alt>q = close-all (Or you can set to whatever feels right for you ;). -- Cheers Jorge.-
Am Wed, 27 Apr 2011 16:07:37 -0300 schrieb Jorge Arellano Cid <jcid@dillo.org>:
Hereafter the default for close tab/window is ctrl-w.
For those that have Ctrl-q hardwired in the brain, just:
$ echo "<Ctrl>q = close-tab" >> ~/.dillo/keysrc
Hey, thanks. I hope other users don't mind the changed default. Now... I guess it's really time to get around and add dillo 1.3 to my distro. I'll have to add fltk 1.3 first, though. Alrighty then, Thomas.
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.-
On Thu, 21 Apr 2011 12:27:08 -0400, Jorge Arellano Cid <jcid@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
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
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.-
On Thu, 21 Apr 2011 18:17:17 -0400, Jorge Arellano Cid <jcid@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
participants (10)
-
corvid＠lavabit.com -
higuita7＠yahoo.co.uk -
itsme_410＠yahoo.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de
-
mr_semantics＠hotmail.com -
obeythepenguin＠gmail.com -
rogerx.oss＠gmail.com -
thomas-forum＠orgis.org