Bug 88626 - Cursor selection and management begs for improvement
Cursor selection and management begs for improvement
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: control-center (Show other bugs)
9
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Ray Strode [halfline]
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-11 11:50 EDT by Michael Lee Yohe
Modified: 2007-04-18 12:52 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-31 15:34:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Lee Yohe 2003-04-11 11:50:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030102

Description of problem:
With one of the features advertised about Red Hat Linux 9 being the new mouse
cursor support featured with XFree86 4.3, there seems to be a differing
philosophies about how to add and implement new cursor themes for Red Hat Linux 9.

Xcursor's documentation (man Xcursor) discusses briefly about the new system and
how to add cursors to your XFree86 session.  Red Hat Linux 8.0 allowed for the
user to select four different cursor themes (provided via Gnome's control
center).  Black and white, small and large were available.

The same goes for Red Hat Linux 9.  But, if one adds a theme to their ~/.icons
directory and makes it the default theme, it will appear briefly upon login only
to be overridden by the last selection made in the control-center.

I believe this is because there are two different "cursor managers" at work. 
Microsoft's method of cursor management is nice and slick - Red Hat's approach
to finding out where change your cursor is also nice and slick.  However, added
themes in ~/.icons do not appear in the control panel making them unavailable
for use without manual editing of configuration.  Microsoft has never been
chided for not being able to create an easy to use and understand interface.

It really is a nice first try, but the applets need to be modified to take
advantage of the new advertised feature.

Version-Release number of selected component (if applicable):
control-center-2.2.0.1-9

How reproducible:
Always

Steps to Reproduce:
1. see description
2.
3.
    

Actual Results:  Control center overrides any XFree86 native configuration
changes to mouse cursor selection.

Expected Results:  No manual modifications required.  One unified applet needs
to recognize the new cursors (in the global /usr/share/icons or ~/.icons
directory), offer a preview display, and allow selection.

Additional info:
Comment 1 Mike A. Harris 2003-08-21 04:14:58 EDT
This is IMHO a problem needing solving at a higher level than Red Hat
specifically.
This problem should be solved at XFree86.org first, and GNOME/KDE projects
in a sensible way, rather than each distribution trying to solve the problem
in their own distro specific way.  If the XFree86 people do not consider such
problems to fit into their envelope, then it is a problem that needs to be
solved by a standards body like freedesktop.org

Here are the different aspects of this, as I see it:

- Standardization on where the cursors go is one aspect.  The stock XFree86
  source code comes up short here by neglecting directory structure common
  throughout the rest of Linux standardization efforts.  I've corrected this
  in Red Hat XFree86 by patching it to improve the default cursor search
  path.  This was done with discussion with Keith Packard, and my patches
  should have gotten integrated into 4.3.0 stock, but got overlooked for
  one reason or another.  Future XFree86 and future upstream Xcursor libs,
  will have my changes.  In general, once this is applied, all Linux OS
  distributions should be using /usr/share/icons and ~/.icons

- The cursors should be runtime changeable and stick.  The current Xcursor
  implementation does not do this.  If you change cursors, they will get lost
  unless you restart X.  That is not a bug, but it is a side effect of the
  current implementation.  A better or more improved implementation from
  upstream is needed to address this.

- A sane user friendly tool to select mouse cursors is needed, both on a
  system-wide basis, and per-user.  IMHO the best place for this to happen,
  is in the desktop environment space.  GNOME/KDE in other words, as opposed
  to some XFree86 tool (done in Xt/Xaw, ick.  No way.)  For such a tool, this
  is something for the GNOME and KDE projects to handle IMHO in a sane graceful
  way, and is not a Red hat specific thing.  It might be implemented by someone
  at Red Hat perhaps, but IMHO it should be in GNOME/KDE bugzilla so that
  others are looking at this as well.

- There are some other problems and glitches with the new cursor code also,
  some of which are likely generic X server bugs, and others which are video
  driver specific.  Those should be reported to XFree86.org directly in their
  bugzilla.  I know of only a problem in the i740 driver at present, and I'll
  probably fix that one myself sometime before long.

In order for the cursors to be as friendly and useful as in Windows, I believe
all these aspects need to be taken into account.  There is also some
interdependancy.  ie: a tool can only find cursors if there is a standardized
location for them.

I agree with your request, but I think you should make the request(s) to a
 wider audience than just Red Hat developers.  ;o)

Comment 2 Ray Strode [halfline] 2005-05-12 11:46:52 EDT
Hi,
I'm going through bugs assigned to me and attempting to clean some of the older,
fixed ones up.

This bug hasn't changed in over a year old now.  Are you still seeing the problem? 

(This a batch message is being sent to all my bugs that haven't changed in a year)
Comment 3 Ray Strode [halfline] 2005-05-31 15:34:09 EDT
Hi,

This bug has been in the NEEDINFO state for at least a couple of weeks now.  I'm
going to close the bug, but if you can provide the required information feel
free to open a new report.

Thanks.

(This is a mass message being sent to a bunch of bug reports)

Note You need to log in before you can comment on or make changes to this bug.