gnome-volume-manager blank CD defaults

Michael Wiktowy mwiktowy at gmx.net
Fri Oct 8 21:26:59 UTC 2004


>Date: Thu, 07 Oct 2004 22:17:09 -0400
>From: "John (J5) Palmieri" <johnp at redhat.com>
>Subject: Re: gnome-volume-manager blank CD defaults
>To: Development discussions related to Fedora Core
>	<fedora-devel-list at redhat.com>
>Message-ID: <1097201799.22130.74.camel at localhost.localdomain>
>Content-Type: text/plain
>
>On Thu, 2004-10-07 at 18:15, Michael Wiktowy wrote:
>  
>
>>>> > Date: Thu, 07 Oct 2004 12:02:57 -0400
>>>> > From: "John (J5) Palmieri" <johnp at redhat.com>
>>>> > Subject: gnome-volume-manager blank CD defaults
>>>> > To: Development discussions related to Fedora Core
>>>> > 	<fedora-devel-list at redhat.com>
>>>> > Message-ID: <1097164977.22577.6.camel at remedyz.boston.redhat.com>
>>>> > Content-Type: text/plain
>>>> > 
>>>> > I wanted to get the Fedora communities opinion on popping up a burn://
>>>> > folder when a blank CD is inserted into the drive.  Right now we pop it
>>>> > up which makes sense because if you pop in a blank CD most likely you
>>>> > want to burn to it.  Problems come in when a user is using browser mode
>>>> > in Nautilus.  If you pop the CD in and out a couple of times you get a
>>>> > bunch of burn:// folders.  Since you get a CD icon on the desktop which
>>>> > you can double click to open up the burn:// folder I am wondering if I
>>>> > should turn this off by default.  I am of no opinion either way so I
>>>> > want to see how everyone else feels. 
>>>> > 
>>>> > -- 
>>>> > John (J5) Palmieri
>>>> > Associate Software Engineer
>>>> > Desktop Group
>>>> > Red Hat, Inc.
>>>> > Blog: http://martianrock.com
>>>      
>>>
>>> 
>>> My Opinion since you asked for it:
>>> One of my major annoyances is things that pop up obtrusively.
>>    
>>
> Ok well this should be fixed once we have some sort of notification 
> system that is informative yet non-intrusive so I am not so worried 
> about this since you can turn it off. Defaults aren't whats least 
> annoying to experienced users, they are about what is most convenient 
> for new users.


Also, it is what is most convenient to unprivilaged or unknowledgeable 
users. There will be some situations where a user cannot switch settings 
due to the administrator imposing the default on them or just a tendancy 
of a non-computer savvy user to not dig around to figure out how to 
change things to their liking. They will just have to put up with 
whatever is given. Just giving a few deployment scenarios that may be 
target audiences for reasonable defaults.

>>> I think
>>> that a default option should be as intuitive and non-intrusive as
>>> possible while still guiding the user to the proper solution.
>>    
>>
> That is the goal but I would take intuitive before non-intrusive.


They are not mutually exclusive and I would want to maximize both. 
Having a default application popup is not the most intuitive since 
burn:// is not the most approriate application for all burning options 
(for instance burning .iso, transcoding compressed digital audio and 
burning to audio CDs, CD duplication, etc. ... unless you have greatly 
improved burn:// since I last used it ... I couldn't figure out how to 
intuitively use it for any of those options that I do more often than 
just burning simple data CDs). It is great for data CDs but I have been 
forced to use something else for all those other usage modes.

>>> With that in mind, I would say that the icon appearing on the desktop
>>> with some descriptive title that it is a blank CD and what drive it is
>>> in (realizing that some have multiple burners on their systems) would be
>>> adequate.
>>    
>>
> The problem with this is the desktop is often obscured and a new user 
> would have to find where the icon popped up so it is not extremely 
> intuitive. Once a user understands about dynamic icons then it becomes 
> more intuitive.


I agree. This is where something in the notification area would be 
useful. Alternatively, I quite like the idea of a first time only popup 
to allow default action that others have suggested.

>>> Right clicking should give you the option to burn it with your choice of
>>> installed burners.
>>    
>>
> This I don't understand.


Sorry ... I wasn't clear there at all. That should have been 
"Right-clicking on the Blank CD desktop icon should give you a choice of 
which installed burning applications to use. Much like right-clicking on 
a movie/audio media file gives you the option to choose the player to 
play it with." Keep the same expected behaviour and the same world-view. 
Kind of an extension of the "everything is a file" mentality in *nix.

>>> Double-clicking on it should activate the default burning software which
>>> would be burn://.
>>    
>>
> This is already what it does.
>
>>> I would do this for audio CD also.
>>    
>>
> There is no question about audio CD defaults. For those the right 
> thing is to start an CD player. It is the same thing that happens when 
> you pop a CD into your stereo.


Well ... it was just my opinion based on my mode of operation. There are 
fewer things that you might want to do with an audio CD when you pop it 
in so I suppose my justification for not popping up applications 
automagically is weaker. However, if I want to play an audio CD, I 
normally pop it into my stereo. If I want to rip/burn/mix then I put it 
into my computer. I just prefer the right tool for the right job, I 
suppose. I would guess that new users would likely still choose a stereo 
too. But this is appearently not up for debate so I will drop the issue.

>>> i.e. Treat removable media as kind of a pseudo mime-type in nautilus.
>>    
>>
> Removable media works fine in Nautilus. They pop up as icons and you 
> can launch them. By default they also pop up windows which makes 
> sense. The reason I special case CD burning is because of some of the 
> problems associated with it, though I have yet to hear any compelling 
> argument for removing it. As I said when I started this thread I 
> really don't care either way but there have been compelling points for 
> leaving it in so I am leaning that way right now. If you want to 
> convince me you need to come from the point of a new user who just 
> wants things to work out of the box. Any experienced user can 
> configure the desktop to how they like it. I want to make sure it is 
> usable to those who just want to use the desktop.


>>> If people want to automagically start up things then they can have that
>>> option in the preferences. 
>>    
>>
> And if people don't want to automagically start things up now, then 
> they already have that option in the preferences.
>
>>> But this is a semi-automatic solution that
>>> will avoid all the familiar and annoying problems like:
>>    
>>
> There is no semi-automatic solution. Its either on or off. The rest of 
> the desktop will function the same way.


semi-automatic to me = just destop icon/notification, no popup app. I 
was thinking in the whole process sense rather then just that last step. 
The last step is a binary decision.
There isn't really a strong case for either way. The way things are set 
up now it is not a big hassle to switch to either modes but to summarize 
my reasons for the non-pop app:
1) burn:// is not the right/best tool for everything you might want to 
do with a blank CD. Users are not always in control of their settings. 
The default should present the best option for everything they would 
want to do and not send them into blind alleys.
2) you are not always starting the burning process off by inserting a CD
3) All burning apps *currently* included in FC3T are not coded to block 
one another ... maybe when they are a default popup app will not screw 
up workflow and would make more sense.


>>> - Burning with an app that asks you to enter a blank CD and then having
>>> another app start up in the middle of the burn. You don't *always* start
>>> a burn by sticking in a blank CD.
>>    
>>
> This is a problem with a solution.


Many solutions, no doubt.

>>> - Opening up the default burning software while you already have another
>>> one open in preparation for burning. While all software *should* be
>>> written to block access via hal, forcing that feature on all CD burning
>>> apps just so the default doesn't screw up is not entirely fair ...
>>    
>>
> It is perfectly fair. If we want an integrated desktop with components 
> that work well together HAL and DBUS will get us there but that is 
> another story.
>
>>> especially if they are also included in Fedora (past and present since
>>> supposedly upgrading Fedora between major releases is something that is
>>> "supported").
>>    
>>
> I don't get the reference to upgrading. 


The upgrading reference was due to the possibility of burning 
applications being around from pervious releases that may not be 
included in the current release. It was more of a hypothetical since I 
cannot think of a particular example of a burning app that was included 
previously that has been removed since and besides that would be more in 
the domain of an experienced user ... not a new one ... therefore not 
really relevant.

> Yes we should add the functionality to all CD burning apps in FC 
> though I am not sure that will happen this time around.


I agree. It would be great if all the burning apps could be made to work 
within these systems today but realistically they are not. So the 
fail-safe thing to do would be to pick defaults that won't conflict. It 
is the difference between a fail-safe approch to design (badly acting 
apps are worked around) vs. a protesting approach to design (badly 
acting apps break to force updating of bad apps). A protesting approch 
tends to prod development at the expense of the user experience. Yes, 
they are wrong for not keeping with current infrustructure technology. 
Yes, you are coding things properly. Yes, the users are going to suffer 
while the developers point fingers at one another unless a more 
pragmatic approach is taken. IMHO, one should never design something 
that is known to break under known operational conditions.


>>> Just my opinion.
>>    
>>
> Thank you. -- J5





More information about the devel mailing list