waashk/20ng huggingface dataset:
In article <WHALEY.93Apr22110027@sigma.kpc.com>, whaley@sigma.kpc.com (Ken Whaley) writes: > One advanage of MIT-SHM is that if your images are large, you don't end up > growing the size of the server process to hold them. >   Correct. Most X servers use a version of  malloc(3)  which will not return   memory to the OS (ie. the X server might  free(3)  a Pixmap, but the heap does   not shrink).  > One disadvantage of the MIT-SHM is that, in its sample implementation, > there is no provision for elegantly cleaning up the shared memory segments > if the client dies a sudden, violent death (e.g., "kill").  You have to  > be mindful of cluttering up the system with zombie shared memory segments. >   Well, part of the routines I mentioned do a dirty little trick to get around   that problem. First, I create the shared memory segment, attach the client,   attach the X server, and then remove (!) the segment. If you read the man   pages on removing of shared memory segments, you will see that the segment   only dies after all attachments are gone.   Now, if the client dies, that's one attachment gone (the OS cleans up for you)   and since the X server notices the client has dies, frees up it's resources,   including detaching from the segment: there goes the last attachment. No more   shared memory segment.   Terrible, but it works.  				Regards,
Is there a PD version of cfb, or other PD server stuff, which has a colour frame buffer implementation which works in bitplaned mode, i.e. where the screen memory is grouped so that "bit 0 of every pixel is here, bit 1 is there, etc."  The only such beast I know if at the moment is the GfxBase server for the Commodore Amiga, and it is commercial. I don't know if they wrote their own cfb, but I suspect they did.  Please respond by email, as I don't read this group.  Many thanks Dave
In article <1993Apr23.114028.17633@bernina.ethz.ch>, queloz@bernina.ethz.ch (Ronald Queloz) writes: > Hi netlanders, >  > Does anybody know if there is something like Macintosh Hypercard for any UNIX  > platform? >  >  > Thanks in advance >  >  > Ron.  --   Try MetaCard - a HyperCard-like programming environment on X.
In article <C6wLIJ.L5K@bailgate.gpsemi.com> wilkinson_m@roborough.gpsemi.com writes: > Hi All, >        This is the first time I've posted to the net, so I hope this is > going to the right people. >   I'm looking for software packages that run on an IBM PC clone that > allows me to display Openlook and motif windows on the PC.    I highly recommend Starnet's Micro-X.  They have versions for DOS and Windows, with support for PC/TCP, or the Clarkson packet drivers.  I have used it successfully with twm, mwm, and olwm, over both ethernet and SLIP. And their tech support is top notch.  They really impressed me.    Kevin
I am trying to write an image display program that uses the MIT shared memory extension.  The shared memory segment gets allocated and attached to the process with no problem. But the program crashes at the first call to XShmPutImage, with the following message:  X Error of failed request:  BadShmSeg (invalid shared segment parameter)   Major opcode of failed request:  133 (MIT-SHM)   Minor opcode of failed request:  3 (X_ShmPutImage)   Segment id in failed request 0x0   Serial number of failed request:  741   Current serial number in output stream:  742  Like I said, I did error checking on all the calls to shmget and shmat that are necessary to create the shared memory segment, as well as checking XShmAttach.  There are no problems.  If anybody has had the same problem or has used MIT-SHM without having the same problem, please let me know.  By the way, I am running OpenWindows 3.0 on a Sun Sparc2.
In article <930424212154.1000227@tgv.com> mahan@TGV.COM (Patrick L. Mahan) writes: ># I remember seeing something in the X distribution mentioning support ># for a Tektronix terminal in an X server.  Is this accurate?   >Xterm supports 401x emulation.  What I was talking about was using an Tek terminal as your X display.  I should be possible to write an X server that does this as far as I can tell, but what I'm asking is if there is already one.  --  mike@hopper.acs.virginia.edu
In article <WHALEY.93Apr19171228@sigma.kpc.com> whaley@sigma.kpc.com (Ken Whaley) writes: >   As per your question: why not have the button handler add the object, and >   then call the "window_redraw()" (or whatever) directly?  Although, depending  This design will work but I don't think it can take easily take advantage of expose event redraw optimization; that is, the whole window will be redrawn, not just the area with the new item.
Is it possible to have xdm put up a multi-line greeting?  If so, how do I specify such a thing in the Xresources file?  I don't have much (anything) for X books, so I can't look it up.  Thanks.   --  Mark Van Overbeke                   Systems Software Programmer Computing Services                  BITNET:    Mark@UMNMOR.BITNET   (VMS) University of Minnesota, Morris     INTERNET:  Mark@caa.mrs.umn.edu (VMS)  Morris, MN   56267           1-612-589-6378    mark@cda.mrs.umn.edu (Ultrix)
--- Received from EEI.EEIIHY  353-1-2800455         93-04-26 12.28   -> VAX.XPERT..EXPO.LCS.MIT.EDU..INET   -: - - - - - - - - - - > MAIL USER IN VAX AND INTERNET help
In article <1993Apr7.044749.11770@topgun>, smikes@topgun (Steven Mikes) writes: > Another company, Congruent Corporation of New York City, has also ported Xlib > Xt and Motif 1.1 over to MS Windows NT, which provides full client development > for X applications in an NT environment.  Could someone please send me the postal and email address of Congruent Corporation (and any competitors they may have).  Thank you. --  snail@lsl.co.uk
I am in the process of installing X11R5 on my Sun Sparcstation 2 and have run into a problem.  I imagine it has something to do with a missing screen driver, or something along those lines, but figured someone out there in Internet land might be able to help.  I am installing it on a machine that already has OpenLook installed, and would like to have both installed concurrently.  Thus, I set it up to compile to my /usr/X11R5 directory.  I worked out all the kinks in getting it compiled (with gcc), so that it compiles without any warnings.  I need it installed for PEX-SI, so I set all those appropriate flags.  When I run it, however, I get a message along the lines of:  Getting interface configuration : Operation not supported on socket  sunOpenFrameBuffer : Inappropriate ioctl for device  Fatal server error : no screens found    Any ideas on how I can fix it?  Please respond by e-mail at the below address.  Thanks in advance.  -Dan --  "I do not want to be immortalized through my works; I want to be  immortalized through not dying."  -Woody Allen
Hi *,  Has anyone out there compile a list of X security holes??  If yes, will you please send me a copy of this??  If this is a wrong group, please point me to a right one.  Thanks!!  BTW, the list doesn't have to contain the info "How to use the holes?".  Instead, I need the info of how to detect the holes, how to seal the holes, and how to monitor the  activities if possible.  Any info is welcomed.  Thanks!!     --Eric
I've gotten very few posts on this group in the last couple days.  (I recently added it to my feed list.)  Is it just me, or is this group near death? --
>>>>> In article <1qvir1$idi@lll-winken.llnl.gov>, dale@wente.llnl.gov (Dale M. Slone) writes:  dale> I found an oddity with our SGI Indigo (MIPS R3000 chip). dale> When xlock +nolock is running, and I am working remotely dale> or in batch (at) mode, the runtime of my programs (as timed dale> by using clock() in the code itself) is ~25% slower than if dale> xlock is NOT running.  No other processes seem to affect my dale> runtimes, yet this is very consistent!  Unless you run `xlock -mode blank`, xlock consumes CPU time generating the nice animated display. The code you are running is competing with xlock for the CPU. If you run top (via a remote login), you can really see what is going on.  =-=-=
Could someone PLEASE give a guess as to why this simple little program causes a BadPixmap error on the FOURTH (bizarre???) call to XtRelaizeWidget()?  Here is the code:   int stoploop = 0;  static void Callback(Widget, XtPointer, XtPointer);  main() {         XtToolkitInitialize();         XtAppContext app = XtCreateApplicationContext();         while (1)         {                 int junk = 0;                 Display *dis = XtOpenDisplay(app, NULL, NULL, NULL, NULL, 0,                                                 &junk, NULL);                  Widget top = XtAppCreateShell(NULL, NULL,                                 applicationShellWidgetClass, dis, NULL, 0);                  Widget box = XtVaCreateManagedWidget("x",                                                         xmPushButtonWidgetClass,                                                         top,                                                         XmNheight, 25,                                                         XmNwidth, 25, NULL);                  XtAddCallback(box, XmNactivateCallback, Callback, NULL);                  XtRealizeWidget(top);                 while (!stoploop)                 {                         XEvent event;                         XtAppNextEvent(app, &event);                         XtDispatchEvent(&event);                 }                 stoploop = 0;                 XtReleaseGC(top, XDefaultGCOfScreen(XtScreen(top))); // needed?                 XtDestroyWidget(top);                 XtCloseDisplay(dis);         } }  static void Callback(Widget, XtPointer, XtPointer) {         stoploop = 1; }   The error I get (yes, the 4TH time I try to show the box) is:  X Error of failed request:  BadPixmap (invalid Pixmap parameter)   Major opcode of failed request:  55 (X_CreateGC)   Resource id in failed request:  0xd0000d   Serial number of failed request:  71   Current serial number in output stream:  85   Please respond via email.  Thanks very, very much!  (NOTE: I realize this program does nothing useful, its an ultra-trivialized version fo a real library routine) --  ------------------------------------------------------------------------------- David Rex Wood -- davewood@cs.colorado.edu -- University of Colorado at Boulder
When I run our RS6000's "info" utility through a remote login   shell (rlogin) from my Sun Sparc 1+, I can no longer type   lower case in any of info's window prompt's.    I thought the prob. may have been due to my Sun window mgr.    (Openlook) being incompatible with the AIX Motif application   but I tried it under TVTWM also.  Same result.      So this is presumably an X11 key definition problem between    workstations - but my system admins. feign ignorance.      What do I need to do the be able to type lower case into    this remote AIX motif app. from within my local Openlook   window manager?       --
In article <1465@minya.UUCP> jc@minya.UUCP (John Chambers) writes: <It seems silly, but while I've located things like tgif that can  edit <gif  files, and various tools to convert to/from gif format, I haven't <been able to locate a program that just opens a window and displays  a <gif file in it.  I've looked thru various faq files, also to no avail. <Is there one lurking about in some  archive?   Nothing  sophisticated; <just "show the pretty picture"? < <Alternatively, if I could locate the specs for gif, I don't suppose it <would be too hard to write it myself, but I have no idea where to even <start looking for the spec.  (Well, actually, I do have an idea - this <newsgroup.  ;-)  Get, xv, version 3.0.  It reads/displays/manipulates many different formats.
In article <93122.142712CHANGJ@QUCDN.QueensU.CA> <CHANGJ@QUCDN.QueensU.CA> writes: >Is there a tn3270 program which support xterm? I don't like x3270 at all. You >can't copy with other windows. Thanks.  The x3270 at export.lcs.mit.edu supposedly does.  I use another x3270 that was cleaned up by Brian Ward <ward@math.psu.edu> which adds better color support, and cleans up _lots_ of bugs, as well as cut&paste. I just put it on export.lcs.mit.edu, as x3270v2.65beta.tar.Z.  --Dave
Yes, it's possible... in fact, there's some gl widget code in /usr/lpp/GL somewhere... (it's named Glib.c; my IBM's down right now though, so I can't find the exact location :)    WARNING: this code feels quite bogus. It does things like calling noport() before winopen(), and then extracting an X window id from it anyway. It worked just fine under aix 3.1; I spent last weekend trying to port it to 3.2 (gl under 3.2 doesn't seem to like it), and it's turning into a Hard Job.    Check out your "info" pages; it has some pretty good documentation on whan you can and can't do when mixing gl and X, and how to go about doing so.
d3e758@bucky.pnl.gov (JE Pelkey) writes:     >I am looking for online help Motif widgets (public domain or otherwise) to >run on a Sun Sparc.  >I'd be especially interested in help widgets that can integrate hypertext  >help, graphics, etc.  >I know that some of the GUI builders like Galaxy come with online >help widgets, but I need to check into stand-alone help widgets as >well, seeing as how we have not picked a GUI tool yet.  >Anybody know of any widgets like this?  X Resource, Issue 6
I have heard of two packages for the PC that support X-Win. The first is Linux which is a free Unix Package.  The Second is X-Appeal, which sounds pretty good.  It can be found at  garbo.uwusa.fi in the ~ftp/pc/demo/ dir.  The files are  	xap13exe.zip 	xap10fon.zip 	drivers.zip  This should get you started.  Josh.
It seems like XTranslateCoord. doesn't work the way I expecting it.  Right after performs a XMoveWindow, I want to know the absolute window position with respect to the root window.  To get this info. I do a XTranslateCoordinates but the abs_x, and abs_y aren't right?  Does anybody know of a way to find  out this information?  Thanks, please e-mail to hsteve@carina.unm.edu if it's possible
Is it possible to run an MIT R5 based Xserver on a Sun with a Rasterops TC Colorboard (24bit board)?  I have the Xsun24 patches for supporting sun's 24bit frame buffers but does the rasterops appear as if its a cgtwelve or something else?  I know nothing about the rasterops other than we might be buying one to put in an IPX.
I'm running xterm under X11R5, Motif 1.1, mwm and UNIX SVR4 on a UNISYS 386 based machine. My default shell is /bin/csh or the C shell. Whenever I run xterm, I get the following message before the first C shell prompt:  Warning: no access to tty; thus no job control in this shell...  After this, I can't run any job control commands like fg, bg etc. Also, I can't run another xterm from the command line of this xterm (I can only launch additional xterms from a .mwmrc menu).  I'd appreciate some help with this problem, or pointers to where I can get some help. By the way, my environment variable TERM is set to xterm.  ---------------------------- Saad Mufti Personal Library Software
I'm trying to set up an IPX for another group. I copied all the X stuff that I compiled on my 4/280 (which runs SunOS 4.1.1) using gcc 2.1, and most things run just fine. however, I did find a couple of bugs, and when I try to recompile those clients on the IPX (which runs 4.1.3), I get  ld: Undefined symbol    _XShapeQueryExtension    _XShapeCombineMask  I know that I can include libXext and get rid of those messages, but I can't figure out why I get them on the IPX and not on the 4/280. any ideas?
Hello,  I was wondering if anyone knew of an interface to od ( octal dump ), I assume it would be called xod.  Actually, any viewer for a core file will do.  I looked at export ( @ mit ) in the index of /contrib, but didn't find anything  relevant.
Is there such a document either in the Bookstores or possible on an ftp site somewhere?  Nothing really fancy, just something that gives a listing of the available widgets, and the resources that are pertinant to them, and what flavors of Motif they occur in.
I just had an idea. I'm not sure if its been done and I'm just remembering it unconsiously, but I thought that in dialog boxes and whatever in windowing systems, there should be a way to intuitivly set some things checked or unchecked or filled in a certain way. My idea: tape. You know, like putting a piece of tape over a light switch? Just an idea, if you like it, use it.
Mouseless operation is documented in the man pages for olwm and olvwm... However, I can't get it to work in either. I have this line in my .Xdefaults: OpenWindows.KeyboardCommands:           Full  That should do it... I haven't rebound the keys. Am I missing something?
I'm running X under openwindows 3.  Normal X programs not having a font specified always show up in the same font - until I change the fontpath, and restart windows - then a new default font is used until the next change.  I can't seem to figure out how it chooses.  Is there some way to set this?  Possibly something in .Xdefaults???  Please reply in direct email - I summarize.
I am planning to convert my Motif 1.2 app from pixel to font units which would all be set in the app's resource file instead of hard coded in the program.  However, the word here is from people who tried this already that for some unknown reason XmForm offsets placed in the resource file are still interpreted in pixel units forcing people to code those offset font units into the program.  Can somebody confirm this?
In article <1993Apr20.114824.9110@alex.com>, bryan@alex.com (Bryan Boreham) writes: |>  |> The shell is waiting for the window-manager to respond to its |> positioning request.  The window-manager is not responding because |> it thinks the window is already in the right place. |>  |> Exactly *why* the two components get into this sulk is unclear to |> me; all information greatly received.  This problem is caused by a bad interaction between the way olwm reparents windows, a misfeature of the X protocol, and a bug in the Xt intrinsics.    The Intrinsics bug is that it ignores the (x,y) position given in ReparentNotify events.  Olwm is structured in such a way that, when a window is popped down, the last event the client receives is a ReparentNotify event.  At this point, the Intrinsics' notion of the shell's location is out of date.  If a SetValues is done using the same (x,y) position, the Intrinsics thinks it needs to move the shell, so it issues a ConfigureWindow request to move it there.  However, a (mis)feature of the X protocol is that a ConfigureWindow request that has no effect will generate no ConfigureNotify event.  The Intrinsics thus waits for an event that will never arrive, and times out after wmTimeout has expired.  (Actually, things are somewhat more complex because the request is redirected to the window manager, but the net result is the same.)  The solution is for the Intrinsics to note the (x,y) positioning information in ReparentNotify events.  This has been implemented and is available in X11R5 public fix 20.  This is XBUG 5513 for those of you who are interested in gorier details.  s'marks
I've been offerred an old 4-bits/pixel greyscale Xterminal.  Aside from the "real people have already upgraded to RISC architecture R5 servers", do I want this Xterminal?   I'm concerned about the 4-planes...I've only ever heard of 1 (mono) and 8 (colour) planes -- will I have any concerns with this 4-plane unit?  [Specifically related to 4-planes vs 1 or 8]  Thanks! -C-
The XView version 3 source distribution included in the contrib section  of X11R5 included the source to the textedit program.  I'd like to take  the sources and modify them to add support for a ToolTalk-like message  server, and maybe for ToolTalk while I'm at it, since the Sun-supplied textedit binary doesn't seem to speak tooltalk.  However, the sources in the R5 contrib area seem to be for an older version of textedit than the version shipped with OpenWindows 3.  For example, the OWN 3.0 textedit includes drag and drop support and a  dropsite in the main control area, while the source in contrib/xview knows nothing about drag and drop.  The textedit.c included in the xview sources says it's version 15.50, dated 5/22/90, while doing a 'what textedit' on the OWN 3.0 binary says:          textedit.c 2.62 91/09/14 Copyr 1990 Sun Micro         dragdrop.c 1.26 91/09/14 Copyr 1990 Sun Micro         tooltalk.c 2.16 91/09/14 Copyr 1990 Sun Micro         ds_relname.c    1.7 91/09/14 Copyr 1990 Sun Micro  So, does anyone know if the 9/14/91 sources to textedit are available? I'd really like to work from the latest source if possible.  Please reply by email, and I'll post a summary if there's enough  interest.
In article <lttm1lINNrli@news.bbn.com>, swalker@bbn.com (Susan Walker) writes: |> I have found a situation which I think is a bug in X or Motif, but I'm hoping |> is really just a mistake on my part.  Does anyone know anything about |> this problem........ |>  |> - I am using an XmTextField, and setting its XmNvalue to a hardcoded |>   text string (ascii or Kanji) either via XtSetValues or XmTextSetString. |>   The problem is that when the XmTextField is displayed, the text is getting |>   truncated, depending on the setting of the environment variables |>   LANG (more specifically LC_ALL).  When they are set to japanese, |>   the text gets truncated.  When they are set to english, everything |>   works fine.  I am taking the default for XmNcolumns. |>   (Please note that hardcoding of text is NOT done in my actual |>    application, just in my sample code to make things easier) |> 	 |> - I am running Motif 1.2, X11R5 via HPUX9.01.  My test program is set up |>   to handle 16 bit Kanji characters.  I have remembered to do    |>   XtSetLanguageProc() prior to my MrmInitialize and my font resources |>   are set to japanese fonts. |>  |> - Don't know if this matters, but my dialog box and TextField is initially |>   created with UIL.  |>  |>  |> The problem does NOT happen with XmText.  Unfortunately substituting |> XmTextFields with XmTexts in my application is not an acceptable |> alternative (way too much code to be modified while in beta!) |>  |> I have a small test program which illustrates the problem if anyone |> wants it.  My best guess is that either the X code or Motif is not |> properly allocating memory for japanese, but since I don't have the |> source to look at it is just a guess.  The problem was that TextField was improperly walking the string; it used the character count instead of the byte count... a significan "Oops".  The problem has been fixed and the patch is included in the latest periodic patch from HP support services.
In article <WHALEY.93Apr15103931@sigma.kpc.com> whaley@sigma.kpc.com (Ken Whaley) writes: >   Actually, I must also ask the FAQ's #1 most popular reason why graphics >   don't show up: do you wait for an expose event before drawing your >   rectangle?  Suppose you have an idle app with a realized and mapped Window that contains Xlib graphics.  A button widget, when pressed, will cause a new item to be drawn in the Window.  This action clearly should not call XCopyArea()  (or equiv) directly; instead, it should register the existence of the new item in a memory structure and let the expose event handler take care of rendering the image because at that time it is guaranteed that the Window is mapped.