garya@stan.com (Gary Aitken) (12/07/88)
Is there a good reason that the font identifier in the font structure returned from fontp = XQueryFont(dpy,XDefaultGC(dpy,scn))->gid) ; is not a valid font id? xterm (and how many other clients??) specifically avoids setting the font when it has to use the default font info. In addition, attempting to extract the font identifier for a default gc returns a 0xffffffff, which sometimes is accepted as a valid font identifier and sometimes is rejected: XGCValues gcvalues ; gcvalues.font = XDefaultGCOfScreen(XDefaultScreenOfDisplay(dpy))->values.font ; XChangeGC(dpy,existing_gc,GCFont,&gcvalues) ; When this fails, the error is always the same: X Protocol error: BadFont, invalid Font parameter Major opcode of failed request: 56 (X_ChangeGC) Minor opcode of failed request: 0 Resource id in failed request: 0xffffffff But when it succeeds, the value used is the same, 0xffffffff. Sun3, 4.2, V11R3 Gary Aitken ncar!boulder!stan!garya
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/07/88)
Is there a good reason that the font identifier in the font structure
returned from
fontp = XQueryFont(dpy,XDefaultGC(dpy,scn))->gid) ;
is not a valid font id?
It's the same old (tired) argument about resource id allocation being
a client responsibility, there's no a priori id to assign to it, it
would require special mechanism (deemed unnecessary) to assign an id
to it.
In addition, attempting to extract the font identifier for a default gc
returns a 0xffffffff
If you are reaching into a gc, you are writing non-portable code. The
gc structure in Xlib is supposed to be opaque, there is absolutely no
guarantee about how it's implemented.
which sometimes is accepted as a valid font identifier and sometimes
is rejected
If it succeeds, its probably a server bug.garya@stan.com (Gary Aitken) (12/09/88)
It's the same old (tired) argument about resource id allocation being
a client responsibility, there's no a priori id to assign to it, it
would require special mechanism (deemed unnecessary) to assign an id
to it.
I understand I'm not supposed to reach into the guts of the X structures.
The code in question is in a toolkit, not an application.
The X documentation states that gcs are scarce resources and should be
reused if possible; it's cheaper to change an attribute than make another gc.
Most supporting hardware agrees with this interpretation.
If a client/toolkit is trying to reuse a gc, changing only those quantities
which are different, it must somehow be able to restore a font to the server
default. Is there an accepted way to do this?
Otherwise, the only alternative is to keep track of which attribute sets were
created with the default font and using the appropriate default font/known
font gc as appropriate. Any systems analyst worth ten cents would barf all
over doing this....rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/09/88)
I understand I'm not supposed to reach into the guts of the X structures.
The code in question is in a toolkit, not an application.
A toolkit is part of the application, looking out from Xlib. You've simply
isolated the no-no.
If a client/toolkit is trying to reuse a gc, changing only those quantities
which are different, it must somehow be able to restore a font to the
server default. Is there an accepted way to do this?
You can use XCopyGC to copy it back from a GC known to have the default font.
A bit gross, I agree. Would have been nicer to provide a special value for
doing this.