[PATCH] New feature: closed tabs trash bin as in Opera

Eduardo Robles Elvira edulix at gmail.com
Sat Feb 24 10:30:24 GMT 2007


El Lunes, 19 de Febrero de 2007, David Faure escribió:
> KConfig( "closed_tabs" ... )  => will create a closed_tabsrc. This should
> have konqueror in the name somewhere ;) Maybe KConfig
> ("konqueror_closedtabs")?

Fixed

> + if(!sender()->inherits("KonqUndoManager"))
> This breaks if the class is renamed one day, please use !qt_cast<const
> KonqUndoManager *>(sender()). Testing sender() is a bit hackish though, in
> any case.

Fixed, now it doesn't test the sender anymore

> m_closedTabsListLength is a constant, so it should become a file-static
> imho.

Done

> +  m_closedTabsConfig->setGroup( "Closed_Tab"  + QString::number(group) );
> Please use KConfigGroup grp( m_closedTabsConfig, "Closed_Tab"  +
> QString::number(group) ), and then use grp.readEntry().
> setGroup is going away very soon.

Okey this is the only thing I didn't fix. Using a KConfigGroup required major 
changes in konqueror code, probably including plugins and such. Once 
KonqFrameBase::saveConfig and KonqFrameBase::loadItem end up taking a 
KConfigGroup instead of a KConfig as an argument, I promise I will stop using 
setGroup.

> +  friend class KonqMainWindow;
> Can we avoid that? It's the main user of KonqViewManager anyway, so the api
> needed by the mainwindow can just be made public.

Done, friend statement removed

> Well done for the integration into konq_undomanager. I have some questions
> about that though: bool KonqUndoManager::undoAvailable() const
>  {
> -    return ( d->m_commands.count() > 0 ) && !d->m_lock;
> +    if(firstClosedTab() > -1)
> +    {
> +       return true;
> +    } else
> +       return ( d->m_commands.count() > 0 ) && !d->m_lock;
>  }
> Why is this change necessary? "Undo is available if there's any command to
> undo" should be general principle; and I see that tab-closing is done as a
> command, as one might expect. But somehow, tab closing seems to be have
> more priority, according to the top of undo(). Why? If I close a tab, then
> move a file, and then I press Undo - shouldn't that undo the file moving,
> instead of the tab closing? I think containsAnyClosedTab and firstClosedTab
> can just go away... (Otherwise, the strange operator== could be removed by
> not using indexOf, but a simple ++i).

As I said in the last email, this is necessary. But operator== have been 
removed ;-)

> slotAddClosedURL -> slotAddClosedUrl - new naming style ;)

Done

> +  QList<ClosedTabItem*> m_closedTabsList;
> Memory management might be simpler if using QList<ClosedTabItem> instead of
> a pointer. For instance, what happens if I close 11 tabs? Doesn't the
> oldest one get removed from that list, but would still be in the
> KonqUndoManager's list, as a dangling pointer? So in fact we can't store as
> value (libkonq doesn't know that class), but how about making the undo
> manager -own- the ClosedTabItem, and then m_closedTabsList isn't necessary
> at all? Of course the signal openLastClosedTab should ship the
> ClosedTabItem* to konqueror. No need to store that data in both places
> (even as just a pointer).

Done (probably it was the most difficult part ;-)
Now there's no m_closedTabsList anymore, every closedTab is only listed in the 
UndoManager.

Probably you have still some questions, if so I will answer and try to correct 
any problem with the code.

        Eduardo Robles Elvira.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20070224/4266fbf9/attachment.sig>


More information about the kfm-devel mailing list