Re: [LAD] LASH - some questions & comments
Fons Adriaensen <[EMAIL PROTECTED]> 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 pgp4QHyek9C1n.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LASH - some questions & comments
"Emanuel Rumpf" <[EMAIL PROTECTED]> 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 pgprqFQ58WljF.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LASH - some questions & comments
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Lash-dev] Re: LASH - some questions & comments
Nedko Arnaudov wrote: > "Emanuel Rumpf" <[EMAIL PROTECTED]> 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? > 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Lash-dev] Re: LASH - some questions & comments
schoappied <[EMAIL PROTECTED]> writes: > There is posted a message for testers here: > http://linuxmusicians.com/viewtopic.php?f=24&t=622 > and a discussion about lash here: > http://linuxmusicians.com/viewtopic.php?f=28&t=609 > > If you need testers in the future maybe good to left a message there > or/ and on the LAU mailinglist? Thank you for your forum post about rc1. Posting announce of rc1 to dev-only lists only was intetional. The reason is to avoid user frustration that can be caused by "unpolished" software. Also devs are supposed to be able to give better feedback for crashing software. If everything goes as I expect, rc2 announce will probably be posted in laa and lau mailing lists too. -- Nedko Arnaudov pgp0ZOcF3wF0H.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LASH - some questions & comments
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! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
