Hi,
I believe there is a usability flaw in Geany - opened documents' list is saved only if you exit the editor in 'traditional' way (by clicking exit button or so). It's completely lost, if the process's killed. This was irritating for me, as I tend not to close every program when shutting down, but rather push the 'shutdown' button and get them all killed - and get the list of opened documents lost. I believe I'm not the only one saving time on this, moreover, if your system hangs, you loose this list as well.
Anyway, this wasn't hard to fix - just calling *configuration_save() *upon opening or closing a file. Operation itself seems to be cheap (although it's rewriting a config completely, as I see) - noticed no performance issues on my 1 GB RAM netbook.
Sent you a pull request on GitHub.
On Tue, 10 Jul 2012 01:41:46 +0300 Axel apeka1990@gmail.com wrote:
I believe there is a usability flaw in Geany - opened documents' list is saved only if you exit the editor in 'traditional' way (by clicking exit button or so). It's completely lost, if the process's killed. This was irritating for me, as I tend not to close every program when shutting down, but rather push the 'shutdown' button and get them all killed - and get the list of opened documents lost.
There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too.
Anyway, this wasn't hard to fix - just calling *configuration_save()* upon opening or closing a file.
You can have any number of primary and secondary Geany instances open. With simply calling configuration save, on restart you'll get *some* file list... If that list is from a secondary (-i) instance, it'll likely only contain a file or two, and you would be better with the list from the last normal Quit.
(not 'you' personally, I mean any user)
Operation itself seems to be cheap (although it's rewriting a config completely, as I see) - noticed no performance issues on my 1 GB RAM netbook.
It's cheap if your config directory (a) is local and (b) resides on a hard drive or SSD. That's OK for the majority of users, but not all.
(N.B. I'm not a leading developer, so the decision will not be mine.)
You can have any number of primary and secondary Geany instances open. With simply calling configuration save, on restart you'll get *some* file list...
Wait, wait. That's a *competely* different problem. You *can't* allow users to have multiple instances of application which all write to one config file.
If that list is from a secondary (-i) instance, it'll likely only contain a file or two, and you would be better with the list from the last normal Quit
Well, it's a flaw - in the end, it's not much "better" or "worse". How you can call Geany an IDE if it looses all the open files in all instances but the last closed one? Either it's a more like a code editor (i.e. Notepad++ - limited to one instance) or it's like a serious IDE (i.e. VS or Eclipse), which, AFAIK store the separate file list for each project.
Anyway, I don't understand how anything can be a stopper to fixing an * obvious* usability flaw. If it worsens usability for some rare users, it would make sense to implement an option to turn it off. But I see no reasons, why majority should suffer.
On Tue, 10 Jul 2012 23:09:42 +0300 Axel apeka1990@gmail.com wrote:
You can have any number of primary and secondary Geany instances open. With simply calling configuration save, on restart you'll get *some* file list...
Wait, wait. That's a *competely* different problem. You *can't* allow users to have multiple instances of application which all write to one config file.
We had several long discussions on this problem, with no conclusion reached. Try "multiply instances" in the mailing list archives.
If that list is from a secondary (-i) instance, it'll likely only contain a file or two, and you would be better with the list from the last normal Quit
Well, it's a flaw - in the end, it's not much "better" or "worse". How you can call Geany an IDE if it looses all the open files in all instances but the last closed one? Either it's a more like a code editor (i.e. Notepad++
- limited to one instance) or it's like a serious IDE (i.e. VS or Eclipse),
which, AFAIK store the separate file list for each project.
Geany stores separate file list for each project if you quit it normally, or even for each running instance with session management.
A list autosave on open/close should check if a project is open and save accordingly, which the patch does not do. It also seems to save the list even if the open dialog is canceled.
On 12-07-10 11:20 AM, Dimitar Zhekov wrote:
On Tue, 10 Jul 2012 01:41:46 +0300 Axel apeka1990@gmail.com wrote:
I believe there is a usability flaw in Geany - opened documents' list is saved only if you exit the editor in 'traditional' way (by clicking exit button or so). It's completely lost, if the process's killed. This was irritating for me, as I tend not to close every program when shutting down, but rather push the 'shutdown' button and get them all killed - and get the list of opened documents lost.
There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too.
So it only works in KDE and Unity? (and maybe TWM :)
Shouldn't bugs be filed against these projects (if not done yet) if they don't support the standard X/Linux session management? AFAIK they all claim to try and support the various standards floating around out there. I have no clue about SM, but it seems crazy that it cannot be done. There must be apps out there that work properly cross-desktop, maybe we can copy them?
P.S. When logging out/shutting down, what order does it handle Geany instances in? Does it always make sure the first opened instance is the last to get handled so that you don't clobber the open files list for it and stuff?
Cheers, Matthew Brush
On Tue, 10 Jul 2012 14:55:30 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On Tue, 10 Jul 2012 21:20:55 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too.
So it only works in KDE and Unity? (and maybe TWM :)
KDE4 has prefect XSMP support, KDE3 was pretty good, don't know about Unity. Xfce is OK if you don't have unsaved files.
Shouldn't bugs be filed against these projects (if not done yet) if they don't support the standard X/Linux session management?
https://bugzilla.xfce.org/show_bug.cgi?id=5379. The latest Xfce has problems even with a single probram asking whether to save a modified file, so I had to disable that part.
AFAIK they all claim to try and support the various standards floating around out there.
As of the GNOME guys, they had a lousy support for the legacy (X11R5) session support, dropped it AFAIK, and then deprecated XSMP in favour their own session protocol in 2.24. Don't know about GNOME3.
Funny thing, considering that the small Xfce has full support for the legacy protocol, and it's even supported by gtk+ - for example that's how Devhelp or Firefox are restarted on login.
I have no clue about SM, but it seems crazy that it cannot be done. There must be apps out there that work properly cross-desktop, maybe we can copy them?
gedit has the same problems with Xfce. Aside from the kde applications, there are very few programs with full xsmp support.
P.S. When logging out/shutting down, what order does it handle Geany instances in? Does it always make sure the first opened instance is the last to get handled so that you don't clobber the open files list for it and stuff?
In no partilular order. Each instance saves it's own file list and preferences in a separate .conf file, based on the instance xsmp ID. Neither geany.conf nor the project files are saved - it works as if you suspend/resume or hybernate/restore (with some exceptions).
You can of course do an Edit -> Preferences -> OK or Project -> Properties -> OK, that'll save geany.conf or the project file respectively. You can do that even after logout/login.
--
On Tue, 10 Jul 2012 21:59:35 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
I pushed it to a "sm" branch[1] on the git repo just now. I haven't really tested it much but it builds and runs fine after a very trivial fix of the Makefile (and wscript) files.
Yes, that's the part that normally breaks.
It might get more usage/testing/experimenting in a branch on the main repository compared to the sf.net tracker.
That may well be. Though while Geany was on svn, the patches were marked with the svn release number, and thus very easy to apply, and there were two or three svn-marked versions on the ML even before that...
The last notable changes were done two years ago. After that it's only tweaking for specific SM-s, "more strict" xsmp support, which didn't help (sigh), and updates various Geany changes.
On 12-07-10 11:20 AM, Dimitar Zhekov wrote:
On Tue, 10 Jul 2012 01:41:46 +0300 Axel apeka1990@gmail.com wrote:
I believe there is a usability flaw in Geany - opened documents' list is saved only if you exit the editor in 'traditional' way (by clicking exit button or so). It's completely lost, if the process's killed. This was irritating for me, as I tend not to close every program when shutting down, but rather push the 'shutdown' button and get them all killed - and get the list of opened documents lost.
There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too.
I pushed it to a "sm" branch[1] on the git repo just now. I haven't really tested it much but it builds and runs fine after a very trivial fix of the Makefile (and wscript) files.
It might get more usage/testing/experimenting in a branch on the main repository compared to the sf.net tracker.
Cheers, Matthew Brush