incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: [Extension]Task panel/ sidebar view
Date Thu, 20 Sep 2012 07:21:30 GMT
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
>   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?


View raw message