[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Getting rid of KateSearch ?
From:       Dominik Haumann <dhdev () gmx ! de>
Date:       2007-02-19 23:55:22
Message-ID: 200702200055.23024.dhdev () gmx ! de
[Download RAW message or body]

On Monday 19 February 2007, Anders Lund wrote:
> Hi,
>
> Maybe this is the time to get rid of KateSearch (katesearch.cpp/h)?

That was the plan, wasn't it? :)

> The classes therein are badly cluttered, and it's probably as easy to
> just dismiss it and start with what is already in katesearchbar.
>
> What is missing form that is
>
> * replacement (requires some work, but not scaringly much)
>
> * picking up search phrases based on the cursor position/selection (this
> needs some deciding, if we pick up a search phrase we should wait for
> user activation before searching, and not nessecarily search whenever the
> pattern is changed)

incremental search can be really useful. i'd like to see that for kde4.

> * search options (the buttons are there but not all working)

christoph initially added them just to have the gui ;)

> * saving options over sesisons (do we want that?)

maybe globally? i don't think you'd want to configure that per session. hm, 
maybe i'm wrong :)

> * saving search phrases (do we want that?)

like a combobox? this will be tricky if we want to support multiline search.

> * sane defaults (case sensitive off, whole words off, regex off, from
> cursor on, selection only automatic(?), highlight all off) (user
> configurable?)

maybe simply remember what the user had last time? iirc that's what we do in 
the KFindDialog and it works pretty well.

> * command line support (which is not as important with the embedded
> interface, though still nice - at least for me it has become a habit
> using the command line)
>
> Supposedly this would allow us to close quite a few bugs related to
> searching!
>
> Problems and thoughts:
> Getting enough space for all those widgets!

konversation has an "options v" button on the right. as in kate edition is 
*the* central part the user wants to do using a button might not really 
work. is there a problem with two lines?

> The 'Previous' and 'Next' buttons already suffer, since the labels should
> really be 'Find Next/Previous' or 'Next/previous Match' to really make
> sense.

are you sure? look at for example qt assistant. i don't see a problem with 
short strings. if you hit ctrl+f you know after all what you are doing...

> For replacement, at least one more line will be needed, probably two to
> make room for the placeholder stuff.

right... we'll have to see how this will work. otoh: having something 
working is good, ui tweaking can still be done afterwards :)

> We could make it possible to hide the search options, to benefit users
> with simple needs. I personally often wants exactly what the searchbar
> provides pr default: incremental search for a simple string from the
> cursor position.  ;)

in this case we indeed can use a 'advanced' or 'options' button like in 
konversation. if you click the button, it simply could vanish and all the 
options can be shown... just an idea.

> We could make the incremental search optional, I'd personally like that
> quite often.

yet another option? :) uhh...

> There is a hidden feature!! (TAB/BS key does find next/previous). How do
> we expose that? (also, ESC hides the widget)

what do you mean by expose? I'd say it's a nice feature for power users. the 
only drawback is that TAB does not switch focus to the next widget... but 
we have the keyboard accelerators.

> The 'lightsalmon' color used to visually indicate that the text could not
> be found. visual feedback is cool, but could we use a red color instead
> of an orange? (the 'palegreen' works better, green as it is)

there are 3 colors on
http://oldwiki.kate-editor.org/index.php/Current_Work_&_TODO
maybe we can try them?

alternatively we could test the oxygen colors:
http://developernew.kde.org/Projects/Oxygen/Style

> I send this just having comitted a lot of functionality to the search:
>
> SVN commit 635416 by alund:
>
> Make the functions in the search bar work (mostly), here is a status:
>
> [x] case sensitive (was working already.)
> [x] whole words (like in 3.5, add \b at the ends of the pattern.
> [x] regular expression (if not enabled, the pattern used is passed
> through QRegExp::excape(). Search is not performed unless the pattern is
> valid.) [x] from cursor (begin in the proper place IMO, this should be
> enabled pr default.)
> [/] selection only (when enabled, the search is not incremental and you
> have to press the RETURN key to perform the search. This is because the
> result is selected, and as such the selection is moved. We could store
> the original selection to work around this, and eventually highlight it
> differently. thoughts about this is wellcome.)
> [/] highlight all (all matches are found, and highlight added but not
> displayed or removed *visually* again EVER. read kwrite-devel from today
> for the entertaining story ;). Code-wise, the highlight are removed when
> a new search is initiated, this should be subject to discussion as well,
> maybe we should provide a way to unhighlight it, or do it in other/more
> events (hiding the search bar comes to mind.))
>
> TODO: Currently search is always performed when RETURN/ENTER keys are
> pressed, and this is wrong when the incremental searching is active
> (becomes like find next). A possible fix is comparing the potential
> pattern to that in the regex.
>
> In addition, I have made this small improvement: When searching
> incrementally and you get no match, the non-matching string is selected
> in the pattern entry, so that you just overwrite it with the next
> keypress.
>
> Happy searching :-)
>
> I *mean* it -- go ahead and beat away on it! And don't forget to post
> your experiences and comments.

awesome work! :)

Dominik
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]