[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: [patch] Preliminary Tabbed Browsing in Konquerorj
From:       Doug Hanley <hanleyman () adelphia ! net>
Date:       2001-12-15 19:00:38
[Download RAW message or body]

On Friday 14 December 2001 13:12, David Faure wrote:
> On Friday 14 December 2001 15:56, Alexander Kellett wrote:
> > On Fri, Dec 14, 2001 at 03:37:49PM +0100, Alexander Kellett wrote:
> > > Hiya Doug/Daniel, hope you don't mind (:]) but i'm working on getting
> > > this working for KDE3 at this very second, as soon as its compiling /
> > > running i'll post the patch.
> >
> > Okay, here's a Work Here (tm) re-patch, no serious testing though.
> > Only QList -> QPtrList changes were needed.
> >
> > Thanks Doug, it looks pretty darn nice!
>
> Yes, vey nice. And looking at the code, I like the overall design. Very
> nice too.
>

Thanks!

> I note that the hierarchy is that tabs are around everything, and one
> can split things inside a tab, which is great, it's the way we talked
> about, Carsten and myself, some time ago.
>
> > (if you're gonna use tabs, it makes sense that you would only use them at
> > the top level, right?)
>
> Yes, exactly.
>
> First bug report: "konqueror <URL>" from the command line leads
> to 0 tab being created, so the url isn't shown at all. This needs the
> creation of an initial tab.
>

I'll look into that one, looks like I could fix that pretty easily.

> Layout management seems broken by this patch too. Starting
> konqueror with no args this time, I get $HOME, but when resizing
> the window it's the statusbar that takes the new available space (!!).
> There are also layout problems when splitting views... one needs to resize
> the window to get things into place.
> Still about the layout, I think it's almost a requirement that the tab-bar
> doesn't appear if there is only one page (i.e. for people not using tabs).
> I see the hide() call, but the layout seems to still make room for the
> bar...
>

Yeah, the layout was definitely acting funky in that first case.  I'm not 
sure whats up with that, all I know is that when I create a new tab, that 
problem gets fixed.  I'll fiddle around with some ways to get that working, 
I'll probly come up with something, maybe a call to updateGeometry()?

As for the layout of the frames, thats one of my top priorities.  I want to 
make it so when you create views and remove views, they are in the right 
spot, now it seems like they get all out of order.

I think instead of hiding the tabbar, I'll just add or remove it from the 
layout as needed.

> Tab naming seems broken in some cases too (I ended up with tabs
> named "KonqFrameBaseTab" ;))
>

Hmm...I know I have to assign the name when the frame is created, and change 
the name when a new file is opened it.  I think the reason for the lack of a 
name on the tab, is when I split a frame that is a child of a tab, I dont 
give the tab name, I can fix that.  

Another problem is that the program will have to keep a record of what the 
active view is under EACH tab, that way it can display an accurate name at 
all times.  I'll try and get to that after I resolve all these showstopping 
bugs.

> Removing a tab simply crashes.... err in the DirFilterPlugin.
> #0  0x00000000 in ?? ()
> #1  0x4057b41e in KXMLGUIFactory::removeRecursive (this=0x84316c0,
> element=@0xbfffdf80, node=0x8460560) at
> /mnt/devel/kde/kdecvs/kdelibs/kdeui/kxmlguifactory.cpp:995 #2  0x4057b192
> in KXMLGUIFactory::removeRecursive (this=0x84316c0, element=@0xbfffe080,
> node=0x84301e0) at
> /mnt/devel/kde/kdecvs/kdelibs/kdeui/kxmlguifactory.cpp:961 #3  0x4057b192
> in KXMLGUIFactory::removeRecursive (this=0x84316c0, element=@0xbfffe0d0,
> node=0x842ba80) at
> /mnt/devel/kde/kdecvs/kdelibs/kdeui/kxmlguifactory.cpp:961 #4  0x40579b35
> in KXMLGUIFactory::removeClient (this=0x84316c0, client=0x8558a74) at
> /mnt/devel/kde/kdecvs/kdelibs/kdeui/kxmlguifactory.cpp:601
> #5  0x4017ff14 in KParts::Plugin::~Plugin (this=0x8558a30, __in_chrg=0)
>     at /mnt/devel/kde/kdecvs/kdelibs/kparts/plugin.cpp:59
> #6  0x4146e671 in DirFilterPlugin::~DirFilterPlugin ()
>    from /mnt/perso/kde2dev/lib/kde3/libdirfilterplugin.so
> #7  0x40a0d618 in QObject::~QObject (this=0x850eeb0, __in_chrg=0) at
> kernel/qobject.cpp:436 #8  0x4017dafd in KParts::Part::~Part
> (this=0x850eeb0, __in_chrg=0) at
> /mnt/devel/kde/kdecvs/kdelibs/kparts/part.cpp:139
> #9  0x4017e0b9 in KParts::ReadOnlyPart::~ReadOnlyPart (this=0x850eeb0,
> __in_chrg=0) at /mnt/devel/kde/kdecvs/kdelibs/kparts/part.cpp:299
> #10 0x4012ea1f in KonqDirPart::~KonqDirPart () from
> /mnt/perso/kde2dev/lib/libkonq.so.4 #11 0x414b165c in
> KonqListView::~KonqListView ()
>    from /mnt/perso/kde2dev/lib/kde3/libkonqlistview.so
> #12 0x4017df37 in KParts::Part::slotWidgetDestroyed (this=0x850eeb0)
>     at /mnt/devel/kde/kdecvs/kdelibs/kparts/part.cpp:263
>
> Uninstalling the plugin solves the problem... so there's something wrong
> with the way this patch handles the plugins...
>

I'm still a little confused by the relationship between parts, views.  But if 
I can figure out why this happens when I do removeCurrentTab and not when I 
do removeCurrentView, it should yield a sollution.

> > I also changed the way frames are deleted.  I wasn't sure about this one
> > since it changed quite a few things, but it made more sense to me.
> > Now when frames are deleted all you do is call delete on the frame you
> > want to delete and through class destructors, it will hierarchially
> > delete subframes of the original frame.  You still have to take care of
> > deleting views but this can be done easily though the listViews function
> > in KonqFrameBase.  Again, this last change is not essential to tabs, so
> > it can be removed if it needs to be.
>
> Careful about this. There are always many ways things can get deleted.
> The user can ask for a view to be removed... but a part can also suicide
> itself and must be removed cleanly in that case too. For instance, this is
> the case if you hit "Control+D" inside of the embedded konsole part.
> This case - and the whole destruction order - has given me quite a few
> headaches in the past ;}
> I can't test this with your patch, because.... Window / Terminal Emulator
> crashes :( (gdb) bt
> #0  0x400798ad in ToggleViewGUIClient::slotToggleView () from
> /mnt/perso/kde2dev/lib/konqueror.so #1  0x4007aa8e in
> ToggleViewGUIClient::qt_invoke () from /mnt/perso/kde2dev/lib/konqueror.so
> #2  0x40a0fbdb in QObject::activate_signal (this=0x8104f68,
> clist=0x810bba0, o=0xbfffe940) at kernel/qobject.cpp:2013
> #3  0x40a10119 in QObject::activate_signal_bool (this=0x8104f68, signal=4,
> param=true) at kernel/qobject.cpp:2066
> #4  0x4055bcb1 in KToggleAction::toggled (this=0x8104f68, t0=true) at
> kaction.moc:369 #5  0x40553d8a in KToggleAction::slotActivated
> (this=0x8104f68)
> Argl, no debug symbols in konq_guiclients.lo ...
>

Oh, I see, I saw mention of suicidal parts in the code comments, but I 
couldn't figure out why a part would go suicidal, that clears things up a 
little.  I might need a little help on solving this one though.

> Can you get KDE3 and polish those last things, or do you need someone to
> take over ? I'd prefer the first solution, obviously ;)

I think I can handle most of the bugs listed here, I might need a little help 
or just advice on the last one.

I'll start compiling KDE3 and if I have any problems I'll post them.  Also, 
once I resolve most of these bugs, I'll post another patch.

Best regards,
Doug Hanley

[prev in list] [next in list] [prev in thread] [next in thread]