Hello Juergen, On Sunday 18 January 2009 09:50, Juergen Schmidt wrote: > > 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_Enhancemen > >t#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.
this is not the underlying problem. Of course it may be confusing for an API client why some API is unplushed after a long time. But once I asked a developer, he answered that leaving a service unpublished was the only way to add functionality as the implementation evolved (instead of declaring this new functionality to be Optional, or design an XSomthing2/3/4...n) OOo API describes an abstract specification, but on the other hand it's not that abstract in the sense that there are different vendor's implementations; in this sense OOo API describes concrete impls. inside OOo project only, so it has to evolve as OOo evolves. Besides evolving, some stablished things may/should be redisign to take advantage of service constructors and multiple inheritance. With things like XDocument Document.create() to create a new doc. and get access to *all* its functinality XDocument Document.create(URL aURL) to load an existing one form its URL etc. etc. OOo will win more enthusiastic developers. Regards -- Ariel Constenla-Haile La Plata, Argentina "Aus der Kriegsschule des Lebens - Was mich nicht umbringt, macht mich härter." Nietzsche Götzendämmerung, Sprüche und Pfeile, 8. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org