"undo closed tab" feature for konqueror

[David Faure]

On Sunday 18 November 2007, Thomas Zander wrote:
> Hi David,
> 
> On Sunday 18 November 2007 15:42:09 David Faure wrote:
> > Can I request an exception to the feature and message freeze?
> > Eduardo Robles Elvira has been working on the long-awaited "undo closed
> > tab" feature for konqueror, and reworking it a number of times based on
> > my feedback. Now it's finally ready, but we're past the freeze
> > unfortunately.
> 
> How feature complete is it?  Or, more specifically, do you expect that it 
> needs more work (stabilization, known missing stuff) after its 
> integrated?

I hadn't touched the code yet, it was all from Eduardo, so I felt it needed some stabilization work needed, 
of which I have done a lot yesterday while travelling.

The new patch below has a cleaner design, removes some hacks like the singleshot timer,
fixes memory leaks, uses QAction instead of deprecated activated(int), turns struct into real class with 
Konq prefix, has the beginning of a unit test, uses refs instead of pointers where possible...

OK ktown says my mail is spam so let's try with a url instead of an attachment: 
http://web.davidfaure.fr/kde/undo-closed-tab.diff

I'm sad that we're being told "sorry too late to commit" when we could just have committed the feature
in its broken form when Eduardo started developing it 6 months ago, and done the refactorings in svn.
But since I have been bitten by too much broken code being committed to konqueror, I wanted
to have clean code -before- committing, for once, so I made Eduardo revise his patch numerous times
and I now cleaned it up further.

Now what? If I can't commit to trunk then there is a lot of code that is being prevented from
being touched (e.g. for any kind of simple refactoring while working on stabilization of the other, existing, features)
because of this pending patch...

> As features go, this sounds like a nice one, but also one that I can 
> imagine having a lot of side effects only becoming visible after lots of 
> people start using it.

Not more than many other konqueror features IMHO...
but yeah, the patch needs more testing, which is actually a good reason for
having it in trunk :) It's certainly less broken than other stuff which I have to fix :)

> The point of a feature freeze is to give people time to find and fix those 
> bugs. So if you are certain only minimal bugs will be found, that can be 
> fixed in under a week or two, then I'd personally have no objectsions to 
> making an exception.  One great way to find this out if the new code is 
> well unit tested.

Yep I started to add unit tests, and I hope Eduardo will write some more.
But of course I have to concentrate again on the more basic functionality
(that was in kde3) and that is still missing in konqueror, although I did a
lot of that last week (e.g. rename/cut/copy/paste/trash/delete works again).

I would like to plead for inclusion of the feature again.
In addition to the above reasons, I would like to mention that -one- new feature
in konqueror compared to kde3 is actually good for PR (better than telling people
"well this is the same konqueror as in kde3, only the inside has changed, no difference
for you except for the porting bugs").

Being able to commit this will actually allow me to concentrate on the rest of konq
again and letting Eduardo polish that code instead of us playing patch ping-pong
or working on an unmergeable patch in a svn branch...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).