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

List:       kwrite-devel
Subject:    Re: New KTextEditor::SearchInterface draft #1
From:       Christoph Cullmann <cullmann () babylon2k ! de>
Date:       2007-04-21 10:09:53
Message-ID: 200704211209.53658.cullmann () babylon2k ! de
[Download RAW message or body]

On Saturday 21 April 2007 02:16:48 Matthew Woehlke wrote:
> Sebastian Pipping wrote:
> > Matthew Woehlke wrote:
> >> The problem is that you can't pass in multiple enum's at once ('2 | 3'
> >> is not distinguishable from e.g. '1 | 3' or just '3'). Therefore enums
> >> must be passed in singly. It might make sense to return an int with all
> >> supported *flags*, however. Is that useful? I don't know. :-)
> >
> > To solve this problem only powers of two are used for the
> > enum values. With that rule in mind you can always split
> > x := (a | b | c) back into its components. The enum
> > values I chose all look like "1 << y" so they will not
> > share any bits and therfore can be split back.
>
> D'oh, I'm being too attached to my combo box idea. :-)
>
> Anyway, maybe I am just being dense, but what is the use case for
> evaluating multiple flags at once? (Specifically, what happens if only
> some of them are supported?) Would it make more sense to have a function
> that takes no arguments and just returns the list of supported flags?
True, the function supportedSearchFlags () const; could just return the 
comibend int or QFlags of all supported bits...
The app can than test itself if the needed bits are in the bitfield ;)

I think we should first implement the API in KateDocument internally and use 
it for our search and replace bars, if we are happy with them, we can rewrite 
the search interface before KDE 4.0.

As the Search interface is aimed for the document, it makes no sense to have 
the highlight all option there or other display related stuff, as this 
interface should not influence the view. As the users wishs multi-document 
searchs in the kate application since ever, it might make sense to add a more 
toplevel interface for search to the view, too, to allow the kate application 
a simpler method to search and replace through all open documents/views, not 
that sure.... 

cu
Christoph

-- 
Christoph Cullmann
KDE Developer, Kate Maintainer
http://babylon2k.de, cullmann@kde.org
_______________________________________________
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]