Hi Jo?o, On Fri, Jan 30, 2009 at 09:38:18PM +0000, Jo?o Ricardo Louren?o wrote:
I have never worked with tabs in FLTK, but I've been browsing the documentation and have been trying to understand them. As for the button, I've nearly got it, the only problem is finding a way to prevent tabs from going over the button and that doesn't seem to be happening. An alternative would be to have the button in the 'tool-bar' or limit the number of tabs (doesn't seem nice right?). I'm trying to figure out pagers to set some kind of limit...
The button outside the tab-labels area would be confusing...
One other problem seems to be the fact that the button keeps resizing, that's probably bad FLTK coding on my side, let's hope I can figure it out.
FLTK-2.0 widgets have a handle() method that handles events. They also have a draw() method that draws the widget. My first idea was to draw the button in the draw() method of the pager, and to hook its functionality in the handle() method. This is the way I'd explore.
The canonical way would be to try to add a child button widget in the pager. It may not be possible though.
Yes, I did try to think of adding a button widget in the pager, though digging with the pager itself is quite a mess I'm trying to work out. For now, I'm trying to move my hackish code into CustTabGroup and the problem is that I can't seem to get the tab height...
What I am doing (for now, which still suffers from the resizing bug, since I did not touch pagers) is adding an fltk::Button, positioning it correctly and making it visible. In order to have it visible I add() it to the parent of a CustTabGroup instance (a UI, I believe), and this UI is the one that resizes it, I should figure out a way of preventing that. Is there another way of making it visible, not having it resize? It's something I never dug before.
I don't know why it is resizing. FLTK2 widgets need an explicit resize() call to enable it. Although there're exceptions. If you add it with a fixed size int the UI that should be it.
Adding a child button widget in the pager seems difficult in the 'real' meaning of the word 'add'. As a pager isn't a group that seems difficult, unless I do not use a widget but draw() it myself and then handle() it correctly.
Yes, the second option is where I'd start. There's the fltk.general forum for question like this: http://fltk.org/newsgroups.php?gfltk.general+T I haven't tried there yet and it would be interseting to know their advice.
On to another issue.
Browsing the code I noticed: // WORKAROUND: limit the number of tabs because of a fltk bug if (ui->tabs()->children() >= 127)
And, then, browsing the FLTK code I found:
static int p[128]; ... void TabGroup::draw() { ... int w[128]; ... //code using w and p...
I guess the problem is p being limited to 128...Probably fixing this issue has been discussed earlier, but a hipothesis would be overriding Fltk's code for TabGroup, anyway, that doesn't seem nice. Maybe we could ask the FLTK people to change it, if they agreed with it. Having more than 127 tabs open seems impossible but we never know.
FLTK2 is beong stalled for some time now. The team is focused on the 1.3.x branch. I wouldn't expect a patch unless we send it to them. At some point in the future we may be switching to 1.3.x. (they seem to want to develop a compatibility layer for FLTK-2.0, so ATM it's better to wait). I'd focus on the close-tab issue. ;) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
participants (1)
-
jcid@dillo.org