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

List:       kwrite-devel
Subject:    Re: Getting rid of KateSearch ?
From:       Anders Lund <anders () alweb ! dk>
Date:       2007-02-20 0:40:21
Message-ID: 200702200140.23639.anders () alweb ! dk
[Download RAW message or body]

On Tuesday 20 February 2007, Dominik Haumann wrote:
> > * 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.

Again, i think this should be the default behavior. But when looking for a 
specific, long string, the view moving is just distracting. I'm not sure what 
I would end up doing in practice, setting an option or live with the 
discraction. The impact of distraction might be worse for others, say people 
with handicaps.

> > * search options (the buttons are there but not all working)
>
> christoph initially added them just to have the gui ;)

And I promised to take action  :-)

> > * saving search phrases (do we want that?)
>
> like a combobox? this will be tricky if we want to support multiline
> search.

Yes. We will see...

> > * 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.

Maybe. I'm not the biggest fan of that in face, I'm more likely to set options 
before doing something special than to reset them after. I think I'd like 
user configurable defaults a lot :-)

> > 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?

Konversation has a menu button, which is space efficient but also efficiently 
makeing your current settings invisible during action. In fact the problem 
with hiding the 'advanced' section of the widget is exactly that.

> > 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...

Some will be pressing the toolbar button or menu item with their mouse. As far 
as Qt assistant is concerned, i have a hard time taking serious an 
application that defaults to having a tabbar with partially hidden tabs in 
its userinterface.

No button in its search widget have uninterpretable labels, but then it has 
no 'next' or 'previous' option. Maybe I'm looking in the wrong place?

> > We could make the incremental search optional, I'd personally like that
> > quite often.
>
> yet another option? :) uhh...

Don't be (too) afraid of options. Although we get better at Doing The Right 
Thing, choice is still a key concept of freedom.

> > 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.

Well, putting it in the manual is of course obvious, and ironically, the 
manual is probably most likely to be read by _real_ powerusers (joe can't 
read, wannabe geeks doesn't think they should) :p

Another option is something like the tips provided by kpdf, or even mr. clips. 
While we simplify the interface but keeps|adds power, we need to be able to 
communicate that in a simple and efficient way.

> > 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?

I do not see an orange color yell error, nor a pink. the error color should 
unboubtfully red. the color for highlighting all items should be in the color 
scheme, because it must stand out in the active scheme, and thus be 
definable.

We should probably provide a standard mechanism for extending the color 
scheme.

The other colors by the way must be configurable too, or preferably come from 
the KDE color scheme. Since other apps are likely to start using similar 
types of widgets in the future (some already does), maybe we should come up 
with a suggestion for that.

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

I'm all for making our default color scheme use colors from that pallette.


-- 
Anders

www: http://www.alweb.dk
jabber: anderslund@jabber.dk
_______________________________________________
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]