15 Oct
2008
15 Oct
'08
8:16 p.m.
Some questions and comments regarding the LASH release candidate.
1. lahs_init()
Would it be possible to document the contents of
the first argument 'lash_args_t *args' ?
I'd be happy to give lash all the info it needs
but feel quite strongly that I should be able
to provide this myself and not being forced to
have liblash inspect/mangle my argv. See also 2.
2. lash_extract_args()
The type of main()'s argv is char *argv[], so
why is the second argument a triple pointer ?
Re-arranging the elements of argv does not
require access to the variable argv itself,
only to its elements, and for this a double
pointer is all you need.
3. The Restore_Data_Set event.
How does a client know when all configs saved
by a previous session have been received ?
The client may be updated meanwhile and
expect more configs than were saved. It
should have defaults for these of course,
but how long should it wait for data that
may never arrive ?
Ciao,
--
FA
Follie! Follie! Delirio vano e' questo!
16 Oct
16 Oct
6:40 a.m.
Fons Adriaensen <fons(a)kokkinizita.net> writes:
Some questions and comments regarding the LASH release
candidate.
Nice to get lash-0.6.0.~rc1 reivewed by you Fons! Thank you!
1. lahs_init()
Would it be possible to document the contents of
the first argument 'lash_args_t *args' ?
I'd be happy to give lash all the info it needs
but feel quite strongly that I should be able
to provide this myself and not being forced to
have liblash inspect/mangle my argv. See also 2.
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.
2. lash_extract_args()
The type of main()'s argv is char *argv[], so
why is the second argument a triple pointer ?
Re-arranging the elements of argv does not
require access to the variable argv itself,
only to its elements, and for this a double
pointer is all you need.
I spoted this too, when I was doing python bindings some time ago. I
think I got response something like "it is for consistency". OTOH the
important part is that we dont want to brake existing apps by chaning
the API. The plan is to introduce entirely new API. That should fix all
known issues. Disclaimer: Other LASH project members may not agree on
these statements.
3. The Restore_Data_Set event.
How does a client know when all configs saved
by a previous session have been received ?
The client may be updated meanwhile and
expect more configs than were saved. It
should have defaults for these of course,
but how long should it wait for data that
may never arrive ?
Good point! AFAIK client cannot know this. I'll write it as comment for
our new API ticket (#14) so we address this issue when designing the new
API.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
7:30 a.m.
Hi
I get handler/signal doesn't exist messages.
If I press the save button in lash_panel:
lash_control_signal_handler: Received unknown signal 'ProjectSaved'
lash_control_signal_handler: Received unknown signal
'ProjectModifiedStatusChanged'
Is that expected behavior ?
(lash 6.0rc1, Compiled with JACK 0.109.2, D-Bus 1.2.1, libxml2 2.6.32,
ALSA 1.0.16 )
Output:
-------------------------------------------------------------------
$ lash_save_button
lash_control_signal_handler: Received unknown signal
'ProjectModifiedStatusChanged'
Add client (New Project): c93429bd-c532-4482-b33b-d156ff53c8a7
method_default_handler: Method "SaveProject" with signature "" on
interface "org.nongnu.LASH.Server" doesn't exist
10:27 a.m.
"Emanuel Rumpf" <xbran(a)web.de> writes:
Hi
Hello Emanuel
I get handler/signal doesn't exist messages.
If I press the save button in lash_panel:
lash_control_signal_handler: Received unknown signal 'ProjectSaved'
lash_control_signal_handler: Received unknown signal
'ProjectModifiedStatusChanged'
Is that expected behavior ?
(lash 6.0rc1, Compiled with JACK 0.109.2, D-Bus 1.2.1, libxml2 2.6.32,
ALSA 1.0.16 )
$ lash_save_button
lash_control_signal_handler: Received unknown signal
'ProjectModifiedStatusChanged'
Add client (New Project): c93429bd-c532-4482-b33b-d156ff53c8a7
method_default_handler: Method "SaveProject" with signature "" on
interface "org.nongnu.LASH.Server" doesn't exist
I haven't really tested liblash control API after dbus changes. I think
it is safe to assume that it is deprecated. Thus, please test with
patchage or lpatchage instead of lash_panel and lash_save_button.
Juuso and Dave, do you think we should remove these control apps from
make install?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
12:56 p.m.
New subject: [Lash-dev] Re: LASH - some questions & comments
Nedko Arnaudov wrote:
"Emanuel Rumpf" <xbran(a)web.de> writes:
Hi, and sorry for the long absence. I think I will now get more
interested about LASH and help with the next release.
I think the old API control apps should no longer get installed, but
their source code could stay for the time being. We should work on the
new API.
Juuso
Hi
Hello Emanuel
I get handler/signal doesn't exist messages.
If I press the save button in lash_panel:
lash_control_signal_handler: Received unknown signal 'ProjectSaved'
lash_control_signal_handler: Received unknown signal
'ProjectModifiedStatusChanged'
Is that expected behavior ?
(lash 6.0rc1, Compiled with JACK 0.109.2, D-Bus 1.2.1, libxml2 2.6.32,
ALSA 1.0.16 )
$ lash_save_button
lash_control_signal_handler: Received unknown signal
'ProjectModifiedStatusChanged'
Add client (New Project): c93429bd-c532-4482-b33b-d156ff53c8a7
method_default_handler: Method "SaveProject" with signature "" on
interface "org.nongnu.LASH.Server" doesn't exist
I haven't really tested liblash control API after dbus changes. I think
it is safe to assume that it is deprecated. Thus, please test with
patchage or lpatchage instead of lash_panel and lash_save_button.
Juuso and Dave, do you think we should remove these control apps from
make install?
7:02 p.m.
On Thu, Oct 16, 2008 at 11:40:09AM +0300, Nedko Arnaudov wrote:
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'.
Looking at the source, there's indeed a lot of
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
and giving it back when the client is restarted
later by lash is a good idea.
If there is any data in there that is essential
for the client to be restarted later, then the
client would probably include that in its configs
or in its saved config file.
The only exception would be things that are essential
even before the restarted client connects to lash.
But only the client knows which data that would be.
So it seems it would be a better approach to let
the client supply those parts of its argv that it
wants back the next time, if any, rather than just
taking it all.
This issue (and some others, like jack connections)
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.
Ciao,
--
FA
Follie! Follie! Delirio vano e' questo!
17 Oct
17 Oct
1:39 p.m.
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Thu, Oct 16, 2008 at 11:40:09AM +0300, Nedko
Arnaudov wrote:
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.
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'. Looking at the source, there's indeed a lot of
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
and giving it back when the client is restarted
later by lash is a good idea.
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
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
even before the restarted client connects to lash.
But only the client knows which data that would be.
Can you give some example, please?
So it seems it would be a better approach to let
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)
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).
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
23 Oct
23 Oct
11:15 a.m.
On Thu, 2008-10-16 at 00:10 +0200, Fons Adriaensen wrote:
Some questions and comments regarding the LASH release
candidate.
1. lahs_init()
Would it be possible to document the contents of
the first argument 'lash_args_t *args' ?
I'd be happy to give lash all the info it needs
but feel quite strongly that I should be able
to provide this myself and not being forced to
have liblash inspect/mangle my argv. See also 2.
The issue here is that lash arguments are properties of the particular
session that the client is loaded into. LASH takes the responsibility
of being aware of the lash session out of the hands of the client. In
the case of argc/argv, this isn't just a convenience thing but, as Nedko
noted, a deliberate opacity.
Originally, clients that wanted to be aware of the lash session would
had to have been Server Interfaces. That whole business was messy
anyhow.
2. lash_extract_args()
The type of main()'s argv is char *argv[], so
why is the second argument a triple pointer ?
Re-arranging the elements of argv does not
require access to the variable argv itself,
only to its elements, and for this a double
pointer is all you need.
I think the better option would have been to use environment variables
rather than command-line arguments. That would have required no
fiddling at all. As for why a double pointer was used, it was likely
because I was following the method used in GTK+ et al.
3. The Restore_Data_Set event.
How does a client know when all configs saved
by a previous session have been received ?
The client may be updated meanwhile and
expect more configs than were saved. It
should have defaults for these of course,
but how long should it wait for data that
may never arrive ?
The philosophy here is that the client's state is the client's business.
The schema it uses to store its state is up to the client; the configs
simply provide a method of doing so.
In your example, the client isn't saving its state *as a whole* but
simply storing data for individual configuration options. In order to
save the entire state, the client would have to store information about
which configuration options were saved.
The name "config" may be misleading.
Bob
--
Bob Ham <rah(a)bash.sh>
3:43 p.m.
Thanks for your comments Bob!
Bob Ham <rah(a)bash.sh> writes:
On Thu, 2008-10-16 at 00:10 +0200, Fons Adriaensen
wrote:
I also think that LASH should use environment and remove use of
arguments for LASH business competely.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
2. lash_extract_args()
The type of main()'s argv is char *argv[], so
why is the second argument a triple pointer ?
Re-arranging the elements of argv does not
require access to the variable argv itself,
only to its elements, and for this a double
pointer is all you need.
I think the better option would have been to use environment variables
rather than command-line arguments. That would have required no
fiddling at all. As for why a double pointer was used, it was likely
because I was following the method used in GTK+ et al.
6215
days inactive
6223
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Bob Ham -
Emanuel Rumpf -
Fons Adriaensen -
Juuso Alasuutari -
Nedko Arnaudov