On Mon, Sep 29, 2008 at 07:46:52PM +0200, Johannes Hofmann wrote:
> Hi Jorge,
>
> On Mon, Sep 29, 2008 at 11:12:39AM -0400, Jorge Arellano Cid wrote:
> > On Mon, Sep 29, 2008 at 04:03:55PM +0200, Johannes Hofmann wrote:
> > > Hi,
> > >
> > > On Mon, Sep 29, 2008 at 09:48:58AM -0400, Jorge Arellano Cid wrote:
> > > > Hi,
> > > >
> > > > Can somebody please make the dialog for closing a window
> > > > with tabs open?
> > >
> > > "Close Window" only closes the current tab anyway.
> >
> > Yes.
> >
> > > "Exit Dillo" closes all windows including tabs.
> > > So, do you think about a dialog in the "Exit Dillo" case when
> > > there is more than one tab or more than one window or both?
> >
> > Both, plus the window manager's "close window" if there're open Tabs.
> >
> > > Do we have the number of open windows somewhere?
> >
> > In bw.cc's num_bws.
> >
>
> just tried to implement that by creating a callback for the
> fltk::Window. But then I noticed that user_data() of the windows is
> already beeing used in ui.cc.
> I don't understand why this is necessary. UI also contains a pointer
> to the BrowserWindow (Bw).
It helps the child widgets find their bw. e.g. search button,
panel buttons, etc. They are nested in different ways depending
on the panel shape choice so AFAIS there's no easy way to
navigate up to the UI. One way solve it is to store the bw in the
window's user_data(), thus a simple wid->window()->user_data()
does the trick.
Giving it some more thought, the danger of some function not
belonging to the current UI geting the wrong bw is real, and it
may end sending commands to the wrong bw.
IOW: there's only one window for several tabs. When Tabs switch
focus, the window()->user_data() is updated accordingly. If a
background Tab requests its bw using window()->user_data() it
will get the wrong one!
(this may cause problems as the one reported by corvid.)
If we can find an alternative method to get to a widget's bw
(storing it in the CustTabGroup for instance), it'd be much
better.
--
Cheers
Jorge.-
