incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dali Liu <wawal...@gmail.com>
Subject Re: [Extension]Task panel/ sidebar view
Date Thu, 20 Sep 2012 07:46:07 GMT
2012/9/20 Jürgen Schmidt <jogischmidt@gmail.com>

> 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
>
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message