Hey Eugene,
Am Montag, den 15.02.2010, 14:12 +0300 schrieb Eugene Arshinov:
Hi all. Here is the last question.
Preface. Currently if the first filename passed via command-line has ".geany" extension, it's opened as a project. If I implement project support in SM using this behaviour, there will be a little trouble.
The trouble. Suppose a user has neither default session not a project opened (example: "geany -s"), and he opens a project file to edit it manually. Then if he logs out without closing Geany, my SM code has to store opened files in restart command like "geany -s edited_proj.geany". You see what happens after that when Geany is restarted.
A solution. Provide a separate command-line option to open a project (e.g., "--project" or "-r" as "-p" is reserved for "--no-plugins"). This behaviour is more convenient and it eliminates the problem completely.
Absence of compatibility (1). BUT current behaviour is rather old and users may be familiar with it. Maybe(?) it is acceptable to drop that behaviour completely and tell all users about it (is there a way to do it? I believe that most of users are not subscribed to Geany mailing list). If it isn't acceptable, see below.
I think it would be acceptable, even if compatibility is nicer. We have mailing lists, IRC channel and release notes where users can hear about any change. If there would be still a user who gets confused, he should subscribe to the mailing list and ask or at least file a bug at the sf tracker and hear about the change that way. I think that would be okay.
Making it compatible (2). Geany instance has some means to know whether it's run by a user or being restarted (via hidden command-line option I introduced to support XSMP). If an instance if being restarted, it is completely safe to disable the old behaviour and enable the new one. That solves the problem.
I tend to drop the old behaviour as written above. But let's wait for other opinions. Maybe the compatibility is the better solution.
Removing the old behaviour (3). From my point of view, it is not comfortable to maintain two variations of handling command-line options (though the difference between them is little). Maybe(?) it is acceptable to keep the old behaviour in the next version (say, 0.19), but issue a warning to stderr when the old behaviour is used, and remove the old behaviour some time after that (say, in 0.20).
That's the way I'd also prefer about compatibility, since it's just a "smoother" (1). :)
Regs, Dominic