KTextSelectionExtension::findText...

[Dawit A]

On Fri, Oct 8, 2010 at 3:55 PM, David Faure <faure at kde.org> wrote:
> On Friday 08 October 2010, Dawit A wrote:
>> > Did you have a look at implementing that method in both khtmlpart and
>> > webkitpart?
>>
>> Yes, the khtmlpart already exposes the following four functions...
>>
>>   void findText();
>>   void findText( const QString &str, long options, QWidget *parent =
>> 0, KFindDialog *findDialog = 0 );
>>   void findTextBegin();
>>   bool findTextNext( bool reverse = false );
>
> Yes. Well, the first one pops up a dialog, we probably don't want that? Well,
> it's hard to know all the future use cases, but I'm thinking, parts already
> exports kactions, for this, we probably don't want to provide APIs for
> everything that parts can do. The non-interactive "find this text" like you
> suggest is probably good however. We do need some sort of "clear/reset find" to
> get rid of the selected text at some point. (Is that KHTMLFind::deactivate in
> khtml? Not sure.). And findTextNext(Forward or Reverse) looks good too.

I mentioned all those functions just to answer your question that this
is indeed implementable in both parts, nothing else... :) 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 ?

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

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

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

>> Anyhow, that is a matter of semantics and does not really matter. What
>> matters most to me are the following:
>>
>> 1.) What would the function used for querying return ? A QStringList ?
>> Seems too limited to me. Perhaps we should consider a
>> something like a readonly list of KWebElement modeled after QWebElement ?
>
> Yep, that's the only way to do it. We need name and attributes, for each
> element.

Great...

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

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

> Maybe we should be discussing this on kfm-devel, after all ;)
> (Feel free to CC the list if you agree)

Done. Though I doubt anyone would be interested...