[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