Ariel Constenla-Haile wrote:
Hello Frank,
On Saturday 17 January 2009 19:08, Frank Schönheit - Sun Microsystems Germany
wrote:
Hi Carsten,
With the following we work have been enhanced this API, by extending
it with new interfaces.
....
+com.sun.star.awt.XMenuExtended2
interface XMenuExtended2
{
interface com::sun::star::awt::XMenuExtended;
interface com::sun::star::awt::XMenu;
...
Given that "XMenuExtended" is not published, I suggest putting the
extensions made to it via "XMenuExtended2" directly into
"XMenuExtended". This would noticably reduce the API complexity IMO.
I first proposed that, but Carsten answered (I quote a private mail assuming
his kind permission):
"There is one problem with your
solution, I don't want that we change an interface (XMenuExtended)
incompatible which has been available since four years. Although it's
not published yet changing it would be a bad signal for developers who
already use the interface. Therefore, from my point of view, the only
solution would be to add a new interface providing access to images."
(And while we are at it ... is it just me as non-native English speaker
who thinks that "XFooExtended" sounds like ... well, non-native English
speakers creating API names? XExtendedFoo, or XFooExtension, or XFoo2,
or ... but "XFooExtended"?)
yes, there is the (deprecated) XExtendedToolkit. I just followed the
XMenuExtended naming scheme, as it wouldn't make any sense to name
XExtendedMenu2 with a XMenuExtended, so I also named XPopupMenuExtended,
XMenuBarExtended.
I know my design is awful and looks complicated, but that's the best I could
imagine in the current OOo API design/situation; vid.
http://wiki.services.openoffice.org/wiki/User:Arielch/Menu_API_Enhancement#New_Menu_API_.28and_its_design_problems.29
Today [in d...@openoffice.org] Jürgen suggested "an incompatible change and
redesign of the toolkit or a complete new one. First and foremost should we
make use of the UNO "ease of use" features, means multiple inheritance,
service constructor etc. to make it more comfortable and easier to use."
well, this have to be seen in the correct context. If we really think
about a replacement of VCL and if we want a clear separation between UI
and core via an abstract layer than i would suggest that we start with a
incompatible redesign or a new UNO toolkit. And of course we should
then allow incompatible changes over years to allow fixing design errors.
The awt module is just a reflection of the global situation in OOo API, or how
do we interpret things like css.ucb.XSimpleFIleAccess/2/3 ... n? When will it
stop? when they reach XSimpleFileAccess30?
Of course css.ucb.SimpleFIleAccess/XSimpleFileAccess cannot be changed because
they are published, the same goes for css.awt.X/PopupMenu and
css.awt.X/MenuBar, so IMHO the published/unpublished concept should be
redesign.
or it should be used more accurately. An interface that is intended for
public use and not published after 4 years is questionable.
I still have a mixed feeling when we start talking about this basic
design principle. I promised that i will come up with a proposal how we
can handle "useful" incompatible API changes more flexible or possible
at all. And i have to confess that i wasn't able to provide it till this
day. But that means not that i am and probably others don't think about it.
Others FOSS projects are not affraid of incompatible changes, as FOSS is life
and movement not something mummified.
maybe, both have pros and cons. I personally don't like to maintain a
finished project and make it working with the next release because of
incompatible API changes. But on the other hand i see the benefits for
an API to evolve over time and to become better and better. And most
impoertant better to use and more intuitive.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
