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 think this statement needs to be examined a bit. The "special mechanism"
required in the server concentrates a well bounded problem in a single
place. The alternative, in the case for all quantities which can be set
but cannot be retrieved, is for every client ever written to stand on its
head to keep track of extra information. If we were talking about a world
of clients which were not supposed to cooperate with one another, that's
possibly (but I doubt it) justifiable. But in the X world, where cooperation
among clients is encouraged, it makes no sense at all.
It seems to me that one should add the capability to retrieve any
quantity which can be set as soon as possible. Otherwise, you are requiring
untold hundreds (thousands? millions? well...) of programmers, now and in
the future, to drag around extra baggage because of a deficiency in the
server.
Furthermore, all servers are required to supply at least one font. Presumably
this is the "default". Why can't the server allocate an id for it just like
it does for other clients? Consider the server itself client #0. At server
start up, the server should allocate all of the default id's (font, gc, etc).
Whenever a client makes a connection, automatically grant it the default
set of id's, to which it appends its own private ones. Doesn't this already
happen anyway, at least to some extent, when one references XDefaultGC(dpy,scn)?dshr@SUN.COM (David Rosenthal) (12/09/88)
No-one should ever do anything with the default font. The only reason it exists is to prevent there being a "No-font-selected" error. In fact, there is absolutely nothing that you CAN do with the default font reliably. You certainly cannot display any characters with it, since you cannot predict the encoding it uses. I'm willing to bet that your code assumes that the encoding for the default font is ISO Latin-1. Note that not even my Hello World program, which was trying to be as simple as possible, tried to use the default font. David.
dshr@SUN.COM (David Rosenthal) (12/09/88)
Actually, my last mail was too optimistic. The protocol spec says that the font you get when you create a GC is server-dependent. It does NOT say that you get the same font every time. Therefore, the concept of "the" default font does not exist. The fact that current servers normally provide new GCs with the same font is an artefact of their implementation. If "the" default font had existed, the correct thing to have done would have been to have supplied its ID during the connection handshake. But, since it doesn't exist, there is no need for this (nor for inventing a special mechanism to assign an ID). David.
asente@decwrl.dec.com (Paul Asente) (12/10/88)
>No-one should ever do anything with the default font. The only reason it >exists is to prevent there being a "No-font-selected" error. The toolkit needs some sort of default font for resource conversions. Part of the toolkit philosophy is that for any resource type there is some value that is guaranteed to work. Currently to support this with fonts, it resorts to the totally unreliable expedient of using "fixed" as the default font. This could be provided by either expanding the protocol to allow a GContext anyplace it allows a Font (as it does in XQueryFont), or having some special resource ID to refer to the default font, as someone else suggested. -paul asente asente@decwrl.dec.com decwrl!asente
dshr@SUN.COM (David Rosenthal) (12/12/88)
> Part of the toolkit philosophy is that for any resource type there is some > value that is guaranteed to work. What exactly does "guaranteed to work" mean in this context? Will produce intelligible results? In that case, something needs to be said about the encoding. > Currently to support this with fonts, > it resorts to the totally unreliable expedient of using "fixed" as the > default font. > Since the toolkit app almost certainly assumes that "guaranteed to work" means "has ISO Latin 1 encoding", a simple change from the string "fixed" to whatever the string is that selects an ISO8859-1 encoding but no other font properties will do the trick. Note that this is not "guaranteed to work", but in the cases where it will fail the toolkit application will fail too, because its assumption about usable encodings is false. > This could be provided by either expanding the protocol to allow a > GContext anyplace it allows a Font (as it does in XQueryFont), or having > some special resource ID to refer to the default font, as someone else > suggested. > I've got news for you. It'll be quite a while before there's a protocol rev. You have to learn to live with things the way they are. Fortunately, in this case its really easy. Nevertheless, the first of your ideas is pretty good.... David.
pds@quintus.uucp (Peter Schachte) (12/13/88)
In article <976@bacchus.dec.com> asente@decwrl.dec.com (Paul Asente) writes: ... >This could be provided by either expanding the protocol to allow a >GContext anyplace it allows a Font (as it does in XQueryFont), or having >some special resource ID to refer to the default font, as someone else >suggested. How about having XLoadFont(display, "") return The Default Font? It's at least somewhat consistent with XOpenDisplay("") returning the default display. I hope we could be guaranteed a few things about this font. It would sure be nice if there were a way to write portable code that displays text without having to scan the list of available fonts. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
karlton@decwrl.dec.com (Philip Karlton) (12/13/88)
In article <8812112322.AA07917@devnull.sun.com> dshr@SUN.COM (David Rosenthal) writes: >> Part of the toolkit philosophy is that for any resource type there is some >> value that is guaranteed to work. > >What exactly does "guaranteed to work" mean in this context? Will produce >intelligible results? In that case, something needs to be said about >the encoding. I believe that "guaranteed to work" in this case means generates a value that can be used by the client without risking getting an X error. Yes, it is true that there are no guarantees in this case that the text is readable. It is the case however that a well chosen default font by the server can allow some relief to developers early in the process. This kind of information (default font choice) does not belong in the intrinsics layer. Having simple clients work serendipitously is not a bad idea. PK