Issue 59087 - Add-on toolbars should be adaptable
Summary: Add-on toolbars should be adaptable
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 2.0
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-08 14:18 UTC by bmarcelly
Modified: 2017-05-20 10:35 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description bmarcelly 2005-12-08 14:18:56 UTC
When you install an add-on in OOo 2.0, you get a new toolbar called Add-on 1
When you install a second add-on, you get a new toolbar called Add-on 2
And so on...

Problems:
- too many toolbars in the application (an aggravation of the well known problem of 
OOo 2.0)
- the toolbar names cannot be set by the xcu file (I think, no info in the Dev'Guide)
- the toolbar names cannot be changed by the user to something more descriptive
- the user cannot move the toolbar icons to another toolbar
- a toolbar with only one icon is very strange when floating, and the title of the 
toolbar is not visible
- OOo 2.0 solution is inesthetic, compared to OOo 1.1.

Proposals (implement both):
- only one toolbar for all add-ons; preferably with a separator between successive 
add-ons
- the user should be able to copy any icon of that toolbar to any other toolbar, e.g. 
to a user-defined toolbar

With these 2 improvements the user should be able to configure the add-ons at will, 
and ignore (hide) the original add-on toolbar if he wants.
Comment 1 maison.godard 2005-12-08 14:43:21 UTC
Hi

manipulating icons and toolbars can be achieved through Tools > adaptation
note so easy as drag and drop but doable, i think

the main problem for ma is that one can not set the menu name for a toolbar
(Add-on 1) - Nothing in the addon schema. 

if it is not translatable, i think it is a defact
the schema for toolBarItems should accept a Title property

Laurent
Comment 2 carsten.driesner 2005-12-09 10:16:08 UTC
cd: Let me give you my view to your problems:

Problems:
- too many toolbars in the application (an aggravation of the well known problem
of OOo 2.0)
You get one add-on toolbar for every add-on. I don't see a problem here. The
user can open/close toolbars as he/she likes. I think the OOo 2.0 toolbar
concept is a big improvement. If you look at the press reviews, most of them
clearly praise us for the OOo 2.0 toolbars.

- the toolbar names cannot be set by the xcu file (I think, no info in the
Dev'Guide)
Correct. We decided to leave the Addon.xcs/Addon.xcu untouched for OOo 2.0. You
are right that for the toolbar name this was not a good choice.

- the toolbar names cannot be changed by the user to something more descriptive
This is technically not easy to achieve. The add-on toolbar data is stored in a
UNO-package, which is not writable. May be there is a way to access the special
configuration layer to store this data.

- the user cannot move the toolbar icons to another toolbar
From my point of view this doesn't make sense for add-on toolbar buttons. The
function of the button is bound to the add-on. The life-time of another toolbar
is not bound to the add-on. You could have non-function buttons on your
toolbars, if you deinstall an add-on. It would be very time consuming to check
on start-up, if a function is available or not (which would hurt our start-up
performance considerably).

- a toolbar with only one icon is very strange when floating, and the title of
the toolbar is not visible
Yes, that's right. I am not sure how to solve this problem. May be it would be
better to have more functions in one add-on than using two or more separate
add-ons. Developers of add-ons can help us here.

- OOo 2.0 solution is inesthetic, compared to OOo 1.1.
I cannot agree here. From my point of view the OOo 1.1 implementation is clearly
much worser. There are add-ons with more than 10 toolbar buttons. In OOo 1.1
with two or more add-ons you have to scroll the function bar, which is very
annoying. We chose that solution for OOo 1.1 only for technical reasons.

Proposals (implement both):
- only one toolbar for all add-ons; preferably with a separator between
successive add-ons
I don't think that this would be a good idea. As I mentioned before you could
loose the fast access to toolbar buttons (have to use)

- the user should be able to copy any icon of that toolbar to any other toolbar,
e.g. to a user-defined toolbar
As I mentioned before, this doesn't make sense. This function of the button is
bound to the add-on. If you remove the add-on nobody would remove the toolbar
button from the other toolbar. This would be a major annoying draw back of your
proposal.

cd->cj (user experience): Can you please give your notion to this issue.
Comment 3 maison.godard 2005-12-09 10:31:59 UTC
- We decided to leave the Addon.xcs/Addon.xcu untouched for OOo 2.0. You
are right that for the toolbar name this was not a good choice.

--> This should be corrected as addons will become more and more popular
Add a localizable title property to the schema of ToolBartItems
Any workaround though ?

- The add-on toolbar data is stored in a
UNO-package, which is not writable. May be there is a way to access the special
configuration layer to store this data.

--> perharps playing with
./user/registry/data/org/openoffice/Office/UI/WriterWindowState.xcu:     <value
xml:lang="fr">Add-on 1</value>

  

Comment 4 carsten.driesner 2005-12-09 14:29:41 UTC
cd->laurentgodard:
--> perharps playing with
./user/registry/data/org/openoffice/Office/UI/WriterWindowState.xcu:     <value
xml:lang="fr">Add-on 1</value>
It's possible, but with some draw backs:
1.) You can only change the toolbar name for one module or the implementation
has to change the name for all modules.
2.) We don't have a unique ID for an add-on/add-on toolbar. Therefore the
entries in the WindowState.xcu files are not bad but there can be name clashes.
You even don't know which add-on is bound to which add-on toolbar in the
WindowState.xcu. Think of one add-on is uninstalled and two are installed.
That's why we think of a better way to support this.

Currently I have no good solution for this problem. Changing the Addon.xcs file
for OOo 2.0.x would make add-ons downward incompatible. An add-on for OOo 2.0.x
wouldn't work for OOo 2.0 as the Addon.xcu is not compatible with the schema!
Comment 5 Rainer Bielefeld 2006-10-19 06:50:34 UTC
I believe these problems exist for all OS?
Comment 6 Edwin Sharp 2014-02-08 20:02:00 UTC
Extension of bug 99856, comment 4 has toolbar named "Extension example bar" and not Add-on 1.
AOO410m1(Build:9750)  -  Rev. 1565724
Rev.1565724
Win 7