> On Thu, 2010-09-23 at 12:44 -0500, Timothy Pearson wrote:
>> > On Thu, 2010-09-23 at 12:19 -0500, Timothy Pearson wrote:
>> >> > Timothy Pearson wrote:
>> >> >>> Also on the Squeeze install all the icons on the desktop belong
>> to
>> >> root?
>> >> >>> Including trash and my documents, a strange "konqueror web
>> browser"
>> >> icon
>> >> >>> is on the desktop belonging to root and I can not put it in the
>> >> trash or
>> >> >>> delete it, this is definitely not a "point-n-click" system.
>> >> >>>
>> >> >>
>> >> >> I was not sure if those icons should be included by default on
>> >> Debian;
>> >> they can be removed easily enough through the use of Configure
>> >> >> Desktop->Behavior->Device Icons.  Simply deselect the icons you
>> don't
>> >> want
>> >> >> to see and they will magically disappear.  This feature is similar
>> to
>> >> the
>> >> >> old Microsoft system icons system; you cannot delete as you would
>> >> other
>> >> icons because they are part of the desktop itself.
>> >> >>
>> >> >
>> >> >
>> >> > On my laptops Lenny install I have icons, webcam, documents, home,
>> >> system and trash, all those icons belong to "user: jimmy", "group:
>> >> users", this has nothing to do with device icons, the Trinity Squeeze
>> >> system says all the icons belong to root and that is the problem.
>> >> >
>> >> > Even your Trinity on Ubuntu says the icons on the desktop belong to
>> me
>> >> "user: jimmy, group: jimmy" I can add and remove what I want.
>> >>
>> >> You can remove those icons from within the "Device Icons" page.  The
>> >> reasoning behind making them root owned (and therefore impossible to
>> >> delete from the desktop through "normal" means) is as follows:
>> >> OLD WAY: User A decides to remove an icon from the desktop.  He or
>> she
>> >> deletes said icon through the delete key and empties the trash bin.
>> User
>> >> A
>> >> later on decides that he or she wants the icon back.  Since it has
>> been
>> >> deleted, the only obvious way to get it back is to create a new
>> profile
>> >> from scratch (most people don't know about /etc/skel).  This is not
>> >> exactly user-friendly!
>> >>
>> >> OLD WAY: Developer A notices that one of the icons is broken on some
>> >> systems, so he decides to change the .desktop file responsible for
>> the
>> >> icon.  However, there is no way to propagate the change to existing
>> user
>> >> profiles, as /etc/skel is only copied on first login.  Therefore, the
>> >> developer has to instruct people to recreate their profiles, or copy
>> a
>> >> file from /etc/skel and change permissions on it.  This is not user
>> or
>> >> developer friendly, and acts to make Trinity less accessible to the
>> >> average user.
>> >>
>> >> NEW WAY: User B deactivates the icon through "Device Icons".  When
>> User
>> >> B
>> >> wants the icon back, it is available in "Device Icons" and can be
>> >> reenabled with a few mouse clicks.
>> >>
>> >> Developer B propagates a .desktop file changes to the system
>> directory
>> >> where the icons are stored.  All users receive the updated icon
>> .desktop
>> >> file transparently.
>> >>
>> >> What I can do is to change the default under Debian to not show the
>> >> icons
>> >> by default, however I would like some input from the other Debian
>> users
>> >> on
>> >> this list as well.  Thoughts?
>> >>
>> >> Tim
>> >>
>> >>
>> >>
>> > I think the technology is sound but the user experience is probably
>> > non-intuitive.  I thought about capturing the delete and turning it
>> into
>> > a disable but that would leave the user ignorant of how to restore it.
>> > I wonder if there should be a context menu item for "Configure Desktop
>> > Icons" which would point to Device Icons.  I also assume it is all
>> > configurable via rc files in Kiosk mode.
>>
>> Yes.
>>
>> > Perhaps the menu item should be "Enable/Disable Desktop Icons" or we
>> may
>> > simply make it pertain to the specific icon and have a "Hide This
>> Icon"
>> > context menu item.  That would still leave users ignorant of how to
>> > restore it but would probably be the most intuitive.  Just my two
>> cents
>>
>> The best way to handle this might be to trap the delete, and pop up a
>> message box with a quick description of how to restore the icon.
>> However,
>> I'm not sure that such a change can be made for 3.5.12 due to the
>> freeze.
>>
>> Thoughts on this method?
>>
>> Tim
>>
>>
> That sounds reasonably intuitive.  The primary end user behavior (press
> or click delete) is preserved - John
>
>

OK, it has been implemented in revision 1178835.  Binary packages will be
available within 24 hours.

Tim