Issue 101513

I found the next problem :(

I read http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1 and
wonder why i didn't found the new menue entries in Base.

How can we publish which file in the user configuration should be created new to
get the new menu entries?

This is a basic problem if a user change a menu and/or a toolbar. In this case
there settings are saved in the user directory.
After a update of OOo changes in menu or toolbar has no effect because of the
settings stored in the user directory.

Workaround: Delete in the user directory (may be deleting the directory 'config'
is enough) and start OOo. Then you must customize your menu/toolbar again.

this is not a workaround in a productive environment

then you need exact informations which file(s) contains these informations

Otherwise you lost *all* settings in your productive environment like personal
dictionary, installed extensions, autotext, and many more things.

There is also a thread at users@de.openoffice.org in German 

I add fs to CC

because there are some menu changes since 3.0 which are not vivible by some users

of: I'll have have look and ask cd for a comment/solution.

cd: Add myself on CC.

cd: I see the problem but I don't have a solution I fear there is no good
solution at all. The root cause is that the customized menu/toolbar is
completely copied from the user settings to the user data of the new version.
This results that entries which were added by a new version are not visible. So
only copying cannot be the "real" solution at all. Something like merging must
be done but. Unfortunately this can be a very complicated task and in the end
could also lead to bad results. Think of sub menus which were moved from one
place to another one. What to do with changes there? Create this sub menu again
in the new version? May be someone create a new menu and removed a old one. Then
you are definitely lost. Although I have thought about a good solution for
several months now I still have now good solution. The best algorithm I
currently see is add all user changes into the new version. If a sub menu is
missing it will be recreated. Dependent on the sum of changes between two
versions this could result in a good or bad user experience. The only good thing
is that the user won't lose his/her changes and could access all new functions.
It should be clear that there is no easy solution at all. A short-term
workaround could be to add version numbers to user interface configuration files
and don't copy user data for all elements that have changed between two version.
This would be an "optimized" version of the proposed workaround to completely
delete the user interface data.

@ cd

I have the following idea.

Is it possible to add to the user configuration file only the new menu entries.
Therefore you need a diff between both files.

In the case the user delete an entry this one should only be set to hidden. So
you only add really new entries (similar to "Migrate Code..." in Base)

If there is to change an entry (like Autotext). you have to look if it is on the
old Place and if it is set True or False. you have to moe it to the new place
with the same flag.

fs->cd: versioning information sounds like a good thing ...
Other that that, I think that simply resetting the menu/toolbar configuration is
better than not giving the user the new menu/toolbar items at all. Imagine the
Project Renaissance, and what it might do to our user interface: Do we really
want every user who just modified a *single* item in her menu/toolbar to not
benefit from all those hundredths of changes?

fs->mechtilde: I suppose that the approach you suggest would be possible in
general, but arbitrarily difficult to implement ...

in addition to my post before

the package management of Debian help the users to hold their own configuration,
take the new one or can look at the difference between the two difference
versions of the configuration file.

"Users" here means the one you has the rights therefore.

So while the user install such a program (s)he can decide what can happen.

In spezial I use it for the my.cnf the configuration file for the mysql server e.g.

cd: Add myself on CC.
he wrote himself in desc 7 so I do it

I'm interesting to discuss it to a possible solution. 

I think a solution here is very important.

@ cd: We should find out what might be the best solution. As suggested, this is
to risky for 3.1.1.

Not a new problem.
The summary of this issue is not clear.
IMO the situation is:
 - when a user changes a menu /toolbar, this change is migrated to a
 new installed version;
   - however, possible changes in the menu/toolbar from that new version
   are not visible (reasen explained by others)
 - when a menu / toolbar is changed by an extension, this change also is
 migrated to new installed version
  - plus: possible changes in the menu/toolbar from that new version
  are normaly visible 

So if I understand the problem correct, the summary should be something as
"Customization of menu / toolbar prevents visibility of possible change on this
menu/toolbar in new installed version".

@mechtilde: is the summary as I suggested
  http://qa.openoffice.org/issues/show_bug.cgi?id=101513#desc14
a correct description of your problem?

Cor wrote:
- when a menu / toolbar is changed by an extension, this change also is
 migrated to new installed version
  - plus: possible changes in the menu/toolbar from that new version
  are normaly visible 

After installing extensions with menu entries, we havew the problem that the new
entries by the new version are *in*visible

Yes i think your suggstion is right.

Also if this isn't a new propblem, now it affects many many users because more
and more users are using one or more extensions. Then they don't get the new
functions of the newer version.

@mechtilde:  when your problem is
  after installing extensions with menu entries, that are defined in 
  the Addons.xcu from the extensions package (oxt), that is installed in the 
  user configuration path, the new menu entries (if any) by a new version of
  OpenOffice.org are *in*visible ..
then this is *not* the situation I described!
If so, I can check with installing m51 over m50.

cornouws wrote "If so, I can check with installing m51 over m50"
Of course I can't. I'll have to check with verions that I know give new menu
entries. 

a workaround can possibly be done with the informations under 
http://wiki.services.openoffice.org/wiki/Framework/Article/Addon_Menu_Toolbar_Merging

> After installing extensions with menu entries, we havew the problem that the
> new entries by the new version are *in*visible

Mechtilde, can you give examples for such extensions? Actually, menu entries
added by extensions should *not* make the new entries added by the new OOo
version disappear.

cd: There is no specification for this issue. Therefore I have to shift this to
the next release.

cd: Fixed by Wu Yan from CS2C.

cd->wuyan: Thanks for your work, Yan.

cd: Added link to the specification.

cd->of: Please verify.

cd.>mav: Please verify.

Verified in uimigration01 cws, the test configuration was merged successfully.