https://bugs.freedesktop.org/show_bug.cgi?id=69217
--- Comment #5 from Noel Power <nopo...@novell.com> --- (In reply to comment #4) > > Yes, but there is still a window that shows the document, so there is a > continuous link. The basic code is not *shown*, but that's similar to a > change to an unused Writer document style: no effect on screen, but still > it is a change to the document and the document is on an existing window. I don't buy that, you have no clue what change is in the document, just that there is *some* unsaved modification to the document model > > >> My preference would be that the nag for application basic should happen > >> when closing the IDE, because that's the equivalent of closing a document. > > > If you mean closing the IDE ( when no documents exist ) then it is similar, > > if you mean closing the IDE normally then... e.g. consider you have changes > > to application basic but then switch the IDE to view some document basic ( > > and perhaps even have some other documents open ) and *then* close the IDE, > > do you nag then > > Yes. > > > ( and only point to application basic having chaged? or > > enumerate and prompt for each document > > Enumerate and prompt for each. As I think about it more IMO it would be more annoying to be prompted to save each document that has it's modified state set when dismissing the IDE ( if that is really what you are suggesting). Ideally one should be prompted only if basic has been changed and also save from the IDE should just save/commit just the basic storage. I have no idea why that isn't the way it works or if there are practical reasons why it doesn't work that way > > > or... should you perhaps nag when you > > switch the IDE view from application to document. > > The Basic IDE has this "weakness" or let's say "difference to the rest > of LibreOffice" that it uses a unique window, and thus this window > switches one module to the other. you mean switching between library container(s) ( be that a document or some application area ) > > For better consistency, we could change the IDE to have a window > per opened module. By "window", I don't necessarily mean "full top-level > OS-level window", but it could be a "subwindow", that is a window that > is shown within the IDE top-level window. perhaps I don't understand exactly what you mean, I don't see how it makes a difference, you still could be closing the ide with multiple ( subwindows ) open > > But that's a bigger work. In the meantime, we have to (imperfectly) > map the concepts of the usual "one window per document unit" world > to the IDE's unique window. I think the main problem is the state of the basic in the longer living containers ( e.g. share/user ) that are active for the lifetime of the application, That is the one the doesn't map easily to raising a nag at a specific time. > > It could make sense to nag for save when switching from one module > (or dialog) to another, by mapping that action to > "close window, open new window" > in the one-window-per-unit world. > But IMO, this would be too impractical for the user. > > > Either way I think it gets > > annoying/confusing for the user, there needs to be some reasonable and > > consistent behaviour but... I have no clue :-) > > I think my preference is the most reasonable and consistent > that can be achieved with the current "IDE is exactly one window". I'm afraid I've lost track now exactly what your preference is, I don't have a problem with a nag dialog but as yet I don't fully see what nag ( and the content you would see ) under which circumstances you would be presented with for various scenarios of application and/or open document(s) with/without modified basic. Another possibility in the mean time would be to disable the save button when an application container is selected in the IDE ( and preserve the behaviour where changes to basic are sticky for those containers ) at least that would be consistent -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
