barnett@grymoire.crd.ge.com (Bruce Barnett) (02/22/90)
I am trying to write an XView application that is very tolerant of multiple environments. However, when I run this application on an X terminal without the OpenLook cursor "olcursor" installed, the program terminates with an error. I would like to know if there is any way to prevent a fatal error in XView if the cursors aren't there. (I believe I have programmed around the case when the default font is missing). -- -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
hvr@kimba.Sun.COM (Heather Rose) (03/06/90)
In article <5452@crdgw1.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes: >I am trying to write an XView application that is very tolerant >of multiple environments. > >However, when I run this application on an >X terminal without the OpenLook cursor "olcursor" installed, the program >terminates with an error. xset [-display display] +fp $XVIEWHOME/lib/X11/fonts/xview/misc does not add the open look fonts to your X11 server? All X11R4 compatible servers should have these loaded in the default locations... >I would like to know if there is any way to prevent a fatal error >in XView if the cursors aren't there. (I believe I have programmed >around the case when the default font is missing). I imagine you might be able to get it to work, but you'll need to create bitmaps from each font object first. The xv_set() command for the cursor can take an X11 bitmap as the object. We'll have to look into building that into the library. the xv_find command can be used to determine whether or not a font is available. The O'Reilly book has an example for the case of fonts. Regards, Heather
barnett@grymoire.crd.ge.com (Bruce Barnett) (03/07/90)
In article <132555@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: |>However, when I run this application on an |>X terminal without the OpenLook cursor "olcursor" installed, the program |>terminates with an error. | |xset [-display display] +fp $XVIEWHOME/lib/X11/fonts/xview/misc | |does not add the open look fonts to your X11 server? All X11R4 compatible |servers should have these loaded in the default locations... We have several different types of X terminals. There are several different ways to download the fonts. Also - some fonts have to be built to match the architecture, and installed by the system manager. In another case, I had to FTP the fonts to a Macintosh and run a Mac program before I could run the XView application. This is not something I expect end users to know how to do. The point is - OpenLook fonts are currently non-standard. The mechanism needed to download the fonts are non-standard. If I write an OpenLook application that will run in a heterogeneous environment, I cannot say it will run on any X terminal or server. The system administrator or principle user must do something special before they can run the OL application. I no longer have a simple X program that can be used by anyone with a simple server. I have to teach secretaries, corporate managers, system managers etc. the commands needed to download the fonts. Each product might require a new procedure. Fonts aren't really the problem. I can specify "standard" fonts. The problem is "olglyth" and "olcursor". These "fonts" are hardwired into the application. I would like to have a means that a) detects if "olglyth" and "olcursor" are available. b) if not, then do something in my program that will allow the program to be useful, but with limited functionality. I could decide not to use a scrollbar, if olcursor were not available. Or use a server image, if I knew how. I can do step a. But it might be a useful extension to XView if I can either provide the fonts from the client side, or download the fonts into the server. -- -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
hvr@kimba.Sun.COM (Heather Rose) (03/07/90)
In article <5818@crdgw1.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes: >In article <132555@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: > >|>However, when I run this application on an >|>X terminal without the OpenLook cursor "olcursor" installed, the program >|>terminates with an error. >| >|xset [-display display] +fp $XVIEWHOME/lib/X11/fonts/xview/misc >| >|does not add the open look fonts to your X11 server? All X11R4 compatible >|servers should have these loaded in the default locations... > >We have several different types of X terminals. There are several >different ways to download the fonts. Also - some fonts have to be >built to match the architecture, and installed by the system manager. All the X11 servers do not use the standard utility bdftosnf to compile the font files? The XView source includes rules for compiling the fonts for X11R3 based servers. The X11R4 based servers should already have these fonts compiled in. Once the fonts have been installed, it is just a matter of adding them with "xset +fp ..." or use "xset rehash" if they are installed in the same directory as the other fonts. I suppose the whole fonts issue will become simplified when the font server concept is finalized, implemented, and adopted... >In another case, I had to FTP the fonts to a Macintosh and run a Mac >program before I could run the XView application. This is not >something I expect end users to know how to do. > >The point is - OpenLook fonts are currently non-standard. >The mechanism needed to download the fonts are non-standard. How so? We provide them in the same format as any other X11 supplied font. We provide the same rules for compiling them as any other X11 font. We also add the font to the font database in the same way as any other X11 font. I do not understand how bdftosnf and xset can be considered non-standard... >If I write an OpenLook application that will run in a heterogeneous >environment, I cannot say it will run on any X terminal or server. >The system administrator or principle user must do something special >before they can run the OL application. >I no longer have a simple X program that can be used by anyone >with a simple server. I have to teach secretaries, corporate managers, >system managers etc. the commands needed to download the fonts. >Each product might require a new procedure. >Fonts aren't really the problem. I can specify "standard" fonts. > >The problem is "olglyth" and "olcursor". These "fonts" are hardwired >into the application. I would like to have a means that > a) detects if "olglyth" and "olcursor" are available. > b) if not, then do something in my program that will > allow the program to be useful, but with limited functionality. > > I could decide not to use a scrollbar, if olcursor were not > available. Or use a server image, if I knew how. > >I can do step a. But it might be a useful extension to XView >if I can either provide the fonts from the client side, or >download the fonts into the server. OK. Perhaps what you mean by "non-standard" is that X11 servers that came out before X11R4 do not download the OpenLook fonts by default? That you need to run bdftosnf or xset at all... This is a valid request for change--if the toolkit cannot find the OpenLook fonts, it loads in bitmap data and uses that instead. The only problem we would have with this is increasing the library size. But perhaps we could read in the files at run time if needed. But then there's the problem again needing some extra files to run a program. The advantage of using a font over bitmaps is that many XView applications can share the same OpenLook glyph images---by using the same font. When using bitmaps, you either have to download the bitmap over the wire each time you draw (cheap on the server) or allocate server side bitmaps for each application (cheap on the wire and potentially disatrous for the server). Is there a way to allocate server pixmaps as sharable objects? i.e. one client allocates a pixmap as "read-only" so other clients could use it. That would make the problem much easier to solve. Regards, Heather
barnett@grymoire.crd.ge.com (Bruce Barnett) (03/08/90)
In article <132607@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: |All the X11 servers do not use the standard utility bdftosnf to |compile the font files? The XView source includes rules for compiling |the fonts for X11R3 based servers. In one case we had a X terminal from company "Q" This required us to have a machine from that company to compile the fonts into the right mode. The system that is providing boot service for our X terminals is an Encore. It's version of native font formats were not the same as the format neded by that particular terminal. Also - as I said - I had to FTP the fonts to a Mac and convert them myself - using a Mac utility. (Finder - not A/UX). Our world is not heterogenous. |>The point is - OpenLook fonts are currently non-standard. |>The mechanism needed to download the fonts are non-standard. | |How so? We provide them in the same format as any other X11 supplied font. |We provide the same rules for compiling them as any other X11 font. We also |add the font to the font database in the same way as any other X11 font. |OK. Perhaps what you mean by "non-standard" is that X11 servers that came |out before X11R4 do not download the OpenLook fonts by default? That you |need to run bdftosnf or xset at all... Yes. Another question I have - is HP/Apollo, IBM, Apple and DEC going to provide OpenLook fonts standard with each of their X servers? I can believe that a lot of these users might try an XView application - and get a fatal error because the olcursor font wasn't there. -- -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
karlton@fudge.sgi.com (Phil Karlton) (03/09/90)
In article <132607@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: >Is there a way to allocate server pixmaps as sharable objects? i.e. one >client allocates a pixmap as "read-only" so other clients could use it. >That would make the problem much easier to solve. There are several ways. One fairly straightforward way would be for a client that needed to create the pixmaps to open a second connection and set it's close down mode to RetainPermanent. Then it should create the appropriate pixmaps and put a property on the root window listing the pixmaps. Some care must be taken to avoid race conditions. Most likely, creation and edition of the property will have to be done with the server grabbed. Take care to observe the conventions for atom names. PK -- Phil Karlton karlton@sgi.com Silicon Graphics Computer Systems 415-335-1557 2011 N. Shoreline Blvd. Mountain View, CA 94039
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (03/09/90)
> This is a valid request for change--if the toolkit cannot find the > OpenLook fonts, it loads in bitmap data and uses that instead. The > only problem we would have with this is increasing the library size. I thought shared libraries eliminated the problems associated with growing a library, at least by small amounts (like this). > The advantage of using a font over bitmaps is that many XView > applications can share the same OpenLook glyph images---by using the > same font. When using bitmaps, you either have to download the > bitmap over the wire each time you draw (cheap on the server) or > allocate server side bitmaps for each application (cheap on the wire > and potentially disatrous for the server). > Is there a way to allocate server pixmaps as sharable objects? i.e. > one client allocates a pixmap as "read-only" so other clients could > use it. That would make the problem much easier to solve. Pixmaps are already shared objects - if you can find out the XID of a pixmap, you can access it. The only problem is that when the allocating client disconnects, the pixmap goes away. I see at least two ways to solve this problem: 1) All OL clients are prepared to get BadPixmap errors and check to see if the bad pixmap ID is one of the OL glyph substitutes, and if so, recreate the pixmap. 2) The glyph substitutes are created via a separate server connection whose close-down mode is set to RetainPermanent. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
prc@erbe.se (Robert Claeson) (03/09/90)
In article <5863@crdgw1.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > In one case we had a X terminal from company "Q" > This required us to have a machine from that company to compile > the fonts into the right mode. The system that is providing boot > service for our X terminals is an Encore. It's version of native font > formats were not the same as the format neded by that particular terminal. The X terminals from Visual accepts font files in almost any thinkable format -- byte ordering, padding and alignment doesn't seem to matter. I've compiled fonts on Encore Multimax'es, Sun 3's and DG AViiON's in our network and the Visual terminals uses them without complaints. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
hvr@kimba.Sun.COM (Heather Rose) (03/11/90)
In article <5863@crdgw1.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes: >In article <132607@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: >|All the X11 servers do not use the standard utility bdftosnf to >|compile the font files? The XView source includes rules for compiling >|the fonts for X11R3 based servers. > > >In one case we had a X terminal from company "Q" >This required us to have a machine from that company to compile >the fonts into the right mode. The system that is providing boot >service for our X terminals is an Encore. It's version of native font >formats were not the same as the format neded by that particular terminal. > >Also - as I said - I had to FTP the fonts to a Mac and convert them >myself - using a Mac utility. (Finder - not A/UX). I do not know enough about X11 fonts to be able to say for sure what is going on; however, I will guess from the described behavior that when an X11 font is compiled, it is compiled into a form that is not readily understood by an arbitrary X11 server. I suppose the problem could be solved by specifying one format for the loadable fonts---something like specifying the format of pixmaps so every X11 server may read an X11 pixmap. I would also guess that this problem could be solved by the font server which would read one format such as .bdf files or something else which would allow scalable fonts such as the F3 format in Open Fonts. I would also guess that since a font server would need to send font glyphs to several different X11 servers, it would have to specify some standard format such as a pixmap that each server would be guaranteed to understand. If it did not, I don't see any point in doing it in the first place. >Our world is not heterogenous. >|>The point is - OpenLook fonts are currently non-standard. >|>The mechanism needed to download the fonts are non-standard. >| >|How so? We provide them in the same format as any other X11 supplied font. >|We provide the same rules for compiling them as any other X11 font. We also >|add the font to the font database in the same way as any other X11 font. > >|OK. Perhaps what you mean by "non-standard" is that X11 servers that came >|out before X11R4 do not download the OpenLook fonts by default? That you >|need to run bdftosnf or xset at all... > >Yes. > >Another question I have - is HP/Apollo, IBM, Apple and DEC going to >provide OpenLook fonts standard with each of their X servers? Ask HP/Apollo, IBM, Apple and DEC. I won't even try to guess what other companies might be releasing in future products. >I can believe that a lot of these users might try an XView >application - and get a fatal error because the olcursor font wasn't >there. Given the useful information some other people have given us concerning pixmaps, it is reasonable to consider as an alternate implementation of the OPEN LOOK glyphs. When we looked at this issue originally, we found fonts to be more flexible and better performing than pixmaps, so we chose to use this method instead. Given the portability issues with X11 fonts, this is an issue in an heterogeneous environment. However, supporting both pixmaps and fonts will double the text space for rendering since you need to deal with either the case of a pixmap or a font for each case. Granted this is averaged over a number of clients (when using shared libraries which is not the common case), but any increase in library size is still an increase in library size. We've been trying to make it smaller...a penny saved is a penny earned. Realistically, by the time we could release a version of the XView library that implemented this change, the font server issue would be solved, and all this work would have been for naught (in my guestamation). However, if this is very important to you, we do supply the source to the olgx support library. The XView library will be using olgx in the next major release to render all it's OPEN LOOK glyphs. So, if you would like to make changes to this library to use pixmaps instead of fonts, you are free to do so. And since Sun supplies binaries compiled with shared libraries, you could replace our version of olgx with yours (as long as you do not break any of the interfaces) and everything would run just as it's supposed to. One of the distinct advantages of shared libraries... If you do modify olgx, please send us the suggested fix. It is our policy to try to integrate any changes to the XView source someone may make. __________________________________________________________________ Heather Rose Window Systems Group internet: hrose@sun.com Sun Microsystems, Inc. uucp: ...!sun!hrose
hvr@kimba.Sun.COM (Heather Rose) (03/11/90)
In article <9003090650.AA11211@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: >> This is a valid request for change--if the toolkit cannot find the >> OpenLook fonts, it loads in bitmap data and uses that instead. The >> only problem we would have with this is increasing the library size. > >I thought shared libraries eliminated the problems associated with >growing a library, at least by small amounts (like this). You still increase size to handle two cases for rendering. A size increase is a size increase whether you have shared libraries or not. __________________________________________________________________ Heather Rose Window Systems Group internet: hrose@sun.com Sun Microsystems, Inc. uucp: ...!sun!hrose
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (03/11/90)
>>> This is a valid request for change--if the toolkit cannot find the >>> OpenLook fonts, it loads in bitmap data and uses that instead. The >>> only problem we would have with this is increasing the library size. >>I thought shared libraries eliminated the problems associated with >>growing a library, at least by small amounts (like this). > You still increase size to handle two cases for rendering. A size > increase is a size increase whether you have shared libraries or not. Well yes, but a size increase of 2K (say) would likely be tolerable whereas a size increase of 2K * number-of-XView-binaries probably would not. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
barnett@grymoire.crd.ge.com (Bruce Barnett) (03/12/90)
In article <132803@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: |>Another question I have - is HP/Apollo, IBM, Apple and DEC going to |>provide OpenLook fonts standard with each of their X servers? | |Ask HP/Apollo, IBM, Apple and DEC. I won't even try to guess what other |companies might be releasing in future products. I really didn't expect Sun to comment on this. I was just pointing out that "selecting" the XView toolkit does involve some problems that a program developer might not be aware of. I am developing a program for use in our facility that I want to be user friendly. In order to say the problem is solved, I must investigate and document how the end user down-loads the fonts to all X servers (i.e. X Terminals, Macintoshes, PC's, DECstations, VMS workstations, etc). |However, supporting both pixmaps and fonts will double the text space for |rendering since you need to deal with either the case of a pixmap or a font |for each case. As I said, I can specify a different font in the program. I cannot specify a different cursor. There are only 20-30 cursors in the olcursor "font", I believe. The extra code text would be small compared to the size of the library. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
stripes@eng.umd.edu (Joshua Osborne) (03/14/90)
In article <132607@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: >Is there a way to allocate server pixmaps as sharable objects? i.e. one >client allocates a pixmap as "read-only" so other clients could use it. >That would make the problem much easier to solve. Yes. I did it for xtrek sometime last year (I mucked around w/ xtrek so much it needed around 300 pixmaps, and there was a full second pause anytime anyone new was added to the game...). From what I remember: do access checks change the shutdown mode to (someting like) RetainPerminant, create Pixmaps (and any other perminant objects), then hang a property off the root window called XTREK_PIXMAPS which should be created to be of type PIXMAP (or XA_PIXMAP, or someting like that), contact tell the xtrek server to go for it, then exit. O, of corse if there was aready a XTREK_PIXMAPS and it had the right number of Pixmaps I skiped the creation step (unless given a force-it argument). (there is also a RetainTempory that can be used to remove things when you are done, but something seemed wrong about it so I ignored it). For XView you will probbly want to fork off a process that exec's a program to create the Pixmaps. -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
hvr@kimba.Sun.COM (Heather Rose) (03/17/90)
In article <9003110755.AA20288@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: >>>> This is a valid request for change--if the toolkit cannot find the >>>> OpenLook fonts, it loads in bitmap data and uses that instead. The >>>> only problem we would have with this is increasing the library size. >>>I thought shared libraries eliminated the problems associated with >>>growing a library, at least by small amounts (like this). > >> You still increase size to handle two cases for rendering. A size >> increase is a size increase whether you have shared libraries or not. > >Well yes, but a size increase of 2K (say) would likely be tolerable >whereas a size increase of 2K * number-of-XView-binaries probably would >not. It's not a small matter of 2K in the next release. XView with 3-D look uses the same rendering scheme of OPEN LOOK glyphs as olwm uses now. Now, it's just the olcursor, this summer it will be all buttons, scrollbars, and other OPEN LOOK glyph objects. Also, add to that descriptions for 3-D look, so multiply your data objects by 4 (different parts to describe shadowing). Also, add to that a multiple sizes. Also, it's just not a matter of XView clients finding the bitmaps. The window manager and other toolkits must also be able to find the bitmaps and share them. By using fonts, we allow the X11 server to be the rondevue point for these sharable glyphs. There already exists an easy mechanism to share fonts among multiple clients in X11. It will take resources to 1) produce all the bitmaps for all sizes plus both 2-D and 3-D looks, 2) makes changes to olgx and anything else that needs to be done to the library, 3) devise a scheme to make the bitmaps shareable among many clients and 4) integrate the changes with new development. Sun does not have the resources to produce this alternate scheme; however, if someone else would like to donate this work, we will try to integrate it. I would suggest starting with converting olgx to use bitmaps instead of fonts. Sun has provided olgx as a method for all OPEN LOOK toolkits and clients to produce the same OPEN LOOK glyphs for their objects. Thus, the window manager, the toolkit, and other toolkits share same the look. __________________________________________________________________ Heather Rose Window Systems Group internet: hrose@sun.com Sun Microsystems, Inc. uucp: ...!sun!hrose