2012/9/20 Jürgen Schmidt <[email protected]> > 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. >
The sidebar feature can be extend via extensions would be very useful for uses/developer > > 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? > > +1 > Juergen > > > > > >
