hello,
this is my first post so I'd like to thank all programmers working on geany. it is so close to perfect :) thanks!
I keep my ~/.config/geany dir under git so I can distribute my environment prefs on all machines I use. unfortunately there are some config entries which always collide since they are "local" to the current machine. those are:
[geany] geometry
[files] all-of-them-...
I modified keyfile.c to keep all those in separated (session/local) file so it can be excluded from git.
diff/patch is against commit 1ce4b1fac516f89dadb639cb773c76b68cfa286b
I'd like to ask for a review of the patch?
thank you and good luck!
Vladi.
Le 28/07/2012 17:16, Vladi Belperchinov-Shabanski a écrit :
hello,
Hi!
this is my first post so I'd like to thank all programmers working on geany. it is so close to perfect :) thanks!
Welcome here then, and thanks a lot :)
I keep my ~/.config/geany dir under git so I can distribute my environment prefs on all machines I use. unfortunately there are some config entries which always collide since they are "local" to the current machine. those are:
[geany] geometry
[files] all-of-them-...
I modified keyfile.c to keep all those in separated (session/local) file so it can be excluded from git.
I understand your concern, but do splitting this into two files have any other benefit than making it simpler to keep it in Git? Moreover, one could imagine to commit to git only the relevant parts of the file (git add -p & friends). OK, it's a bit tedious but shouldn't be required that often, is it?
My concern is that this adds a new config file, and particularly *moves* some settings around. This leads to the need to maintain compatibility code to load from one file or the other, which is always boring an ugly.
So, I'm not sure such a change is really wanted if it only addresses configuration spreading, that could even arguably be done with a fresh config file/by stripping uninteresting parts.
However, maybe splitting "session" things out might help towards a better support for saving multiple instance configurations, and if we see that such changes would help on that subject too, the noise might be worth. Dimitar, Eugene, Nick, Matthew, Lex..., thoughts?
diff/patch is against commit 1ce4b1fac516f89dadb639cb773c76b68cfa286b
I'd like to ask for a review of the patch?
Apart what I said above, the patch looks very clean but:
* we use tabs for indent (width set to 4), not 2 spaces * as said above, you need to add backward compatibility code, to load the prefs to the old file as a fallback.
Best regards, Colomban
[...]
However, maybe splitting "session" things out might help towards a better support for saving multiple instance configurations, and if we see that such changes would help on that subject too, the noise might be worth. Dimitar, Eugene, Nick, Matthew, Lex..., thoughts?
Hi Colomban,
A few random thoughts in no particular order:
1. Committing the project files can be useful since they contain build commands, indent settings and other stuff that is useful to share. User config files I am less convinced about in this use case. The OP could probably get most of what he wants by using a project file in git with "save sessions in project files" off. An improvement would be to have that setting also be in the project file so each project remembers what was set last time.
2. If the session is removed from the project file then where to store it? I would vote for a subdir of the user config dir perhaps with a (user settable) limit on how many. That way each user remembers which files they had open in that project.
3. Multiple instances would not benefit from having user session info saved separately unless we also switched to saving the remaining config immediately it was changed, not at shutdown. Then there would not be any race for the config file at shutdown. Without session management, multiple instances of course don't save their sessions, since they have no way of finding them again. Although this doesn't address accessing the same file from multiple instances it is a step in the right direction to making multiple instances safer but saving config immediately is a significant change (I think).
4. I have completely ignored session management since I am back on a DE where it doesn't work :) That is the problem with session management, it only works on some DEs and how well it works varies. So I think we should keep Dimitars patch available for as long as he cares to maintain it so individual users can add it if they want, but the variability makes it inappropriate to commit to Geany. Perhaps a link from the wiki to the patch tracker would be useful?
To summarise (in roughly increasing order of difficulty):
a. the OP use project files with sessions off b. the sessions off setting duplicated in the project files c. sessions removed from project files d. User config files saved on change and sessions saved on shutdown by non -i instances. e. Session management nirvana (unlikely :)
Cheers Lex
diff/patch is against commit 1ce4b1fac516f89dadb639cb773c76b68cfa286b
I'd like to ask for a review of the patch?
Apart what I said above, the patch looks very clean but:
- we use tabs for indent (width set to 4), not 2 spaces
- as said above, you need to add backward compatibility code, to load
the prefs to the old file as a fallback.
Best regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 2 Aug 2012 10:57:22 +1000 Lex Trotman elextr@gmail.com wrote:
- Multiple instances would not benefit from having user session info
saved separately unless we also switched to saving the remaining config immediately it was changed, not at shutdown.
View -> Show Message Window -> save configuration, Search -> Find -> save configuration... hmmm.
- I have completely ignored session management since I am back on a
DE where it doesn't work :) That is the problem with session management, it only works on some DEs and how well it works varies.
Indeed. On that note, I'm happy to inform all Xfce users that the long standing bug with asking for unsaved files on logout was fixed. It doesn't seem like any dev noted, so I'll have to ring a few bells, and hopefully get it for the next release.
So I think we should keep Dimitars patch available for as long as he cares to maintain it so individual users can add it if they want, but the variability makes it inappropriate to commit to Geany.
Pretty much infinitely, Geany without sm would be a big downgrade to me. I'm not going to support the git branch though, and it's already out of date.
On 12-08-03 10:05 AM, Dimitar Zhekov wrote:
On Thu, 2 Aug 2012 10:57:22 +1000 Lex Trotman elextr@gmail.com wrote:
So I think we should keep Dimitars patch available for as long as he cares to maintain it so individual users can add it if they want, but the variability makes it inappropriate to commit to Geany.
If the changes were properly guarded out and disabled by default at compile-time, I see no reason not to merge the patch into master. I haven't really reviewed the changes in detail though. IMO, the patch tracker on sf.net is barely a step up from being local to Dimitar's hard-drive in terms of exposure and usefulness to general users.
Pretty much infinitely, Geany without sm would be a big downgrade to me. I'm not going to support the git branch though, and it's already out of date.
I don't mind keeping the Git branch up to date if it helps keep some exposure on this useful patch, but it seems I don't get emails when the patch tracker is updated, so I dunno. I'm "Monitoring" the patch tracker but apparently I wasn't "Watching" it, so maybe now I'll get emails when there's updates now that I'm "Watching" it (unless I also have to "Like" it or "Friend" it or something). Of course if you want me to take the Git branch down instead, I can do that too.
Cheers, Matthew Brush
On 4 August 2012 10:21, Matthew Brush mbrush@codebrainz.ca wrote:
On 12-08-03 10:05 AM, Dimitar Zhekov wrote:
On Thu, 2 Aug 2012 10:57:22 +1000 Lex Trotman elextr@gmail.com wrote:
So I think we should keep Dimitars patch available for as long as he cares to maintain it so individual users can add it if they want, but the variability makes it inappropriate to commit to Geany.
If the changes were properly guarded out and disabled by default at compile-time, I see no reason not to merge the patch into master. I haven't
My problem isn't so much with the patch, it worked fine last time I had a working DE. Although it probably should be broken into a few commits to separate some of the "preparatory" changes from the actual SM stuff. My concern is rather with the maintenance issues if it is in git master. Unfortunately I expect lots of "I turned it on for <some DE> and it didn't work but <firefox, gedit, etc> does, fix it waaa waaa waaa" if we did that.
really reviewed the changes in detail though. IMO, the patch tracker on sf.net is barely a step up from being local to Dimitar's hard-drive in terms of exposure and usefulness to general users.
Yes agree that the patch tracker isn't ideal, it probably should be a git branch that Dimitar can maintain and then it is more visible without increasing his workload.
Pretty much infinitely, Geany without sm would be a big downgrade to me. I'm not going to support the git branch though, and it's already out of date.
I thought the Git branch was Eugenes and he already said it could be removed??
If my memory is right, then removing it and applying the patch to a "new_sm" branch would be the way to go.
I don't mind keeping the Git branch up to date if it helps keep some exposure on this useful patch, but it seems I don't get emails when the patch tracker is updated, so I dunno. I'm "Monitoring" the patch tracker but apparently I wasn't "Watching" it, so maybe now I'll get emails when there's updates now that I'm "Watching" it (unless I also have to "Like" it or "Friend" it or something). Of course if you want me to take the Git branch down instead, I can do that too.
Its SF, you have to stand on one leg, spin around three times while the wind is in the southwest and sprinkle pixie dust, easy :)
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 12-08-03 05:58 PM, Lex Trotman wrote:
I thought the Git branch was Eugenes and he already said it could be removed??
See below.
If my memory is right, then removing it and applying the patch to a "new_sm" branch would be the way to go.
I pushed the libsm patch from the patch tracker to a new Git branch[1] a couple weeks ago or so, expecting to be getting emails from sf.net when the patch tracker was updated to queue me to apply the latest patch to the Git branch.
IMO, it makes more sense to maintain it as a branch (or merging into the master branch) in the Git repository, even thought the patch tracker item is meticulously well documented/commented/updated. If Dimitar doesn't mind working on the Git repo instead of keeping a sf.net patch tracker item up to date, I'd be +1 for that.
Cheers, Matthew Brush
[1] https://github.com/geany/geany/commit/0f07b31aa866f92dcbaf29659ead7beab60a1d...
On 4 August 2012 11:14, Matthew Brush mbrush@codebrainz.ca wrote:
On 12-08-03 05:58 PM, Lex Trotman wrote:
I thought the Git branch was Eugenes and he already said it could be removed??
See below.
If my memory is right, then removing it and applying the patch to a "new_sm" branch would be the way to go.
I pushed the libsm patch from the patch tracker to a new Git branch[1] a couple weeks ago or so, expecting to be getting emails from sf.net when the patch tracker was updated to queue me to apply the latest patch to the Git branch.
IMO, it makes more sense to maintain it as a branch (or merging into the master branch) in the Git repository, even thought the patch tracker item is meticulously well documented/commented/updated. If Dimitar doesn't mind working on the Git repo instead of keeping a sf.net patch tracker item up to date, I'd be +1 for that.
Ah, missed that one :)
So totally agree, Dimitar should be given rights to maintain this instead of the patch if he wants to.
Cheers Lex
Cheers, Matthew Brush
[1] https://github.com/geany/geany/commit/0f07b31aa866f92dcbaf29659ead7beab60a1d...
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 4 Aug 2012 10:58:54 +1000 Lex Trotman elextr@gmail.com wrote:
My problem isn't so much with the patch, it worked fine last time I had a working DE. [...] I expect lots of "I turned it on for <some DE> and it didn't work but <firefox, gedit, etc> does, fix it waaa waaa waaa" if we did that.
As a gtk+ application, Geany uses the legacy (X11R5) session protocol, yet we are not receiving such messages. But of course, given the xsmp support sutuation, your concern has merit.
Thanks to Eugene's initial implementation, the SM functionality can be en/disabled with --enable-libsm=yes|no in configure or autogen. So I changed the default to "no" in the latest patch (2012-08-07).
--
On Fri, 03 Aug 2012 18:14:40 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
If Dimitar doesn't mind working on the Git repo instead of keeping a sf.net patch tracker item up to date, I'd be +1 for that.
On Sat, 4 Aug 2012 11:47:55 +1000 Lex Trotman elextr@gmail.com wrote:
So totally agree, Dimitar should be given rights to maintain this instead of the patch if he wants to.
That would have been very useful while while Eugene, and later me, were developing the patch. But there are very little changes in the latest two years, I have 3 other patches in the tracker, and another 3 on my machine for a plugin I'm writing... So it's easier for me to regenerate all of them in the same way, and keep their previous version(s) as .diff files, instead of dealing N branches. I changed the latest tracker patches to .git to format though.
On Sat, 28 Jul 2012 18:16:03 +0300 Vladi Belperchinov-Shabanski cade@bis.bg wrote:
I keep my ~/.config/geany dir under git so I can distribute my environment prefs on all machines I use. unfortunately there are some config entries which always collide since they are "local" to the current machine. [...]
If you are using Geany under *nix, with a GUI that supports sessions (kde, xfce, maybe gnome), you can do the following:
1. Patch geany for x11 session management - see the patch tracker.
2. Don't Quit it, but logout (shutdown, restart) instead. The sm will save your configuration in a separate .conf file.
3. Using Quit, or Edit -> Preferences -> OK / Apply, will save your current settings in geany.conf - including the "local" ones.
Hope this can be somewhat useful to you.
--
On Mon, 30 Jul 2012 18:12:29 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
However, maybe splitting "session" things out might help towards a better support for saving multiple instance configurations, and if we see that such changes would help on that subject too, the noise might be worth. Dimitar, Eugene, Nick, Matthew, Lex..., thoughts?
The sm patch supports any number of separate instances, each with it's own configuration.
Putting more settings into the project files will help - that's their raison d'etre in the first place.
As of multiply instances that share their configuration to some(?) extent, we had this discussion at least twice, and could not reach a conclusion.
hi,
On Mon Jul 30 16:12:29 UTC 2012, Colomban Wendling wrote
Le 28/07/2012 17:16, Vladi Belperchinov-Shabanski a ?crit :
I keep my ~/.config/geany dir under git so I can distribute my environment prefs on all machines I use. unfortunately there are some config entries which always collide since they are "local" to the
current machine. those are:
[geany] geometry
[files] all-of-them-...
I modified keyfile.c to keep all those in separated (session/local) file so it can be excluded from git.
I understand your concern, but do splitting this into two files have any other benefit than making it simpler to keep it in Git? Moreover, one could imagine to commit to git only the relevant parts of the file (git add -p & friends). OK, it's a bit tedious but shouldn't be required that often, is it?
My concern is that this adds a new config file, and particularly *moves* some settings around. This leads to the need to maintain compatibility code to load from one file or the other, which is always boring an ugly.
Actually I'm no trying to move settings/config to several files but to separate history/status data. You would agree that open files list and geometry are local to the current machine (work locations, monitor sizes, etc.)?
However, maybe splitting "session" things out might help towards a better support for saving multiple instance configurations, and if we see that such changes would help on that subject too, the noise might be worth. Dimitar, Eugene, Nick, Matthew, Lex..., thoughts?
Well, I'm not sure about this :/ also not sure how this would affect "projects" since I do not use them yet. Comments from more developers are welcome :) thanks!
diff/patch is against commit 1ce4b1fac516f89dadb639cb773c76b68cfa286b
I'd like to ask for a review of the patch?
Apart what I said above, the patch looks very clean but:
- we use tabs for indent (width set to 4), not 2 spaces
yes, point taken, sorry :/ :)
- as said above, you need to add backward compatibility code, to load
the prefs to the old file as a fallback.
I'd prefer not to add such code unless it goes away in few (1-2) revisions in the future. If not backward compatible, the only problem will be lost geometry (i.e. using default) and no open files. And this will be only one time problem :)
Best regards, Colomban
----------------------------------
On Mon Jul 30 17:10:24 UTC 2012, Dimitar Zhekov wrote:
On Sat, 28 Jul 2012 18:16:03 +0300 Vladi Belperchinov-Shabanski <cade at bis.bg> wrote:
I keep my ~/.config/geany dir under git so I can distribute my environment prefs on all machines I use. unfortunately there are some config entries which always collide since they are "local" to the current machine. [...]
If you are using Geany under *nix, with a GUI that supports sessions (kde, xfce, maybe gnome), you can do the following:
I use only IceWM and I'd prefer not to add another dependancy (unless it also depends on x11 sm, not aware, sorry.)
Patch geany for x11 session management - see the patch tracker.
Don't Quit it, but logout (shutdown, restart) instead. The sm will
save your configuration in a separate .conf file.
- Using Quit, or Edit -> Preferences -> OK / Apply, will save your
current settings in geany.conf - including the "local" ones.
Hope this can be somewhat useful to you.
Have to check :) thanks.
...
E-gards: Jimmy
P! Vladi.