Bug 88626
| Summary: | Cursor selection and management begs for improvement | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Michael Lee Yohe <michael> |
| Component: | control-center | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | mitr |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-05-31 19:34:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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) 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) 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) |
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: