Hi there, The tabs patch has grown to a quite usable state, so it was committed for you to test. I know we're close to the release so we can still rollback. It's just that I'd much like to have it in the main tree before dillo2 goes out. The patch comes with several assorted cleanups and normalizations. For instance: derived widgets now use the "Cust" prefix instead of "New", the window->user_data() holds a pointer to the current UI, and child widgets get it from there, etc. OK, so to the tabs... This implementation uses one UI per tab, and it's quite fast. You can switch tabs with the mouse, Shift+{Left, Right} or {Ctrl,Ctrl+Shift}+TAB. Use Ctrl+N, or middle click over a link to open a new tab (just as it was with new windows). Ctrl+Q closes the tab. The idea is that in the future the user can dillo2rc-choose whether to use windows or tabs, and windows with tabs. Some issues: 1.- Tab Tooltips are commented out because FLTK has problems with them. 2.- Shift+{Left, Right} work even when the location is focused. In the latter case you may need to click the right key twice for it to focus and work (don't know why, the Left key works OK). 3.- Currently there's no hidden tabs widget, when there's only one tab (haven't even tried, it may be as simple as hiding the group). 4.- There's no close tab icon in the tab label. 5.- No warning popup for close window with multiple open tabs. OK, please take it for a ride and test. Comments, fixes and patches are welcomed. -- Cheers Jorge.-
Hi Jorge, On Wed, Sep 17, 2008 at 06:14:58PM -0400, Jorge Arellano Cid wrote:
Hi there,
The tabs patch has grown to a quite usable state, so it was committed for you to test. I know we're close to the release so we can still rollback. It's just that I'd much like to have it in the main tree before dillo2 goes out.
The patch comes with several assorted cleanups and normalizations. For instance: derived widgets now use the "Cust" prefix instead of "New", the window->user_data() holds a pointer to the current UI, and child widgets get it from there, etc.
OK, so to the tabs...
This implementation uses one UI per tab, and it's quite fast. You can switch tabs with the mouse, Shift+{Left, Right} or {Ctrl,Ctrl+Shift}+TAB. Use Ctrl+N, or middle click over a link to open a new tab (just as it was with new windows). Ctrl+Q closes the tab.
The idea is that in the future the user can dillo2rc-choose whether to use windows or tabs, and windows with tabs.
Very nice!
Some issues:
1.- Tab Tooltips are commented out because FLTK has problems with them. 2.- Shift+{Left, Right} work even when the location is focused. In the latter case you may need to click the right key twice for it to focus and work (don't know why, the Left key works OK). 3.- Currently there's no hidden tabs widget, when there's only one tab (haven't even tried, it may be as simple as hiding the group).
Attached patch implements that. I don't like the global DilloTabs variable in uicmd.cc, but the static one a_UIcmd_browser_window_new() was not better. Perhaps DilloTabs should become member of some new class?
4.- There's no close tab icon in the tab label. 5.- No warning popup for close window with multiple open tabs.
OK, please take it for a ride and test.
Sometimes Shift-Arrow does not seem to work depending on where the focus is. Ctrl-Tab seems to work always. The window title is not updated when switching between tabs. Is this intended? Cheers, Johannes
On Thu, Sep 18, 2008 at 05:39:43PM +0200, Johannes Hofmann wrote:
Hi Jorge,
On Wed, Sep 17, 2008 at 06:14:58PM -0400, Jorge Arellano Cid wrote:
Hi there,
The tabs patch has grown to a quite usable state, so it was committed for you to test. I know we're close to the release so we can still rollback. It's just that I'd much like to have it in the main tree before dillo2 goes out.
The patch comes with several assorted cleanups and normalizations. For instance: derived widgets now use the "Cust" prefix instead of "New", the window->user_data() holds a pointer to the current UI, and child widgets get it from there, etc.
OK, so to the tabs...
This implementation uses one UI per tab, and it's quite fast. You can switch tabs with the mouse, Shift+{Left, Right} or {Ctrl,Ctrl+Shift}+TAB. Use Ctrl+N, or middle click over a link to open a new tab (just as it was with new windows). Ctrl+Q closes the tab.
The idea is that in the future the user can dillo2rc-choose whether to use windows or tabs, and windows with tabs.
Very nice!
The whole tabs or the future dillo2rc idea? ;-)
Some issues:
1.- Tab Tooltips are commented out because FLTK has problems with them. 2.- Shift+{Left, Right} work even when the location is focused. In the latter case you may need to click the right key twice for it to focus and work (don't know why, the Left key works OK). 3.- Currently there's no hidden tabs widget, when there's only one tab (haven't even tried, it may be as simple as hiding the group).
Attached patch implements that. I don't like the global DilloTabs variable in uicmd.cc, but the static one a_UIcmd_browser_window_new() was not better. Perhaps DilloTabs should become member of some new class?
Committed. The good thing of it being a simple variable is that no-tabs windows is straightforward to implement.
4.- There's no close tab icon in the tab label. 5.- No warning popup for close window with multiple open tabs.
OK, please take it for a ride and test.
Sometimes Shift-Arrow does not seem to work depending on where the focus is. Ctrl-Tab seems to work always.
Yes, that's what I tried to state in point 2. Well, I have an idea why it happens. The RightKey event gets to a group that handles it as widget navigation and that's why left and right are different.
The window title is not updated when switching between tabs. Is this intended?
Undecided. For tabs, I don't know whether it's a good idea. For single windows certainly it is. This is an open point. -- Cheers Jorge.-
On Thu, Sep 18, 2008 at 11:22:24PM -0400, Jorge Arellano Cid wrote:
On Thu, Sep 18, 2008 at 05:39:43PM +0200, Johannes Hofmann wrote:
Hi Jorge,
On Wed, Sep 17, 2008 at 06:14:58PM -0400, Jorge Arellano Cid wrote:
Hi there,
The tabs patch has grown to a quite usable state, so it was committed for you to test. I know we're close to the release so we can still rollback. It's just that I'd much like to have it in the main tree before dillo2 goes out.
The patch comes with several assorted cleanups and normalizations. For instance: derived widgets now use the "Cust" prefix instead of "New", the window->user_data() holds a pointer to the current UI, and child widgets get it from there, etc.
OK, so to the tabs...
This implementation uses one UI per tab, and it's quite fast. You can switch tabs with the mouse, Shift+{Left, Right} or {Ctrl,Ctrl+Shift}+TAB. Use Ctrl+N, or middle click over a link to open a new tab (just as it was with new windows). Ctrl+Q closes the tab.
The idea is that in the future the user can dillo2rc-choose whether to use windows or tabs, and windows with tabs.
Very nice!
The whole tabs or the future dillo2rc idea? ;-)
The whole tabs. I'm not sure I understand the dillo2rc idea correctly (see below).
Some issues:
1.- Tab Tooltips are commented out because FLTK has problems with them. 2.- Shift+{Left, Right} work even when the location is focused. In the latter case you may need to click the right key twice for it to focus and work (don't know why, the Left key works OK). 3.- Currently there's no hidden tabs widget, when there's only one tab (haven't even tried, it may be as simple as hiding the group).
Attached patch implements that. I don't like the global DilloTabs variable in uicmd.cc, but the static one a_UIcmd_browser_window_new() was not better. Perhaps DilloTabs should become member of some new class?
Committed.
The good thing of it being a simple variable is that no-tabs windows is straightforward to implement.
I'd say we should support multiple windows with one or more tabs each. In that case DilloTabs can not be a single global variable, as we need one tab widget per window. Cheers, Johannes
Sometimes the window closes when I click on a page. A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, and then HIDE. (I only had one tab, in case that matters.)
I wrote:
Sometimes the window closes when I click on a page. A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, and then HIDE. (I only had one tab, in case that matters.)
Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down. Since they're very close to each other on my keyboard and I am so accustomed to the click-and-space sequence, it can come from muscle memory even when I'm paying enough attention to think I know what happened before dillo disappeared.
On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote:
I wrote:
Sometimes the window closes when I click on a page. A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, and then HIDE. (I only had one tab, in case that matters.)
Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down.
I'm also seeing that. No idea yet... Johannes
Johannes wrote:
On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote:
I wrote:
Sometimes the window closes when I click on a page. A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, and then HIDE. (I only had one tab, in case that matters.)
Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down.
I'm also seeing that. No idea yet...
I finally sat down and worked out what the problem is. It's not only click-space, but that's the most common case. <title>...&[character]...</title> causes click-[character] to close it. So fltk must think that's a shortcut in the tab text, and it tries to do whatever it does with shortcuts -- but there's a shortcut-handling piece missing, so it just closes the window.
I wrote:
Johannes wrote:
On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote:
I wrote:
Sometimes the window closes when I click on a page. A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, and then HIDE. (I only had one tab, in case that matters.)
Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down.
I'm also seeing that. No idea yet...
I finally sat down and worked out what the problem is. It's not only click-space, but that's the most common case.
<title>...&[character]...</title>
causes click-[character] to close it.
So fltk must think that's a shortcut in the tab text, and it tries to do whatever it does with shortcuts -- but there's a shortcut-handling piece missing, so it just closes the window.
It doesn't care about the tab text. It's the UI->window() label stuff that's causing the problem. It appears that you can escape &-as-shortcut in general by doubling them, but I end up with doubled && in the title bar. Why wasn't this a problem in the past? I don't know; maybe it _was_ regarded as a shortcut but handle() took care of it.
On Mon, Sep 22, 2008 at 05:06:35AM +0000, corvid wrote:
I wrote:
Johannes wrote:
On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote:
I wrote:
Sometimes the window closes when I click on a page. A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, and then HIDE. (I only had one tab, in case that matters.)
Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down.
I'm also seeing that. No idea yet...
I finally sat down and worked out what the problem is. It's not only click-space, but that's the most common case.
<title>...&[character]...</title>
causes click-[character] to close it.
So fltk must think that's a shortcut in the tab text, and it tries to do whatever it does with shortcuts -- but there's a shortcut-handling piece missing, so it just closes the window.
It doesn't care about the tab text. It's the UI->window() label stuff that's causing the problem. It appears that you can escape &-as-shortcut in general by doubling them, but I end up with doubled && in the title bar. Why wasn't this a problem in the past? I don't know; maybe it _was_ regarded as a shortcut but handle() took care of it.
Thanks for tracking this down! I could also reproduce it with pre-tabs versions. Please try attached patch. Cheers, Johannes PS: We will need to set RAW_LABEL for all widgets that get their labels fom html...
Johannes wrote:
On Mon, Sep 22, 2008 at 05:06:35AM +0000, corvid wrote:
I wrote:
Johannes wrote:
On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote:
I wrote:
Sometimes the window closes when I click on a page. A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, and then HIDE. (I only had one tab, in case that matters.)
Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down.
I'm also seeing that. No idea yet...
I finally sat down and worked out what the problem is. It's not only click-space, but that's the most common case.
<title>...&[character]...</title>
causes click-[character] to close it.
So fltk must think that's a shortcut in the tab text, and it tries to do whatever it does with shortcuts -- but there's a shortcut-handling piece missing, so it just closes the window.
It doesn't care about the tab text. It's the UI->window() label stuff that's causing the problem. It appears that you can escape &-as-shortcut in general by doubling them, but I end up with doubled && in the title bar. Why wasn't this a problem in the past? I don't know; maybe it _was_ regarded as a shortcut but handle() took care of it.
Thanks for tracking this down! I could also reproduce it with pre-tabs versions.
I have a dillo from Sept. 5 around, and space doesn't close the window for me.
Please try attached patch.
It works! RAW_LABEL is so much better than trying to escape &.
On Mon, Sep 22, 2008 at 03:31:58PM +0000, corvid wrote:
Johannes wrote:
On Mon, Sep 22, 2008 at 05:06:35AM +0000, corvid wrote:
I wrote:
Johannes wrote:
On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote:
I wrote: > Sometimes the window closes when I click on a page. > A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, > and then HIDE. > (I only had one tab, in case that matters.)
Okay, that was not accurate. It looks like PUSH and FOCUS_CHANGE is from clicking and HIDE is from pressing Space to page down.
I'm also seeing that. No idea yet...
I finally sat down and worked out what the problem is. It's not only click-space, but that's the most common case.
<title>...&[character]...</title>
causes click-[character] to close it.
So fltk must think that's a shortcut in the tab text, and it tries to do whatever it does with shortcuts -- but there's a shortcut-handling piece missing, so it just closes the window.
It doesn't care about the tab text. It's the UI->window() label stuff that's causing the problem. It appears that you can escape &-as-shortcut in general by doubling them, but I end up with doubled && in the title bar. Why wasn't this a problem in the past? I don't know; maybe it _was_ regarded as a shortcut but handle() took care of it.
Thanks for tracking this down! I could also reproduce it with pre-tabs versions.
I have a dillo from Sept. 5 around, and space doesn't close the window for me.
Please try attached patch.
It works! RAW_LABEL is so much better than trying to escape &.
Here comes a complete patch to disable label parsing for labels set from html. I hope I didn't miss one. Cheers, Johannes
On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote:
Johannes wrote:
Here comes a complete patch to disable label parsing for labels set from html. I hope I didn't miss one.
Does the UI's label need it in principle? (It didn't seem to require escaping the other day, but...)
I tried it with <html> <body> <form> <select> <option>&a</option> <option>&b</option> <option>&c</option> </select> </form> </body> </html> Without the patch there is no & and Alt a/b/c seem to be working as shortcut on the open select. Cheers, Johannes
Johannes wrote:
On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote:
Johannes wrote:
Here comes a complete patch to disable label parsing for labels set from html. I hope I didn't miss one.
Does the UI's label need it in principle? (It didn't seem to require escaping the other day, but...)
I tried it with
<html> <body> <form> <select> <option>&a</option> <option>&b</option> <option>&c</option> </select> </form> </body> </html>
Without the patch there is no & and Alt a/b/c seem to be working as shortcut on the open select.
Oh, I mean the UI label text that is shown in a tab.
On Fri, Sep 26, 2008 at 07:14:05PM +0000, corvid wrote:
Johannes wrote:
On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote:
Johannes wrote:
Here comes a complete patch to disable label parsing for labels set from html. I hope I didn't miss one.
Does the UI's label need it in principle? (It didn't seem to require escaping the other day, but...)
I tried it with
<html> <body> <form> <select> <option>&a</option> <option>&b</option> <option>&c</option> </select> </form> </body> </html>
Without the patch there is no & and Alt a/b/c seem to be working as shortcut on the open select.
Oh, I mean the UI label text that is shown in a tab.
Oh I see. I missed that one. It is also needed: <html> <head> <title>&foo</title> </head> <body>bar</body> </html> but set_flag(RAW_LABEL) does seem to help here :-(
Johannes wrote:
On Fri, Sep 26, 2008 at 07:14:05PM +0000, corvid wrote:
Johannes wrote:
On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote:
Johannes wrote:
Here comes a complete patch to disable label parsing for labels set from html. I hope I didn't miss one.
Does the UI's label need it in principle? (It didn't seem to require escaping the other day, but...)
I tried it with
<html> <body> <form> <select> <option>&a</option> <option>&b</option> <option>&c</option> </select> </form> </body> </html>
Without the patch there is no & and Alt a/b/c seem to be working as shortcut on the open select.
Oh, I mean the UI label text that is shown in a tab.
Oh I see. I missed that one. It is also needed:
<html> <head> <title>&foo</title> </head> <body>bar</body> </html>
but set_flag(RAW_LABEL) does seem to help here :-(
Oh, I see what you mean. I was just trying it with a space following the &, which seems to help it appear.
On Fri, Sep 26, 2008 at 07:50:58PM +0000, corvid wrote:
Johannes wrote:
On Fri, Sep 26, 2008 at 07:14:05PM +0000, corvid wrote:
Johannes wrote:
On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote:
Johannes wrote:
Here comes a complete patch to disable label parsing for labels set from html. I hope I didn't miss one.
Does the UI's label need it in principle? (It didn't seem to require escaping the other day, but...)
I tried it with
<html> <body> <form> <select> <option>&a</option> <option>&b</option> <option>&c</option> </select> </form> </body> </html>
Without the patch there is no & and Alt a/b/c seem to be working as shortcut on the open select.
Oh, I mean the UI label text that is shown in a tab.
Oh I see. I missed that one. It is also needed:
<html> <head> <title>&foo</title> </head> <body>bar</body> </html>
but set_flag(RAW_LABEL) does seem to help here :-(
Oh, I see what you mean. I was just trying it with a space following the &, which seems to help it appear.
I'd say we set RAW_LABEL for in UI::UI() and wait for fltk people to fix the problem. I've filed a bug report. Cheers, Johannes
On Fri, Sep 26, 2008 at 09:52:25PM +0200, Johannes Hofmann wrote:
On Fri, Sep 26, 2008 at 07:50:58PM +0000, corvid wrote:
Johannes wrote:
On Fri, Sep 26, 2008 at 07:14:05PM +0000, corvid wrote:
Johannes wrote:
On Fri, Sep 26, 2008 at 06:47:55PM +0000, corvid wrote:
Johannes wrote: > Here comes a complete patch to disable label parsing for labels set > from html. I hope I didn't miss one.
Does the UI's label need it in principle? (It didn't seem to require escaping the other day, but...)
I tried it with
<html> <body> <form> <select> <option>&a</option> <option>&b</option> <option>&c</option> </select> </form> </body> </html>
Without the patch there is no & and Alt a/b/c seem to be working as shortcut on the open select.
Oh, I mean the UI label text that is shown in a tab.
Oh I see. I missed that one. It is also needed:
<html> <head> <title>&foo</title> </head> <body>bar</body> </html>
but set_flag(RAW_LABEL) does seem to help here :-(
Oh, I see what you mean. I was just trying it with a space following the &, which seems to help it appear.
I'd say we set RAW_LABEL for in UI::UI() and wait for fltk people to fix the problem. I've filed a bug report.
Committed. -- Cheers Jorge.-
On Fri, Sep 26, 2008 at 07:36:30PM +0200, Johannes Hofmann wrote:
On Mon, Sep 22, 2008 at 03:31:58PM +0000, corvid wrote:
Johannes wrote:
On Mon, Sep 22, 2008 at 05:06:35AM +0000, corvid wrote:
I wrote:
Johannes wrote:
On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote: > I wrote: > > Sometimes the window closes when I click on a page. > > A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, > > and then HIDE. > > (I only had one tab, in case that matters.) > > Okay, that was not accurate. > It looks like PUSH and FOCUS_CHANGE is from clicking > and HIDE is from pressing Space to page down.
I'm also seeing that. No idea yet...
I finally sat down and worked out what the problem is. It's not only click-space, but that's the most common case.
<title>...&[character]...</title>
causes click-[character] to close it.
So fltk must think that's a shortcut in the tab text, and it tries to do whatever it does with shortcuts -- but there's a shortcut-handling piece missing, so it just closes the window.
It doesn't care about the tab text. It's the UI->window() label stuff that's causing the problem. It appears that you can escape &-as-shortcut in general by doubling them, but I end up with doubled && in the title bar. Why wasn't this a problem in the past? I don't know; maybe it _was_ regarded as a shortcut but handle() took care of it.
Thanks for tracking this down! I could also reproduce it with pre-tabs versions.
I have a dillo from Sept. 5 around, and space doesn't close the window for me.
Please try attached patch.
It works! RAW_LABEL is so much better than trying to escape &.
Here comes a complete patch to disable label parsing for labels set from html. I hope I didn't miss one.
Committed. -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de