Project Filter merged

[Andreas Pakulat]

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).

> > 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.

> But I disagree with it being cluttering, it's just one line with a useful 
> feature, new users (existing ones as well probably) will love it I'm sure. 
> Hiding it behind some actions is just overkill imo.

FACK.

Andreas

-- 
You will be imprisoned for contributing your time and skill to a bank robbery.