Project Filter merged

[Milian Wolff]

On Sunday 21 November 2010 16:41:46 Andreas Pakulat wrote:
> On 21.11.10 16:08:16, Milian Wolff wrote:
> > On Sunday 21 November 2010 13:32:15 David Nolden wrote:
> > > I don't like that the filter-line is visible all the time. It adds
> > > permanent UI clutter.
> > > 
> > > What are the usecases of this filter? Isn't it solvable on the
> > > project-manager level? I think that is where we need better filtering
> > > capabilities (It should be possible to specify include/exclude
> > > patterns and directories when importing a project).
> > 
> > It's a simple filter, isn't the usecase obvious? It's to find stuff. And
> > no, while it's similar to quickopen I would not say it is obsolete.
> > QuickOpen is nice and I use it mostly, but sometimes I want to search
> > for things in the project tree and looking at url's is not as nice as
> > looking at the tree itself.
> > 
> > And this is neither something related to the filter we have in e.g. the
> > generic manager, as that really skips creating ProjectFileItems etc. pp.
> > for the patterns. E.g. DUChain, QuickOpen etc. pp. all don't see those
> > hidden files. The filter in the project view is only related to the
> > view.
> 
> FWIW, I do use "search as you type" a lot in Win7's explorer and also in
> Eclipse, though more seldomly as I use quick-open there mostly. In
> eclipse a small line-edit is overlayed as soon as I type, thats quite
> nice. It doesn't really filter the tree though, it simply jumps to the
> first entry that matches (and opens up the tree as necessary).

This is standard QTreeView behavior, just without the popup and without 
extending the tree. Imo not very important to integrate, but we might want to 
introduce "expand on exact match" in the new filter? Not sure how that's 
possible...

> > > If the line stays, then it should only become visible when the user
> > > presses a "Filter" toolbutton.
> > 
> > I thought about putting it in one line with the other actions, which
> > would require some changes in Sublime API though, i.e. to make it
> > possible to add widgets and actions into the toolbar (like is possible
> > when you'd have direct access to the toolbar). I'll think about how to
> > do it properly. It would require the ability to place widgets (and
> > separators) at a very specific position, so either (my favorite) make
> > the toolbar available in the plugin to get full access to it, or -
> > alternatively change the current QList<QAction> to something like
> > QList<QVariant> or similar... Lets see.
> 
> Uhm, QWidgetAction is a QAction so using that to embed a widget
> shouldn't be a problem with the existing API. Also all KAction's are
> QWidgetActions by inheritance already.

Awesome, didn't know that. Will try that out later!
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101121/87ad7609/attachment.sig>