For information about how to run X windows: X11Doc.tioga

For client programmer information, see: X11ClientsDoc.tioga

For XTk information, see: XTkDoc.tioga

For implementor information, see: X11ImplDoc.tioga

/PCedar2.0/top/X11-Suite.df

/PCedar2.0/top/X11TIP-Suite.df

/PCedar2.0/top/X11Viewers-Suite.df

/PCedar2.0/top/X11Selections-Suite.df

/PCedar2.0/top/Slate-Suite.df

/PCedar2.0/top/PseudoKeyboard-Suite.df

/PCedar2.0/top/ScreenSpy-Suite.df

/PCedar2.0/top/PopUpMenus-Suite.df

/PCedar2.0/top/SharedPaint-Suite.df

/PCedar2.0/top/X11Eval-Suite.df

Major release of the X11 client software. Supports migrating widgets.

On Xl level:

On XTk level:

X11Viewers

Al other applications

Application have the choice whether and how it supports migration. I believe the major applications will support migration by creating new widgets on a different connection. The mechanism implemented here is a poor applications choice, where migration is built in and free, but limited in power. All supported widget classes support this migration method. All my application support some migration.

Think of migration as un-realize, followed by binding a new screen, followed by re-realize. Its main difficulty is that asynchronous terminations must terminate clean, so that widgets could be re-used safely.

Clients do still have the option to use direct X level features. They must be aware that on un-realize all screen dependent information has to be abandonned. This is easier as it sounds; e.g X11Viewers and X11Selections were the only applications where this applies. While enabling migration was a major update, it is nevertheless not expensive when not used. It was a important to make it sufficiently lightweight to not scare any potential XTk users which don't explicitely need that feature.

Screen dependent features are removed when an old screen is forgotten instead of initialized when a new screen is introduced. This scheme has been selected so that silly applications without migration support do not need to set screen dependent features in a callback, but could do it directly at widget creation time.

Stop reading here.

This is for my log and for client programmers.

I believe the number of lines of code did decrease !

Name changes:

New public interfaces

New functionality added to existing packages

New public interfaces with new functionality.

XTk

Selection of displays or predefine geometry:

XTkFriends

XTkShellWidgets

XTkBitmapWidgets

XTkDB and geometry handling

Xl

XlTQOps

XlRecycleMotionEvents

XlBitmap

XlConventions

XlICCCMTypes

X11Viewers

X11TIP

X11SelectionOwner

Slate, ScreenSpy, PseudoKeyboard

New commands

CBitmapReader

Removed packages

Some bug fixes.

Some code for Icons.

Input-focus

Icons

New package to read bitmaps in X11's horrible format for bitmap files.

Of course suns icon editor uses a different, actually nicer, but not documented format. Tough luck, but I have chosen the better documented format (Writing scanners is not my idea of having fun; one is enough).

New conveniance procedure to handle some un-interesting but mandatory targets.

Bug fix: No more raises an error when the connection dies while a transfer is in progress. This scenario really used to happen in one of my applications.

Bug fix: Deals more graceful with applications aquiring for selection ownership before a time-stamp is initialized. Even if explicitely forbidden by ICCCM, some people (like me) did yield to the temptation to write such applications (the time-stamp allows to prevent a racing condition, which in that particular application didn't bother me).

All debugging done with druid and print statements; please somebody make the patch "meadow" larger.

when it means the Cedar Xlib library. X11 now is reseved for the window system.

when it means a command.

when it means a demo program.

when it means a program used for multiple levels.

A demo program from the viewpoint of Xl and XTk

This is logically lower then Xl.

Even in cases where the old name forgot the Tk, like X11Collections;

XTk is the Cedar Xt aequivalent.

If you have more than just 2 or 3 files to adapt, you might try to use TransTioga for the renaming.

Some procedures are named more closely like the X requests they are implementing. (Even if the implementation might have been put on a higher level). The idea is to make the learning curve for using Cedar Xl instead of C XLib faster.

PolyText8 (new from Extras, parameters nicyfied)

ListFonts (Instead EnumerateFonts; added parameter)

CreateConection has applicationKey parameter to handle defaulted servers.

LastTime new procedure.

XPropInfo new procedure.

Now takes advantage that the X Server sends replies and error messages in the right order (It used to take them in any order. This is a substantial simplification!!)

Now handles replies of arbitrary length. (This was previously limited to 2**15-8, motivated basically by the maximum length for REF TEXT's)

Events with equal structures now use the same data type. Using "WITH event SELECT FROM" is discouraged. Better usage is "SELECT event.type FROM" and later NARROW for the event. This is typically faster.

"state" in events has more meaningful type; new comment that "state" is from immediately before the event is generated.

EventHandler type replaced by EventSet type.

Match has separate field for proc and events. (Feels more naturally)

keymapNotify event has pointer to previous event.

New concept of extending requests with details parameter. Among others this allows specification whether the request should be synchrounous and how to deal with reported errors.

This is particularly aimed at implementors of window managers or ICCCM selections, which must access windows owned by other connections. Errors caused by disappearing clients can now be located and caught at the right spot.

Now an opaque type. New procedures IsGCContext, NarrowGCContext. New interface XlGContextOps to remove the more esoteric functions from Xl.

More dummy elements to make mask fill words for more efficient code.

Implementation: Inlined to allow constant folding.

Remembers value on server (It used to remember only whether value was equal or not). This should speed up ImagerX11 a little.

Now an opaque type. New procedures IsFont, NarrowFont.

DF: Standard places...

Documentation: A lot.

X11Bitmap: new interface

X11Cursor

Some new widget classes

X11RemoteCedar (PrincOps)

X11Viewers (PCedar)

Boston, Massachusetts

14-16 January 1991

If you don't want to read it all, I consider the section about a font server to be the most important one.

I apologize if this report is too opinionated, but if you want a less subjective trip report you can read the conference announcements instead.

I think the program committee did a good job. Many talks were quite good. The talks were reasonably grouped so I didn¹t have to run in and out too often.

This looked like the year of the interactive user interface builder.

I have chosen this tutorial for two reasons.

I think they did a nice job. However, I would not like to have to use X windows from Ada. It all felt far too much like pioneering. Among other things, they are funded to do the specifications; but not so for the testing. Handling of errors reported by the X server seems a little underpowered.

I tried to mention some of my interoperability concerns to the implementors, but I thought they did not really understand my problems. I might not have explained myself clearly enough.

Their approach is to use inter-language calling to C for the XLib level, but to provide a native Ada implementation of the toolkit level stuff. They tried to use the exact same specification for a toolkit as the standard intrinsics in C. They use the C specification to reduce work, but do not really guarantee binary compatibility.

Two different companies have solved the missing procedure variables problem in two different ways. They have to make a module for each procedure type.

There were free books about Postscript. However there were less books than tutorial participants. You really should have seen that frenzy... People were shaking and tearing the books out of each others hands. (I didn't get one).

There were two speakers, and both knew what they were speaking about. One of them had a free ride on my nerves for behaving like a sales person.

I wish they had put more emphasis on the protocol instead of the C language interfaces.

If they standardized the display postscript protocol but not the server extension doing the actual imaging, we¹d have an immediate business opportunity providing an alternative server (I think the X consortium and Adobe differ on the point whether an implementation is required).

(Chris Kent made some more remarks about display postscript).

A very inspiring lecture on how to and how not to do user interfaces. His paper is worth reading. It is also available in UnixWorld August 1990.

Nice work taking advantage of using the same language to do programming and data. By using text as data and programs, he can even access widgets of other applications and has tremendous power with little code. (When I'm in a bad mood I call it the C programmer's lisp; when I'm in a good mood I admire this work).

I had no chance to ask John about debugging or fire walls.

They found a problem and rightfully complained. For my taste this talk was much too narrowly focused on the current Xt intrinsics. They basically require better documentation. The Cedar/Mesa toolkit does not share this particular problem due to different widget creation semantics.

Mark basically proposes to put the emphasis not on the creation of control panels and menu part, but on the actual graphics of the application. I think he is essentially right, and did good work. However, I think his example program with Chinese fonts was extremely counter-productive.

Jim pleaded for more customization. Jim's examples of when customization is useful and absolutely not anticipatable by the program authors, were quite convincing. It is a pity he failed to show when there is too much of a good thing.

There is a real need for this kind of work. But I cannot help myself for not being excited. Maybe I'm too old-fashioned and like to see the firewall between programmers customizing an application, and users customizing the same application.

As a talk it was quite good, but I prefer to make more general remarks.

My feel is that X windows is heading the wrong way here, but I am definitely not an expert. They are not providing enough of their own standards but rely on Ansi C locales. It looks to me as if they want to switch what language the computer is using, instead of enabling an application to use multiple languages simultaneously. (They do know better, but they don't know how).

I think some multilingual capabilities ought to be required of people speaking about multilingual computing; I think it would provide some additional perspective that might currently be missing for many native English speakers.

I don't remember what they said. (See Chris Kent's addition)

My personal feeling is that they are definitely on the wrong track. Too much actual functionality is required from the server. I'd prefer a window server act more like an arbiter of how different applications can cooperate using the same display.

Too bad, but I think we at Xerox ought to monitor this work. There is quite some overlap between the applications they want to base on this Image Extension, and our DocuWorld frenzy. Even (or specially?) if this work is not to my liking, it might influence the way we have to do business.

PEX is a PHIGS standard for X windows. (For those who don't know PHIGS; this is a library to draw in 3D)

I'm not qualified to report on this, as I left some talks to prevent boredom. I then had a great discussion about Trexel with Mark Manasse in the hallway (Trexel is a window system from DEC SRC).

PEX has about 400 features. That's definitely more than fits my brain and I hope for something simpler.

Not very inspiring. They seem to have the most capable display hardware but nevertheless have problems implementing the X protocol. BTW: Jeff used to implement an X server for the Dandylion as a CSL summer project intern under Neil Gunther.

Jim Fulton gave a talk about font servers for X windows. While the current state might be considered poor by Xerox standards (e.g., no outline fonts yet; no rotations yet) I thought the basics made a robust and professional impression. I think they are on the right way, and that Jim did a good job.

The Font server is a server whose client is the X window server. The X window client will not see the Font server directly. Using the Font server will really allow applications to use X servers of different vendors, or X terminals with limited memory for fonts.

What the X consortium standardizes on is the protocol, and probably an example server. Some important problems are solved, at least partly. This Font server protocol will be able to deal with authentications. The need for an X server to deal with multiple font servers is already delt with (but maybe not optimal).

I consider tracking this work to be extremely important for Xerox. (But I am not volunteering myself). I also see three business opportunities.

BTW: They would like somebody to donate them scan conversion code for outline fonts...

The talk did more to scare me off than to show good work. This was wrong, as can be seen by reading about the meeting of the wmtalk group. I always have to remind myself that the thing wrong with Drag-and-Drop is not its implementation, but the fact that our user interface is different. X windows is supposed to implement mechanisms and not policy; but that is also true if somebody wants a mechanism for a policy I don't like too much.

A must to read for CSL's ParcPad crew.

They did some minor X extension to deal with pens, and a separate overlay plane for inking pen moves directly in the server. Please ask for a copy of the paper if you are working on ParcPad or pens. (Others may ignore it, after acknowledging that it was a good talk).

I don't know whether the native English speakers understood him, but I didn't. He showed pictures of amazing hardware completely filling up the room. Nevertheless, the demos were zippy.

Good common sense about separating services. They propose to make a different service for X and audio. Of course, a different service does not absolutely imply a different consortium.

Those of us who hoped for some insight into atomicity or transactional workings were disappointed. All he wanted was some way of synchronizing different applications, like sound and moving mouths in pictures.

On the good side: The proposed server extension is very small and easy to understand.

On the bad side: I think it won't work. Even when it works it is very easy to wedge the server.

Looks like good work, but I'm bored about an other widget creation library.

I was too tired and headed out for hallway discussions.

I was too tired to find out how it works. He uses a good extension language.

- X11R5 will do bit blit double as fast as X11R4.

- In no way will they do my favorite extension to let me access the framebuffer directly.

- He desperately wants information about how to drive the Sun GX hardware. If somebody has this information available, would he please send it to him or to me. I think it should be in CSL's and Sun's best interest to get faster X window servers.

The speaker promised it would not be like a sales talk. He and I must have sat in different rooms.

They consider Display Postscript "interesting."

I was bored. My concerns about interoperability have been ignored.

We had a meeting one evening.

Xerox was represented by folks from 5 different groups (If you consider Bill Janssen and me from the same group...).

I don't understand how the folks in SSU, which is making a server, can afford to miss sending somebody to the X conference.

My general impression was that those Xerox people attending would be more productive if they had a little bit more money, and that Xerox was saving at the wrong end.

Folks present

The wmtalk group is a discussion group within the X consortium, discussing issues like ICCCM.

Stuart Marks from Sun was leading that discussion. I was impressed by his professionalism.

There were lots of problems and the group did not have time to really settle any issue. Nevertheless Stuart Marks made sure that every issue got at least few minutes. The one big issue, Drag and Drop, was delayed till the afternoon. I'm sorry I had to leave early.

Very surprising to me was the large percentage of issues which have already actually occurred in Cedar/Mesa X software. I'm pleased, as many problems hitting us will get solved a reasonable way.

I got a chance to mention my favorite interoperability problem (A feature I thought to be useful for cheops). The group acknowledged the problem and asked me to follow up. I was told a similar problem occurs with input methods (Some feature to deal with multilingual input).

It was nice to see snow again. They don't remove it in Boston. Considered how little snow they had, the delays on the airport have been substantial.

I sat during an evening glued to the television.

I attended the DPS BOF session. Adobe and MIT do disagree on whether or
not an implementation is needed. MIT would like to have a sample
implementation that it can give away with every "official" extension.
Adobe doesn't want to give their implementation away, for obvious
reasons. At last year's X conference, I had several talks with people
from Sun which left me expecting to see a DPS extension from them based
on the NeWS interpreter by this year, but it hasn't happened. It still
might, but the Sun people seem more cautious. Steve Evans of Sun, who
heads either the NeWS or window systems group (I've lost track) was
there, and seemed to be trying to find out how to achieve a common
ground and gain acceptance for both systems.

Adobe is trying to emphasize the programmer's interface (similar to the
Imager interface) over the PostScript language itself. Sun is pushing
on the fact that they have PostScript, but they continue to ignore the
programmer's interface -- you have to write PS programs and send them
to the server. Of course, neither provides serious debugging or
development help .. but I think they got the point that that is a problem.

Jim Sandman's talk was just on the border of being a marketing talk for
Illustrator and Display PostScript. He went through all the
capabilities of Illustrator, and then talked about how they implemented
it on X. He only talked a little about the actual implementation, and
said that using DPS saved them about 3 months of effort. I asked him
what he meant by that 3 months after the talk, and he said that he
could have ported the stripped down PS interpreter that's in Macintosh
Illustrator in about 3 months, but they would then lose the ability to
do generalized EPS file preview in illustrations.

I would add that there is a mailing list for X fontserver discussions,
and that we should be represented there.

OI is a nice set of classes from Solbourne that make up an X toolkit.
It has the interesting property of emulating completely either Open
Look, OpenLook-3D, or Motif. It knows all the proprietary protocols
that they speak. The appearance is selectable at run-time, so that a
commercial firm can ship one binary to all customers, regardless of
which look-and-feel they are using. Interesting tension in the class
design, between subclassing and callbacks. I was able to build a mildly
different widget by subclassing one of the existing widgets, during the
evening BOF, and it seemed reasonable clean and quick. The crew at
Solbourne are committed to tracking changes to both standards as they
evolve.

There is some unreasonably complicated code to deal with the
unreasonably complicated Xt standard resource and translation
mechanisms. I asked why they didn't just junk that, and they replied
that it was too much of a standard to ignore. Apparently the various
.Xresource and application default files work in the same way as they do
under Xt-based applications.

A window manager, swm, is provided with OI that can also present any of
the three appearances, but still speaks all the private protocols all
the time. This means that you can run both Motif and XView
applications, and the window manager will know how to speak to both of
them properly. The window manager also has built in desktops, which can
be larger than the physical screen. Probably the best commercial window
manager.

This toolkit is being sold by AT&T, current $10K for a source license.
Solbourne will start selling binary versions directly in February. My
opinion is that this is a very interesting bit of technology for any
parts of Xerox that are interested in doing work on X with C++. Contact
your local Solbourne and/or AT&T rep for pricing and delivery.

This was a non-event, with about 8 attendees. I got into a long talk
with Dick Orgass at IBM and Tom Neuendorffer of the CMU ITC, about
putting ATK into Modula-3. Seems doable. Tom also tells me that Andy
Palay spent about 6 weeks fixing many of the problems with the Andrew
text widget, and that we'll be seeing these changes in about a month.

I too was impressed with how well Stuart Marks of Sun controlled this
meeting and brought order out of chaos.

This was a 5-hour session, trying to come up with a communication
protocol that would allow everyone to implement their favorite
drag'n'drop scheme. Some brain-dead proposals were dealt with summarily
(for example, IXI wanted to have the recipient of the drag receive a
note telling it what events initiated the drag, so it could decide what
to do. Upon someone pointing out that these events would have a
toolkit-specific meaning, everyone else decided that this was nonsense,
but we failed to convince the IXI rep.), others dragged on for quite
some time. Much of the time was spent in thinking of ways that drop
sites could register themselves in some way, so that they would not have
to be swapped into memory to highlight themselves as the dragged object
went over them. Rather, the draggee is in charge of doing all graphics
for highlighting of drag sites. This bogosity is because people are
running X on 286's with 2 MB of memory, and can't affort to swap another
client in to send it an event!

A summary of this will appear on the wmtalk list (visible at PARC in the
ATK bulletin board ext.X.wmtalk), along with the next round of proposals.

Mark Linton of Silicon Graphics chaired this meeting. The object of
this effort is to develop a 'next-generation' toolkit for X windows and
the C++ programming language. Bob Scheifler, the director of the X
Consortium, is strongly behind this work.

The notion is that the toolkit will be based on Interviews 3.0 (which is
still in beta test). Linton and Scheifler would like to address a
number of interestingly advanced issues with it, including threads,
garbage collection, structured multi-media documents, extension
languages, and multi-lingual support. Much of what they will actually
be able to accomplish will depend on what kind of people sign on to work
on this toolkit. The editor they are proposing to supply as a widget
sounds something like Tioga (levels, per-character attributes). Too bad
PARC isn't more interested in C++ work. Seems like a good way to get
advanced notions incorporated in an external toolkit which a lot of
people will use. SGI, H-P, and IBM seem to be the main contributors,
with DEC becoming more interested.

The big things for R5 of the MIT X server are going to be
device-independent color (using the TekCMS model), incorporation of the
MIT (really NCD) fontserver for loading fonts over the network (which
also uses the MIT Athena system Kerberos for authentication),
non-English capability, mainly on the input side, and the incorporation
of the Sample Implementation of the PHIGS extension to X (PEX), which
will provide a 3D rendering model in X. The PEX honchos seemed to think
that most people would use the immediate mode of PHIGS for rendering
only, handling events via the normal X event mechanism.

Keith Packard of the X Consortium staff (a reliable source) feels that
the R5 server is roughly twice as fast as the R4 server, with up to 15x
speedups in places. He'd *really* like to get some better description
of what's what on the Sun GX board so that it can run fast there, too.
Perhaps we could help there?

The alpha version of R5 will be shipped around Feb 15, with the beta
version scheduled for Apr 15, and the final version Jun 15. I will make
them available on a Xerox file-server if there is any demand.

Boston, Massachusetts

14-16 January 1991

If you don't want to read it all, I consider the section about a font server to be the most important one.

I apologize if this report is too opinionated, but if you want a less subjective trip report you can read the conference announcements instead.

I think the program committee did a good job. Many talks were quite good. The talks were reasonably grouped so I didn¹t have to run in and out too often.

This looked like the year of the interactive user interface builder.

I have chosen this tutorial for two reasons.

I think they did a nice job. However, I would not like to have to use X windows from Ada. It all felt far too much like pioneering. Among other things, they are funded to do the specifications; but not so for the testing. Handling of errors reported by the X server seems a little underpowered.

I tried to mention some of my interoperability concerns to the implementors, but I thought they did not really understand my problems. I might not have explained myself clearly enough.

Their approach is to use inter-language calling to C for the XLib level, but to provide a native Ada implementation of the toolkit level stuff. They tried to use the exact same specification for a toolkit as the standard intrinsics in C. They use the C specification to reduce work, but do not really guarantee binary compatibility.

Two different companies have solved the missing procedure variables problem in two different ways. They have to make a module for each procedure type.

There were free books about Postscript. However there were less books than tutorial participants. You really should have seen that frenzy... People were shaking and tearing the books out of each others hands. (I didn't get one).

There were two speakers, and both knew what they were speaking about. One of them had a free ride on my nerves for behaving like a sales person.

I wish they had put more emphasis on the protocol instead of the C language interfaces.

If they standardized the display postscript protocol but not the server extension doing the actual imaging, we¹d have an immediate business opportunity providing an alternative server (I think the X consortium and Adobe differ on the point whether an implementation is required).

(Chris Kent made some more remarks about display postscript).

A very inspiring lecture on how to and how not to do user interfaces. His paper is worth reading. It is also available in UnixWorld August 1990.

Nice work taking advantage of using the same language to do programming and data. By using text as data and programs, he can even access widgets of other applications and has tremendous power with little code. (When I'm in a bad mood I call it the C programmer's lisp; when I'm in a good mood I admire this work).

I had no chance to ask John about debugging or fire walls.

They found a problem and rightfully complained. For my taste this talk was much too narrowly focused on the current Xt intrinsics. They basically require better documentation. The Cedar/Mesa toolkit does not share this particular problem due to different widget creation semantics.

Mark basically proposes to put the emphasis not on the creation of control panels and menu part, but on the actual graphics of the application. I think he is essentially right, and did good work. However, I think his example program with Chinese fonts was extremely counter-productive.

Jim pleaded for more customization. Jim's examples of when customization is useful and absolutely not anticipatable by the program authors, were quite convincing. It is a pity he failed to show when there is too much of a good thing.

There is a real need for this kind of work. But I cannot help myself for not being excited. Maybe I'm too old-fashioned and like to see the firewall between programmers customizing an application, and users customizing the same application.

As a talk it was quite good, but I prefer to make more general remarks.

My feel is that X windows is heading the wrong way here, but I am definitely not an expert. They are not providing enough of their own standards but rely on Ansi C locales. It looks to me as if they want to switch what language the computer is using, instead of enabling an application to use multiple languages simultaneously. (They do know better, but they don't know how).

I think some multilingual capabilities ought to be required of people speaking about multilingual computing; I think it would provide some additional perspective that might currently be missing for many native English speakers.

I don't remember what they said. (See Chris Kent's addition)

My personal feeling is that they are definitely on the wrong track. Too much actual functionality is required from the server. I'd prefer a window server act more like an arbiter of how different applications can cooperate using the same display.

Too bad, but I think we at Xerox ought to monitor this work. There is quite some overlap between the applications they want to base on this Image Extension, and our DocuWorld frenzy. Even (or specially?) if this work is not to my liking, it might influence the way we have to do business.

PEX is a PHIGS standard for X windows. (For those who don't know PHIGS; this is a library to draw in 3D)

I'm not qualified to report on this, as I left some talks to prevent boredom. I then had a great discussion about Trexel with Mark Manasse in the hallway (Trexel is a window system from DEC SRC).

PEX has about 400 features. That's definitely more than fits my brain and I hope for something simpler.

Not very inspiring. They seem to have the most capable display hardware but nevertheless have problems implementing the X protocol. BTW: Jeff used to implement an X server for the Dandylion as a CSL summer project intern under Neil Gunther.

Jim Fulton gave a talk about font servers for X windows. While the current state might be considered poor by Xerox standards (e.g., no outline fonts yet; no rotations yet) I thought the basics made a robust and professional impression. I think they are on the right way, and that Jim did a good job.

The Font server is a server whose client is the X window server. The X window client will not see the Font server directly. Using the Font server will really allow applications to use X servers of different vendors, or X terminals with limited memory for fonts.

What the X consortium standardizes on is the protocol, and probably an example server. Some important problems are solved, at least partly. This Font server protocol will be able to deal with authentications. The need for an X server to deal with multiple font servers is already delt with (but maybe not optimal).

I consider tracking this work to be extremely important for Xerox. (But I am not volunteering myself). I also see three business opportunities.

BTW: They would like somebody to donate them scan conversion code for outline fonts...

The talk did more to scare me off than to show good work. This was wrong, as can be seen by reading about the meeting of the wmtalk group. I always have to remind myself that the thing wrong with Drag-and-Drop is not its implementation, but the fact that our user interface is different. X windows is supposed to implement mechanisms and not policy; but that is also true if somebody wants a mechanism for a policy I don't like too much.

A must to read for CSL's ParcPad crew.

They did some minor X extension to deal with pens, and a separate overlay plane for inking pen moves directly in the server. Please ask for a copy of the paper if you are working on ParcPad or pens. (Others may ignore it, after acknowledging that it was a good talk).

I don't know whether the native English speakers understood him, but I didn't. He showed pictures of amazing hardware completely filling up the room. Nevertheless, the demos were zippy.

Good common sense about separating services. They propose to make a different service for X and audio. Of course, a different service does not absolutely imply a different consortium.

Those of us who hoped for some insight into atomicity or transactional workings were disappointed. All he wanted was some way of synchronizing different applications, like sound and moving mouths in pictures.

On the good side: The proposed server extension is very small and easy to understand.

On the bad side: I think it won't work. Even when it works it is very easy to wedge the server.

Looks like good work, but I'm bored about an other widget creation library.

I was too tired and headed out for hallway discussions.

I was too tired to find out how it works. He uses a good extension language.

- X11R5 will do bit blit double as fast as X11R4.

- In no way will they do my favorite extension to let me access the framebuffer directly.

- He desperately wants information about how to drive the Sun GX hardware. If somebody has this information available, would he please send it to him or to me. I think it should be in CSL's and Sun's best interest to get faster X window servers.

The speaker promised it would not be like a sales talk. He and I must have sat in different rooms.

They consider Display Postscript "interesting."

I was bored. My concerns about interoperability have been ignored.

We had a meeting one evening.

Xerox was represented by folks from 5 different groups (If you consider Bill Janssen and me from the same group...).

I don't understand how the folks in SSU, which is making a server, can afford to miss sending somebody to the X conference.

My general impression was that those Xerox people attending would be more productive if they had a little bit more money, and that Xerox was saving at the wrong end.

Folks present

The wmtalk group is a discussion group within the X consortium, discussing issues like ICCCM.

Stuart Marks from Sun was leading that discussion. I was impressed by his professionalism.

There were lots of problems and the group did not have time to really settle any issue. Nevertheless Stuart Marks made sure that every issue got at least few minutes. The one big issue, Drag and Drop, was delayed till the afternoon. I'm sorry I had to leave early.

Very surprising to me was the large percentage of issues which have already actually occurred in Cedar/Mesa X software. I'm pleased, as many problems hitting us will get solved a reasonable way.

I got a chance to mention my favorite interoperability problem (A feature I thought to be useful for cheops). The group acknowledged the problem and asked me to follow up. I was told a similar problem occurs with input methods (Some feature to deal with multilingual input).

It was nice to see snow again. They don't remove it in Boston. Considered how little snow they had, the delays on the airport have been substantial.

I sat during an evening glued to the television.

I attended the DPS BOF session. Adobe and MIT do disagree on whether or
not an implementation is needed. MIT would like to have a sample
implementation that it can give away with every "official" extension.
Adobe doesn't want to give their implementation away, for obvious
reasons. At last year's X conference, I had several talks with people
from Sun which left me expecting to see a DPS extension from them based
on the NeWS interpreter by this year, but it hasn't happened. It still
might, but the Sun people seem more cautious. Steve Evans of Sun, who
heads either the NeWS or window systems group (I've lost track) was
there, and seemed to be trying to find out how to achieve a common
ground and gain acceptance for both systems.

Adobe is trying to emphasize the programmer's interface (similar to the
Imager interface) over the PostScript language itself. Sun is pushing
on the fact that they have PostScript, but they continue to ignore the
programmer's interface -- you have to write PS programs and send them
to the server. Of course, neither provides serious debugging or
development help .. but I think they got the point that that is a problem.

Jim Sandman's talk was just on the border of being a marketing talk for
Illustrator and Display PostScript. He went through all the
capabilities of Illustrator, and then talked about how they implemented
it on X. He only talked a little about the actual implementation, and
said that using DPS saved them about 3 months of effort. I asked him
what he meant by that 3 months after the talk, and he said that he
could have ported the stripped down PS interpreter that's in Macintosh
Illustrator in about 3 months, but they would then lose the ability to
do generalized EPS file preview in illustrations.

I would add that there is a mailing list for X fontserver discussions,
and that we should be represented there.

OI is a nice set of classes from Solbourne that make up an X toolkit.
It has the interesting property of emulating completely either Open
Look, OpenLook-3D, or Motif. It knows all the proprietary protocols
that they speak. The appearance is selectable at run-time, so that a
commercial firm can ship one binary to all customers, regardless of
which look-and-feel they are using. Interesting tension in the class
design, between subclassing and callbacks. I was able to build a mildly
different widget by subclassing one of the existing widgets, during the
evening BOF, and it seemed reasonable clean and quick. The crew at
Solbourne are committed to tracking changes to both standards as they
evolve.

There is some unreasonably complicated code to deal with the
unreasonably complicated Xt standard resource and translation
mechanisms. I asked why they didn't just junk that, and they replied
that it was too much of a standard to ignore. Apparently the various
.Xresource and application default files work in the same way as they do
under Xt-based applications.

A window manager, swm, is provided with OI that can also present any of
the three appearances, but still speaks all the private protocols all
the time. This means that you can run both Motif and XView
applications, and the window manager will know how to speak to both of
them properly. The window manager also has built in desktops, which can
be larger than the physical screen. Probably the best commercial window
manager.

This toolkit is being sold by AT&T, current $10K for a source license.
Solbourne will start selling binary versions directly in February. My
opinion is that this is a very interesting bit of technology for any
parts of Xerox that are interested in doing work on X with C++. Contact
your local Solbourne and/or AT&T rep for pricing and delivery.

This was a non-event, with about 8 attendees. I got into a long talk
with Dick Orgass at IBM and Tom Neuendorffer of the CMU ITC, about
putting ATK into Modula-3. Seems doable. Tom also tells me that Andy
Palay spent about 6 weeks fixing many of the problems with the Andrew
text widget, and that we'll be seeing these changes in about a month.

I too was impressed with how well Stuart Marks of Sun controlled this
meeting and brought order out of chaos.

This was a 5-hour session, trying to come up with a communication
protocol that would allow everyone to implement their favorite
drag'n'drop scheme. Some brain-dead proposals were dealt with summarily
(for example, IXI wanted to have the recipient of the drag receive a
note telling it what events initiated the drag, so it could decide what
to do. Upon someone pointing out that these events would have a
toolkit-specific meaning, everyone else decided that this was nonsense,
but we failed to convince the IXI rep.), others dragged on for quite
some time. Much of the time was spent in thinking of ways that drop
sites could register themselves in some way, so that they would not have
to be swapped into memory to highlight themselves as the dragged object
went over them. Rather, the draggee is in charge of doing all graphics
for highlighting of drag sites. This bogosity is because people are
running X on 286's with 2 MB of memory, and can't affort to swap another
client in to send it an event!

A summary of this will appear on the wmtalk list (visible at PARC in the
ATK bulletin board ext.X.wmtalk), along with the next round of proposals.

Mark Linton of Silicon Graphics chaired this meeting. The object of
this effort is to develop a 'next-generation' toolkit for X windows and
the C++ programming language. Bob Scheifler, the director of the X
Consortium, is strongly behind this work.

The notion is that the toolkit will be based on Interviews 3.0 (which is
still in beta test). Linton and Scheifler would like to address a
number of interestingly advanced issues with it, including threads,
garbage collection, structured multi-media documents, extension
languages, and multi-lingual support. Much of what they will actually
be able to accomplish will depend on what kind of people sign on to work
on this toolkit. The editor they are proposing to supply as a widget
sounds something like Tioga (levels, per-character attributes). Too bad
PARC isn't more interested in C++ work. Seems like a good way to get
advanced notions incorporated in an external toolkit which a lot of
people will use. SGI, H-P, and IBM seem to be the main contributors,
with DEC becoming more interested.

The big things for R5 of the MIT X server are going to be
device-independent color (using the TekCMS model), incorporation of the
MIT (really NCD) fontserver for loading fonts over the network (which
also uses the MIT Athena system Kerberos for authentication),
non-English capability, mainly on the input side, and the incorporation
of the Sample Implementation of the PHIGS extension to X (PEX), which
will provide a 3D rendering model in X. The PEX honchos seemed to think
that most people would use the immediate mode of PHIGS for rendering
only, handling events via the normal X event mechanism.

Keith Packard of the X Consortium staff (a reliable source) feels that
the R5 server is roughly twice as fast as the R4 server, with up to 15x
speedups in places. He'd *really* like to get some better description
of what's what on the Sun GX board so that it can run fast there, too.
Perhaps we could help there?

The alpha version of R5 will be shipped around Feb 15, with the beta
version scheduled for Apr 15, and the final version Jun 15. I will make
them available on a Xerox file-server if there is any demand.

Long list of small changes

-Bug fix in X11.EnumerateFonts (used to terminate most font names with a null char).

-Added procedure X11Extras.ListFontsWithInfo.

-Added special close down mode of X11Viewers for boardwalk (liveboard).

-X11Widgets.ShellWidgets by default explicitely request window manager to open the window.

-Bug fix: Double buffering switched on again.

-New X11FontCommandsImpl program (load it separately on need) with commands:

-Uses the new (3.4) PCR's method to cleanup shared memory identifiers.

-Changed cut of labels and paste to fields to work with secondary keysyms. This change was necessary so I could make key mapping which works for both, Cedar-Labels and sun openwindow tools. (Now sun is cheating and Cedar is clever)

-New .xmodmaprc file which does the Cedar keys compatible for sun's openwindow. (Neither an interoperability or cedar problem; sun tools simply didn't work with the old .xmodmaprc aimed at Cedar.)