Re: patch to append files to playlist

Cal Peake wrote:
> On Fri, 3 Dec 2004, Cal Peake wrote:
> 
>> Yes, you're right - it's too early in the morning for me. Writing the 
>> config out to the disk upon state change or having the already running 
>> xmms tell the invoked one what the current state is would seem to be the 
>> options.
> 
> Yes, adding a save_config() call after the cfg.append_to_playlist = 
> GTK_CHECK_MENU_ITEM(...) call creates the desired behavior. Question is, 
> is this best/proper way?

that is the very question that led to other two alternatives...

one problem with xmms today, as I see it, is that so much config gets
lost if xmms is killed before it can save the config... so I don't
really see adding save_config() in a few important places as a big
problem...

but in the end, someone has to make a policy decision on this subject,
and I ain't one to do it. (this patch is the only piece of xmms code
I've ever really read.)

I think, if save_config() is a no-go, that the "architecture change" I
mentioned would be the best way to go.. that is, let the running xmms
decide if we should append the passed file(s) to the queue or simply
replace the queue.

This approach would possibly cause some issues - we'd need to be able to
force the running thread to overwrite the queue, in case the user wanted
to do that (with a command-line flag)

so, maybe a "tri-state" ipc load command;

a) replace queue
b) running process decides (using the new flag)
c) enqueue

this would make the proposed change more flexible, I think, and allow
the user to explicitly do an action, regardless of the configuration in
the running thread.

At this time, let me just say that I have no idea of how the IPC is
actually carried out, I'm just guessing out of how xmms behaves, and the
code of the patch in this thread.

Cheers,
-- 
Morten