https://bugs.freedesktop.org/show_bug.cgi?id=69217
--- Comment #6 from Lionel Elie Mamane <[email protected]> --- (In reply to comment #5) > (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 No clue what change there is: that is correct, but that is nearly always the case, even with changes to the document itself. The only exception I can think of is Writer documents with "change tracking" enabled. In all other situations, there is no clue what changed in the document, whether the changes are in Basic code or in the "main" document itself. Basically, my observation is equating the Basic IDE with a dialog of Writer or Calc. E.g. if one opens a Calc window, and then goes to Tools / Options / LibreOffice Calc / Calculate and then changes the choice of "Date" from 12/30/1899 to 01/01/1904", then press OK. The document just had an "invisible" change. Same if I go to "Format / Page" and change something there. In the mental model I propose, the Basic IDE serves the same function as these dialogs. >>>> 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). No, sorry, I expressed myself incorrectly. What I meant is that there should be one nag per non-document Basic module. E.g. if there are unsaved changes in "My Macros/Standard/Module1" and in "My Macros/Standard/Foo" and in "bar.odt/Standard/qux", then on closing the Basic IDE, there should be *two* nags: one for "My Macros/Standard/Module1" and one for "My Macros/Standard/Foo", but none for "bar.odt/Standard/qux". If that is structurally hard/impossible with the way Basic code is organised in LibreOffice, then one nag per library (attached to "My Macros" or to "LibreOffice macros") or even a global nag for "My Macros" (if any pending change) and one global nag for "LibreOffice macros" (if any pending change) would be OK. > Ideally one should be prompted only if basic has been changed Yes, obviously. > and also save from the IDE should just save/commit just the basic storage. OK, this is another proposition, namely * on closing the Basic IDE, there is one nag for each (changed module of each library of each) document with changed Basic, *and* one nag per (changed module of each library of each) "My Macros" and "LibreOffice macros". * in this nag (and when saving from Basic IDE in general), "save" saves only the Basic code, not the other changes in the document. This scenario, taken as a whole, makes sense. Dunno if it can be implemented reasonably easily. >>> 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 ) There is a three-level structure: - level 1: document or "My Macros" or "LibreOffice Macros" - level 2: library, e.g. "Standard" - level 3: module, e.g. "Module1" I wrote "level 3", but meant "level 2", yes. Because the IDE shows the multiple level 3 containers (objects?) as tabs. >> 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 Yes, but then you have a more clear mental model. E.g. you can close just one subwindow, and then... what happens? You get (if unsaved changes) a nag for just the module opened in that subwindow? Then *clearly* if you close the IDE you should get a nag for *every* opened subwindow that has unsaved changes. Another example of clearer mental model: if you are editing a module and want to "switch" to another one, you can either: - close the subwindow for the first module and open a new window for the second module - just open a second subwindow for the second module These are not the same operations, and it is "expected" that one does not get the same "want to save?" nags in these two different operations. But because the current IDE's approach makes it impossible to edit Library2/module2 without "removing" Library1/module1 from view, I think that nagging for save of module1 when switching to Library2 is too onerous. Actually, now that I think of it, a working mental model for the current IDE is that its unique window is "two level tabs". One level to choose a library (the "Current Library" listbox widget), and then one level to choose the module (the tabs at bottom of the screen). This maps to the more familiar "multiple (sub)windows" world by saying that as long as the IDE is open, *all* modules of *all* libraries are opened (in their own subwindow). And then it makes sense to get a nag (only) when closing the IDE (or the document container), because that's when the "subwindow/tab" gets closed (disappears). >> 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. I see one specific time: when closing the IDE. >> 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. To close *this* bug without going into a big redesign of how the IDE works: * Basic in document: one nag on closing the document, if anything in the document changed (document itself or Basic code or both). This nag already exists. * Basic in application / user store: nag on closing the IDE. I would like to get one nag for each changed module, but one nag per library or failing that one nag for application and one nag for user would be OK. This nag is missing. > 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 Yes, that would be an acceptable mitigation, but then they *must* be written out to disk "often", not only when closing the IDE or (worse!) when closing the whole LibreOffice process. This would lead to data loss on crashes! I don't like it much (because no way to say "throw away all changes I made since last save", which is something I like to use) but would be working. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
