incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Grignon <kevingrignon...@gmail.com>
Subject Re: [Extension]Task panel/ sidebar view
Date Wed, 26 Sep 2012 05:32:03 GMT
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 <wawalovo@gmail.com> wrote:

> 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