Re: [Rhythmbox-devel] playlist source burner


Bastien Nocera wrote:
Hey Colin,

On Sat, 2004-08-28 at 21:37 -0400, Colin Walters wrote:
I agree with Bastien about the temporary folder UI (and GConf key).
nautilus-cd-burner just uses g_get_tmp_dir, this should be fine.  I
don't see a reason why an even halfway modern system wouldn't have space
for a CD image on the normal temporary directory paths.  And if they
don't, then we can add some code to autodetect large local volumes.

Actually, nautilus-cd-burner uses either the user provided path,
g_get_tmp_dir or the user's home directory, and checks the space left in
each of them for that.

I suppose that whatever is done should be consistent between the two applications. However, this method of automatically finding a temporary directory doesn't work very well in a few cases.

- g_get_tmp_dir is too small or already used (perhaps by other users)
- g_get_home_dir is on a (remote) filesystem that is unacceptable for use with streaming media
- user doesn't know how to or cannot set TMPDIR|TMP|TEMP for only this process

And possibly:

- sysadmin wants to set a default / mandated location for large media scratch files

I think this may actually hit more users than it might seem. However, I think these all involve some sysadmin involvement at some point. So, how about checking: GConf key shared between n-c-b and rb for media scratch location, g_get_tmp_dir(), g_get_home_dir()? And removing the UI for the folder selection?

Using an autodetected large local volume without the user's consent may not be so good. If RB happens to crash it will leave litter in an unknown place.

The next thing is to determine how much space will be needed. The easiest way is to compute it from the song duration. Is it safe to rely on the duration being present and correct?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]