waashk/20ng huggingface dataset:
Some  people working a few cubes over have come up with this need, and it seems that someone out there just might have done it  already,  and can point me to some tools that would help. What they'd like to do is: Given a window that is taking a long time to draw (because either  the data  is  arriving  over a slow link, or the $DISPLAY is across a slow link), they would like to first paint a low-resolution version of  the picture,  and then repaint it in higher resolution.  Thus, the picture might first be generated in 1/4 resolution, with each  4x4  square  of pixels  being  filled  in  with a single color.  Next, each 4x4 square would be replaced by 4 2x2 squares; finally the 1x1 version  would  be painted.  Since  one of the scenarios is with the window being on the other side of a slow link, the low-res version obviously wouldn't be  transmitted as  a bitmap; that wouldn't help at all.  Instead, there would have to be a process on the far end that receives the  low-res  picture  as  a small  bitmap,  and  blows up each pixel into a square (sorta like the magnifier programs do).  This brings up the question of whether the  X server  can help.  That is, when a window is opened, is there a way to ask that a "filter" program be run to process the pixels?  Or  is  the only  way  to  use  something  like  rsh  to start up a remote process ("Permission denied" ;-), and have it open a local window?  It seems the most likely scenario is a library routine that starts  up such  a  program  remotely, and then accepts bitmaps, compressing each one by some amount, and sending them to the remote program to  expand. But  if  there is something that X itself can do to help, it's be nice to hear about it.  (I looked in several FMs,  but  if  it's  there,  I obviously  don't  know  the keywords ;-).  If someone has a nifty tool available that packages it all, we might want to get a copy.  Oh, yes; this is to run on some Suns.  Part of the idea  is  to  build demos  that  can  show such things as "If this were run across, say, a 4800-bps link, this is how fast the pictures would appear."  Then  the customer would get a feel for the speed that they need to pay for.
In article <13960@risky.Convergent.COM>, sxs@extol.Convergent.Com (S. Sridhar) writes: |> Keywords: tvtwm icon manager |>  |> Need help on resource bindings for tvtwm.  Here's what I'd like to |> see the icon manager do. |>  |> Say I iconify a window and this shows up on the icon list.  Now when I  |> pan into another section of the virtual desktop and try to deiconify |> the window that I iconed (sp ?)  earlier, I'd like this window to |> deiconify in the current region. |>  |> Any resources that I can use to do this ?  Or more important, can I  |> do this ?  Rather find it painful to remember where I iconified a  |> window, go back there and deiconify.  Or simply, it is a pain to  |> pan around to get to a deiconified window. |>  |> Thanks, |>  |> ssridhar@convergent.com |>  |>  Just opened up the distribution.
Hi there,     Do someone of you have a program for sending a key event to another window but it MUST appear in that window....  I have used xsendevent.tar package but it does not do that !!!  For example, if I get a program executing:  -------------- #!/bin/sh read something .... .... echo $something .... .... --------------  and if I send the key event "<KeyPress>a,<KeyRelease>a" to that window then I will get:  something=a   Thanks in advance.   --
G'Day  Windows NT is a step forward, but not by much. I guess for DOS users who think multi-tasking is really _neat_ (add puke here) and are overjoyed to  be able to use more than 64K of memory, its a major improvement. For Windows users its more like an upgrade with facilities most Unix users take for  granted. Most of  Windows users only use PCs for text processing or running  3rd-party applications anyway so the operating system features are not even  a real issue. My ideal operating system:  	Binary compatible across all plaforms. It should recognize 	binaries and configure on the fly, so I don't have to have 	bin/Mac bin/DOS bin/Dec bin/Sun bin/HP etc...  	Multi-CPU. So I can use the CPUs on my PC and W/S and Mac  	and Transputers and DSPs. I don't know a single site which  	has gone for a single vendor. I am not going to trade-in  	80Mflops per H1 transputer or ultra-fast FFT on DSP chips. 	Note NT runs on Symmetric multi-CPU systems.  	Built-in portable GUI/Graphics tools. You can call DrawButton  	or DrawLine and it does the same thing no matter what platform  	or display. It should also translate graphics commands on-the-fly. 	so I can use PC graphics S/W on my workstation and X software on   	my PC. I think GUIs are not just nice to have but essential.  	Configurable front-end. So you can make it look like Unix or DOS 	or NT or OS/2, and run shell scripts or command/BAT files.  	Object oriented. So I can program easily under it and not have 	to re-invent the wheel if the networking is not up to scratch 	or my application needs to access source/object code on the fly.  In other words it should have some AI capability. That and a tight, clean kernel so you can actually understand it. Anyone know of something like this ?  	adios 	     Ata <(|)>.
Version 1.0 of NCSA Mosaic for the X Window System, a networked information systems and World Wide Web browser, is hereby released:  file://ftp.ncsa.uiuc.edu/Mosaic/xmosaic-source/xmosaic-1.0.tar.Z                             .../xmosaic-binaries/xmosaic-sun.Z                             .../xmosaic-binaries/xmosaic-sgi.Z                             .../xmosaic-binaries/xmosaic-ibm.Z                             .../xmosaic-binaries/xmosaic-dec.Z                             .../xmosaic-binaries/xmosaic-alpha.Z                             .../xmosaic-diffs/xmosaic-0.13-1.0-diffs.Z  NCSA Mosaic provides a consistent and easy-to-use hypermedia-based interface into a wide variety of networked information sources, including Gopher, WAIS, World Wide Web, NNTP/Usenet news, Techinfo, FTP, local filesystems, Archie, finger, Hyper-G, HyTelnet, TeXinfo, telnet, tn3270, and more.  This release of NCSA Mosaic is known to compile on the following platforms:    SGI (IRIX 4.0.2)    IBM (AIX 3.2)   Sun 4 (SunOS 4.1.3 with stock X11R4 and Motif 1.1, and GCC).   DEC Ultrix.   DEC Alpha AXP (OSF/1).  Documentation is available online.  Changes since 0.13 include:   o Added new resource, gethostbynameIsEvil, for Sun's that    coredump when gethostbyname() is called to try to find out what    their own names are. (Command-line flag is -ghbnie.)   o Explicitly pop down all dialog boxes when document view    window is closed, for window managers too dull to do so    themselves.   o Better visited anchor color for non-SGI's.   o Added .hqx and .uu to list of file extensions handled like .tar files.   o Added 'Clear' button to Open box, to allow more convenient    cut-n-paste entries of URL's.   o New resource 'autoPlaceWindows'; if set to False, new document    view windows will not be automatically positioned by the    program itself (but it's still up to your window manager just how    they're placed).   o Command-line flags -i and -iconic now have desired effect (new    resource initialWindowIconic can also be used).   o Gif-reading code is a little more bulletproof.   o Obscure infinite loop triggered by extra space in IMG tag fixed.   o Eliminated nonintuitive error message when image can't be read    (inlined NCSA bitmap is indication enough that something's not    right for authors, and readers can't do anything about bad images    in any case).   o Obscure parsing bug (for constructs like <ADDRESS><A    HREF=...>text<A></ADDRESS>) fixed.   o Fixed mysterious stupid coredump that only hits Suns.   o Fixed stupid coredump on URL's like '://cbl.leeds.ac.uk/'.   o Fixed buglet in handling rlogin URL's.   o New support for Solaris/SYSVR4 (courtesy    dana@thumper.bellcore.com).   o Better support for HP-UX 8.x and 9.x (courtesy    johns@hpwarf.wal.hp.com).   o Better support for NeXT (courtesy scott@shrug.dur.ac.uk).   o Some miscellaneous portability fixes (courtesy    bingle@cs.purdue.edu).   o Miscellaneous bug fixes and cleanups.   Comments, questions, and bug reports should be sent to mosaic-x@ncsa.uiuc.edu.  Thanks in advance for any feedback you can provide.  Cheers, Marc  --
In article <BUZZ.93Apr19125438@lion.bear.com>, buzz@bear.com (Buzz Moschetti) writes: |> (2nd posting of the question that just doesn't seem to get answered) |>  |> 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 same expose event handler that |> handles |> "regular" expose events (e.g. window manager-driven exposures) take care |> of rendering the new image.  Using an expose event handler is a "proper" |> way |> to do this because at the time the handler is called, the Xlib Window is |> guaranteed to be mapped. |>  |> The problem, of course, is that no expose event is generated if the window |> is already visible and mapped.  What we need to do is somehow "tickle" the |> Window so that the expose handler is hit with arguments that will enable |> it to render *just* the part of the window that contains the new item. |>  |> What is the best way to tickle a window to produce this behavior?  To incrementally update the contents of windows, I use the following trick:  	1. Set the window background to None, 	2. Call XClearArea(display, window, 0, 0, 0, 0, True), 	3. Restore the window background to its correct value.  The call to XClearArea does not repaint the window background, but still generates exposure events for visible parts of the window.  In order to let my application know that these expose events must be handled incrementally (something is already displayed on the screen and may need to be erased), I encapsulate the 3 operations with 2 self addressed client messages, which preserve asynchronicity between the client and the server.  XGrabServer(display) client message (start-incremental)  	background None 	XClearArea 	Restore background  client message (end-incremental) XUngrabServer(display)  The GrabServer prevents other events to be inserted by the server in the critical section.
In article <C5r25y.HFz@cs.columbia.edu> ethan@cs.columbia.edu (Ethan Solomita) writes: |> |>	Hi. I'm trying to figure out how to make a window manager |>place the window where the create window command tells it, |>regardless of what it may think is right. (my application has |>reason to know better) |> |>	I don't want to set the override-redirect because I do |>want all the embellishments that the window manager gives, I just |>want the wm to accept my choice of location.   What "it may think is right" may be exactly what the user wants. Assuming that your application "has reason to know better" is, IMHO, anti-social.  If I start your application with a -geometry option are you going to ignore that as well?  There's really no way to force a window manager to do much of anything if it's managing your window.  You can ask, you can hint, but there's no guarantee that you're going to get what you want.
Can anyone give me some information, please ...  I need (probably) to write one or more new Motif widgets on the HP-UX platform. Do I need the Motif private header files and source, or can I make do with the public headers that are provided? "Motif" includes Xt in this context.  One widget is a multi-column list (which lots of people have already written, I am sure), and would therefore be probably be a subclass of List rather than something simple like an Xt class. Is this more difficult (in principle, not lines of code)?  Alternatively, if anyone has a multi-column list widget they could sell me, this might save me from having to write one! Does it by any chance exist in Motif 1.2 already (I do not yet have the spec)?  Answers appreciated,  Nicholas.
We are planning on buying 15-20 X Terminals.  I have the article from Jim Morton regarding prices, etc., and am looking for any other information that will help me decide which to buy.  The terminals will be connected to a DEC 3000/400 AXP with 96Mb RAM, running OSF/1.  From what I have found out so far, it would be best to run as much as possible in the terminal itself (X11, window manager, xterm, etc.), and that in order to do this we need n Mb RAM in the Xterminal (where n ranges from 4 to 10, depending on who I talk to).  What should I be looking for?  What sort of questions should I be asking the salespeople?  Thanks
I have the March/April version of the X Journal open in front of me.  I'll be working on programming x-clients this summer, and since I don't have much experience with programming X, I thought this issue might be helpful as it has a section on debugging, and a section on the 40 most common errors in programming X.  At the end of the errors section, there are the following references for tutorials on X programming style.  They are:  Rosenthal, David -   A simple X11 client program   Proceedings of the Winter 1988 Usenix Conference, 1988.  Lemke, D., and Rosenthal, D. -  Visualizing X11 clients   Proceedings of the Winter 1989 Usenix Conference, 1989.   Does anyone know where I could find these in printed or (preferably) electronic form?  Or can you suggest any net resources devoted to the introduction to programming X (I'll be looking at the bookstore for books, so I am really only asking about what I can find on the net.)  Thanks,  David Simpson
queloz@bernina.ethz.ch (Ronald Queloz) writes:  >Hi netlanders,  >Does anybody know if there is something like Macintosh Hypercard for any UNIX  >platform?  There are several products you might investigate.  If you've got $20,000 per seat and high-end hardware, Gain Momentum might be a good choice.  It isn't compatible with HyperCard, but has a similar architecture (and *way* more functionality).  I don't have contact information, but they were recently purchased by Sybase who shouldn't be too hard to find.  If you're running News on SPARC, check out HyperLook (hyperlook@turing.com).  It uses Postscript as a scripting language which is good if you need to do lots of display oriented scripting, but not so good for non-programmers.  It was $995, last I heard.  You might also look at our product MetaCard.  We're alpha-testing direct importing of HyperCard stacks (we've even made the test release available for anonymous FTP), so we're obviously the closest in functionality.  MetaCard runs on most UNIX workstations and costs $495.  Email to info@metacard.com for more details.   Scott  >Thanks in advance   >Ron.
I recently compiled the X11R5pl22 sources using gcc-2.3.3 on a Sun3/80. Everything seems to work fine. Usually. But at seemingly random times the server will just hang. I will click the mouse somewhere (never happens while my back is turned), and without warning, it will freeze there, requiring the server to be killed. Sometimes it will run fine for weeks, sometimes only for minutes.  (Os: 4.1.1; frame buffer: bw2).  Has anyone seen this before, any ideas? (anything at all?)  thanks, 	--jeff
In article C4M@cuug.ab.ca, winsorr@sun (Robin Winsor 233-4670) writes:  >You are right to be going Motif rather than OpenLook.  Sun has just recently >seen the light and dumped their commitment to OpenLook.  In the announcement >they stated they have no future plans for DevGuide.  This is incorrect.  Sun has made no such claim regarding Devguide, and as  manager of the Devguide engineering group I can state with authority that work on Devguide is continuing apace.  We had quite a strong show of interest from the Devguide user community at last week's Solaris Developer's Conference. Devguide is being advocated not only as a valuable future builder tool, but as an important bit of transition technology that will help sustain current customers and facilitate their migration to the COSE Desktop Environment.  If you have specific questions about Devguide availability, etc., you can  contact Tali Aben, our Devguide Product Marketing person, at (415) 336-3536.
Version 1.3 of Xew widgets is available at  	export.lcs.mit.edu: contrib/Xew-1.3.tar.Z 	export.lcs.mit.edu: contrib/Xew-1.3.README  For better details, check the README. (For extensive details, you have to with Xew-1.1.ps.Z, still haven't had time to update this one).  No new functionality has been added since 1.2 version. Raster widget handles now expose events slightly more intelligently than before (really had to do this when I added a simple program that uses X11R5 Athena Porthole and Panner widgets). The program demo/viewer.c is very simple demonstration of panner/porthole usage (copied from'editres' actually :-)
The motif mailing list will now be located at lobo.gsfc.nasa.gov  If you would like to be added (or deleted) from this list, please send mail to motif-request@lobo.gsfc.nasa.gov to mail to the list, send mail to motif@lobo.gsfc.nasa.gov   Brian
H. J. Hong (hjhong@ev004.ev.nctu.edu.tw) wrote:  > Hi! I'm looking for a tool to dump a X-window screen image? > Any one can help me ?                                  See xwd, xpr.  Even better, grab xdump from ftp.cs.uwm.edu.  It makes use  of these programs as well, but has a much nicer interface (and can do more). You can dump to PostScript, bitmaps, etc.
pyeatt@Texaco.com writes:  >> There is a widget already defined for GL.  It is the GlxMDraw (motif) or >> GlxDraw (athena) widget.  It is similar to a XmDrawingArea, except that it >> allows you to use GL calls to render into the window.  Look at glxlink, >> glxunlink, glxgetconfig, and glxwinset in the man pages.  Where do I get hold of these widgets?
In article <C56M19.17r@world.std.com>, grier@world.std.com (The Political Crony) writes: >  > The title line says it. The Galaxy package was just recently announced, and > includes a GUI-builder and portable toolkit. I'm interested in any > feedback from those who may have used it thus far.  We've been using it for a year on Unix (Sun and HP) and Windows platforms.  In my opinion, it is the best toolkit on the market.  It supports a rich API to a high level IPC mechanism, file system abstraction, memory management, command driven application development, drawing, geometry management, and, oh yeah, Open Look, Motif, MS-Windows and Mac (at the flip of a switch).  >  > Thanks > Jim Grier > grier@world.std.com >   --
Greetings,   I am using an X server that provides 3 visuals: PseudoColor 8 bit, Truecolor 24 bit and DirectColor 24 bit.  A problem occurs when I try to create a window with a visual that is different from the visual of the parent (which uses the default visual which is TC24).  In the Xlib reference guide from 'O reilly one can read in the section about XCteateWindow, something like: "In the current implementation of X11: When using a visual other than the parent's, be sure to create or find a suitable colourmap which is to be used  in the window attributes when creating, or else a BadMatch occurs."  This warning, strangely enough, is only mentioned in the newer editions of the X11R5 guides.  However, even if I pass along a suitable colourmap, I still get a BadMatch when I create a window with a non-default visual. The code looks like this:  ------------------ cut here and you'll destroy your CRT ----------------  Window create_8bit_window_on_truecolour_display(dpy,width,height) Display *dpy; int width, height; {   Window win;   XVisualInfo vinfo;   XSetWindowAttributes attr;    fprintf(stderr,"Opening 8 bit window...\n");   if (!XMatchVisualInfo(dpy,DefaultScreen(dpy),8,PseudoColor,&vinfo)) {     fprintf(stderr,"Your display can't handle 8 bit PseudoColor.\n");     exit(1);   }   fprintf(stderr,"Using visual: %x\n",vinfo.visual->visualid);   cmap = XCreateColormap(            dpy,            DefaultRootWindow(dpy),            vinfo.visual,            AllocNone          );   XSync(dpy,False);   XInstallColormap(dpy,cmap);	/* ommision of this line gives same result */   attr.colormap = cmap;   win = XCreateWindow(           dpy,           DefaultRootWindow(dpy),           10,10,           width,height,           CopyFromParent,       /* border width */           8,                    /* depth */           InputOutput,          /* class */           vinfo.visual,         /* visual */           CWColormap,           &attr         );   return win; }  --- cut here and you'll destroy your CRT -----  Executing this piece of code results in a BadMatch error. Anybody who knows why? If so, please drop me a line.    	Take care,
In article <1993May07.160443.6208@nenuphar.saclay.cea.fr>, basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) writes: > I'm seeking a *simple* window manager (ICCCM compliant) with a minimal doc. > I don't want ol*wm twm gwm *twm.  Whatever happened to uwm? Is it still available in some form? It's been years since I used it or heard anyone talk about it. --
I am new to X programming, so please bear with me....  I am trying to have a dialog box that returns it's value upon the user entering a new value and hitting the <return> key. (don't want to have a "done" button).  The piece of code below will work if I exclude the XtNvalue argument but will not work as is. Can someone shed some light on this or suggest a better way?  Ultimately I will have several areas active at the same time to allow a user to modify parameters in the program.     Thanks for your help,  Karen Rogers Dupont rogerskm@pluto.es.dupont.com  ######### Code starts here ################ void doit() { printf("Entered the doit function\n"); exit(); }  main(argc, argv) int argc; char **argv; { Widget toplevel; Widget outer; XtAppContext app_con; Widget samples; Arg args[3]; static XtActionsRec key_actions[]=      {     {"doit", doit},     };  toplevel = XtVaAppInitialize(&app_con, "TEST", NULL, 0, 	                       &argc, argv, NULL, NULL);  outer = XtCreateManagedWidget( "paned", panedWidgetClass, toplevel, 					NULL, ZERO);  XtAppAddActions(app_con, key_actions, XtNumber(key_actions));  XtSetArg(args[0], XtNlabel, "Enter value"); XtSetArg(args[1], XtNvalue, "0");  samples = XtCreateManagedWidget("samples", dialogWidgetClass,outer,args,2);  XtOverrideTranslations(samples,  	  XtParseTranslationTable("<Key>Return: doit()"));
How can get a pixel value from a Drawable, without having to copy it to the client as an XImage and use XGetPixel ?? - I want to select pixels from an animating window on the server, without having to copy the whole lot back to my client. (X11R5).  Any pointers appreciated,  Gordon.