Hey All, Thanks for the links to existing effort. This is useful to see what has been considered already.
As a reminder, AOO UX looked at the Symphony Task Pane and prepared a report that identified positive aspects of the Symphony task pane to emulate via merge/migration, and which aspects to avoid. We also identified a number of opportunities for improvement for the task pane implementation moving forward. See: AOO Symphony UX Migration/Merge Analysis - Task Pane<http://wiki.openoffice.org/wiki/AOO_Symphony_UX_Migration/Merge_Analysis_-_Task_Pane>for more information. Regards, Kevin On Thu, Sep 20, 2012 at 3:46 PM, Dali Liu <[email protected]> wrote: > 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 > > > > > > > > > > > > >
