ALG: When two impress open both in master view mode, D&D from one masterpage to the other in SlideSorter (left) is not allowed. D&D to the page view (edit view) is allowed and crashes. Half-confirmed...?

> ... drag onto the (master) slide in the editing area ...

> ... SlideSorter (left) is not allowed. D&D to the page view (edit view) is allowed and crashes. Half-confirmed...?

Why 'half'? Sounds like exactly what I see.

Recent snapshots, as well as LibO, all crash.

The crash is bad enough, but I've yet to find a way to copy a master slide from one presentation to another. Copy to clipboard is disabled in master view; D&D looked promising, but ... agggh, down in flames.

It seems that in order to use a master slide in more than one presentation, you have to create the master in a (registered) template.

ALG: 'half' because dragging from master to master in slidesorters is grayed out -> probably should be like that.
I understand your frustration, I also could not identify another way for exchange. Adding awf to cc.

@awf: Is there a better way to get one masterpage to another document?
Also looked at the crash: in sd/source/core/drawdoc3.cxx SdDrawDocument::SetMasterPage line 1741 ff all needed is there: the source document, the target document. The masterpage to move is removed from the source document and added to the target document (what crashes the source document - i the masterpage was used there). Wouldn't all work when cloning the masrrepage there and insert in target document? Does it make sense at all to migrate an existing masterpage between documents like the code tries to do currently (it's another SdrModel!) ?

At the moment master pages should be able to be copied or even moved.  There is no general reason that prevents this but this functionality has not yet been reliably implemented.

ALG: Currently the MasterPages (and NotesMasterPages) get moved, no checks if used in source document or not. At insertion in the new model, a SetModel() at the SdrPage adapts the model. Using something like

        if (pSourceDoc != this)
        {
            SdPage* pNewNotesMaster = dynamic_cast< SdPage* >(pNotesMaster->Clone(this));
            SdPage* pNewMaster = dynamic_cast< SdPage* >(pMaster->Clone(this));

            if(!pNewNotesMaster || !pNewMaster)
            {
                delete pNewNotesMaster;
                delete pNewMaster;
                OSL_ASSERT("SdDrawDocument::SetMasterPage() cloning of MasterPage/NoteAmsterPage failed!" );
                return;
            }

            pNotesMaster = pNewNotesMaster;
            pMaster = pNewMaster;
        }

in line 1607 already adds a clone of the source pages, but assigning the SlideLayout to a new slide in the SlideDesign dialog does not work. Save/Reload works well, though, and the new MasterPage is shown in the SlideDesign dialog properly, also editable in MasterPage view mode. Hmmm..

ALG: Assigning the new does not work because it has the same name as the old one (in a simple example). Thus, renaming has to be added, adaption of StyleSheets has to be adapted, and so on. Too much for now.

ALG: Grepping as reminder.

Created attachment 80750 [details]
Patch with code so far

ALG: Adding changes so far, not stable yet but a starting pint.

ALG: tried to find a simple minimal-invasive solution to avoid the crash, but found none. Removal of the source MasterPages is no option, this will crash the source document. Insertion in target document works for some moments, but it will crash when the source document gets closed (since the pages still are owned by that model and get destroyed). Thus - pragmatically seen - it is better to adapt the last details on the code I already did. Adapted some more of the StyleSheet mapping/recreation. Checked it, it works well, I can copy MasterPages back and forth between documents. Doing some more tests...

ALG: Okay, looks good. Checked many cases, including load/save copying back and forth, using, deleting. Anyways, it originally was a crash, cannot get more bad (in theory...).

ALG: During experimenting I found out that D&D between SlideSorters (left of doc or SlideSorter view) *does* copy the MasterPage with the page when there exists not yet a MasterPage in the target document with the name of the source MasterPage (else that one is assumed equal and used). To test:
- Create two impress
- on second, view/master/SlideMaster
- Use RenameMaster in MasterView Toolbar
- CloseMaster, back to Normal or SlideSorter
- D&D to SlideSorter of first document
->Master gets copied with the page.

Besides that, my fix avoids the crash now and also copies the MasterPage(s) (HandoutMasterPage, too) and can be used the same way. Preparing checkin...

ALG: Okay, done.

"alg" committed SVN revision 1488195 into trunk:
i121863 Corrected D&D from MasterPage view, source SlideSorter, target 2nd Do...

> ALG: During experimenting I found out that D&D between SlideSorters (left of
> doc or SlideSorter view) *does* copy the MasterPage with the page when there 
> exists not yet a MasterPage in the target document with the name of the source 
> MasterPage (else that one is assumed equal and used).

Oh ... ouch.

Thanks so much for looking into this--sorry it turned out to be a goose chase.

I was completely fooled and never thought to change the master name, but it works just as you described.

This is a really counter-intuitive design, particularly for the master named "Default", but that's a different issue.

Thanks again!

ALG: Joe, you are right and I agree (as you see I did not know from mind either). Maybe you should write an enhancement request (e.g. not only use the name, but compare MasterPage content before deciding to use the existing one). Maybe you even have a better idea, be creatiove ;-)

Testing
AOO400m3(Build:9702)  -  Rev. 1502185
2013-07-11 08:22:42 (Thu, 11 Jul 2013) - Linux i686
on Fedora 17

Trying to verify fix; I find that I can't test it because the slide master view keeps switching back to normal editing view as the mouse enters the window.

I'm running sloppy focus-follows-mouse; that may have something to do with it.

Nope, same thing in click-to-focus: the window keeps leaving master view and switching back to normal.

Bug or feature? ;-)

(In reply to Joe Smith from comment #16)
> Trying to verify fix; I find that I can't test it because the slide master
> view keeps switching back to normal editing view as the mouse enters the
> window.
> 
> I'm running sloppy focus-follows-mouse; that may have something to do with
> it.
> 
> Nope, same thing in click-to-focus: the window keeps leaving master view and
> switching back to normal.
> 
> Bug or feature? ;-)

Is this what you are seeing?:

a) File > New > Presentation > Create (all defaults)
b) View > Master > Slide Master
c) repeat (a) and (b) to create a second Impress document
d) set the focus on the first document by simply touching the window title bar. Bug: switches to normal view
e) set the focus on the second document. Bug: switches to normal view too

(In reply to Ariel Constenla-Haile from comment #17)
> Is this what you are seeing?:
> 
> a) File > New > Presentation > Create (all defaults)
> b) View > Master > Slide Master
> c) repeat (a) and (b) to create a second Impress document
> d) set the focus on the first document by simply touching the window title
> bar. Bug: switches to normal view
> e) set the focus on the second document. Bug: switches to normal view too

The bug does not happen if the presentation is the only AOO document, and you switch to another application.

It is reproducible if you have more than one AOO document:

a) new Impress document
b) switch to Slide Master view
c) new Writer document
d) go back to the Impress document Bug: the document switches from Slide Master view to Normal view

(In reply to Ariel Constenla-Haile from comment #18)
> It is reproducible if you have more than one AOO document:
> 
> a) new Impress document
> b) switch to Slide Master view
> c) new Writer document
> d) go back to the Impress document Bug: the document switches from Slide
> Master view to Normal view

@Andre: might be related to changes in revision 1486578 for bug 122332

@Ariel: I can not reproduce the bug you described with the changes from bug 123276 applied.  Maybe this has been fixed, too.

But the drag and drop of master pages between documents is an independent problem.  And one, where the solution, as far as I know, is not well defined.  Something we should do before fixing it.