The book "X Power Tools" has a chapter "Display Specifications", where it states:
Since X clients can connect to a
display anywhere on the network, it is
necessary to have some way of
specifying the display to be used.
This is done using a display
specification (or displayspec).
A displayspec takes this form:
host:display[.screen]
How do you use the specifications in your projects? Can anyone connect to your screen if your host, display and screen are known? How can you protect it or share it if many people are working on the same programming project?
Normally, no. Most X Servers will not, by default, accept connections from anything but localhost. The easiest way around this if you need it is to ssh into the box you want to run apps on with X Tunneling enabled. The apps get a valid DISPLAY setting that appears to be local to the X Server, so it all works.
Using X Window display spec in applications generally revolve around looking for DISPLAY in the environment and handing it to the X Client library. You don't have to do anything with it. In fact, modern X Client libraries are probably capable of fishing it out of the environment itself.
See
http://tldp.org/HOWTO/Remote-X-Apps.html
and
http://tldp.org/HOWTO/XWindow-User-HOWTO/ (Chapter 8)
Related
I am trying to add a feature to an Okuma application that can change the operating screens.
I have cycled through the enumerations and I believe the panelgroup I need is 0.
I would like to be able to put the machine into "Manual Mode"
from what I have read in the API Options are Auto / MDI / Manual
Here is one of the variants that I have tried.
It does not throw an error but it does not actually change the operating mode to manual.
If the machine is in Auto/MDI/Manual it will switch to that screen but not the mode.
Maybe I need to access some other API call or maybe I don't actually have API access to put the machine into a mode that code interrupt any other processing G-code..
The ability to change machining modes (Auto / MDI / Manual) is not available from the API.
I can understand why someone may be confused about this point. The way things are worded in the API indicates that changing mode should be possible. That is because in the very early days of API, it was. At one time it was even possible to remote start a machine.
As you know, the Okuma API cannot cycle-start the machine due to safety concerns.
By the same token, changing machine modes while the machine is running in auto would stop / reset the machine. Therefore it is not allowed.
I need to create a very simple program, that should run on raspberry pi without network connection. The program should first show one full-screen bitmap ("insert disk"), and after receiving somehow an external signal (disk inserted), another bitmap which would ask to input password. After inputting the password (each pushed button shows an asterisk *) the application should show yet another bitmap, which would inform whether the password was correct or not.
So in principle I would like to create something that looks like password screen in any Hollywood movie!
Raspberry should boot directly to the application.
I was expecting that this would be easy to do (and it would be if we could use Windows and Visual Studio), but I haven't yet found a simple tool to create this for pi. Booting Raspberry into browser with kiosk mode and creating HTML application seems like an overkill.
Although a browser in kiosk mode might look that a sledgehammer to crack a nut, I think you might find this nut harder than it looks.
It wouldn't be difficult to write a simple app in Java, or Python, or perhaps even C using GTK, that carries out the actions you want. You could have the app loaded when X starts, as an alternative to a desktop and Window manager. You could even do away with X altogether, and write some code that interacts directly with the video framebuffer and the keyboard hardware. Or, heck, go the whole hog, and have your code substitute for the operating system kernel :)
I would guess that even the simplest of these approaches involves more work than hacking something up using a HTML and JavaScript in a browser.
I am new to OS X and have to create an application having 2 parts - launch daemon and launch agent. The daemon is going to do stuff such as command execution, logging, etc and has to somehow communicate these results to launch agent (which would transfer them to a login item displaying a GUI, although that is a future step).
My question:
How do I achieve this communication?. From what I have been able to gather so far after reading Apple docs is that my best bet is using CFSockets. Is there any alternate(simpler) way ? Does anybody have any sample tutorial/example/code that shows how to use CFSockets (I could not find any) ?.
PS: My question might be a duplicate of this one, but that question is not yet answered and so I thought of posting this.
I was able to set up communication between my daemon and agent using CFSockets and it wasn't as bad as I had thought before. I followed the step-by-step instructions at :
https://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/NetworkingTopics/Articles/UsingSocketsandSocketStreams.html (Writing a TCP-Based Server).
You could probably also try using plain BSD sockets. There is a simple example at : http://www.minek.com/files/unix_examples/poll.html (although I have not tried this out).
Good luck.
Here is what I want to do:
I want to run Mathematica on another Mac from my Mac (both Snow Leopards). I want to do this because the remote Mac has multiple cores/processors while my local Mac is rather shabby. I would like to have the front end still locally (i.e. the graphical interface).
What I've learned:
I used to do this type of thing from multiple Linux machines and was expecting to have similar success for Mac-to-Mac operation. However no such luck.
The problem seems to be a display issue (front end).
Mac front end runs in Aqua while X11 is what is really needed (this is why there is no problem on Unix). While Macs have X11, for some reason Mathematica can't use it.
So how do I get around this issue?
Possible solutions that I have had to rule out are: 1. screen sharing. Not practical since someone else will be using the remote Mac on another account. Screen sharing only uses the active screen. 2. Installing Unix on the remote computer. Not possible in my situation.
Thanks.
You should be able to set up a remote kernel on the other Mac. This is done through the Evaluation > Kernel Configurations menu item. The you can set the remote kernel for a given notebook using Evaluation > Notebook's Kernel or globally via Evaluation > Default Kernel.
I haven't done this in a while, and it's sometimes useful to test things from a terminal with something like
ssh <user>#<remote.machine.com> </path/to/remote/Mathematica.app/Contents/MacOS/MathKernel>
Why not use the command line kernel? I have a script math which does:
#!/bin/bash
rlwrap /Applications/Mathematica.app/Contents/MacOS/MathKernel
I built rlwrap from source, but basically that tool gives you readline behaviors. You can just do
ssh remote-machine /Applications/Mathematica.app/Contents/MacOS/MathKernel
The only solution, I believe, is for you to upgrade to OS X Lion. It allows simultaneous screen sharing sessions where each user can control the screen for their own account:
http://www.apple.com/macosx/whats-new/features.html#screensharing
Is there a version of the CUPS server available for Windows? Looking at the CUPS source code it seems it is ready for Visual Studio compilation, but I did not find any trace of an actual supported package. I'd like to set up a CUPS server on Windows so that I can print form Linux/MacOSX/Win clients to printers I set up on this server.
I've got a new answer for you:
Since some time there is a project called ippsample on GitHub. It's slowly approaching a mature version 1.0 release.
Here are the first two sentences of given as self-description in the mandatory README file:
"This code provides sample implementations of IPP Clients, Printers, and Proxies. It is largely based upon the CUPS software, with substantial changes to the ippproxy and ippserver implementations to make them more general-purpose and configurable." (my emphasis)
This project is hosted by the ISTO Printer Working Group (PWG), the same industry organization which develops and promotes the IPP as a general standard.
The ippserver, ipptool, ippfind, ippproxy and ipptransform components of the IPP Sample project together make up for a standard-conforming IPP Everywhere implementation, covering the client as well as the server side of printing.
The GitHub code for IPP Sample project is maintained by the very same Mike Sweet who also develops CUPS -- so it's the real thing.
Yes, it compiles and works nicely on Windows, and there are a bunch of .vclxproj and .sln files available to make the build process with MS Visual Studio as smooth as possible.
Yes, the IPP Sample code is working and can print to a CUPS server (or receive print jobs from there) running on macOS or any blend of Linux.
No, this is not yet a fully-blown CUPS server for Windows which can serve as a drop-in replacement for a Windows print server. It does not have with ALL the features which would be required.
But if you want to create such a beast:
this is the place were you would have to poke around first;
this is were you possibly could fork the code and start adding functionality to get where you want to go.
Oh, and did you know that Apple recently changed the license conditions for CUPS and made it more permissive, moving away from GPL2 to Apache 2.0 licensing?
You have never heard of "IPP Everywhere" before? It is the future of "driverless" printing.
Never heard of "driverless printing"? A slightly modified (and stripped down) version of it already implemented as "Apple AirPrint" for iPhone and iPad devices.
The current implementation of the CUPS-based printing stack includes new pieces of code in the cups-drivers project which recently moved to GitHub. This new code implements IPP Everywhere functionality.
This cups-filters project is under the stewardship by The Linux Foundation's OpenPrinting department ever since Apple handed over these parts of the original CUPS source code to them when they became no longer useful for macOS but were still important to Linux.
What are the basic ideas of driverless printing then?
Have the devices automatically announce their presence and their type of service in the local network. Use the IETF standard protocols mDNS and DNS-SD (which are implemented in macOS under the name of "Bonjour" and in Linux as "Avahi") to take note of the offered services.
Tell the print clients that they can use the IPP protocol in order to get a query response when they make a get-printer-attributes request. This request will tell them which set of print options the devices support. The print clients can then show an exactly tailored print dialog to show to the printing user a selection of choices. The print client will also be told what job submission formats each devices supports. This MUST be either PDF or a simple raster format called "PWG-Raster".
So... where would you need a specific "printer driver" in such an environment? Everything and everyone can create PDF documents nowadays. Check! No need for a device-specific conversion to any other print language.
Are there printers which support IPP Everywhere already? Oh yes, look here -- they are all said to be fully compliant with the standard:
List of IPP Everywhere printer models
The .sln and .vcproj files you've been seeing in the CUPS sources are not meant to compile all of CUPS for Windows.
They serve to compile only a few of its utilities (such as ipptool.exe)...
Making the complete CUPS server+filtering code work on Windows would be a daunting task, since Windows spooling and printing is so much different from the Unix world.
CUPS uses Internet Printing Protocol for client-server communications. According to Technet article, Windows can be used as IPP host:
To enable a computer running Windows
Server 2008 to act as a server
supporting Internet printing, you must
install the Web Server (IIS) role, the
Print Services role, and the Internet
Printing role service in the Print
Services role.
Moreover, it seems that Windows, Linux and Mac OS X clients can use printers shared via SMB.
"Making the complete CUPS server+filtering code work on Windows would be a daunting task, since Windows spooling and printing is so much different from the Unix world."
Back in the dial up internet days, I ran into a problem where some IPS' had a replacement dll for modem functionality. The problem with it was that the dll prevented legit programs from accessing the modem until you uninstalled the IPS program.
This same technique can be used to create a Windows CUPS server by writing a Windows spooling and printing replacement program that, rather than printing directly to the printer, hands off the printing tasks to the CUPS server.
It would of course, take someone with in depth knowledge of the windows spooling and printing protocols.
cygwin ports has patch files for implementing a cups in (some versions of) cygwin. I can't speak to how well it might work.
https://github.com/cygwinports-extras/cups