Fedora 20, xorg 1.14.4-11.
I run with a lot of terminal windows open, and I make heavy use of the compose/multi-key mechanism. One of the most frustrating things is that after altering my ~/.Xcompose file, I need to start new terminal windows in order to see the changes.
Is there any way to get X clients to reload ~/.Xcompose rather than just the once when they start? Particularly terminal apps and XChat?
Thanks!
In order to reload `~/.Xcompose´ one needs to close and then re-open the input method:
XCloseIM (im);
im = XOpenIM (display, ...);
Normally X11 clients never do that, so there appears to be no way to make existing programs reload the file. You can make it happen in your own programs.
I use multiple keyboard layouts, and I just figured out that switching layouts (at least in GNOME) reloads the XCompose file.
If you are using IBus as your input method, doing
ibus restart
will make any programs that use it (most of them but not xterm for example) reread .XCompose.
Related
I am trying to create an updater for a screenshot application I have.
I've done the main part of downloading the update, but I now need to find a way to rename the new file the same as the existing one -
e.g. "NewFile.exe" > "ScreenshotApp.exe".
Also, I don't want to add another .exe solely for updating, just for the purpose of keeping it light and portable.
Is there any way of renaming a file that's in use?
Perhaps telling Windows to rename it AS SOON AS the application has closed itself?
Option 1:
Have launcher which most likely you want update that will handle updating your application as well as launching.
Option 2:
Have external exe monitoring updates and updating your app.
Option 3:
Cretate batch file that will update your app whenever your done using it.
Option 3 is the one you are looking for but it is the worst. If anything goes wrong the app wont work and if user can live without it, they wont reinstall.
Option 2 is mostly used by bigger players. They either work all the time or are scheduled.
I would do option 3, it is much easier than you think, and if you want single exe, just make your app a dll, you can update it whenever you want but launcher will stay the same. That way you can handle any errors, and fix them if there is need for it.
Option 4 would be to run installer with fresh update that will close app install update. That solution is better to buy. For $250 you can get neat stuff where it would take you a lot man hours to o something even remotely close.
So I am trying to keep my Node server on a embedded computer running when it is out in the field. This lead me to leveraging inittab's respawn action. Here is the file I added to inittab:
node:5:respawn:node /path/to/node/files &
I know for a fact that when I startup this node application from command line, it does not get to the bottom of the main body and console.log "done" until a good 2-3 seconds after I issue the command.
So I feel like in that 2-3 second window the OS just keeps firing off respawns of the node app. I see in the error logs too in fact that the kernel ends up killing off a bunch of node processes because its running out of memory and stuff... plus I do get the 'node' process respawning too fast will suspend for 5 minutes message too.
I tried wrapping this in a script, dint work. I know I can use crontab but thats every minute... am I doing something wrong? or should I have a different approach all together?
Any and all advice is welcome!
TIA
Surely too late for you, but in case someone else finds such a problem: try removing the & from the command invocation.
What happens is that when the command goes to the background (thanks to the &), the parent (init) sees that it exited, and respawns it. Result: a storm of new instantations of your command.
Worse, you mention embedded, so I guess you are using busybox, whose init won't rate-limit the respawning - as would other implementations. So the respawning will only end when the system is out of memory.
inittab is overkill for this. I found out what I need is a process monitor. I found one that is lightweight and effective; it has some good reports of working great out in the field. http://en.wikipedia.org/wiki/Process_control_daemon
Using this would entail configuring this daemon to start and monitor your Node.js application for you.
That is a solution that works from the OS side.
Another way to do it is as follows. So if you are trying to keep Node.js running like I was, there are several modules written meant to keep other Node.js apps running. To mention a couple there are forever and respawn. I chose to use respawn.
This method entails starting one app written in Node.js that uses the respawn module to start and monitor the actual Node.js app you were interested in keeping running anyway.
Of course the downside of this is that if the Node.js engine (V8) goes down altogether then both your monitoring and monitored process will go down with it :-(. But its better than nothing!
PCD would be the ideal option. It would go down probably only if the OS goes down, and if the OS goes down then hope fully one has a watchdog in place to reboot the device/hardware.
Niko
What I want to be able to do is that, run a vmware machine on workstation, windows xp or 7 for instance. But all the changes I make while I am running the machine e.g. create a file, install something etc, I don't want them to be written to the system/image. Instead it should act like even the image itself is sandboxed, and when I shut down the machine, the image stays the same.
Now, I know about the snapshots functionality, but I basically want to save the time that is expended while reverting an image, on every power down session. Instead it should be such that the changes aren't written to the image/system in the first place (and instead are done in something like memory or a temporary location etc), and thus there is no need to revert when the system is powered off.
Now, is this possible to achieve with just vmware workstation itself? if not than is it possible with some third party tool or something of the sort? if yes then specifically which tool? or if this is possible utilizing any other concepts, say ramdisks etc or anything at all really?
Any help at all is really appreciated!
If I understand your you correctly, defining the VM's disks as nonpersistant should help.
I was wondering if there's a way to force the window created using glutCreateWindow (along with the associated command prompt for my application ) to open on a specific monitor in my dual monitor setup. I use one monitor for coding and would like to use the other for actually running my application everytime I fire it.
Thanks !
This is not possible using only glut. Your solution is going to be specific to the operating system that your program runs on.
Getting this to work is going to be far more effort than it is worth considering you want to do this just to speed up your workflow a bit.
I am writing a custom xulrunner-based app and I wish to have some files deployed in the user profile the first time the application is run.
I placed the files in my application's defaults/profile directory but they did not get copied to user's profile during the first run of the application.
Should I write some additional code or this should happen automatically?
The thing that gets copied for sure is the application default preferences.
Is there a "standard" way offered by Firefox or some of the many mozilla applications?
Any link to some reading will be helpful.
Any hint is valuable.
Thanks in advance.
Unfortunately the standard way of doing first run code is to use the pref system to determine if you have or haven't done something yet. There are a few gotchas though:
Make sure this code only runs once. If your firstrun code is in an overlay or main browser window, it can be run multiple times (once per window)
after you run the code and set the pref, make sure you flush the prefs, since prefs are written on close and will only be saved when you close.
Components.classes['#mozilla.org/preferences-service;1']
.getService(Components.interfaces.nsIPrefService)
.savePrefFile(null);
You could also use the preferences system in concert with querying for an extensions version number. When the version changes, call your function. That would allow you the flexibility to call the function again later if you want - but only at a version change.