| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #3318
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | FLUID |
|---|
| Summary: | fluid: options for how to handle external editors on fluid quit |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | greg.ercolano |
|---|
| Fix Version: | 1.3.4 (SVN: v11879) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | greg.ercolano
13:13 Jul 17, 2016 |
| The new 'external editor' feature added in r11816
currently terminates any editors fluid opened during fluid quit.
There is the situation where the user, while in an external editor
opened by fluid, might open another file and edit it, but leave
the changes unsaved on quitting fluid.
There perhaps isn't a "standard" way for the parent fluid process
to tell its child editor process to close on quit that works
across platforms.. the desire would be to allow triggering the
usual "Do you want to save" dialog in the editor for such situations.
This was all brought up in STR #3213, Comments #33-38. Albrecht wrote:
* * *
There is only one issue I'd like to have documented VERY clearly
because it _could_ do harm: reaping the editor process(es) when
FLTK exits may cause data loss if the user opens another file
and edits that file in an editor instance started by fluid.
This may be done after closing the fluid temp file or in an
editor with tabs even while editing the temp (code) file.
Hence, AFAICT, reaping the editor(s) when the fluid window is closed
can really be dangerous. [..]
* * *
Options might be:
o Tell the open child editors to quit 'nicely' and wait for the
processes to quit. This seems possible in Windows by sending WIN_CLOSE
events to the windows, which is what we currently do. But we also
send a TerminateProcess if the process hasn't died after a few fractions
of a second, which is the 'hard kill'. Can possibly skip that and just
keep waiting until the editor is closed. Not sure if under Unix sending
SIGTERM is sufficient to do this.
o Allow options in the "GUI Settings" for how to handle closing open
editors:
a) Force close unconditionally (current behavior)
b) Prompt user editors are open, and wait for user to close them.
c) Leave the editors open and just exit, removing any temp files
There's drawbacks to (a) and (c), with (b) being perhaps the best compromise,
albeit noisy (a dialog would have to be posted indicating fluid is waiting for
the user to close the open editors)
Perhaps (b) could be the only behavior, or at least the default if options
are made available. | |
| |
| #2 | greg.ercolano
19:15 Jul 21, 2016 |
| Suggesting the attached patch, str3318_v1.patch.
Instead of killing open editors, it pops a dialog suggesting
the user close the editors, and to hit the "Closed" button,
which re-checks to make sure the editor really was closed.
A second option, "Force Close", lets the user choose to force
the editor closed. | |
| |
| #3 | greg.ercolano
13:43 Aug 16, 2016 |
| Applied str3318_v1.patch as 11878.
This fix is Unix only though -- a Windows equivalent of the v1 patch
is needed to close this out. | |
| |
| #4 | greg.ercolano
14:09 Aug 16, 2016 |
| Fixed in Subversion repository.
Attaching and committing str3318_win32_v1.patch,
which solves this STR for the windows platform. | |
[ Return to Bugs & Features ]
|
| |
