[Geany-devel] Command-line option to open a project (was: Questions about Geany project support)

[Dominic Hopf]

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

-- 
Dominic Hopf <dmaphy at googlemail.com>

http://dominichopf.de/

Key Fingerprint:
A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.geany.org/pipermail/devel/attachments/20100215/3f950d11/attachment.pgp>