[patch] konqi using searchline

David Faure faure at kde.org
Sun Dec 26 12:18:29 GMT 2004


On Saturday 25 December 2004 17:23, Martin Koller wrote:
> On Friday 24 December 2004 15:41, David Faure wrote:
> > I hope it doesn't slow down listing of big directories too much - even when
> > not shown, the connect()s will trigger the filtering code, right?
> 
> You mean the searchline widget?
> Yes, the connect is triggered, but as the widget is not visible, the filter 
> string is empty, which then does only one if in 
> KListViewSearchLine::itemMatches()
>     if(s.isEmpty())
>         return true;

OK, thanks for the explanation.

[...]
> but in the configure Toolbars dialog I have
> Extra Toolbar <Konqueror>
> Extra Toolbar <DirFilter>
> Filter Toolbar <DirFilter>
That's a limitation in "configure toolbars" - it shows an item per-toolbar and per-component,
but don't make decisions based on that... There is hope that we can improve xmlgui for kde4
to make the configure toolbars dialog more high-level.

> Do you think this is ok?
Not having seen the result I got a bit lost in the reasoning :).
But don't take my previous question as an objection - if there is a filter toolbar,
why not have everything related to filtering in it?
Anyway that's between you and Dawit :)

The thing that surprises me is that the XML doesn't ever mention  toolbar_filter_field
 -> how does the action appear in the gui?
Either I'm not seeing clearly (too much Christmas turkey :), or maybe you're testing
with another version of the .rc file installed locally?

> Attached is a new version.
Looks better. Please use ::qt_cast<QIconView> instead of inherits("QIconView") which is a bit slower.

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




More information about the kfm-devel mailing list