Handling of editing in treeview

Andreas Pakulat apaku at gmx.de
Sun Jun 22 23:57:15 UTC 2008

On 23.06.08 01:34:50, Andreas Pakulat wrote:
> Hi,
> I just committed a change to the project treeview which will cause
> a problem when using a plain-qt-styles (i.e. not inheriting from KStyle)
> due to QTreeView defaulting to the DoubleClickEditTrigger. That means by
> default QTreeView will start editing on double-click and not do anything
> else (like emitting the activated signal). As we can't control Qt styles
> and can't guarantee that people use KDE styles, I think we need to find
> another way to fix this. The options as far as I can see are (my
> opinions will be in a separate mail):
> - disable in-place-editing of items in the project treeview.

Thats a no-go IMHO, needing a separate dialog to change the name of a
file is sooooo out-dated ;)

> - find an edit-trigger that suits us, possible options are
>   "pressing edit key", "pressing any key". I don't think any of the
>   other options is usable for a project treeview

Having had a quick look at the Qt sources, EditKey == "F2" on anything
but MacOSX and there I'm not sure what it is (I think Enter, but am not
sure). So to me this sounds like a not-to-bad option. I think also
starting editing when typing non-control keys could be a nice difference
to other UI's. Qt's code still handles the navigation keys and such
things, so editing mostly only starts on pressing letter/number keys.

> - install an eventfilter/override the event hooks to have full control
>   over how to do that

Thats the other viable option to have better control and for example do
something like Aleix posted, i.e. only allow start of editing when the
proejctmanager can handle that (though currently all need to implement
the interface methods anyway :)


You fill a much-needed gap.

More information about the KDevelop-devel mailing list