Reassigned.

set to new and change the target

It's the same issue like issue 48458.
Deleting unused masterpager should correspond to the settings in 'Format / Slide
Design'
I don't know if you already started fixing the other issue, therefore please set
one of this both bugs to duplicate of the other.
Thanks.

Due to resource constraints I set the target to OOo Later.

*** Issue 58449 has been marked as a duplicate of this issue. ***

*** Issue 48458 has been marked as a duplicate of this issue. ***

*** Issue 67896 has been marked as a duplicate of this issue. ***

*** Issue 68765 has been marked as a duplicate of this issue. ***

*** Issue 76546 has been marked as a duplicate of this issue. ***

This is now a very long known and annoying bug.

Will it be fixed in one of the next releases? I think the target should be OOo 2.3.

Users who are new to OpenOffice.org Impress and start working will be very
confused when they loose their master slides.

@ka,af: given on the count of votes and the number of duplicates, please review
this issue.

Could this bug be targeted for OOo 2.4?

I think loosing your master slides is some kind of data loss. I use Impress for
a lecture and having a set of master slides in every lecture-set is a
"must-have". So please target this for 2.4.

I agree that deleting user edited master slides should not be deleted so easy.

But we should keep in mind that if a user just clicks through all the available
templates so see how they look, the user should not have all the loaded master
slides in his document after that.

Maybe it is possible to detect that the unused master slide has user added
content and was not just loaded from a template without any further modification?

BTW: Isn't there a workaround by using the context menu?

There is a "normal" menu, in which an operation can be started, that unused
master slides are deleted. But it doesn't matter if this option is set or not,
the slides will be deleted after saving and reopening.

The slides are also sometimes deleted while working.

Is there already a snapshot available where this bug is fixed (a 2.4 Preview)?

Changed target due to time constraints.

Many duplicates, many votes ... it would be very nice to have this fixed in OOo
3.0. I have lost master-design slides in some presentations because of this bug.
If you use OOo for Lectures this is a really time-consuming bug.

Over three years after initial report and the problem is still not solved.  This
is data loss, plain and simple.  I would like some word on whether or not this
will be fixed in 3.0.  It seems like any data loss issues should be of extremely
high priority.  I have a very hard time recommending people switch from
PowerPoint to Impress if I also have to explain the hoops they need to go
through to ensure that their master slides don't get lost.

Couldn't agree more - I have a hard time convincing myself to make such a switch
- and have now tended to end up still using Powerpoint on my work laptop until I
consider Impress safe enough for anything I remotely care about.

You are both right, this bug IS DATA LOSS.

It means: Someone creates templates for presentations and they are worth nothing
because nearly all master slides are lost. This is really a problem.

I am using OpenOffice.org for lectures and it is not possible to create simple
templates because of this issue.

I agree. This has to be fixed in 3.0

Any news for this issue?

Will this bug be fixed in OOo 3.0 beta so that the people can test whether
data-loss still occurs?

Hi,

Beta 3.0 is planned for April 30
(http://wiki.services.openoffice.org/wiki/OOoRelease30)

I just tested in snapshot 300m9, and the fix is not yet in that build, as you
can find out yourself. So obviously the integration will be later.

This bug also triggers a crash in 3.0 beta as follows:

1. Create a blank presentation with normal settings.
2. View->Slide Master, New Master.
3. Close Master View.
4. Click "Master Pages" on right-hand side, and click "Default 1" (the one on
the right). The old "Default" master will disappear.
5. View->Slide Master, New Master. The "Default" master reappears in the list.
6. Click on the "Default" master on the left.
7. Right click on the title box, change the font color, click OK. 

Result: Crash.

Note that if you change the "Default" master style before making it disappear,
the reborn "Default" page will have those style changes after doing New Master
in step 5. Apparently the master pages remain somewhere in memory and are reused
by New Master somehow.

Will the issue be fixed before Beta 2 release? It would be nice to test a
version of OpenOffice.org in where a patch for this issue is applied.

I have to change the target to OOo3.1 because there still is no good concept
which master pages to keep and which master pages to delete.

Simply keeping all master pages is no good solution: if for example a user
clicks on all entries in the list of predefined master pages ("Available for
Use") to see if they look good with his content, then there would be a huge
number of unused, and in this case unwanted, master pages in his document.

Hi af,
Do I understand correct, that there is some conflict, or maybe merge of what
looks as two containers from the users perspective: the master slides that are
part of the template/document, and the master slides shown in "Available for
Use" in the Tasks pane. Is that the core of this problem?

Hi cor,

the problem is that the user who works with master pages expects not to loose
his master pages by default. On the other hand the user that does not know about
master pages and just 'clicks through the available presets' will end with
documents that contain a lot of unused master pages. We introduced the current
default in StarOffice 5 because we got lots and lots of customers complaining
about huge document sizes that where caused by master pages that where not used.

The tricky part is to detect which master pages should be removed and which
should not...

Thanks Christian,

Could ik be possible to distinct between:
a. master slides only present in the active document and/or that are present the
template it is based on (thus belonging to that document or the template)
b. other master slides.

I think it is safe to keep group a. in the presentation.

The dialog "Slide design" offers the possibility to delete unused master slides
(should work in that manner, anyway).
And maybe, as suggested by someone else, deleting a single masterslide could be
possible via the context menu in the dialog "Slide design". But then we talk
about a RFE, and just solving the current bug would be great of course.

I still don't know what the difficulty is.  I agree with cornouws that there are
at least two types of master slides: those that are in the present document, and
those that could be used.  There are a third type as well, and those are the
ones that the user creates or modifies herself/himself.  It's this third type
that _should not be deleted automatically under any circumstances_.  How hard is
it, as a partial fix, to just mark any changed master slide as ineligible for
deletion?  And how hard is it to cycle through the slides in the document to
determine which masters are being used on which slides, and then mark those as
ones not to remove?  Not knowing the internals of the program, I don't know, but
programatically it seems fairly straightforward.

Just as I mentioned before, this bug continues to prevent me from being
comfortable with recommending OpenOffice to other users.  Until the bug is
fixed, I'm going to be unable to do so.

Hello,

without knowing the source code of OpenOffice.org I can imagine that this
problem may not be easy to solve. The solution to have all slide masters
(templates which the user selected temporarily) in the presentation is not
really a solution.

I think it is a big problem that OOo cannot disinguish between master slides
created by the user and master slides which were only short time selected from
templates.

This bug was encountered before the 2.0 release (about 3 years ago). The bug
leads to data loss and to a behaviour that a normal user cannot understand.

In order to use OOo as a professional presentation program, this bug has to be
fixed.

I think the open-source community always has good arguments for using
open-source. One is that important bugs are recognised and fixed very soon.

In my opinion this bug should be set to P1 or P2 since it is really a
release-critical bug which has to be fixed for 3.0.

Are there other opinions refering to this bug and its priority?

*** Issue 91667 has been marked as a duplicate of this issue. ***

cor@cl: what do you think of my comment from Thu Jun 26 2008, trying to find a
solution?

This issue:

- causes data loss
- has many duplicates
- has 25 votes
- and is still treated as a "P3" bug?

I think this issue has to be adressed as soon as possible.

Many new users will probably try OpenOffice.org 3.0 and if this data loss
happens, they will loose their trust in an alterative Office Suite.

Seems to be a blocker for 3.0.1 for me.

We have to solve two problems in order to fix this bug:

1. Detect changes to master pages.

Doing this reliably is not so simple, especially when it comes to changes caused
by API calls.  Many changes to single shapes are not notified to general
listeners: there is more than one implementation of XPropertySet which has no
support for property change listeners.  Maybe we can use the flag that the whole
document has been modified but in itself it is too unspecific.


2. Make the modification flag of master pages persistent.

Now this really is a problem.  We can not just add some flag to the ODF file
format.  Maybe we could hack it into some other value (like the name of the
modified master page).  But maybe it is enough to not store that flag at all.
Just mark all master pages that are read from file as (potentially) modified and
'precious' and delete them only on explicit request from the user.


So, yes, I agree that this is an ugly bug.  However, it has no pretty fix.

If I find the time I will investigate the problem of change detection further.

Comments and help are welcome.

Hi André,

Thanks for your comment, which I now try to understand ;-)
You write that it is needed to detect changes to master pages. I cannot link
that to the problem, that master pages are removed if they are not used. Both
changed and unchanged master pages, not in use, are removed.

On Thu Jun 26 2008 I made the suggestion: keep all masterpages that are in use
plus the ones that come from the template of the document.
This is of course not perfect, because if no tempate can be found, masterpages
still can go lost. And I have no idea how easy it is to detect the template (it
works in Writer however).

Thinking in another direction: could it be possible to offer the user a choice.
On saving the document, if there are unused masterpages? 
For example aks : 
= = =
There are one or more unused masterpages in the document. They can be saved in
the document, which makes the file larger, or can be deleted.
You may also delete single masterpages from the context menu in the dialog Slide
design.
 [keep] [delete] [cancel]
= = =

?
Cor

I think that the master pages to keep are those that have been modified by the
user.  Everything else, especially unmodified master pages from templates, can
be re-created easily.  Loosing your own changes is the problem, even when these
master pages are not currently in use.

So, in order to automatically and silently delete a master page we have to be
able to detect a given master page that 
a) it originated from a template (otherwise it very likely has been created by
the user and therefore must not be deleted) and that
b) it was not modified.

I think that a) can be solved by checking the layout name of the master page and
comparing that to the list of known templates.

One solution for b) is to wait for notifications of modifications.  I you get
one for a master page that comes from a template, then mark that master page as
precious.

Master pages that do not come from templates are marked as precious right away.
Precious master pages are then deleted only on explicit user request.

Regarding the dialog: well, I don't like it.  Such a dialog basically says that
the developers were not able to come up with a technical solution and therefore
have to bother the user to make that decision.  I am not yet willing to accept
that we can not come up with a solution that is good enough  :-)

OK with the idea for the solution... if it works ;)

About  a) checking the layout name of the master page and comparing that to the
list of known templates. This can be tricky, since you can expect more
masterpages with the same name in different templates.
Or do you mean: comparing the name of the masterpage with the ones in the
associated template.

On b) this means that there is the problem of how to detect all changes. And if
I understand your comment from Oct. 13 well, that is very hard.

A dialog ... it has advantages as well: 
 - it gives users a choice
 some might prefer larger documents over re-loading masterpages later on
 (don't forget that since SO 5, disk and memory size have grown a lot!)
 - it is easy to implement, especially because a technical solution is
  both complicated and will probably always be imperfect, due to causes
  out of developers scope
 - is is faster to implement, so dataloss is prevented sooner ...

I just read cournows dialog idea.

Maybe there is the possibility to show a dialog only when there are more than x
(unused) masterslides in the document. 

The dialog could be something like "There are a lot of masterslides in the
document. Maybe you should check if they are all needed".

This could also happen as a tool-tip. The bulb could appear in the corner.

Is this an option? Better is a clean solution. But I think a dialog in the next
OOo version is better than dataloss.

Although finding a "correct" way to solve this issue would be good, i think that
an immediate temporary fix preventing the worst is in urgent need. As suggested
in my initial report, even a simple Warning dialog - raised before the deletion
of all those user-created designs - should avoid the incredibly frustrating
experience of having one lose all his work just by having single clicked on some
panel icon. Among new users, few would realize quick enough that office actually
did delete their work, and would immediately press Ctrl-Z - They'll learn it the
hard way.

I would definitely support the idea of a short-term solution like a popup.
This make Impress virtually unusable, if have to use a non-OO (e.g.
employer-CI-conform template).

Maybe another "fast-solution" is to add an option which can be set for master
slides. Something like "Keep this slide". So that the user can define
masterslides as "must-have" slides.
I think the market leader of presentation programs has an option like this.

When the user wants to close an presentation in which OOo would remove some
master slides, there could be a dialog "Impress will remove unused master
slides. Please check if you checked all you "must-have" masterslides.

I know that this is no perfect solution. But it is much better than loosing the
slides.

I have now a working fix that is not perfect but maybe good enough.  I would
like to know if there are any objections against it.

Here are the details:
-Add a flag, which I called "precious" to SdPage to mark master pages which must
not be deleted automatically.  By default this flag is on.

-Master pages that come from template documents are marked as not precious so
that they (well, their copies in the current document) can be deleted automatically.

-When a master page is modified in any way (well in any way that makes the
document send a SFX_HINT_DOCCHANGED) it is marked as precious and thus is
protected from automatic deletion.

-The precious flag is only temporary.  That means that all master pages of a
document loaded from a file are marked as precious, even the ones that originate
from a template document and are unmodified.

-In order to be able to delete unused master pages that are marked as precious,
the context menu of the "Used in This Presentation" panel is extended by a
"Delete Master" entry.  It is active only for unused master pages regardless of
the precious flag.  Oh, and it deletes the master page for which the context
menu is opened.


Consequences:
-Master pages loaded from a file are not deleted automatically.

-Master pages that are modified are not deleted automatically.

-When you click through the available master pages only the last one remains in
the document.  Other master pages from templates are deleted (until the document
is saved, of course).

>  I would like to know if there are any objections against it.

Do you also like to know if I'm happy with it ;-)
Looks really good IMO.

Only one question. The description 
> -The precious flag is only temporary.  That means that all master pages 
> of a document loaded from a file are marked as precious, even the 
> ones that originate from a template document and are unmodified.
does not sound logic to me.
Maybe I must understand "That means that ... are marked as ..."
as "Thus ... can (and will) be marked as ..."

Thanks!

@cornouws: Yes, your words are better than mine.

Let me try to make it more clear.  The precious flag is temporary because of
pragmatic reasons.  Storing it in the document would require a file format
change, which is not possible on such a short notice.  Maybe we can do that later.

So, when a document is loaded we don't know which master pages should be marked
as precious.  To be on the safe side, all loaded master pages are marked as
precious.  

The negative side of this is that after saving and reloading of a document,
unmodified templates are not removed automatically when they become unused. 
However, I regard this as a minor drawback.  Additionally, after some time the
user may forget that a master page originates from a template.  Deleting it
automatically may then still be unexpected.

Commited my changes.  The modified behavior is:

Unused master pages are not deleted when
a) they are loaded from a document or
b) they have been modified since creation.

Context menu of the "Used in This Presentation" task pane control has new entry
"Delete Master" (only displayed when master page is not in use by any slide.)

Modified files are:
sd\inc\drawdoc.hxx
sd\inc\sdpage.hxx
sd\sdi\TaskPaneViewShell.sdi
sd\source\core\drawdoc.cxx
sd\source\core\drawdoc3.cxx
sd\source\core\sdpage.cxx
sd\source\ui\app\popup.src
sd\source\ui\func\fuinsfil.cxx
sd\source\ui\inc\res_bmp.hrc
sd\source\ui\toolpanel\controls\CurrentMasterPagesSelector.cxx
sd\source\ui\toolpanel\controls\CurrentMasterPagesSelector.hxx
sd\source\ui\toolpanel\controls\DocumentHelper.cxx
sd\source\ui\toolpanel\controls\MasterPageContainerFiller.cxx
sd\source\ui\toolpanel\controls\MasterPageContainerProviders.cxx
sd\source\ui\toolpanel\controls\MasterPageContainerQueue.cxx
sd\source\ui\toolpanel\controls\MasterPageDescriptor.cxx
sd\source\ui\toolpanel\controls\MasterPageDescriptor.hxx
sd\source\ui\toolpanel\controls\MasterPagesSelector.cxx
sd\source\ui\toolpanel\controls\MasterPagesSelector.hxx
sd\source\ui\toolpanel\controls\RecentlyUsedMasterPages.cxx

SVN revision is 265206.

@andré: thanks for the explanation and the 'fix' (change of the old feature ;-) )
I think I can speak on behalf of the others when I say that it looks really good!

@WG: Please verify.

Verified in sjfixes10.

Tested in DEV300_m15. Closed.