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

List:       kwrite-devel
Subject:    Re: find
From:       Sebastian Pipping <webmaster () hartwork ! org>
Date:       2007-10-03 5:37:20
Message-ID: 47032A90.1030108 () hartwork ! org
[Download RAW message or body]

Anders Lund wrote:
> On Tuesday 02 October 2007, Sebastian Pipping wrote:
>> So again my suggestion is make
>> * <Return> search and close the bar, and
>> * <Ctrl>+<Return> search and keep it open.
>>
>> That's a solution at least you and I could be happy with.
>> Or did I misunderstand you?
> 
> No, I would be fine with that :-)

------------------------------------------------------
Good and bad news in this mail. Please don't beat me
for it but I thought about it some more, had a look
at Firefox again and changed my view on this a bit:

Pressing <return> should _not_ be the closer.
Firefox' search bar is jumping to the next match on
<return> as well. We were cloning Firefox all the
time - for good reason in my eyes. In Firefox
<shift> + <return> jumps to the previous match which -
good news here - kate supports now as well.

So what I did about that close thing is to map it
on <ctrl> + <return>. That way you have a way of closing
it right after the search. In case you like
<alt> + <return> better, that would be an alternative.
Please check out the current state live and see if you
can get used to that.


To sum it up again in a modifier/action map:

   <ctrl> <shift> | action
   ---------------|----------------------
                  | search next
             X    | search prev
     X            | search next, hide bar
     X       X    | search prev, hide bar


Please let me know what you think of the current solution.



Sebastian
_______________________________________________
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]