linuxaudio.org

--=-=-=

Content-Transfer-Encoding: quoted-printable
Fons Adriaensen  writes:
> On Thu, Oct 16, 2008 at 11:40:09AM +0300, Nedko Arnaudov wrote:

quoted text
>

>> The trend is to remove usage of argv at all. As for documentation, I

>> agree LASH needs better one. In current documentation (somewhat out of

>> date), argv thing is supposed to be opaque. I.e. LASH app should not

>> know what lash specific arguments are.

>

> That exactly is the problem. Any app should be allowed

> to know. Elementary courtesy towards your client...

> Support libraries are not meant to be 'stealthy'.

IMHO this should be provided by libjack API itself.

This is same thing that kfoltman requested these days, to be able to

check whether app is started as part of process of restoring lash

session. I'm fine with this and such approach in general.
> Looking at the source, there's indeed a lot of

quoted text
> deprecated stuff, followed by two flags, and then

> the complete argv minus the lash-specific parts.

>

> I don't think blindly copying the complete argv=20

> and giving it back when the client is restarted

> later by lash is a good idea.=20

I have plan to allow user to tweak commandline of both lash first time

launched apps (when launched through lash control app) and restored lash

app processes, before launched. However this is not in my short term

TODO list.
> If there is any data in there that is essential

quoted text
> for the client to be restarted later, then the

> client would probably include that in its configs

> or in its saved config file.

Unless you have app that has no internal state at all. Examples:

fluidjack and jkmeter (ver nice app btw). This simplifies lash

integration for simple commandline apps.
> The only exception would be things that are essential

quoted text
> even before the restarted client connects to lash.

> But only the client knows which data that would be.=20

Can you give some example, please?
> So it seems it would be a better approach to let

quoted text
> the client supply those parts of its argv that it

> wants back the next time, if any, rather than just

> taking it all.

Such option seems fine. I'm only opposed to *requiring* such

app<->liblash interaction, because it will make commandline argument

management more tricky.
> This issue (and some others, like jack connections)

quoted text
> is not as simple as it seems.

>

> For example, none of my (GUI) apps knows if any

> of its configuration comes from compile-time defaults,

> /etc/appname.conf, ~/.appnamerc, ~/Xdefaults, or

> the command line. They just interrogate the X11

> database which combines all of that with the right

> priorities (part of libclxclient).

> Some of that data may be pointers to application

> resources (e.g. the instrument definitions used

> by Aeolus) rather than user options. Such resources

> may have been moved or replaced next time lash runs

> the app. In that case the app wants the current

> values, not the old ones. But only the application

> knows such things, so blindly copying everything

> is not the right way. Since the app is given the

> chance to store its config in any way it wants,

> it isn't necessary either.

I think the easiest option would be to store internal state in lash and

ignore commandline when restored as part of lash session. Other option

would be to declare such behaviour to lash, either by call of liblash,

or in the desktop entry for your app (X-LASH-XXX fields, we have some of

them already).
=2D-=20

Nedko Arnaudov 
--=-=-=

Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQBI+LGX6bb4v94XFrARAk+UAJoCB1HTG9d6R8/x1lpo4alyCccPwQCgg7cy

L4xYzbpBqI1jmIL819hY4ds=

=M3pC

-----END PGP SIGNATURE-----

--=-=-=--