There are some cool pieces of software out there, like Deckboard or Macrodeck that allow users to control their computer (and streaming software) remotely.
As an example it is possible to press a button in order to open OBS, switch to the scene dedicated to streaming CS:GO and then open CS:GO and Spotify.
Is there any way to execute macros on a computer by using a website hosted on it (using NodeJS if possible)?
Related
I'm making an online exam using PHP and I was wondering if there is a way for me to lock the user's PC onto the browser only. The system will not allow the PC to load and/or open other apps/tabs while the exam is running or should prompt if the system detects that you left the page.
I have a GPS 84H-3 sat nav which runs on windows CE. It uses iGO for navigation.
The interface has an icon which opens the Windows CE desktop. It appears to give unrestricted access to the file system. It has reader versions of various MS office programs; other than that it seems to serve no purpose.
I have 3 questions:
Why would the manufacturer leave access to the desktop in the devices interface?
Is it possible to download and run an updated version of iGO on the machine (I found that the existing iGO version has a icon in the programs folder and the non-Windows interface has a app which lets me set the file the system runs when I click on the navigation icon; remember that the file system is accessible)
Is it possible to run alternative navigation software on the machine?
this question is not well suited to Stack Overflow, but I will try to answer:
1) to allow users to run other programs, simply to make this device more user friendly.
2) probably yes, I suggest you ask iGO for any updates to your software
3) I suppose yes, but you must be aware that navigation software very often needs some form of integration with device, ie. it should take over the sound subsystem of your device while generating navigation voices, it should allow to switch between device UI interface and back to navigation, etc. This might need some changes from navigation software side (like usage of device API).
Be aware than an embedded OS like Windows CE isn't the same as a desktop OS. The application is likely part of the OS and it's quite likely that you cannot replace it without replacing the entire OS, which would have to come from the device OEM. You might be able to "hide" the existing app with a new one, but it's also possible that any replacement will get lost when the device is restarted.
Running any other applications (a replacement navigation app or other) would depend on a lot of things. The app would have to be built for CE. The OS would have to have any dependencies the app needs. The app would have to "understand" or be configurable for any peripherals you may need to use (like the GPS).
It may be possible to install apps or override behavior, but it's completely up to the device OEM on how they implemented things. They have the choice of blocking all apps but the one(s) they want which would give you zero ability to do anything, or they may have left it wide open. Short of some formal documentation from them, testing would be the only way to know for sure.
I want to create a webpage that will access the USB port of the client. Intent is to configure the hardware connected the USB port. I can do a desktop application because the configuration option is different for different hardware. connected and I need to pull this code dynamically from the server. I am not a web programmer. It will great to find the best way to do this.
It ends up that I am attempting to write an app that performs something similar. What I am doing, instead is writing both the web server and the web page. Use something simple, like DLib for the web server, to serve the data to the end user.
This is how it works:
The web server handles the USB connection. If written in C++ or some other native language, you will have much more control over the device. The web page is then loaded from the web server that you have written. In the web page, you can have some sort of javascript worker, etc. to constantly pull new data from the server and push data from the web interface to the USB device. This also adds a layer of protection because you can ensure that the user has not made any modifications to the web page.
The main drawback to this possibility is that you will be required to install the server on the client's machine. However, this can be circumvented by writing this as a applet that can be embedded within the page!
It is possible to write a browser plugin that communicates with USB devices. An example of an app that does that is MyTrezor.com, but unfortunately I don't think you can see the source of their plugin.
Another option might be to use the chrome.usb or chrome.serial Javascript API, but this means your app would only work in Google Chrome, and it would have to be installed as a Chrome packaged app, a special thing that looks more like a native app than a web page.
My company has a Compact Framework.NET WinForms application which runs on rugged handhelds manufactured by companies like Motorola, Intermec and Psion. These are expensive devices with built-in barcode scanners that are used in harsh conditions.
The configuration of the handheld application is managed by business users through our web site. The devices pick up the configuration when they sync from within the handheld application. Field workers use the handhelds, business users use the web site.
The business users have expressed the desire to, for lack of a better description, configure and preview or even fully use the actual handheld application through a web browser. They want to make configuration changes in the web site and immediately see what the impact will be in the handheld, without having to have a physical device (again, the devices are quite expensive). They want to be able to create training materials or conduct sales meetings and be able to demonstrate the application to their customers without having a physical device on hand.
Microsoft offers several Device Emulators, but they are probably too complex for business users. They are developer tools. One idea might be to somehow use the emulators within virtual machines possibly in conjunction with Terminal Services or even some kind of clever screen capture/VNC to show an emulated device in a browser. I suspect running emulators in the fashion may not exactly be a scalable solution, however. Also, only one emulator at a time on a single machine can be "cradled" and connected to network.
I'm looking for any suggestions which might help me meet the business users' requirements.
Thanks.
The only thing I can think of offhand is not that simple, but would probably be useful (and certainly the only "true" way for them to test).
I'd create a service that works like the Remote Display app (part of the WinMo Developer power tools, also ships with Platform Builder for CE), in fact it might just use that app (the source code for it actually ships with Platform Builder, so the eval version of PB would get you that source).
You would then create a web interface that acts as a "shell" for that service, marshalling the display image out to a web page and image clicks back as mouse events to the device.
I recently started using Linux (where I work is a Microsoft shop, so I only code in C#, work with MS products etc).
I'm trying to understand at a high level how some basic things in Linux hang together.
I've been reading www.linfo.org
Anyway I've never quite got what X is.
From reading this article it seems to me that X is layer that sits on top of the operating system (one X server sitting on top of the OS??) and X client applications make requests to the X server.
I think KDE, Xfce and Gnome are display managers, are they X server clients then?
I'm quite confused where everything sits.
Any explanation would be really appreciated!
It's all very modular and flexible; however this leads to complexity.
The "X Server" drives the display device. It provides graphics services to clients, and those services are pretty simple - such as:
"Give me a window frame to draw in"
"Put this bitmap here"
"Draw a horizontal black line 100px wide"
"Render the text 'hello' at (100,100)"
"Tell me if any mouse clicks or key presses have been aimed at my window frame"
There is a library called Xlib, provided by X, that has a standard interface for all these simple services. Any program that wants to use the X server's display eventually uses this client library and is called an X Client. Xlib knows how to connect to an arbitrary X server - on the local machine, or via TCP/IP across the LAN, or across the world - to call these services.
The Window Manager, which is just another X client program, is in charge of the "look and feel" of the desktop - how you move and arrange windows, etc. Because the window manager draws all the window decorations, it can make the desktop look like WindowsXP, or a Mac, or NeXTSTEP.
Part of the philosophy of X was to define "mechanism and not policy" - meaning, they give you tools to do it, but don't tell you how to use those tools. One such tool is the window manager, which can be replaced at will.
Many modern X applications are written to use a desktop enviroment such as Gnome or KDE. This offers these programs a consistent set of buttons and controls to draw, and a consistent interface for some things not traditionally included in X, but often considered part of a desktop - such as how to respond to drag-and-drop or how to present a standard file chooser dialog box.
The desktop environment usually provides an object model or programmatic interface that takes care of making all the simple X client requests and lets the program handle more important things. Removing these low-level calls yields another important benefit - platform independence.
Many desktop environments include a window manager, so that the look and feel of window controls and buttons is consistent and works with the desktop metaphor provided by the environment. However, it can usually still be switched out.
The separation of the X Server (running the display) and the X Client (wanting to use the display) has a few implications:
The graphics system is separate from the GUI programs, and they are separated about as completely as a web browser and web server are.
So the GUI program might not be displaying on the local machine - just like a web browser doesn't have to point at a web server on the local machine.
A machine can run JUST the client, with the X server elsewhere.
The machine with the display doesn't have to run the client - it can run JUST the X server, and all the clients can run on a dedicated machine. This is the original thin client: big programs running on big central server - with graphical user interaction handled by dedicated hardware on the desk in front of the user.
You need to know what your X server's network address is so you can tell GUI programs where to display their GUI. (this is usually done by setting the DISPLAY environment variable)
You can display many programs, from many different machines, all on the same desktop at the same time. It is all handled seamlessly, including cut-and-paste.
X11 is a network protocol, currently at release 7 (hence X11R7). It encapsulates graphics and input information, and connects an X client (application or window manager) running on a local or remote machine to the X server currently driving the local screen and input devices.
Gnome, KDE, XFCE, and LXDE are desktop environments; they contain pieces that talk to/with the X server (metacity, kwin, etc.), but also consist of specifications that applications must follow and libraries that are available in order for an application to "belong" to the DE.
In addition, it's worth remembering that the X server is just another program that gets run under linux. There's nothing special about it, it just happens to know how to grab onto the graphics card and take over the monitor using video drivers.
You can (theoretically) run linux very happily without ever running an X server - although of course, you would be limited to the command line programs.
That's how linux organises itself - kernel at the base, then a set of programs that provide functionality to higher level programs, which themselves provide functionality to higher level programs, all building up into a complete stack of software oriented to whatever the job of the machine is (say, general desktop, software development, web server, etc).
Beyond the kernel and it's modules, nothing is 'special'.
Wikipedia has some info about it.