In Gnome, whenever an application is started, the mouse cursor changes from normal to an activity indicator (a spinning wheel type thing on Ubuntu). Is there any way to inform Gnome (through some system call) when the application has finished launching so that the mouse cursor returns to normal without waiting for the usual timeout of 30 seconds to occur.
I have a program in Pythong using GTK+ that is showing the icon even after launching, so what system call do I make?
Normally it happens automatically when you open the application's window.
It may be that the application's launcher just calls an already running instance, in that case it won't be automatically detected. The call you need then is this:
import gtk
gtk.gdk.notify_startup_complete()
Your application can opt out of startup notification by adding
StartupNotify=false
to your application's .desktop file.
Of course, it is friendlier to leave it enabled and participate in startup notification.
I had a similar issue with an application I wrote. I was launching the application through a shell script containing the line
python /path/to/application.py
This launched the application as I expected, but the startup notification did not stop.
It worked correctly once I changed the content of my script to this:
exec "/usr/bin/python" "/path/to/application.py"
Obviously the latter one seems to be the correct way to launch the application, though I don't have enough insight to tell why.
This normally happens automatically when calling the gtk.main() function
Related
I have a sikuli script which does the Siebel Tools incremental Compilation Task on a Windows Box from Jenkins.
The problem is: When i run the task i always have to open the RDC window open for the task to be executed.As soon i minimize the window the script fails.
Hence if the Sikuli script is running i will not able to use my local system for any other task.
I found some posts on launchpad.net.
this is one reference: https://answers.launchpad.net/sikuli/+question/213636
But it did not work.
Can anyone help on this.
This solution has helped me out:
Close all open Remote Desktop sessions.
Launch the Registry editor (regedit.exe).
Navigate to one of the following Registry keys, depending on whether you wish to modify the Remote Desktop settings only for the current user or for all users on the computer:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
Create a DWORD value named RemoteDesktop_SuppressWhenMinimized and set it to 2.
Close the Registry Editor.
After these steps are done RDC when minimized will not be suppressed and sikuli will work.
Answer taken from:
https://support.smartbear.com/testcomplete/docs/testing-with/running/via-rdp/in-minimized-window.html
Other solution is to use VNC connection instead of RDC. RealVNC for example.
You setup VNC server on machine that sikuli scripts are running on and connect from your other machine. You should even be able to close the connection window and scripts should still be able to run.
You could just keep the RDC session running in the background. Just don't minimize it. I am doing the same with my tests.
I have a question about Python on Linux. I have a Python application that currently runs on Windows. The application controls some hardware, and each hardware control application runs in it's own process, which in turn sometimes start processes of their own. The processes communicate with named pipes, named mutexes, and named memory-mapped files to the main control process, but each application process has its own console window. This allows the user to select the window for one application process, representing one hardware item, and view what it's doing. It also allows a simple "print" to produce debug statements on the window for that process. On Windows this is easy because either os.startfile or subprocess.popen can run a python script in a separate process, in a new console window, and capturing "print" output in that window. The main process starts all the application processes and then minimizes the windows, making it easy for the user to select one (or more) for viewing. The application processes write log files when they are done, but having a console window for each one allows viewing of progress and messages in real time.
I need to make a linux version of this and I'm running into issues. I can't figure out how to make Linux open an application in a separate, visible, process window. If I use subprocess.popen with shell=True, I get a separate process but no visible window. If I set stdout=subprocess.PIPE, the application isn't in a separate process, but uses the main process window for printing, and incidentally hangs the main process until it's done (this is disasterous in my application). I found a workaround where I open the application process with shell=True, and the application process then creates a named pipe and opens its own GUI (using shell=True) for output display. But this means I have to change all the print statements in the application processes to go to the named pipe, which is a huge amount of work. Plus, it would be nice (but not essential) if the Windows and Linux versions looked the same in how the windows appear.
Is there a way, in Python, on Linux, to start a new Python process in an open, visible window that will capture "print" statements? Or am I trying to do something Linux doesn't support? I'd rather not change everything to sockets - it would probably be easier to use the GUI and named pipe method than to do that.
Thanks for any answers or insight.
I've got this python script that opens up a VNC session through a graphical window. It sits there blocking waiting for a particular message to come in and then spawns the graphical window successfully when ran from the command prompt.
But if I place this in an Upstart .conf file so I can use it as a background service, I can see that my program receives the message to pop up a window but it does not display a graphical window.
...
exec /usr/local/bin/vncscript.py # does not display window
...
How would I go about displaying a graphical window using Upstart?
Ended up going with the solution from by setting up a .desktop file:
https://askubuntu.com/questions/107187/how-to-launch-gui-app-with-upstart-script
Initially, I started by a
export DISPLAY=0.0
...and it worked. I could then control it as a service. But as soon as I restarted the computer, it would not work as expected. Could not even stop the service after starting it. I'm not sure why it worked in the first place.
I'm using Pycharm 4, with flask 0.10.1, python 3.4
It seems that when running a flask application from inside pycharm, if I run it with:
app.run(debug=True)
My breakpoints are ignored. After some googling, I've found that in order to make PyCharm stop on breakpoints, I should run flask with:
app.run(debug=True, use_reloader=False)
Now PyCharm correctly stops on breakpoints, but I miss the autoreloading feature.
Is there any way to make both work together?
Using python 2.7 both things work
I reported this to PyCharm: https://youtrack.jetbrains.com/issue/PY-13976
I'm going to start with the short answer: No, what you want cannot be done with any releases of PyCharm up to 4.0.1.
The problem is that when you use the reloader the Flask application runs in a child process, so the PyCharm debugger is attached to the master process and has no control over the child.
The best way to solve this problem, in my opinion, is to ask Jetbrains to build a "restart on change" feature in their IDE. Then you don't need to use Werkzeug's reloader at all and you get the same functionality direct from PyCharm.
Until Jetbrains decides to implement this, I can share my workaround, which is not terribly bad.
In the "Edit Configurations", set the configuration you are going to use to "Single Instance only" (check box in the top right of the dialog box)
Make sure the configuration is the active one.
Configure your Flask app to not use the Werkzeug reloader.
Press Ctrl-D to start debugging (on Mac, others may have a different shortcut)
Breakpoints should work just fine because the reloader isn't active.
Make any code changes you need.
When you are ready to restart, hit Ctrl-D again. The first time you do it you will get a confirmation prompt, something like "stop and restart?". Say yes, and check the "do not show again" checkbox.
Now you can hit Ctrl-D to quickly restart the debugger whenever you need to.
I agree it is not perfect, but once the Ctrl-D gets into your muscle memory you will not even think about it.
Good luck!
I found that in PyCharm 2018.1.2 there is FLASK_DEBUG checbox in run configuration:
With this after making some changes, saving file triggers reload action.
In my setup, I'm debugging the flask app by running a main.py file which sets some configuration and calls app.run(). My python interpreter is set up in a Docker container.
My issue was that I needed to check Run with Python console.
The problem is because with use_reloader=True the werkzeug application is started in a seperate (child) thread of main application and PyCharm fails to correctly handle breakpoints because they are lost when the thread starts.
You can try to follow this thread: http://forum.jetbrains.com/thread/PyCharm-776 but it seams there was not too much progress on that.
I'd suggest using something Python-ish like pdb, i.e.:
#app.route('/<string:page>')
def main(page):
import pdb; pdb.set_trace() # This line actually stops application execution
# and starts Python debug shell in the console
# where you can examine current scope and continue
# normal code execution at any time.
# You can inject *any* code here.
# For example, if you type `print page` during pause,
# it will output content of "page" variable.
return render_template('index.html')
Try configuring this python running configuration in "Edit Configurations". After that, run in debug mode.
You need to unlock the console.
you start the app in debug mode
then you make something that causes an error.
at the end of the error message from flask is this
Here you enter the PIN flask prints in the console at the start
copy paste this pin into the console and click confirm PIN
now the breakpoints will work
from pycharm 2017 using python 2.7 (in my case with virtual env, but I suppose not necessary) I do:
run...
leave scripts and scripts parameters blank
I put in interpreter options: -m flask run
set the env variables FLASK_APP
than run attach to local process, and finally choose the running process
my use case is to connect from postman to flask rest services endpoints and interrupt on my breakpoints
I have an python 2.7 application that I would like to move from the CMD window to the system/notification tray (Windows 7). The python script currently listens for particular TCP messages, and upon receipt, logs them to a file.
I have recently found the following system tray code, from another question answered here:
systrayicon
I've been able to run the systrayicon demo correctly by creating the SysTrayIcon.py module. My problem is, when I try to run my TCP application alongside the systrayicon (with some of the demo code intact), it only runs my application, or the system tray application, not both. More specifically, if I list my app's main(sys.argv) before the systrayicon(), it only runs my app without the tray icon. If I have the systrayicon listed before my app, it runs the system tray demo, until I select "Quit", and it then runs my app.
I am able to get my TCP app to run correctly if I plug it into one of the menu selection functions, for example:
def hello(sysTrayIcon):
main(sys.argv)
But I'd like my app to begin listening when the application is opened, without selecting something from the menu to initiate it.
This is likely a very basic problem, and maybe worded poorly, my apologies.
I think the easiest way for you to accomplish this would be to just wrap your script with a small piece of GUI code using Tkinter or wxPython. Then it can reside in the tray. You will probably need to run your script in a thread as it sounds like a long running process that would block the toolkit's main loop. You might need to add some code to the threading code that allows you to kill your script when the GUI exits, but other than that, it should be pretty easy.