81088 - Need a way to control the cursors use by mozilla

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[TVL]

It may make sense to limit this to gtk instead of XP.

There needs to be a clean way for embeddors to supply the cursors used by 
mozilla.  On windows you can provide cursor resources, but on gtk the cursors are 
currently pulled directly from gtk so there's no way to make them match the 
cursors the embedding app is using.

(added pavlov at jud's request)

Comment 1

[Adam Lock]

Cut and paste from the email I sent just now.

--
I did some further digging and it may be possible to avoid changing Mozilla at
all. The function gdk_cursor_new that the GTK widget uses, calls
XCreateFontCursor which in turn loads the cursor from a special X11 font called
cursor.pcf. Change this font and the default cursors can be anything you like.

On my system the font is in /usr/X11R6/lib/X11/fonts/misc/cursor.pcf.gz

To see the glyphs, type "xfd -fn cursor". Which cursor corresponds to which
glyph is defined in gdkcursors.h.

The "raw" BDF version of that font is here:

ftp://ftp.x.org/pub/R6.6/xc/fonts/bdf/misc/cursor.bdf

The BDF is text with hex representing each glyph. Edit the file by hand or using
a tool such as xfed, xfbdfed or one of the other tools listed in these
resources:

http://cgm.cs.mcgill.ca/~luc/xsoftware.html

The new font can then be compiled into pcf by typing "bdf2pcf < cursor.bdf |
gzip -c > cursor.pcf.gz". Backup the old cursor file and replace it with the new
one. Restart X and test
--

Comment 2

[Adam Lock]

Attachment: Patch demonstrates how to set custom cursor shapes

Comment 3

[Adam Lock]

Attachment demonstrates how to use a custom cursor shape instead of the ones
defined in X11.

Comment 4

[TVL]

so does it make sense to add something like this to the baseline and pull the 
image maps (and hot spots & fg/bg colors) from preference/property files?

Comment 5

[Adam Lock]

Attachment: Updated patch demonstrates storing/retrieving cursor from prefs

Comment 6

[Adam Lock]

The prior patch shows how cursors may be stored in and retrieved from prefs. The
code for nsWindow::SetCursor searches for a pref called
"mozilla.widget.cursor.NNN" (where NNN is the cursor shape wanted), and if
present sets the shape from that rather than use the GDK default.

There patch still contains some test code which puts the sample shape into the
prefs in the first place. This is all contained in the function
PutSampleCursorIntoPrefs. The result of calling this function is an entry in
prefs.js:

user_pref("mozilla.widget.cursor.0",
"EAAAABAAAAAIAAAACAAAAAAAAAD//wAAAAAAAAAAAAAAAAAA//8AAIABQAIgBBAICBAEIIJBQYJBgoJBBCAIEBAIIARAAoABgAHAA2AGMAwYGIwxxmNjxmPGxmOMMRgYMAxgBsADgAE=");

The binary data is base64 encoded. If the pref is system wide, it would have to
go in all.js instead but would otherwise behave much the same.

Comment 7

[TVL]

How do we handle the endian issues for values in nsGTKCursorInfo?  the pref would 
have to be platform dependent.

also, are there any performance issues since the decode would have to happen each 
time the cursor was changed?

does it make sense to have nsWindow (for GTK) preload all the cursors (or load on 
demand and cache), and expose an API that an embeddor could call to seed the 
cache with premade gtk cursors?  or do we have to make a simple cursor service 
and have them pulled from that service, so replacing cursors would be done by 
creating one of these services  (it would take the place of the switch 
statement)?

Comment 8

[Adam Lock]

If endian is an issue and you don't want cursors to be platform specific, 
then width, height, x & y could be turned in gchars. You may still run into 
structure packing & byte alignment issues unless that can be controlled somehow. 

The alternative is to use external XPM files and point the prefs to those files. 
This would require more prefs per cursor, one for each of the fields in the 
structure.

Performance does need to be addressed. Probably pointers should be cached 
after being created.

Comment 9

[TVL]

i take it add and exposing a cache doesn't sound good? :) it would probably be 
the least amount to change in the window class, and would let people with the 
need to control them have a somewhat clean way to get in there and change things.

otherwise it sounds like we have to go the route of packing the structure or a 
few prefs per cursor (like you said).

Comment 10

[Peter Trudelle]

Pav, do you still own GTK stuff?  Do you want to take this, or recommend someone
else?

Comment 11

[Stuart Parmenter]

adding blizzard to the cc list.

Comment 12

[Adam Lock]

Attachment: Latest version, adds caching & almost (non-functioning) support for cursors stored in xpm files

Comment 13

[Adam Lock]

My latest patch demonstrates how cursors could be cached so loading only occurs
the first time they are referenced.

Endianess issues have been temporarily resolved by making all members in
nsGTKCursorData into gchars. This may still hit packing issues so the proper way
would be to implement some proper persistence routines.

All the cursor loading has moved into GetCachedCursor. You may specify a cursor
either like this:

mozilla.widget.cursor.N

Where N is the cursor ID, in which case the cursor is loaded from a binary pref.

Or you can specify it like this:

mozilla.widget.cursor.N.shape
mozilla.widget.cursor.N.mask
(and optionally)
mozilla.widget.cursor.N.x
mozilla.widget.cursor.N.y
mozilla.widget.cursor.N.width
mozilla.widget.cursor.N.height

The shape and mask point to 2 colour XPM files. In theory the values x, y, width
& height could be inferred from that.

Note that while the code for loading pixmaps from XPM works, there is a problem
setting the cursor from the pixmaps and I haven't resolved this yet. The problem
is that X Windows requires cursors to be monochrome (1-bit) and while I am
loading some valid 2 colour XPM files, gdk_pixmap_create_from_xpm always returns
the XPM using the screen depth (e.g. 24 bits). This causes the
gdk_cursor_new_from_pixmap to fail in the call to X.

Does anyone know how I can turn these pixmaps into 1 bit depth pixmaps? I have a
little bit of code in there that tries to do it, but it fails as well.

This problem may only affect the GDK/GTK port running on X.

Comment 14

[Peter Trudelle]

No time left to consider this in the current release cycle, ->future

Comment 15

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 16

[Peter Trudelle]

Mass moving all of my open Nav/toolkit bugs to new owner.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 18

[Neil Deakin]

Don't think this is valid anymore.