Bug 99700 - bookmark search could be more advanced
Summary: bookmark search could be more advanced
Status: RESOLVED FIXED
Alias: None
Product: keditbookmarks
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-18 13:31 UTC by Urs Dönni
Modified: 2005-07-01 09:23 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Urs Dönni 2005-02-18 13:31:40 UTC
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...).
Comment 1 Sebastian Sauer 2005-03-10 16:13:59 UTC
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. 
Comment 2 Daniel Teske 2005-07-01 01:24:21 UTC
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()));
Comment 3 Scott Wheeler 2005-07-01 01:28:09 UTC
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.
Comment 4 Daniel Teske 2005-07-01 01:42:59 UTC
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.)
Comment 5 Sebastian Sauer 2005-07-01 09:23:52 UTC
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... :)