Hi all, I'm using GNOME with several workspaces, and there's a behaviour I find quite annoying: if you have an instance of Geany running in a workspace and you open a file in another workspace, it just opens the file in the already running instance and switches you back to the workspace. I know this is more a usability issue at the desktop environment level than Geany in particular, since it is the same for other programs such as web browsers, but may be Geany could address it ?
Anyway, I wrote a little wrapper script that detects if there's no Geany window in the current workspace, in which case it forces creating one: https://github.com/nicoulaj/dotfiles/blob/master/bin/geany It was only tested on GNOME but should work as well on other desktop environments.
-- Julien
Dnia sobota, 22 stycznia 2011 o 22:49:47 Julien Nicoulaud napisał(a):
Hi all, I'm using GNOME with several workspaces, and there's a behaviour I find quite annoying: if you have an instance of Geany running in a workspace and you open a file in another workspace, it just opens the file in the already running instance and switches you back to the workspace. I know this is more a usability issue at the desktop environment level than Geany in particular, since it is the same for other programs such as web browsers, but may be Geany could address it ?
Anyway, I wrote a little wrapper script that detects if there's no Geany window in the current workspace, in which case it forces creating one: https://github.com/nicoulaj/dotfiles/blob/master/bin/geany It was only tested on GNOME but should work as well on other desktop environments.
There are four ways to go here.
1. Leave things as it is because Geany is an IDE, so if a file needs to be sent to Geany, it is probably good to show other developer tools as well. 2. Move Geany to the active desktop. 3. Share Geany with the active desktop. 4. Start a separate Geany environment.
I do not see any obvious preference to any of these options.
Chris
Well, from the peanut gallery, to me there's an obvious preference--number 4--it should start a new instance in the current workspace. For now it doesn't affect me, because until I get a lexer for askRhk, I'm only experimenting with Geany. But, once I start using Geany as my default editor, I'd expect to have at least one instance in every workspace (desktop) that I'm using, and files that I open in the workspace should open in the instance of Geany in that workspace.
Randy Kramer
On Saturday 22 January 2011 05:11:39 pm Krzysztof Żelechowski wrote:
Dnia sobota, 22 stycznia 2011 o 22:49:47 Julien Nicoulaud napisał(a):
Hi all, I'm using GNOME with several workspaces, and there's a behaviour I find quite annoying: if you have an instance of Geany running in a workspace and you open a file in another workspace, it just opens the file in the already running instance and switches you back to the workspace. I know this is more a usability issue at the desktop environment level than Geany in particular, since it is the same for other programs such as web browsers, but may be Geany could address it ?
Anyway, I wrote a little wrapper script that detects if there's no Geany window in the current workspace, in which case it forces creating one: https://github.com/nicoulaj/dotfiles/blob/master/bin/geany It was only tested on GNOME but should work as well on other desktop environments.
There are four ways to go here.
- Leave things as it is because Geany is an IDE, so if a file
needs to be sent to Geany, it is probably good to show other developer tools as well. 2. Move Geany to the active desktop. 3. Share Geany with the active desktop. 4. Start a separate Geany environment.
I do not see any obvious preference to any of these options.
Chris _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
2011/1/23 Randy Kramer rhkramer@gmail.com:
Well, from the peanut gallery, to me there's an obvious preference--number 4--it should start a new instance in the current workspace. For now it doesn't affect me, because until I get a lexer for askRhk, I'm only experimenting with Geany. But, once I start using Geany as my default editor, I'd expect to have at least one instance in every workspace (desktop) that I'm using, and files that I open in the workspace should open in the instance of Geany in that workspace.
Randy Kramer
On Saturday 22 January 2011 05:11:39 pm Krzysztof Żelechowski wrote:
Dnia sobota, 22 stycznia 2011 o 22:49:47 Julien Nicoulaud napisał(a):
Hi all, I'm using GNOME with several workspaces, and there's a behaviour I find quite annoying: if you have an instance of Geany running in a workspace and you open a file in another workspace, it just opens the file in the already running instance and switches you back to the workspace. I know this is more a usability issue at the desktop environment level than Geany in particular, since it is the same for other programs such as web browsers, but may be Geany could address it ?
Anyway, I wrote a little wrapper script that detects if there's no Geany window in the current workspace, in which case it forces creating one: https://github.com/nicoulaj/dotfiles/blob/master/bin/geany It was only tested on GNOME but should work as well on other desktop environments.
There are four ways to go here.
1. Leave things as it is because Geany is an IDE, so if a file needs to be sent to Geany, it is probably good to show other developer tools as well. 2. Move Geany to the active desktop. 3. Share Geany with the active desktop. 4. Start a separate Geany environment.
I do not see any obvious preference to any of these options.
Chris
Hi All,
There are two issues that I see which complicate potential solutions here.
1. There is not AFAIK any common portable way to find out which workspace Geany is running in and that a request to show a file in Geany came from a different workspace, so deciding to run another instance or move Geany to another workspace is going to have to be solved for each system Geany runs on. This is probably why many applications are not workspace aware.
2. Issues around running multiple instances of Geany have not yet been finalised despite significant passionate debate on several past threads. This means that there are problems manually running multiple instances, let alone automatically running them. Some of the issues are:
a. who owns the preferences? preventing multiple instances from changing preferences is very limiting, if they can all change them, who saves their set when Geany terminates? and how to lock them irrespective of the filesystem they reside on to prevent scrambled preferences?
b. how do you restart multiple instances? which leads to session management being required, but Geany has two potential implementations of that and no clear path forward yet
c. the same issues relating to preferences apply to project files being used by more than one instance, or if a project can be open in only one instance how to enforce that?
d. and of course these also apply to the same document file being open in multiple instances, at logout/shutdown who's copy gets saved? how do you detect the fact so you can at least warn the user? remember that locking and the like don't work on remote filesystems.
3. It is (I think) a big change to allow Geany to have one instance with multiple top level windows, how to handle different projects in different top levels? how to handle different preferences in different top levels?
So AFAICT there is no clear solution.
My personal choice would be 3 because it would then also support multiple monitor setups, but I believe that there is a lot of usage issues to resolve and a LOT of work involved.
Any good ideas welcome.
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Sun, 23 Jan 2011 13:07:31 +1100 Lex Trotman elextr@gmail.com wrote:
a. who owns the preferences? preventing multiple instances from changing preferences is very limiting, if they can all change them, who saves their set when Geany terminates? and how to lock them irrespective of the filesystem they reside on to prevent scrambled preferences?
Windows: the instances are stopped one by one. The last one wins. X11: the session management supports instances.
b. how do you restart multiple instances? which leads to session management being required, but Geany has two potential implementations of that and no clear path forward yet
It has a complete sm for the current single-instance behaviour, and an incomplete multi-instance sm for the non-implemented multi-instance behaviour. So the real question is, do we plan to introduce any multi instancing in Geany in the foreseeable future? If not, the last single-instance sm applies against 5530, and is quite stable.
c. the same issues relating to preferences apply to project files being used by more than one instance, or if a project can be open in only one instance how to enforce that?
The same answer as for a. and b.
d. and of course these also apply to the same document file being open in multiple instances, at logout/shutdown who's copy gets saved? how do you detect the fact so you can at least warn the user? remember that locking and the like don't work on remote filesystems.
Both Windows and X11-sm will ask you for any modified files.
(In the current implementation, both simply terminate.)
Thanks for the infos and script Dimitar !
2011/1/23 Dimitar Zhekov dimitar.zhekov@gmail.com
On Sun, 23 Jan 2011 13:07:31 +1100 Lex Trotman elextr@gmail.com wrote:
a. who owns the preferences? preventing multiple instances from changing preferences is very limiting, if they can all change them, who saves their set when Geany terminates? and how to lock them irrespective of the filesystem they reside on to prevent scrambled preferences?
Why not save preferences right when closing the preferences dialog ? That's what I would except as a lambda user.
Windows: the instances are stopped one by one. The last one wins. X11: the session management supports instances.
b. how do you restart multiple instances? which leads to session management being required, but Geany has two potential implementations of that and no clear path forward yet
It has a complete sm for the current single-instance behaviour, and an incomplete multi-instance sm for the non-implemented multi-instance behaviour. So the real question is, do we plan to introduce any multi instancing in Geany in the foreseeable future? If not, the last single-instance sm applies against 5530, and is quite stable.
c. the same issues relating to preferences apply to project files being used by more than one instance, or if a project can be open in only one instance how to enforce that?
The same answer as for a. and b.
d. and of course these also apply to the same document file being open in multiple instances, at logout/shutdown who's copy gets saved? how do you detect the fact so you can at least warn the user? remember that locking and the like don't work on remote filesystems.
Both Windows and X11-sm will ask you for any modified files.
(In the current implementation, both simply terminate.)
-- E-gards: Jimmy _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 24 January 2011 01:53, Julien Nicoulaud julien.nicoulaud@gmail.com wrote:
Thanks for the infos and script Dimitar !
2011/1/23 Dimitar Zhekov dimitar.zhekov@gmail.com
On Sun, 23 Jan 2011 13:07:31 +1100 Lex Trotman elextr@gmail.com wrote:
a. who owns the preferences? preventing multiple instances from changing preferences is very limiting, if they can all change them, who saves their set when Geany terminates? and how to lock them irrespective of the filesystem they reside on to prevent scrambled preferences?
Why not save preferences right when closing the preferences dialog ? That's what I would except as a lambda user.
Hi,
Unfortunately the "preferences" includes things that are not set in the prefs dialog, eg screen layout recent files etc. Writing this stuff whenever it changes would mean constantly writing the prefs file and in the absence of locking (which is not available for all file systems) would increase the chances that two instances would try to write it at the same time.
And then there is project session stuff, again writing it all the time is risky, writing it at the end is a who wins problem.
Cheers Lex
PS The prefs file currently also includes some session stuff but I'm assuming that gets moved when session support is added, but the project session stuff can't be
Windows: the instances are stopped one by one. The last one wins. X11: the session management supports instances.
b. how do you restart multiple instances? which leads to session management being required, but Geany has two potential implementations of that and no clear path forward yet
It has a complete sm for the current single-instance behaviour, and an incomplete multi-instance sm for the non-implemented multi-instance behaviour. So the real question is, do we plan to introduce any multi instancing in Geany in the foreseeable future? If not, the last single-instance sm applies against 5530, and is quite stable.
c. the same issues relating to preferences apply to project files being used by more than one instance, or if a project can be open in only one instance how to enforce that?
The same answer as for a. and b.
d. and of course these also apply to the same document file being open in multiple instances, at logout/shutdown who's copy gets saved? how do you detect the fact so you can at least warn the user? remember that locking and the like don't work on remote filesystems.
Both Windows and X11-sm will ask you for any modified files.
(In the current implementation, both simply terminate.)
-- E-gards: Jimmy _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Hiya,
On 24 January 2011 01:35, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 23 Jan 2011 13:07:31 +1100 Lex Trotman elextr@gmail.com wrote:
a. who owns the preferences? preventing multiple instances from changing preferences is very limiting, if they can all change them, who saves their set when Geany terminates? and how to lock them irrespective of the filesystem they reside on to prevent scrambled preferences?
Windows: the instances are stopped one by one. The last one wins.
Kinda arbitary :-)
X11: the session management supports instances.
So who decides who wins?
b. how do you restart multiple instances? which leads to session management being required, but Geany has two potential implementations of that and no clear path forward yet
It has a complete sm for the current single-instance behaviour, and an incomplete multi-instance sm for the non-implemented multi-instance behaviour. So the real question is, do we plan to introduce any multi instancing in Geany in the foreseeable future? If not, the last single-instance sm applies against 5530, and is quite stable.
I didn't realise that the single instance was working, now 0.20 is out maybe its worth prompting Nick, Enrico, Frank et al because it would be worthwhile adding the ability for Geany to close and re-open with the session.
The question of course was about multi instance, and as you say its still ...
c. the same issues relating to preferences apply to project files being used by more than one instance, or if a project can be open in only one instance how to enforce that?
The same answer as for a. and b.
There wasn't a user acceptable multi-instance answer in a or b.
d. and of course these also apply to the same document file being open in multiple instances, at logout/shutdown who's copy gets saved? how do you detect the fact so you can at least warn the user? remember that locking and the like don't work on remote filesystems.
Both Windows and X11-sm will ask you for any modified files.
(In the current implementation, both simply terminate.)
Making incorporation of the single instance sm patch even more worthwhile.
But that doesn't help the user to decide which of multiple instances is the correct one to save the prefs/project/file from.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Mon, 24 Jan 2011 11:22:33 +1100% Lex Trotman elextr@gmail.com wrote:
Hiya,
On 24 January 2011 01:35, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 23 Jan 2011 13:07:31 +1100 Lex Trotman elextr@gmail.com wrote:
a. who owns the preferences? preventing multiple instances from changing preferences is very limiting, if they can all change them, who saves their set when Geany terminates? and how to lock them irrespective of the filesystem they reside on to prevent scrambled preferences?
Windows: the instances are stopped one by one. The last one wins.
Kinda arbitary :-)
X11: the session management supports instances.
So who decides who wins?
b. how do you restart multiple instances? which leads to session management being required, but Geany has two potential implementations of that and no clear path forward yet
It has a complete sm for the current single-instance behaviour, and an incomplete multi-instance sm for the non-implemented multi-instance behaviour. So the real question is, do we plan to introduce any multi instancing in Geany in the foreseeable future? If not, the last single-instance sm applies against 5530, and is quite stable.
I didn't realise that the single instance was working, now 0.20 is out maybe its worth prompting Nick, Enrico, Frank et al because it would be worthwhile adding the ability for Geany to close and re-open with the session.
The question of course was about multi instance, and as you say its still ...
It will be fine if Dimitar's implementation is included in trunk. It is more "right" than mine. Moreover, it does not contain so much miscellaneous stuff unrelated to session management.
c. the same issues relating to preferences apply to project files being used by more than one instance, or if a project can be open in only one instance how to enforce that?
The same answer as for a. and b.
There wasn't a user acceptable multi-instance answer in a or b.
d. and of course these also apply to the same document file being open in multiple instances, at logout/shutdown who's copy gets saved? how do you detect the fact so you can at least warn the user? remember that locking and the like don't work on remote filesystems.
Both Windows and X11-sm will ask you for any modified files.
(In the current implementation, both simply terminate.)
Making incorporation of the single instance sm patch even more worthwhile.
But that doesn't help the user to decide which of multiple instances is the correct one to save the prefs/project/file from.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Mon, 24 Jan 2011 11:22:33 +1100 Lex Trotman elextr@gmail.com wrote:
X11: the session management supports instances.
So who decides who wins?
To answer both a and b, nobody wins. For the preferences and project files, the single instance sm works like hybernate-and-restore: each instance preserves it's own configuration, and neither geany.conf nor the project files are saved.
(For the document files it asks if to save, of course. XSMP suggests that a modified file may be saved into a temporary file, and then reloaded and remarked as modified, but I have yet to see a progam impementing THAT idea.)
It will be fine if Dimitar's implementation is included in trunk. It is more "right" than mine.
Thanks. :)
Moreover, it does not contain so much miscellaneous stuff unrelated to session management.
Actually none. Two extra patches are required, but one of them is shared with the various prefs editor, and the other is a cleanup.
On 25 January 2011 04:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 24 Jan 2011 11:22:33 +1100 Lex Trotman elextr@gmail.com wrote:
X11: the session management supports instances.
So who decides who wins?
To answer both a and b, nobody wins. For the preferences and project files, the single instance sm works like hybernate-and-restore: each instance preserves it's own configuration, and neither geany.conf nor the project files are saved.
Oh ok, its unchanged wins :-), ie thats what is left in the prefs/project files for use by any new instance started up. Or another way to look at it is the most recently closed Geany wins, assuming a user eventually closes one or more of the instances.
(For the document files it asks if to save, of course. XSMP suggests that a modified file may be saved into a temporary file, and then reloaded and remarked as modified, but I have yet to see a progam impementing THAT idea.)
For saving files, and to some extent projects, the problem is not the software, its the liveware behind the keyboard, an example scenario: I have f.txt open and modified in two instances (perhaps on different workspaces and I've forgotten about having two). At logout the session management makes Geany instance one pop-up a "save modified file f.txt?" box, I say yes/no, then instance two does the same and I get very confused about which one I want??!@#$%^&* I'm in a rush to logout and going to miss my bus home :-( Maybe the temporary file now and decide later has some merit!
BTW how does that dialog box identify the instance?
It will be fine if Dimitar's implementation is included in trunk. It is more "right" than mine.
Thanks. :)
Moreover, it does not contain so much miscellaneous stuff unrelated to session management.
Actually none. Two extra patches are required, but one of them is shared with the various prefs editor, and the other is a cleanup.
Might be a nice idea to post the required patch(s) again so Nick/Enrico don't have to search the archives
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Tue, 25 Jan 2011 10:12:05 +1100 Lex Trotman elextr@gmail.com wrote:
To answer both a and b, nobody wins. For the preferences and project files, the single instance sm works like hybernate-and-restore: each instance preserves it's own configuration, and neither geany.conf nor the project files are saved.
Oh ok, its unchanged wins :-), ie thats what is left in the prefs/project files for use by any new instance started up. Or another way to look at it is the most recently closed Geany wins, assuming a user eventually closes one or more of the instances.
I'm not sure what "unchanged wins" means, but as you know, the projects and settings in Geany are saved either when you edit them via the respective dialog and confirm, or when you close an instance. The single instance sm does not change that in any way - it's a session saver/restorer that adheres to Geany logic, not a solver for any for any multiply instance problems.
(For the document files it asks if to save, of course. XSMP suggests that a modified file may be saved into a temporary file, and then reloaded and remarked as modified, but I have yet to see a progam impementing THAT idea.)
For saving files, and to some extent projects, the problem is not the software, its the liveware behind the keyboard, an example scenario: I have f.txt open and modified in two instances (perhaps on different workspaces and I've forgotten about having two). At logout the session management makes Geany instance one pop-up a "save modified file f.txt?" box, I say yes/no, then instance two does the same [...]
KDE will switch you to the respective workspace if needed and raise the instance that requests interaction, IIRC.
GNOME will display the popup messages at once (again IIRC), you'll see the messages for the current workspace, and any other workspaces that need interaction will be "flashed" in the pager.
Xfce 4.6 does not work properly with 2+ programs that request interaction. You'll receive a popup for one of the instances, answer it, and then the logout will stop. When you manually close the 2nd and subsequent instances (Save and close, or Close and answer the save prompt), the logout will continue. Haven't checked Xfce 4.8.
(IMHO, if you modify a file in 2+ instances and close them one by one, you will get confused anyway. And that's a border case.)
BTW how does that dialog box identify the instance?
If you expect identification like "Geany-<number>" or something, it won't be really helpful. The right thing is to raise the top-level window of the application requesting XSMP iteraction. Normally that should be done by the window manager.
Might be a nice idea to post the required patch(s) again so Nick/Enrico don't have to search the archives
I still have no response for the "save find settions" patch from 3 days ago, so that seems pointless. The list really feels unresponsive. :(
On 26 January 2011 05:24, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 25 Jan 2011 10:12:05 +1100 Lex Trotman elextr@gmail.com wrote:
To answer both a and b, nobody wins. For the preferences and project files, the single instance sm works like hybernate-and-restore: each instance preserves it's own configuration, and neither geany.conf nor the project files are saved.
Oh ok, its unchanged wins :-), ie thats what is left in the prefs/project files for use by any new instance started up. Or another way to look at it is the most recently closed Geany wins, assuming a user eventually closes one or more of the instances.
I'm not sure what "unchanged wins" means, but as you know, the projects and settings in Geany are saved either when you edit them via the respective dialog and confirm, or when you close an instance. The single instance sm does not change that in any way - it's a session saver/restorer that adheres to Geany logic, not a solver for any for any multiply instance problems.
Sorry, should have been clearer, you have described it correctly and my point, as you say, is that it doesn't solve multiple instance issues (and is not expected to)
(For the document files it asks if to save, of course. XSMP suggests that a modified file may be saved into a temporary file, and then reloaded and remarked as modified, but I have yet to see a progam impementing THAT idea.)
For saving files, and to some extent projects, the problem is not the software, its the liveware behind the keyboard, an example scenario: I have f.txt open and modified in two instances (perhaps on different workspaces and I've forgotten about having two). At logout the session management makes Geany instance one pop-up a "save modified file f.txt?" box, I say yes/no, then instance two does the same [...]
KDE will switch you to the respective workspace if needed and raise the instance that requests interaction, IIRC.
GNOME will display the popup messages at once (again IIRC), you'll see the messages for the current workspace, and any other workspaces that need interaction will be "flashed" in the pager.
Xfce 4.6 does not work properly with 2+ programs that request interaction. You'll receive a popup for one of the instances, answer it, and then the logout will stop. When you manually close the 2nd and subsequent instances (Save and close, or Close and answer the save prompt), the logout will continue. Haven't checked Xfce 4.8.
Wow, don't you like consistency, pity there isn't any :-D
(IMHO, if you modify a file in 2+ instances and close them one by one, you will get confused anyway. And that's a border case.)
Yes, I'm not saying that you will do it deliberately (although some will try) but if its possible to accidently do it someone (me?) will.
BTW how does that dialog box identify the instance?
If you expect identification like "Geany-<number>" or something, it won't be really helpful.
Yeah thats why I asked.
The right thing is to raise the top-level
window of the application requesting XSMP iteraction. Normally that should be done by the window manager.
Sounds more useful
Might be a nice idea to post the required patch(s) again so Nick/Enrico don't have to search the archives
I still have no response for the "save find settions" patch from 3 days ago, so that seems pointless. The list really feels unresponsive. :(
As discussed elsewhere, there are only 2-3 people who maintain Geany and I suspect that they are having a break after releasing 0.20 and 0,20 plugins. I notice that no one has replied to the email where I suggested that more volunteers would be welcome if they have the time and discipline to assist.
Remember it takes at least half an hour per patch to get a clean trunk, apply the patch, test it, (assuming it works) check the formatting, write the changelog and commit so you need that sort of time.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Lex Trotman wrote:
There are two issues that I see which complicate potential solutions here.
- There is not AFAIK any common portable way to find out which
workspace Geany is running in and that a request to show a file in Geany came from a different workspace, so deciding to run another instance or move Geany to another workspace is going to have to be solved for each system Geany runs on. This is probably why many applications are not workspace aware.
Gedit does the right thing.
Erik
On 24 January 2011 09:18, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
There are two issues that I see which complicate potential solutions here.
- There is not AFAIK any common portable way to find out which
workspace Geany is running in and that a request to show a file in Geany came from a different workspace, so deciding to run another instance or move Geany to another workspace is going to have to be solved for each system Geany runs on. This is probably why many applications are not workspace aware.
Gedit does the right thing.
On MS Windows? On KDE? Portable is the problem, you can always write code for each platform and #if the correct set for the platform but thats much more work to write and maintain.
If Geany only had the number of programmer hours that Gedit does ...
Cheers Lex
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Lex Trotman wrote:
On MS Windows?
Windows doesn't have workspace, or rather it does, but 99.999999% of people don't use them. Even the vast majority of windows developers don't use them.
Contrast that with Linux where well over 90% of people use them. For developers, its very close to 100% that use workspaces.
On KDE?
Yes, I've tested this. I reported the results of that testing on the devel list.
If Geany only had the number of programmer hours that Gedit does ...
I've tried getting patches in. The development list was at best, slow to respond. Many of my patches were never responded to at all. And while I was following the devel list, I was not the only one being roundly ignored by the people with SVN commit access.
You can't complain about lack of developer hours and then keep development as an exclusive club for a small inner circle.
Erik
On 24 January 2011 11:32, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
On MS Windows?
Windows doesn't have workspace, or rather it does, but 99.999999% of people don't use them. Even the vast majority of windows developers don't use them.
Contrast that with Linux where well over 90% of people use them. For developers, its very close to 100% that use workspaces.
-1 me, but I do use two monitors instead :-)
I suspect your contention is a significant overstatement, but then neither of us actually has the statistics to prove it :-)
On KDE?
Yes, I've tested this. I reported the results of that testing on the devel list.
If Geany only had the number of programmer hours that Gedit does ...
I've tried getting patches in. The development list was at best, slow to respond. Many of my patches were never responded to at all. And while I was following the devel list, I was not the only one being roundly ignored by the people with SVN commit access.
You can't complain about lack of developer hours and then keep development as an exclusive club for a small inner circle.
Erik,
I'm sorry you feel that you were ignored.
Everyone in the Geany "inner circle" as you call it, only works on Geany in their own time, and they all have other things to do, they move house, they take holidays, their internet goes down (all happened in 2010)... So yes, response time can be variable, and busy people don't always read all the messages in a conversation etc, its the nature of a small project.
If you have constructive suggestions they will be welcome I'm sure, but remember that big changes of process or code will be difficult to have accepted due to the limited time people have to consider and understand the proposals, and to implement and test the changes, incremental change is the way to approach things when resources are thin.
As to Gedit, it has only one instance with multiple windows (my option 3) so many of the problems don't apply, but refactoring Geany to support multiple top levels is a big change.
Cheers Lex
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 24.01.2011 02:10, Lex Trotman wrote:
Erik,
I'm sorry you feel that you were ignored.
Everyone in the Geany "inner circle" as you call it, only works on Geany in their own time, and they all have other things to do, they move house, they take holidays, their internet goes down (all happened in 2010)... So yes, response time can be variable, and busy people don't always read all the messages in a conversation etc, its the nature of a small project.
If you have constructive suggestions they will be welcome I'm sure, but remember that big changes of process or code will be difficult to have accepted due to the limited time people have to consider and understand the proposals, and to implement and test the changes, incremental change is the way to approach things when resources are thin.
Increasing the number of core developers (i.e. giving more people commit access) can solve this problem. Geany isn't short of willing contributes.
Best regards.
Lex Trotman wrote:
Everyone in the Geany "inner circle" as you call it, only works on Geany in their own time, and they all have other things to do,
I'm well aware of how much time and energy an open source project can suck up. I'm the main maintainer of two widely used FOSS libraries, which i only work on in my own time.
they move house, they take holidays, their internet goes down (all happened in 2010)... So yes, response time can be variable, and busy people don't always read all the messages in a conversation etc, its the nature of a small project.
If you have constructive suggestions they will be welcome I'm sure, but remember that big changes of process or code will be difficult to have accepted due to the limited time people have to consider and understand the proposals, and to implement and test the changes, incremental change is the way to approach things when resources are thin.
I was not actually asking for more reponsiveness for the existing small set of developers, but rather an increase in the number of people with commit access.
As to Gedit, it has only one instance with multiple windows (my option 3) so many of the problems don't apply, but refactoring Geany to support multiple top levels is a big change.
Unfortunately, that statement, in conjunction with the above, is in effect saying "the project's inertia and lack of current progress means nothing much will change".
Erik
Eric & Thomas,
Don't get me wrong, I agree that Geany needs more people who can test format and commit patches and bugfixes and more people who can develop the more major changes we have talked about in branches. I think that Geany makes very little use of branches, even for a SVN project.
And yes the slow pace of change is frustrating (although I don't say this too often since my own lack of time to do much more than emails could prompt the obvious comeback :-D but I hope the emails are helpful in the meantime)
What it needs to get this going is some offers to be maintainers and maybe a maintenance/unstable branch so only critical fixes go directly in trunk and unstable gets promoted after suitable testing. This can allow commits to be checked by multiple people until the new commiters get practice (I know how easy it is to forget the commit log, or format wrong).
Also I believe that the project needs some planning and management for the bigger changes. Unless the change is purely experimental its not good to make major changes without planning and discussion, I refer to the session management changes as an example (without in any way criticising those who worked on them, they responded to concerns as they were raised, but would have had a better time if some of the problems had been addressed prior to implementation).
Whilst I am not suggesting anything near as formal as the PEP system used by Python, the general idea of having a written description of what the change is intended to do and how it is to be implemented helps the implementors get their ideas straight and might point out some of the potential pitfalls prior to starting. It also ensures that everyone has an idea of the extent of the changes so there will be less surprises of the "but I didn't expect it to do that" type.
Anyways I'll climb down off my soapbox now :-)
Cheers Lex
On 24 January 2011 14:06, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
Everyone in the Geany "inner circle" as you call it, only works on Geany in their own time, and they all have other things to do,
I'm well aware of how much time and energy an open source project can suck up. I'm the main maintainer of two widely used FOSS libraries, which i only work on in my own time.
they move house, they take holidays, their internet goes down (all happened in 2010)... So yes, response time can be variable, and busy people don't always read all the messages in a conversation etc, its the nature of a small project.
If you have constructive suggestions they will be welcome I'm sure, but remember that big changes of process or code will be difficult to have accepted due to the limited time people have to consider and understand the proposals, and to implement and test the changes, incremental change is the way to approach things when resources are thin.
I was not actually asking for more reponsiveness for the existing small set of developers, but rather an increase in the number of people with commit access.
As to Gedit, it has only one instance with multiple windows (my option 3) so many of the problems don't apply, but refactoring Geany to support multiple top levels is a big change.
Unfortunately, that statement, in conjunction with the above, is in effect saying "the project's inertia and lack of current progress means nothing much will change".
Erik
Erik de Castro Lopo http://www.mega-nerd.com/
On Saturday 22 January 2011 09:07:31 pm Lex Trotman wrote:
- It is (I think) a big change to allow Geany to have one instance
with multiple top level windows, how to handle different projects in different top levels? how to handle different preferences in different top levels?
So AFAICT there is no clear solution.
My personal choice would be 3 because it would then also support multiple monitor setups, but I believe that there is a lot of usage issues to resolve and a LOT of work involved.
Any good ideas welcome.
No good ideas, but I'll continue to express biased opinions ;-)
I'm not sure I fully understand your number 3, but if that means I can run only one instance of Geany (with multiple top level windows). I would be concerned.
It sounds like the way Iceweasel / Firefox is set up, at least as of version 3.0.6, which is what I'm using.
My problem with that is that if something happens to that one instance of Iceweasel (with several top level windows open on different desktops), I lose all the open pages. (For that reason, I continue to use konqueror as my primary web browser--there are pages for which doesn't work, but when one instance dies (hangs or crashes), I lose only the open pages on that instance.
(I feel this way despite the fact that Iceweasel allows me to easily reopen all those pages (and, I've finally (recently) learned how to do the same thing with konqueror in conjunction with a cron job...))
I don't expect Geany to hang / crash, but 11 years or so ago I was told that Linux never crashes, but I've managed to prove those people wrong (not intentionally, and to my detriment). .-)
Randy Kramer
On 24 January 2011 23:52, Randy Kramer rhkramer@gmail.com wrote:
On Saturday 22 January 2011 09:07:31 pm Lex Trotman wrote:
- It is (I think) a big change to allow Geany to have one instance
with multiple top level windows, how to handle different projects in different top levels? how to handle different preferences in different top levels?
So AFAICT there is no clear solution.
My personal choice would be 3 because it would then also support multiple monitor setups, but I believe that there is a lot of usage issues to resolve and a LOT of work involved.
Any good ideas welcome.
No good ideas, but I'll continue to express biased opinions ;-)
Every opinion is biased, except mine :-)
I'm not sure I fully understand your number 3, but if that means I can run only one instance of Geany (with multiple top level windows). I would be concerned.
It sounds like the way Iceweasel / Firefox is set up, at least as of version 3.0.6, which is what I'm using.
My problem with that is that if something happens to that one instance of Iceweasel (with several top level windows open on different desktops), I lose all the open pages. (For that reason, I continue to use konqueror as my primary web browser--there are pages for which doesn't work, but when one instance dies (hangs or crashes), I lose only the open pages on that instance.
(I feel this way despite the fact that Iceweasel allows me to easily reopen all those pages (and, I've finally (recently) learned how to do the same thing with konqueror in conjunction with a cron job...))
I don't expect Geany to hang / crash, but 11 years or so ago I was told that Linux never crashes, but I've managed to prove those people wrong (not intentionally, and to my detriment). .-)
Save early, save often :-) after all if the file isn't on disk no other tools can access it :-)
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Whereas multiple instances do not know about each other and chaos reigns, the single instance knows about its multiple windows, and so can save multiple sets of prefs/projects etc.
The alternative (to continue your browser theme) is the Chrome approach where each tab (Geany top level) is a separate process but there is a front end controller process that manages them. But Chrome doesn't have to contend with Geany's problem of synchronizing modifications to multiple instances of a file.
Cheers Lex
Randy Kramer
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Dnia wtorek, 25 stycznia 2011 o 00:43:11 Lex Trotman napisał(a):
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Open Office, for example, can: all other instances are either detached (as in stationery) or read-only.
Chris
On Tuesday 25 January 2011 04:04:53 am Krzysztof Żelechowski wrote:
Dnia wtorek, 25 stycznia 2011 o 00:43:11 Lex Trotman napisał(a):
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Open Office, for example, can: all other instances are either detached (as in stationery) or read-only.
Krzysztof,
Is that on Windows or Linux? (I can imagine differences between them, and rarely use Open Office myself.)
Randy Kramer
Dnia wtorek, 25 stycznia 2011 o 14:27:18 Randy Kramer napisał(a):
On Tuesday 25 January 2011 04:04:53 am Krzysztof Żelechowski wrote:
Dnia wtorek, 25 stycznia 2011 o 00:43:11 Lex Trotman napisał(a):
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Open Office, for example, can: all other instances are either detached (as in stationery) or read-only.
Krzysztof,
Is that on Windows or Linux? (I can imagine differences between them, and rarely use Open Office myself.)
I have seen that on Windows.
2011/1/26 Krzysztof Żelechowski giecrilj@stegny.2a.pl:
Dnia wtorek, 25 stycznia 2011 o 14:27:18 Randy Kramer napisał(a):
On Tuesday 25 January 2011 04:04:53 am Krzysztof Żelechowski wrote:
Dnia wtorek, 25 stycznia 2011 o 00:43:11 Lex Trotman napisał(a):
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Open Office, for example, can: all other instances are either detached (as in stationery) or read-only.
Krzysztof,
Is that on Windows or Linux? (I can imagine differences between them, and rarely use Open Office myself.)
I have seen that on Windows.
On Linux OOO is a single instance multiple window application. And I can't get it to load the same document in more than one window anyway, it just raises the window where the document is already open?
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Dnia środa, 26 stycznia 2011 o 00:57:48 Lex Trotman napisał(a):
2011/1/26 Krzysztof Żelechowski giecrilj@stegny.2a.pl:
Dnia wtorek, 25 stycznia 2011 o 14:27:18 Randy Kramer napisał(a):
On Tuesday 25 January 2011 04:04:53 am Krzysztof Żelechowski wrote:
Dnia wtorek, 25 stycznia 2011 o 00:43:11 Lex Trotman napisał(a):
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Open Office, for example, can: all other instances are either detached (as in stationery) or read-only.
Krzysztof,
Is that on Windows or Linux? (I can imagine differences between them, and rarely use Open Office myself.)
I have seen that on Windows.
On Linux OOO is a single instance multiple window application. And I can't get it to load the same document in more than one window anyway, it just raises the window where the document is already open?
You run the other copy of OpenOffice on another workstation.
Chris
2011/1/26 Krzysztof Żelechowski giecrilj@stegny.2a.pl:
Dnia środa, 26 stycznia 2011 o 00:57:48 Lex Trotman napisał(a):
2011/1/26 Krzysztof Żelechowski giecrilj@stegny.2a.pl:
Dnia wtorek, 25 stycznia 2011 o 14:27:18 Randy Kramer napisał(a):
On Tuesday 25 January 2011 04:04:53 am Krzysztof Żelechowski wrote:
Dnia wtorek, 25 stycznia 2011 o 00:43:11 Lex Trotman napisał(a):
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Open Office, for example, can: all other instances are either detached (as in stationery) or read-only.
Krzysztof,
Is that on Windows or Linux? (I can imagine differences between them, and rarely use Open Office myself.)
I have seen that on Windows.
On Linux OOO is a single instance multiple window application. And I can't get it to load the same document in more than one window anyway, it just raises the window where the document is already open?
You run the other copy of OpenOffice on another workstation.
Chris
Ok, understand. OOq puts a lock file in the directory for each file thats open, thats how it prohibits multi-edit.
Thats Ok for a document editor, but I'm not so sure for a development editor where potentially lots of files are open. And the performance hit on remote files is potentially significant. Users editing remote files are already complaining about performance. And we then have the problem of removing lock files when Geany quits or crashes. That means blocking closing Geany until lock files are removed which could be a problem again on remote filesystems.
Cheers Lex
Dnia środa, 26 stycznia 2011 o 11:45:53 Lex Trotman napisał(a):
Ok, understand. OOq puts a lock file in the directory for each file thats open, thats how it prohibits multi-edit.
Thats Ok for a document editor, but I'm not so sure for a development editor where potentially lots of files are open. And the performance hit on remote files is potentially significant. Users editing remote files are already complaining about performance. And we then have the problem of removing lock files when Geany quits or crashes. That means blocking closing Geany until lock files are removed which could be a problem again on remote filesystems.
First of all, proper use of a version control system should eliminate the need to edit networked files in Geany, unless the developer sits on a thin client — but then either the network is good enough or nothing works.
So Geany could limit its locking facilities to local files or instruct the developer about proper procedures.
IMHO, Chris
2011/1/26 Krzysztof Żelechowski giecrilj@stegny.2a.pl:
Dnia środa, 26 stycznia 2011 o 11:45:53 Lex Trotman napisał(a):
Ok, understand. OOq puts a lock file in the directory for each file thats open, thats how it prohibits multi-edit.
Thats Ok for a document editor, but I'm not so sure for a development editor where potentially lots of files are open. And the performance hit on remote files is potentially significant. Users editing remote files are already complaining about performance. And we then have the problem of removing lock files when Geany quits or crashes. That means blocking closing Geany until lock files are removed which could be a problem again on remote filesystems.
First of all, proper use of a version control system should eliminate the need to edit networked files in Geany, unless the developer sits on a thin client -- but then either the network is good enough or nothing works.
So Geany could limit its locking facilities to local files or instruct the developer about proper procedures.
IMHO, Chris
Totally agree, except some people use Geany to edit web files over FTP to their server. To change to a VCS their service provider would need to change.
Cheers Lex
Dnia środa, 26 stycznia 2011 o 23:43:24 Lex Trotman napisał(a):
2011/1/26 Krzysztof Żelechowski giecrilj@stegny.2a.pl:
Dnia środa, 26 stycznia 2011 o 11:45:53 Lex Trotman napisał(a): First of all, proper use of a version control system should eliminate the need to edit networked files in Geany, unless the developer sits on a thin client -- but then either the network is good enough or nothing works.
So Geany could limit its locking facilities to local files or instruct the developer about proper procedures.
IMHO, Chris
Totally agree, except some people use Geany to edit web files over FTP to their server. To change to a VCS their service provider would need to change.
Not necessarily, since the entire site can (and if you create static content from templates, must) be uploaded in batch and the development files can be maintained elsewhere. But I agree it may cause too much overhead with petty projects.
I was told by Geany documentation that Geany does not handle URL. There is no interface for that in Geany’s file requester. When Dolphin passes a remote file to Geany, Geany opens a temporary file. So I can see no way to actually do that, unless you mount a FTP directory into kernel, which looks rather suicidal to me.
Confusedly, Chris
Le 27/01/2011 19:18, Krzysztof Żelechowski a écrit :
Dnia środa, 26 stycznia 2011 o 23:43:24 Lex Trotman napisał(a):
2011/1/26 Krzysztof Żelechowski giecrilj@stegny.2a.pl:
Dnia środa, 26 stycznia 2011 o 11:45:53 Lex Trotman napisał(a): First of all, proper use of a version control system should eliminate the need to edit networked files in Geany, unless the developer sits on a thin client -- but then either the network is good enough or nothing works.
So Geany could limit its locking facilities to local files or instruct the developer about proper procedures.
IMHO, Chris
Totally agree, except some people use Geany to edit web files over FTP to their server. To change to a VCS their service provider would need to change.
Not necessarily, since the entire site can (and if you create static content from templates, must) be uploaded in batch and the development files can be maintained elsewhere. But I agree it may cause too much overhead with petty projects.
I was told by Geany documentation that Geany does not handle URL. There is no interface for that in Geany’s file requester. When Dolphin passes a remote file to Geany, Geany opens a temporary file. So I can see no way to actually do that, unless you mount a FTP directory into kernel, which looks rather suicidal to me.
Using GIO-fuse :) It mounts GIO mounts using fuse, so they are available as true local files.
cheers, Colomban
Dnia czwartek, 27 stycznia 2011 o 19:54:24 Colomban Wendling napisał(a):
I was told by Geany documentation that Geany does not handle URL. There is no interface for that in Geany’s file requester. When Dolphin passes a remote file to Geany, Geany opens a temporary file. So I can see no way to actually do that, unless you mount a FTP directory into kernel, which looks rather suicidal to me.
Using GIO-fuse :) It mounts GIO mounts using fuse, so they are available as true local files.
Whatever the name, I do not believe it is a good thing.
Sorry for the noise, Chris
On Tuesday 25 January 2011 06:57:48 pm Lex Trotman wrote:
2011/1/26 Krzysztof Żelechowski giecrilj@stegny.2a.pl:
Dnia wtorek, 25 stycznia 2011 o 14:27:18 Randy Kramer napisał(a):
On Tuesday 25 January 2011 04:04:53 am Krzysztof Żelechowski wrote:
Dnia wtorek, 25 stycznia 2011 o 00:43:11 Lex Trotman napisał(a):
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Open Office, for example, can: all other instances are either detached (as in stationery) or read-only.
Krzysztof,
Is that on Windows or Linux? (I can imagine differences between them, and rarely use Open Office myself.)
I have seen that on Windows.
On Linux OOO is a single instance multiple window application. And I can't get it to load the same document in more than one window anyway, it just raises the window where the document is already open?
Yes, I forgot about that behavior (that I've seen in other apps)--sometimes quite useful, sometimes very annoying.
Randy Kramer
On 26.01.2011 14:22, Randy Kramer wrote:
Yes, I forgot about that behavior (that I've seen in other apps)--sometimes quite useful, sometimes very annoying.
Very reasonable behavor if you ask me. For both users and developers. It solves the "same file in multiple instances" problem quite easily.
Best regards.
On Wednesday 26 January 2011 09:01:18 am Thomas Martitz wrote:
On 26.01.2011 14:22, Randy Kramer wrote:
Yes, I forgot about that behavior (that I've seen in other apps)--sometimes quite useful, sometimes very annoying.
Very reasonable behavor if you ask me. For both users and developers. It solves the "same file in multiple instances" problem quite easily.
One annoyance is if you want to have a 2nd instance of the file so that you can work in two places in the file. (Some editors allow you to do a split pane or similar to solve that problem, but not all.)
On 26.01.2011 21:05, Randy Kramer wrote:
One annoyance is if you want to have a 2nd instance of the file so that you can work in two places in the file. (Some editors allow you to do a split pane or similar to solve that problem, but not all.)
Concurrent instances is probably not the way to achieve that. Is there any program in the world which allows this?
Best regards.
On Wednesday 26 January 2011 04:58:57 pm Thomas Martitz wrote:
On 26.01.2011 21:05, Randy Kramer wrote:
One annoyance is if you want to have a 2nd instance of the file so that you can work in two places in the file. (Some editors allow you to do a split pane or similar to solve that problem, but not all.)
Concurrent instances is probably not the way to achieve that. Is there any program in the world which allows this?
Allows what? Opening the same file in different tabs of the same instance of an editor? Opening the same file in two different instances of an editor?
Many that I've used.
I don't do it often--I'd have to test again to confirm which of the current editors I use do that.
Randy Kramer
On 26.01.2011 23:12, Randy Kramer wrote:
On Wednesday 26 January 2011 04:58:57 pm Thomas Martitz wrote:
On 26.01.2011 21:05, Randy Kramer wrote:
One annoyance is if you want to have a 2nd instance of the file so that you can work in two places in the file. (Some editors allow you to do a split pane or similar to solve that problem, but not all.)
Concurrent instances is probably not the way to achieve that. Is there any program in the world which allows this?
Allows what? Opening the same file in different tabs of the same instance of an editor? Opening the same file in two different instances of an editor?
Many that I've used.
This thread is about multiple instances, so the latter. Can you name a program? I have never seen this, unless my definition of "work in two places in the file" differs from yours.
Best regards.
On Wednesday 26 January 2011 05:23:06 pm Thomas Martitz wrote:
On 26.01.2011 23:12, Randy Kramer wrote:
On Wednesday 26 January 2011 04:58:57 pm Thomas Martitz wrote:
On 26.01.2011 21:05, Randy Kramer wrote:
One annoyance is if you want to have a 2nd instance of the file so that you can work in two places in the file. (Some editors allow you to do a split pane or similar to solve that problem, but not all.)
Concurrent instances is probably not the way to achieve that. Is there any program in the world which allows this?
Allows what? Opening the same file in different tabs of the same instance of an editor? Opening the same file in two different instances of an editor?
Many that I've used.
This thread is about multiple instances, so the latter. Can you name a program? I have never seen this, unless my definition of "work in two places in the file" differs from yours.
Ok, from Neil's response to this thread, I see that there is a misunderstanding somewhere--I did not intend to say that the changes would be visible in both (or all) instances of the editor.
But, that doesn't keep me from working on them just fine.
(And, if I save the file in one instance of the editor after making changes, when I go to that file in an other instance of the editor, I'm warned that the file on disk doesn't match the one I'm about to edit, and I'm prompted to do things like reload the file. (Nedit is an example.))
Sorry if I created some confusion.
Randy Kramer
On Wed, 26 Jan 2011 20:23:50 -0500 Randy Kramer rhkramer@gmail.com wrote:
Ok, from Neil's response to this thread, I see that there is a misunderstanding somewhere--I did not intend to say that the changes would be visible in both (or all) instances of the editor.
But, that doesn't keep me from working on them just fine.
(And, if I save the file in one instance of the editor after making changes, when I go to that file in an other instance of the editor, I'm warned that the file on disk doesn't match the one I'm about to edit, and I'm prompted to do things like reload the file. (Nedit is an example.))
geany will do the same (I've made use of this in the past. Open a log file in geany then re-run the code that generates the file and geany will ask me if I want to reload the file). As I understand things, you can force a new instance of geany, and you could open a file in both instances. Personally if I want to look at one part of a file and edit another, I prefer to use something passive like "less", which is far less prone to accidental overwriting.
Jon
On 27 January 2011 18:42, Jon Senior jon@restlesslemon.co.uk wrote:
On Wed, 26 Jan 2011 20:23:50 -0500 Randy Kramer rhkramer@gmail.com wrote:
Ok, from Neil's response to this thread, I see that there is a misunderstanding somewhere--I did not intend to say that the changes would be visible in both (or all) instances of the editor.
But, that doesn't keep me from working on them just fine.
(And, if I save the file in one instance of the editor after making changes, when I go to that file in an other instance of the editor, I'm warned that the file on disk doesn't match the one I'm about to edit, and I'm prompted to do things like reload the file. (Nedit is an example.))
geany will do the same (I've made use of this in the past. Open a log file in geany then re-run the code that generates the file and geany will ask me if I want to reload the file). As I understand things, you can force a new instance of geany, and you could open a file in both instances. Personally if I want to look at one part of a file and edit another, I prefer to use something passive like "less", which is far less prone to accidental overwriting.
Jon
Hi Jon,
You don't have to forgo Geany if you only want to read the file in another instance, just set Document->read only and you don't have to accept anything less (boom boom :-).
The problems are when editing prefs/projects/files in more than one instance.
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 27 January 2011 09:12, Randy Kramer rhkramer@gmail.com wrote:
On Wednesday 26 January 2011 04:58:57 pm Thomas Martitz wrote:
On 26.01.2011 21:05, Randy Kramer wrote:
One annoyance is if you want to have a 2nd instance of the file so that you can work in two places in the file. (Some editors allow you to do a split pane or similar to solve that problem, but not all.)
Concurrent instances is probably not the way to achieve that. Is there any program in the world which allows this?
Allows what? Opening the same file in different tabs of the same instance of an editor? Opening the same file in two different instances of an editor?
Many that I've used.
I don't do it often--I'd have to test again to confirm which of the current editors I use do that.
Randy Kramer
Hi Randy,
An Emacs instance of course allows the same file to be edited in more than one top level window and the edits appear in the others. In fact I am occasionally moved to go back to Emacs for just this capability, editing definitions at the top of a file and functions using them at the bottom of the file.
I don't know of any editors where editing the file in multiple instances allows the edits to show up in the other instances.
Dumb editors allow you to edit the file in multiple instances and the last saved just overwrites previous saves, not really what we want since I for one will almost certainly do it accidentally :-(
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Wednesday 26 January 2011 05:37:57 pm Lex Trotman wrote:
On 27 January 2011 09:12, Randy Kramer rhkramer@gmail.com wrote:
On Wednesday 26 January 2011 04:58:57 pm Thomas Martitz wrote:
On 26.01.2011 21:05, Randy Kramer wrote:
One annoyance is if you want to have a 2nd instance of the file so that you can work in two places in the file. (Some editors allow you to do a split pane or similar to solve that problem, but not all.)
Concurrent instances is probably not the way to achieve that. Is there any program in the world which allows this?
Allows what? Opening the same file in different tabs of the same instance of an editor? Opening the same file in two different instances of an editor?
Many that I've used.
I don't do it often--I'd have to test again to confirm which of the current editors I use do that.
Randy Kramer
Hi Randy,
An Emacs instance of course allows the same file to be edited in more than one top level window and the edits appear in the others. In fact I am occasionally moved to go back to Emacs for just this capability, editing definitions at the top of a file and functions using them at the bottom of the file.
I don't know of any editors where editing the file in multiple instances allows the edits to show up in the other instances.
No, sorry, I didn't mean to say that any did. But they do typically warn you when the file on disk doesn't match the file you're working on (when the instance of the editor gets the focus).
Dumb editors allow you to edit the file in multiple instances and the last saved just overwrites previous saves, not really what we want since I for one will almost certainly do it accidentally :-(
Maybe I've just done it accidentally so often that I've developed habits (knock on wood) to avoid the problem. (Primary habit being, always hit <ctrl> s after doing almost anything (and before moving the focus away from an editor).)
Anyway, like I say, sorry if I created some confusion.
Randy Kramer
Dnia czwartek, 27 stycznia 2011 o 02:28:05 Randy Kramer napisał(a):
Maybe I've just done it accidentally so often that I've developed habits (knock on wood) to avoid the problem. (Primary habit being, always hit <ctrl> s after doing almost anything (and before moving the focus away from an editor).)
That does not help if you edit the same file in two independent windows and the editors do not monitor the modification time.
IMHO, Chris
On Monday 24 January 2011 06:43:11 pm Lex Trotman wrote:
On 24 January 2011 23:52, Randy Kramer rhkramer@gmail.com wrote:
On Saturday 22 January 2011 09:07:31 pm Lex Trotman wrote:
- It is (I think) a big change to allow Geany to have one
instance with multiple top level windows, how to handle different projects in different top levels? how to handle different preferences in different top levels?
So AFAICT there is no clear solution.
My personal choice would be 3 because it would then also support multiple monitor setups, but I believe that there is a lot of usage issues to resolve and a LOT of work involved.
Any good ideas welcome.
No good ideas, but I'll continue to express biased opinions ;-)
Every opinion is biased, except mine :-)
I'm not sure I fully understand your number 3, but if that means I can run only one instance of Geany (with multiple top level windows). I would be concerned.
It sounds like the way Iceweasel / Firefox is set up, at least as of version 3.0.6, which is what I'm using.
My problem with that is that if something happens to that one instance of Iceweasel (with several top level windows open on different desktops), I lose all the open pages. (For that reason, I continue to use konqueror as my primary web browser--there are pages for which doesn't work, but when one instance dies (hangs or crashes), I lose only the open pages on that instance.
(I feel this way despite the fact that Iceweasel allows me to easily reopen all those pages (and, I've finally (recently) learned how to do the same thing with konqueror in conjunction with a cron job...))
I don't expect Geany to hang / crash, but 11 years or so ago I was told that Linux never crashes, but I've managed to prove those people wrong (not intentionally, and to my detriment). .-)
Save early, save often :-) after all if the file isn't on disk no other tools can access it :-)
Your description of single instance, multi window is correct, yes there is a slightly enhanced risk, but IMH(unbiased)O compared to the problems with multiple instances this is small, see my scenario on another post on this thread. No software can prevent the same file in two instances being different. With a single instance all windows see the same (possibly modified) version of the file.
Whereas multiple instances do not know about each other and chaos reigns, the single instance knows about its multiple windows, and so can save multiple sets of prefs/projects etc.
The alternative (to continue your browser theme) is the Chrome approach where each tab (Geany top level) is a separate process but there is a front end controller process that manages them. But Chrome doesn't have to contend with Geany's problem of synchronizing modifications to multiple instances of a file.
Thanks for the response!
I have the same file open in multiple windows (on different desktops) so rarely that it is not something I worry about. When I have the same file open more than once, it is almost always on the same desktop.
(I do have some files that I use related to work on more than one desktop, but I keep those on a desktop related to only that type of file, and go to that desktop to read / edit them.)
So, I guess I'm saying I'm not in a position (atm) to comment on the difficulties (or workarounds) related to the same file open on different desktops / instances.
Randy Kramer
Hi,
On the single single instance, multi window: it has it's own problems.
For example, when you stop Geany, it'll have to save in geany.conf the [positions and] desktops of all open windows, which is unportable. And of course, under Windows, multi-window is limited to a single desktop (see "SetThreadDesktop"), so multiply instances are desirable.
Whereas multiple instances do not know about each other and chaos reigns, the single instance knows about its multiple windows, and so can save multiple sets of prefs/projects etc.
Except that we don't know which set of settings has "priority" and applies to the newly open windows, so we're back to square one. NEdit had global shared options and a smaller set of per-window options, but that'll be hell to implement.
On Sat, 22 Jan 2011 22:49:47 +0100 Julien Nicoulaud julien.nicoulaud@gmail.com wrote:
I'm using GNOME with several workspaces, and there's a behaviour I find quite annoying: if you have an instance of Geany running in a workspace and you open a file in another workspace, it just opens the file in the already running instance and switches you back to the workspace. [...]
That was discussed several times, and implemented once, but various issues came out, and the patch was reverted.
Anyway, I wrote a little wrapper script that detects if there's no Geany window in the current workspace, in which case it forces creating one: https://github.com/nicoulaj/dotfiles/blob/master/bin/geany [...]
You can let Geany do this check by using the --socket parameter, which is also required if you want separate instances. The attached wrapper script is equivalent to the former in-Geany implementation.
2011/1/23 Dimitar Zhekov dimitar.zhekov@gmail.com
On Sat, 22 Jan 2011 22:49:47 +0100 Julien Nicoulaud julien.nicoulaud@gmail.com wrote:
I'm using GNOME with several workspaces, and there's a behaviour I find quite annoying: if you have an instance of Geany running in a workspace
and
you open a file in another workspace, it just opens the file in the
already
running instance and switches you back to the workspace. [...]
That was discussed several times, and implemented once, but various issues came out, and the patch was reverted.
Anyway, I wrote a little wrapper script that detects if there's no Geany window in the current workspace, in which case it forces creating one: https://github.com/nicoulaj/dotfiles/blob/master/bin/geany [...]
You can let Geany do this check by using the --socket parameter, which is also required if you want separate instances. The attached wrapper script is equivalent to the former in-Geany implementation.
Has this script been tested recently ? I finally took some time to try it, and it does not seem to work for me.
-- E-gards: Jimmy
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Wed, 26 Jan 2011 22:08:33 +0100 Julien Nicoulaud julien.nicoulaud@gmail.com wrote:
2011/1/23 Dimitar Zhekov dimitar.zhekov@gmail.com
Anyway, I wrote a little wrapper script that detects if there's no Geany window in the current workspace, in which case it forces creating one: https://github.com/nicoulaj/dotfiles/blob/master/bin/geany [...]
You can let Geany do this check by using the --socket parameter, which is also required if you want separate instances. The attached wrapper script is equivalent to the former in-Geany implementation.
Has this script been tested recently ? I finally took some time to try it, and it does not seem to work for me.
I'm using it all the time. A simpler command is listed in the manual: http://www.geany.org/manual/current/, --socket-file.