Bug 130074 - Inline search / shortcut conflict (resolving Konqueror vs. Konversation)
Summary: Inline search / shortcut conflict (resolving Konqueror vs. Konversation)
Status: RESOLVED FIXED
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-30 17:54 UTC by Robert Moore
Modified: 2006-07-01 21:26 UTC (History)
0 users

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 Robert Moore 2006-06-30 17:54:31 UTC
Version:           0.19 #3100 (using KDE 3.5.3, Kubuntu Package 4:3.5.3-0ubuntu0.1 dapper)
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.15-25-386

"/" is a key key for functionality/commands in both Konqueror and Konversation.

It would be useful to have the Konqueror search features integrated within Konversation. This includes the keys "F3" and "/", where for now only "[CTRL]+f" works. At the moment, "//" and "\?" don't get picked up as anything special. But "//" at the start the message/command line could be picked out by Konversation in a similar way as "/" is picked up by Konqueror - to commence a search.

Please implement such searching augmentation for the Konversation interface.
Comment 1 Eike Hein 2006-06-30 18:05:58 UTC
Note: Presently, if a duplication of the command character (which defaults to /) is used to prefix a line, that line is send to the active context as an IRC message, with one of the two command characters removed. Which is consistent with a number of other IRC clients on the platform, notably X-Chat.

Also, it should be noted that "/" invokes find-as-you-type search in Konqueror only when the document widget has focus, not when the address bar is focussed. In the former case, no "/" is added to the address bar contents. In Konversation, keyboard input presently causes focus to be returned to the input line automatically, as we've discovered this to be in line with user expectations (although the numpad's "/" doesn't receive this treatment). 
Comment 2 Robert Moore 2006-06-30 20:33:29 UTC
OK. An alternative to the would be to cause a search-as-you-type interface only when thedocument widget has focus.

Will F3 be implemented?
Comment 3 Eike Hein 2006-06-30 20:45:02 UTC
I think we're going to keep the focus handling by which focus is automatically returned to the input line of meaningful keyboard input - and / is certainly meaningful in an IRC context.

As for F3, I consider it a bug that F3 (which is our hotkey for "Find next", just as in Konqueror) doesn't open the searchbar when it is closed, so yes, that will  hopefully be fixed.
Comment 4 Eike Hein 2006-06-30 20:46:44 UTC
Clarification: F3 should open the searchbar when there is no active search, matching the behavior of the Konqueror search dialog.
Comment 5 Robert Moore 2006-07-01 20:15:13 UTC
F3 search capability would resolve this bug report. Searchbar beats search dialog - it only needs to have one shortcut key.
Comment 6 Eike Hein 2006-07-01 21:26:36 UTC
SVN commit 556874 by hein:

Have "Find Next" open the search bar when there is no active search,
matching Konqueror search dialog behavior.
BUG:130074


 M  +5 -2      ircview.cpp  
 M  +0 -1      nicklistview.cpp  


--- trunk/extragear/network/konversation/src/ircview.cpp #556873:556874
@@ -1173,9 +1173,12 @@
 
 void IRCView::searchAgain()
 {
-
-    if(!m_pattern.isEmpty())
+    if (m_pattern.isEmpty())
     {
+        emit doSearch();
+    }
+    else
+    {
         // next search must begin one index before / after the last search
         // depending on the search direction.
         if(m_forward)
--- trunk/extragear/network/konversation/src/nicklistview.cpp #556873:556874
@@ -22,7 +22,6 @@
 #include <qdragobject.h>
 
 #include "images.h"
-#include "nick.h"
 
 #include "konversationapplication.h"
 #include "nicklistview.h"