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

List:       ktexteditor-devel
Subject:    Re: KTextEditor container extension
From:       Philippe Fremy <phil () freehackers ! org>
Date:       2007-07-30 20:33:26
Message-ID: 46AE4B16.2090305 () freehackers ! org
[Download RAW message or body]

Christoph Cullmann wrote:
> Am Montag, 30. Juli 2007 17:28:44 schrieb Philippe Fremy:
>> I also improved the API. While working on Yzis, I realise that one needs
>> to know in advance whether a given extension is supported, which was not
>> possible when relying on returned values of methods. So I added
>> supportsXXX methods.
> Hmm, but why? If a editor implements this interface, it should just support 
> all methods. As there are << 10 methods, I don't see any use in the supports* 
> methods beside uglifying the API, or?

I made it flexible to the extreme but that may not be indeed the right
way (tm).

How do you see it ? If an editor returns something different that NULL
on qobject_cast<ContainerExtension>( Editor::containerExtension() ),
then the whole interface should be supported ?

That would make it simpler indeed. And now that I think of it, that's
the way KTE currently supports extensions.

I'll propose a new patch tomorrow morning, adding another thing that was
missing: CMakeFiles.txt

	Philippe

_______________________________________________
KTextEditor-Devel mailing list
KTextEditor-Devel@kde.org
https://mail.kde.org/mailman/listinfo/ktexteditor-devel
[prev in list] [next in list] [prev in thread] [next in thread]