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:33:45 GMT
Questions:

Is this feature formally in AOO roadmap?

If so, what release is it in plan for?

Do Bugilla epics or stories exist for this work?

Regards,
Kevin



On Wed, Sep 26, 2012 at 1:32 PM, Kevin Grignon <kevingrignon.oo@gmail.com>wrote:

> 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