trinity-users@lists.pearsoncomputing.net

Message: previous - next
Month: September 2010

Re: [trinity-users] Re: [trinity-announce] Trinity pre-release freeze

From: "John A. Sullivan III" <jsullivan@...>
Date: Thu, 23 Sep 2010 13:54:12 -0400
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