I'm writing a small python script that tracks how I'm dividing my time between programs. It needs to detect the currently active window (ideally, the application controlling that window, but I can make do with just the window title), as well as idle time.
At the moment, I'm using KIdleTime to determine how long I've been not touching my computer, which works fine by itself.
I also try to use wnck to determine which windows are active, and again, this works fine by itself.
It's when I try to combine the two into one program that I run into troubles. Since wnck is a gnome library and KIdleTime is a KDE library, they need to be run on their own threads for the window change and idle timeout signals to fire.
I'm having trouble finding a way to do this in python - if I use the threading module to try to run one of them on a separate thread, the KDE library complains that it's not on the main thread, or the Gnome library has an impressive meltdown and eats all the memory it can get (incidentally, ulimit was very useful in this case, I can recommend it).
So, I have four options:
Find a KDE library that can detect
when the window is changed - I would
have thought that dbus would expose
this in kwin, but it doesn't seem
to.
Find a way of running both the kde and gnome libraries at the same
time.
Find an equivalent of KIdleTime that runs on the Gnome event thread.
Use timers to poll KIdleTime from within the Gnome thread (which is
what I'm doing now, but is far from ideal, it leads to imprecision in
determining idle times).
Can anyone offer me a solution?
One can use the wxPython GUI toolkit for this purpose.
It has a method for getting the active window.
It has a timer class, althou there are multiple ways you could use.
Of course, you can forget about QT, Gnome, and all other graphical libraries.
Here is what wx can do.
Related
I need to be able to zoom in and out of an image I show using cv2.imshow().
I read that this can be done by adding a flag that enables an expanded gui display.
cv2.namedWindow('image',cv2.WINDOW_GUI_EXPANDED)
However, running this does not seem to make a difference, and I don't see any buttons on the gui window I create. Is there anything I need to install and how should I run it? I'm not getting any errors.
Thank you.
imshow zooming should work via built-in mouse events without WINDOW_GUI_EXPANDED.
For imshow or your particular use case, there are two requirements for zooming to work:
OpenCV is compiled with Qt library support
A thread is currently free to handle the window events (cv.waitKey(0) blocking in the main thread, or cv.startWindowThread() to spool up a background thread for window events)
I was never able to get QT support to work in windows with python. It works seamlessly in linux. And by building from source on windows with c++, it also works.
I believe that for python you need to install by copying the pyd file in C:\opencv\build\python\cv2\python-3 to your packages folder. Or you need to compile with the global python directories specified in the cmake config.
This is my first post on stack overflow so I hope I'm doing it properly.
I am currently working on a Terminal User Interface for python applications. I know that there are many ready-to-use libraries such as npyscreen out there, but I wantend to create one as programming excercice. In particular, I wanted to to play with some architectural patterns to learn them.
All that said, I'm currently facing several problems with python curses library, that I'm using as low level interface to the terminal.
The problems arise when I try to resize my terminal. As you can see from the code (see below), I handle the terminal resizing in the main loop, invoking the getmaxyx()() method of my curses window and redrawing what is on the screen accordingly.
The problem is that the screen seems to flicker when I try to resize the terminal.
Moreover, my "curses application" works fine on MacOS but totally crashes on windows (even after installing windows curses).
To handle that I tried to re-write the low-level interfice by using the blessed library. It solved the windows crashing problem, but the flickering still remains.
I can not figure out what the problem is.
Fore those wishing to help me, here follows the github page of the project: Terminal GUI on GitHub
Thank you in advance.
With curses, there's (at least) 3 things to look for:
ncurses can handle SIGWINCH (PDCurses may not)
some Python configurations interfere with ncurses receiving SIGWINCH. If your program never receives KEY_RESIZE (which it's not checking for...), then it's time to file a bug report for Python to get that fixed.
some programs don't actively read keyboard input (and if KEY_RESIZE isn't read, ncurses won't update the screensize. That would make the program crash.
I have an application written in Python and 'compiled' with PyInstaller. It also uses PyQt for the GUI framework.
Running this application has a delay of about 10 seconds before the main window loads and is shown. As far as I can tell, this is not due to slowness in my code. Instead, I suspect this is due to the Python runtime initializing.
The problem is that this application is started with a custom laucncher / taskbar application. The user will click the button to launch the app, see nothing appear to happen, and click elsewhere on another application. When my application shows it's window, it cannot come to the foreground due to the rules for SetForegroundWindow.
I have access to the source for the PyInstaller win32 loader, the Python code, and even the launcher code.
My questions are:
How can I make this application start faster?
How can I measure the time spend i the first few seconds of the process's lifetime?
What is the generally accepted technique for reducing time until the first window is shown?
I'd like to avoid adding a splash screen for two reasons - one, I expect it won't help (the overhead is before Python code runs) and two, I just don't like splash screens :)
If I need to, I could probably edit the PyInstaller loader stub to create a window, but that's another route i'd rather not take.
I suspect that you're using pyinstaller's "one file" mode -- this mode means that it has to unpack all of the libraries to a temporary directory before the app can start. In the case of Qt, these libraries are quite large and take a few seconds to decompress. Try using the "one directory" mode and see if that helps?
Tell PyInstaller to create a console-mode executable. This gives you a working console you can use for debugging.
At the top of your main script, even before the first import is run, add a print "Python Code starting". Then run your packaged executable from the command line. This way you can get a clear picture whether the time is spent in PyInstaller's bootloader or in your application.
PyInstaller's bootloader is usually quite fast in one-dir mode, but it can be much slower in one-file mode, because it depacks everything into a temporary directory. On Windows, I/O is very slow, and then you have antiviruses that will want to double check all those DLL files.
PyQt itself is a non-issue. PyQt is generated by SIP which generates very fast lazy bindings; importing the whole PyQt is faster than any other GUI library because it basically does nothing: all bindings to classes/functions are dynamically created when (and if!) you access them, saving lots of memory too.
If your application is slow at coming up, that will be true without PyInstaller as well. In that case, your only solution is either a splash screen (import just PyQt, create QApplication, create a display the splashscreen, then import the rest of your program and run it), or rework your code. I can't help you much without details.
I agree with above answers. My Qt python program needed about 5 seconds to start up on a decent PC when using onefile mode. After I change to --onedir, it only took around one second to start; almost immediately after user double clicks the exe file. But the drawback is that there are many files in that directory which is not so neat.
For my application, the long startup time almost entirely was caused by the antivirus system. Switching it off reduced the startup in my case from 3 minutes to less than 10secs!
To bring these measurements into perspective: My application was bundled with extra data files (about 150 files with a payload of 250MB), besides carrying around Qt and numpy (that may depend on Intel MKL, which alone adds another 200MB to the bundle!) dependencies. It even didn't help much that the tested system was running with a solid state drive...
In conclusion: if you have a large application with lots of dependencies, the startup time may be affected strongly by the antivirus system!
In case anyone is still have this issue, I resolved mine by running the exe locally and not on any sharedrives. This took the startup time from over a minute to under 10 seconds.
I solved this by adding an exception to the anti-virus monitoring software (F-Secure). It removed the wait of several minutes before running.
I have 'compiled' a few wxPython apps using py2exe and cx_Freeze, None of them take more than 4 seconds to start.
Are you sure sure it's not your code ?
maybe some network or some I/O resource call holding your app ?
Have you tried other machine than yours? Even the fastest hardware can be slow sometimes with the wrong software config, apps or OS, try it.
Try timing it with timeit module.
I never used pyQT, but with wxPython the startup speed is OK, and after the first initialize if I close and open again, it's faster than the first time.
I'm developing a python application that uses a C-extension module I also developed myself. The extension module does some heavy number crunching and makes use of OpenMP.
I was recently adding some GUI components to my Python application using PyQt4. However, when I show a window, the application crashes before the window is fully drawn (The window shows up very shortly). I was able to track the problem down: When I compile my number-crunching C-extension without OpenMP support the Window shows up fine and everything works. I guess it has something to do with the threading stuff between OpenMP and Qt. Has anyone ever made a similar observation?
As a workaround, you can create a stand alone program using openmp, and a Qt frontend program. and make them communicate by using tcp socket or something you familiar (dll is another option?).
the point is, isolate different modules, if one module fails, you know which part fails.
as one whole big program, it is hard to find one wild pointer...
It could be the case that something in the PyQT is thread unsafe.
May be you could try using zeromq with inproc or ipc for example.
Make sure that the OpenMP number crunching extension is free of race conditions.
Avoid updating windows or any other GUI operations from multiple threads - use #pragma omp single or #pragma omp master to this kind of stuff.
If you have a variable/callback to the python code, make sure that all threads have finished what they were supposed to before changing the variable or making the callback.
The threads from QT and the thread from OpenMP are completely different threads, so this shouldn't pose any problems.
I'm developing an application with PyGTK that will make use of visual-python's 3d drawings and animations, but I can't get both libraries to work together: they either hung up when I close the Gtk window or they get stuck when I run the application.
I've tried with threads and they run side-by-side, but when I close visual-python's window this kills python's interpreter, raising a Segmentation Fault.
Has anyone been able to use visual-python from a PyGtk app?
This is a non-trivial problem given the way that VPython wants to work, but there is an example in the contributed programs section of the VPython web site that shows how to embed VPython into a wxPython application, so perhaps you can look over that code and determine what you would need to do to perform the same magic in PyGTK.