KTextSelectionExtension::findText...

[David Faure]

On Saturday 09 October 2010, Dawit A wrote:
> I mentioned all those functions just to answer your question that this
> is indeed implementable in both parts, nothing else... :) 

Yeah sorry, I was in fact already starting to answer the next point, which 
was, which API do we need.

> As far as
> clearing the selected text or finding the next matching one, one can
> simply invoke findText with an empty string and use the
> KFind::FindBackwards option to find the previous match respectively.
> IOW, why not simply call findText repeatedly to advance to the
> next/previous match as well as clear any selected text ?

I had trouble parsing your sentence, but I think you mean
* empty string aborts the search
* same string is passed again for "find next".
OK.
The first one should be documented in the extension, then.

> There is also an issue with the options parameter. I did not realize
> that KFind::Options is not a QFlag. As such to allow OR'ing of
> options, I have to change the second parameter to a long/int or add a
> Q_DECLARE_FLAGS(SearchOptions, Options)  and
> Q_DECLARE_OPERATORS_FOR_FLAGS(KFind::SearchOptions) to KFind. Not sure
> which one is more viable...

IIRC it's not a qflags because it's extended by the derived class 
KReplaceDialog. Well it could also be that this is kde3 code and nobody 
thought about that ;)

Anyway, adding the macros would work, I think, since we don't care for the 
kreplacedialog values (in kde5 we can just add them to the kfind flag set).

> >> > This might also trigger some thoughts about the API, like "is a
> >> > findNext needed", etc.
> >> 
> >> That is a good question. One plugin that would immediately need this
> >> api is the searchbar plugin which has a "Find In This Page" option for
> >> looking up text in the current page, but I am sure this can be useful
> >> for other parts
> > 
> > I thought you added a comment saying that "find in this page" was useless
> > and redundant, in that plugin? :-)
> 
> Yes, I did but the feature is still alive when using KHTMLPart and I
> did not want to unilaterally remove it just because I prevented it
> from showing up when using kwebkitpart...
> 
> > I don't know what to think, myself. It's definitely redundant with
> > Ctrl+F, but it could be that end users don't know about Ctrl+F and use
> > this for find-in- page, instead of Edit / Find? This sounds unlikely,
> > the more I think about it. Shouldn't we just get rid of it?
> 
> That is my personal view as well. I just do not see the point of
> duplicating features for no visible benefit...

Let's just get rid of it then...
Arend, any objections?

> >> > PS: my next target is an HTMLExtension with a querySelectorAll.
> >> 
> >> Great... I was going to ask you about that... Not sure I like the
> >> "querySelectorAll" name though. How about "findAllElements" ?
> >> querySelectorAll sounds vague and rather undescriptive to me...
> > 
> > Well, it's the standard "DOM Selectors" name for it, I thought this made
> > it a good name, especially since it really just calls querySelectorAll
> > in khtml (but indeed findAll in qtwebkit).
> 
> No real objection to using querySelectorAll, just a personal
> preference. Actually querSelectorAll might be better anyhow because it
> is the same name used in the DOM document object...

That's what I said :-)

> >> 2.) When is the new kdeplugins module going to be created for the
> >> plugins ? I want to modify the searchbar plugin to use the new
> >> KUriFilter APIs I added for 4.6, but I do not want to inadvertantly
> >> break things for people/distros that compile against 4.5...
> > 
> > I didn't get much feedback on kde-core-devel about a new module, so I'm
> > not sure what to do overall.
> 
> I think it is because of the subject you used that no one bothered to
> read it ;) I just posted a new thread to see if we can get some take
> on it...

I had tried to change the subject, but indeed, it was too nested by then.

> > But for the searchbar plugin I would like to suggest another approach
> > anyway: how about we move it to the konqueror sources? This would allow
> > us to decide not to make it a plugin, at some point, e.g. if we want to
> > integrate that functionality into the main location bar, like rekonq or
> > firefox do. I don't know yet, but for sure we'll have more flexibility
> > if it's part of kdebase/apps/konqueror so that it can be changed
> > together with konqueror.
> 
> That seems like a temporary workaround that would only help resolve
> the issue for one single plugin to me. I actually have been thinking
> about improving Konqueror's location bar for a while and have put an
> item about it on my TODO list. However, I do not think that the
> searchbar plugin should be moved into Konqueror's source tree.
> Specially if Konqueror's own location bar is going to be improved to a
> point where it makes the functionality in the search bar plugin
> obsolete and/or redundant...

But that's the point: if one day we remove the plugin, it will be much simpler 
if we remove it from kdebase/apps/konqueror exactly when we merge its 
functionality into konqueror, than if it's extragear and we have to deal with 
"does this version of konqueror need the plugin or not".

OK, I see your point though, if we go for kdeplugins then we can rely on it 
being equal to the kdebase version.... hopefully... not sure that's a 100% 
certainty, actually.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).