On 9/19/12 8:24 PM, Ariel Constenla-Haile wrote: > Hi Jürgen, > > On Wed, Sep 19, 2012 at 01:13:23PM +0200, Jürgen Schmidt wrote: >> >> But more important is the question how we can move forward with the >> already planned improvements of this feature (see the wiki pages). > > I guess in the usual way: someone sits down, and writes code ;) > >> Especially the tabs on the right site with icons etc. comparable to the >> side bar in Symphony. Symphony comes here with some good improvements >> and useful property side bars. > > Now that you mentioned it: although the property side bar is "something > new" and may be useful from a user perspective, it has several > drawbacks, and introduces several regressions compared to what AOO > actually has to offer: > > - from the user perspective, AOO currently supports a way to customize > User Interface elements, at application and document level (Tools > - Customize dialog). Symphony's property side bars are completely > hard-coded in resource files, no way to customize them > > - from the programmability perspective: AOO currently offers extension > developer a whole set of features, from disabling commands via > configuration, dispatch interception, menu and toolbar merging, etc. > Symphony's property sidebars cannot be extended by the merging mechanism > (as said before, their structure is hard-coded). The most important > part is that the property sidebar wasn't design taking programmability > into account: try disabling some command as explain in > > http://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Disable_Commands > it will work with toolbars and menus (in context menus the command is > not disabled, but at least the command is not dispatched); but in the > property sidebar the command is enabled and even dispatched > > > While some of these regressions can be fixed (among other things, not > dispatching through the SfxDispatcher but through the SfxBindings, ...), > allowing customization of the sidebars seems not doable (at least in the > current state of the application framework). > > In conclusion, I wouldn't speak about a "revolutionary UI change" in the > code that has been contributed; as explained above, it has several > drawbacks and, from some perspective, is a regression from what AOO > currently offers to users and extension developers.
I agree and share all your observations. Nobody said a "revolutionary UI change" but the property side bar is of course a very useful approach to make these features better and more intuitive available. We should keep in mind that this UI was also awarded, feedback was positive and users like it. From my point of view reasons enough to at least take such an UI into account. The technical realization is of course a different thing. > >> And we have already a mechanism to >> integrate such task panes/side bars via extensions. We should think >> about how we can bring together both ... > > I recall that Carsten Driesner told me that the way how the tool panel > was implemented was a sort of hack; the real solution was in the > refactoring he was doing in the layout manager code, to support docking > windows as new UI elements; unfortunately, he no longer works on > OpenOffice, and there isn't much in the cws dockingwindows2 to get an > idea. I agree and there was work ongoing. My point is that we have to take care of potential existing solutions and if we can support the exiting API's in some way. But even if not we have to think about a good migration of existing extensions making already use of this feature. > > This shows another drawback of the Symphony sidebar implementation, as > completely designed in the old sfx2 framework, away from all the UNO > stuff that makes the application programable for extension development. > I guess that with a corporate mind, making this stuff extensible wasn't > in the original plan; while here at Apache OpenOffice, extensibility is > a way to produce a software for the public good, that can be extended > without the need to modify (nor learn) a single line of code (and nor > building the code by yourself from source, simply using our binaries, > provided to you for your "convenience"). > We should start from the point to decide if the general idea of such a property sidebar is a good one and help us to make our product better from the user perspective. Our goal is to make the usage of our product intuitive and easy and allow our users to handle their daily office tasks most efficient and with best results. And the next step is to think about the technical realization and I agree again that everything you have described is important and we should take it into account. But we should also think about the most practical solution. Do we have the time, the resources to provide the best and most generic implementation or can we move forward with a compromise. You know the framework better than me and you have worked closer with the former framework guys ;-) I was more the man who came with ideas and requests and was most often the first client to use it. I would split the whole thing in 2 areas: 1. is the side bar feature in general that can be used to integrate smoothly in the office UI via normal code or via extensions. 2. the content of a side bar. Here we can differentiate between "hard coded" content often coming via extensions or more dynamic content that can be configured, described in some way. I can of course think about an evaluation how well such a side bar would be accepted by our users and if we need the full flexibility or not. What do you think would it make sense to move forward with something like that until we have a technical better and more flexible solution? Juergen
