S?b, 2009-02-07 ?s 23:38 -0300, Jorge Arellano Cid escreveu:
> On Sat, Feb 07, 2009 at 09:57:52PM +0000, Jo?o Ricardo Louren?o wrote:
> > S?b, 2009-02-07 ?s 18:33 -0300, Jorge Arellano Cid escreveu:
> > > On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote:
> > > > On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote:
> > > > > Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu:
> > > > > > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote:
> > > > > > > Greetings to all.
> > > > > > >
> > > > > > > As a simple introduction may I say I thank you all for your work on
> > > > > > > Dillo.
> > > > > > >
> > > > > > > Currently, I am trying to implement the Close-Tab button. I've been
> > > > > > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to
> > > > > > > dillo-dev.
> > > > > > >
> > > > > > > FLTK Tabs don't support a close-tab button, as many of you have seen,
> > > > > > > and the idea was to have a button at the end of the tabs list.
> > > > > > >
> > > > > > > For that, I created an fltk::Button widget in CustTabGroup. I position
> > > > > > > this widget at the end of the tabs list and, then, I add() it to the
> > > > > > > CustTabGroup's parent() (UI).
> > > > > > >
> > > > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in
> > > > > > > such a way that it doesn't resize the button itself, but only moves it.
> > > > > > >
> > > > > > > Refreshing the button (when changing/adding/closing tabs) is done in the
> > > > > > > handle() method of the CustTabGroup.
> > > > > > >
> > > > > > > Just a second ago I solved one of the problems, which was the fact that
> > > > > > > tab_height() returned 0 in the constructor and resize() didn't work. I
> > > > > > > worked around that by constructing the button only in event() if
> > > > > > > tab_height()>0 and it hasn't been constructed yet. This way we can use
> > > > > > > the correct height for the button.
> > > > > > >
> > > > > > > It may not seem reliable to do so many things in handle(). Any
> > > > > > > suggestions?
> > > > > >
> > > > > > We need to get something working, review it, and then we may
> > > > > > ask in fltk.general whether it could have side effects.
> > > > > >
> > > > > > > It is functional, only you can say if it fully suits Dillo's needs
> > > > > > > though.
> > > > > >
> > > > > > Please post the patch here so we can look at it.
> > > > > >
> > > > > > > Unfortunately, there are some problems:
> > > > > > >
> > > > > > > The first one is the most-relevant one. When the list of tabs grows it
> > > > > > > can go over the button. I have been trying to fix this, but I can't seem
> > > > > > > to do it.
> > > > > > > A possible way could (maybe) be to 'trick' the pager into thinking it
> > > > > > > has less space left to draw the tabs, and that could possibly be
> > > > > > > achieved using update_positions(), although I am having some problems
> > > > > > > with that.
> > > > > >
> > > > > > Or maybe just tweaking the value. After all it's a workaround.
> > > > > >
> > > > > > > The second problem is a minor one, but annoying. I believe when CSS
> > > > > > > rendering is triggered, the render area flickers and that is normal.
> > > > > > > However, the way I implemented this (probably because of it being in
> > > > > > > handle()) makes the Button also flash.
> > > > > >
> > > > > > A side affect of being a child of UI.
> > > > > >
> > > > >
> > > > > So, as requested, here is what I have got until now. There is a
> > > > > particular line I think is not necessary, I commented that specifically.
> > > >
> > > > I'm reviewing it now.
> > >
> > > Well, the good part is that it works and can be polished a bit.
> > > The problem is side effects (e.g. redraw storms while moving the mouse
> > > over the panel buttons, and who knows what else?).
> > >
> > > I tried a different approach and it almost worked OK, but after
> > > resizing the window, the redraw storms are on the whole window.
> > >
> > > Frustrating...
> > >
> > > It looks like drawing the button in the pager could work. I'll
> > > try to write some code this way.
> > >
> >
> > Thanks. Redraw storms are visible when running it under valgrind. Also,
> > parts of the code there were/are unnecessary. For instance, we could
> > send the redraw() message only when adding a new tab and not
> > continuously, but the redraw storms continue either way...
> >
> > Adding it to the pager seems the way to go there, but will you add it as
> > a button, or a custom drawn widget?
> >
> > If you need any help, do say, I'll try to do my best,
>
> Attached goes a patch that behaves nicely.
> Please polish it to a final state. It is commented.
>
> The button drawing code lacks the "X", the callback is not hooked,
> and there's no tooltip, but it doesn't trigger redraw storms,
> and feels right.
>
> Good luck!
OK, I've already implemented update_positions() to prevent tabs from
going over the button (grabbed it from FLTK and altered it). I don't
think there is the need for a callback function, since it only calls a
simple line.
I've noticed that we have no checking if the button is visible or not,
so it is working even though there are no tabs, I'll add a check for
that in event() rather than in other places.
Thanks,
Jo?o
