Laurent Godard wrote: > Hi Carsten > >> Just for your infomration. The new toolbar controller enhancements are >> not a com.sun.star.awt substitution. The implementation is deeply >> integrated into the Office framework and therefore cannot support the >> same feature set as low-level awt controls! Most functions are supported >> or can be added without any problem. > > thanks for your precision > but this sounds odd to me regarding UNO nature and componentization > > I'll have a look (m169 just finished downloading) trying to understand > how it actually works (with an external poor user pow) > But i think that script coders are expecting to have access to the > "standard" features and events of such controls and that's why i told > about the awt controls
Carsten already explained why our concept is more abstract than the AWT. But there is another reason why we don't expose concrete controls: we don't want to lose the flexibility to change our UI. As an example, if OOo would ever want to implement something like the new "ribbon" GUI from the upcoming MS Office 12 we could do that without any changes in the other code of OOo, just because there is no code anywhere in OOo except in the LayoutManager that knows about the concrete build-up of the UI elements. We only expose what we think belongs to the nature of the dispatched commands, not how they are visualized. At the end that's what the Dispatch API (and Carsten's new extensions) is about. As an example, if your command is assigned to a list of element where you can choose one and also have a status information about which one was chosen for the current context the natural representation of this fact is an element list, so there is an API to exchange list functions. But we don't expose wether we represent this list as a list box or something else so that we are free in our current and future(!) implementations, we only expose the "idea" of a list being part of our GUI. Think about it in the following way (I again take the example of an element list): Your code is assigned to one or more GUI elements that visualize a list of elements (e.g. strings) and allow to choose one of them. OTOH these elements expect from your code that it tells them which element should be taken as the "currently selected" one (if possible). That's the contract between your code and the GUI. How the elements look (if they look at all - they could be implemented completely different, e.g. by assistive technologies, as accoustic controls etc.) and where they are located is not only unknown to you, it's completely irrelevant. I hope you can see the benefit of this approach and that you don't loose anything with it because all essential information is handled through the abstract communication API(s) laid out by Carsten. I for myself would have liked to have abstract assignments of commands to "types" (like "string list", "integer value" etc.) instead of (button) control names, but Carsten preferred the control names instead because it looks simpler and less "techy". As it is his "baby" I think that's okay, but OTOH it seems that it sets wrong expectations. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
