Version: 3.3.92 (using KDE 3.3.92 (beta2), compiled sources) Compiler: gcc version 3.3.4 OS: Linux (i686) release 2.4.29 I noticed the nice search bar in the bookmarks section in konqueror. However, when you type "keyword1 keyword2" it only finds bookmarks containing the exact string "keyword1 keyword2". It would be nice if it found all bookmarks containing the strings "keyword1" and "keyword2" in any order. I'm not sure if this is a problem of konqueror, the behaviour of the search bar is similar in other apps (juk, kmail, kcontrol...).
Good idear. I guess it would be really nice if poweruser could use regular expressions as well. In KMLDonkey we have such a searchlineedit as well and the user is able to define regular expressions by passing "~" as first char. A much nicer and cleaner solution would be a button where the user is able to call kregexpeditor and put regular expressions that way in.
SVN commit 430333 by teske: Add a more advanced search line to keditbookmarks. Instead of showing only those matching e.g. "keyword1 keyword2" exactly, show those items, which contain keyword1 AND keyword2. BUG: 99700 M +1 -1 Makefile.am A kebsearchline.cpp [License: GPL (wrong address)] A kebsearchline.h [License: GPL (wrong address)] M +2 -2 toplevel.cpp --- trunk/KDE/kdebase/konqueror/keditbookmarks/Makefile.am #430332:430333 @@ -12,7 +12,7 @@ dcop_DCOPIDLNG = true keditbookmarks_la_SOURCES = main.cpp listview.cpp toplevel.cpp actionsimpl.cpp commands.cpp importers.cpp dcop.skel dcop.cpp bookmarkiterator.cpp \ - testlink.cpp favicons.cpp updater.cpp exporters.cpp kbookmarknotifier.stub bookmarkinfo.cpp settings.kcfgc + testlink.cpp favicons.cpp updater.cpp exporters.cpp kbookmarknotifier.stub bookmarkinfo.cpp kebsearchline.cpp settings.kcfgc kbookmarknotifier_DIR = $(includedir) keditbookmarks_la_LIBADD = $(top_builddir)/libkonq/libkonq.la keditbookmarks_la_LDFLAGS = $(all_libraries) -module -avoid-version --- trunk/KDE/kdebase/konqueror/keditbookmarks/toplevel.cpp #430332:430333 @@ -28,6 +28,7 @@ #include "exporters.h" #include "settings.h" #include "commands.h" +#include "kebsearchline.h" #include <stdlib.h> @@ -49,7 +50,6 @@ #include <kmessagebox.h> #include <klineedit.h> #include <kfiledialog.h> -#include <klistviewsearchline.h> #include <kdebug.h> @@ -222,7 +222,7 @@ QLabel *lbl = new QLabel(i18n("Se&arch:"), quicksearch, "kde toolbar widget"); - KListViewSearchLine *searchLineEdit = new KListViewSearchLine(quicksearch, 0, "KListViewSearchLine"); + KListViewSearchLine *searchLineEdit = new KEBSearchLine(quicksearch, 0, "KListViewSearchLine"); quicksearch->setStretchableWidget(searchLineEdit); lbl->setBuddy(searchLineEdit); connect(resetQuickSearch, SIGNAL(activated()), searchLineEdit, SLOT(clear()));
Just noticed Sebastian's comment here -- regular expression searches are problematic because the execution time is pretty much unbounded. It's pretty easy to generate a regular expression that will lock a GUI solid for 10 minutes. You could throw in a timer to try to catch such situations, but doing that in the UI in a way that didn't confuse or frustrate the user would be difficult.
Well I didn't add Regex support. It's trival to add, but I don't think that it's that usefull. Typing a few words should narrow it down more than enough. And adding a ui-element, which is potentially confusing to 90% of the users isn't user-friendly. If someone disagree, they should open a bug report and convince me/someone else. Most regex matching is NP-complete. (The QRegex is definately.) Some, like for example POSIX-extended aren't. (See the propasal for the addition regex matching to the c++ standard.)
Thanks for the granted wish, Daniel :) Re regexp; I agree that it's more something for powerusers and therefore may usefull for less then 10% of the users. On other other hand it's imho still a damn usefull feature cause the (power-)user is able to define his own filtermask and isn't limited to e.g. just have terms that are and together. With the commit it isn't any longer possible to filter the list with >=2 matches that are or'd together. But I agree that this isn't matter of keditbookmarks, at least it shouldn't be done there. So, a much better solution would be to have such an optional regexpeditor-button at e.g. the newly introduced klinesearchedit (or however it is called) and introduce it that way KDE-wide. Anyway, as long as no other user sees the needing for it and as long as I am not able (cause in the lag of time) to implement it by myself... :)