I was struggling with getting some asynchronous activity to work under PyGTK, when someone suggested that I look at using Twisted.
I know that Twisted started as a networking framework, but that it can be used for other things. However, every single example I've ever seen involves a whole lot of network-based code. I would like to see an example of using Twisted for a simple PyGTK desktop app, without the needing to expend the extra mental effort of understanding the network aspect of things.
So: Is there a clean, simple tutorial for or example of using Twisted to create a GTK (PyGTK) app and perform asynchronous tasks?
(Yes, I've seen pbgtk2.py. It's uncommented, network-centric and completely baffling to a newcomer.)
Updated: I had listed various gripes with glib.idle_add/gtk.gdk.lock and friends not working properly under Windows. This was all reasoned out on the pygtk list - there's some trickery that is needed with PyGTK to get asynchronous behaviour working under Windows.
However, my point still stands that any time I mention doing asynchronous activity in PyGTK, someone says "don't use threads, use Twisted!" I want to know why and how.
Twisted to perform is asynchronous tasks in pygtk simply uses functions such as gobject.io_add_watch/glib.io_add_watch and gobject.timeout_add/glib.timeout_add (plus some others, you find them in the gobject and glib module), so there's not much difference in using raw pygtk functions or twisted if you don't need networking.
As an addition twisted has the same problems as pygtk with asynchronous tasks, twisted use the same loop as of pygtk and so it gets blocked if you perform some blocking task!
The best thing to do is to use one of the glib functions that are intended basically for handle such situations.
I've tested in an application the correct behaviour under windows of twisted+pygtk but I avoided to do blocking stuff (max reading from a large file, chunk per chunk basically using glib.idle_add or glib.io_add_watch, in the sense that twisted uses something like that).
For example I'm not sure that spawning process and processing stdout with glib.io_add_watch seems to not work. I've written an article on my blog that handle the performing of asynchronous processes in pygtk, not very sure that works on windows though it may depend on the version.
Related
I've an application witch update execute commands on a database. I've a function witch execute that commands and in the in this function I display some messages to the user.
My problem is that the texts written into the textEdit are displayed at the end of the function work.
I've tried to use QThread but it does'nt resolve the problem
this->moveToThread(&threadText);
connect(&threadText, SIGNAL(started()), this, SLOT(writeTexte()));
threadText.start();
Does anyone have an idea how to proceed to write into textEdit and not block the UI ?
In Qt you never need threads in standard UI applications! That is because Qt uses something called event loops that process events smoothly without ever blocking. If you experience blocking, that is a sign that you have a bug somewhere in your code. For any beginner there are some pitfalls. The official documentation on the subject is quite good.
It is hard to tell what your exact bug is because there is littel code to look at. I suggest you post more of your code, especially the naive approach that did not work before you added threads to the mix.
On a side note, using threads in Qt is of course possible and has it's usages, however it can be un-intuitive. I have found this article to be a really good starting point to understand how threads is used best in Qt.
TLDR; is it possible to send/receive objects between an app and a 3rd party launch agent?
I'm writing an extension for an existing app (A). It's packaged and I do not have access to the source - but I can write simple plug-ins that can do some basic Cocoa and host a UI. Read: very limited options.
Ideally, what I'd like to do is have the plugin in app (A) message an external service (B) [sending objects], have (B) do some heavy lifting, then respond back to (A) so the UI can update.
I've been reading up on Launch Agents and they look promising, but I noted the examples all use basic types - no objects. I found one post discussing how to use Distributed Objects, but that's about it. It looks great, but what worries me is I'm not seeing a whole lot of current information on DO and I can't tell if it's something Apple will continue to support going forward.
Does anyone have any suggestions on options for a scenario like this? Maybe I'm just approaching this the wrong way?
Another option is I just completely split this out - write a separate full app and have (A) open it up with AppleScript. The UX wouldn't be as nice, but it would also work.
Thank you,
Eric
NOTE: I can't use NSTask. Or at least I've failed utterly to get it to work in this specific situation. Due to issues with app (A) it breaks when some of the methods run within the process. If I could somehow spawn NSTask so it was executing completely outside of (A) that might be an option. Which is actually what prompted me to look at Launch Agents...
I want to develop an application for Mac OS X to record audio from one application.
I played around with Soundflower, but it only grabs the full system audio.
I know that I have to use a HAL plug-in. This plug-in is loaded from an application that uses Core Audio and then I can communicate with the plug-in to grab the audio.
My question is: How does such a plug-in look like? Are there examples on the internet? I have not found anything about this topic.
Now that you've decided that using Cocoa injection is a feasible solution to your problem, let's start there.
What you need to do is find out how the ObjC classes in the app are setting up to play audio, and hook in to set a different AU in place of the default system out.
There are two options (besides writing your own custom AU from scratch, which you don't need to do). You can use AUHAL as the AU, and capture the data from AUHAL. This is a bit easier from the point of view of hooking things up, but it means you have to write the code that renderers and saves the audio. Or you can just hook in a save-to-file AU, which is a bit harder to hook up, but once you do it takes care of rendering automatically.
So, how do you hook things in? Well, most of the higher-level CA calls are written to just write to the current output. If the app is doing things that way, you just need to hook in at startup to find your replacement AU and set it as the current output, in place of the default. On the other hand, if the app is writing directly to an AU that it stores in a variable, you have to hook it to store your AU as a variable. And if it's building a graph of AUs, you either replace the default output, or stick yours in front of it, in the graph.
See TN2091 for some sample code fragments for most of the hard parts for most of the possibilities. It doesn't show you how to put them together, and it's got a lot more about setting inputs than outputs (because that's harder), and the terminology can get confusing, but if you read it carefully, you should be able to find the parts you need.
If you haven't yet built a simple AU host and AU plugin before, you really should take the time to work through the whole Audio Unit Development Fundamentals guide. (And if you don't think you really need to know all that to do something simple, you're wrong. Why CoreAudio is Hard explains half of the reason; the changes between OS X versions versions are the other half of the reason.)
You probably also want to look at CocoaDev's CoreAudioAndAudioUnitsTutorial page for a placeholder page for a complete tutorial that nobody's ever written, with links to a lot of useful stuff.
Meanwhile, if injecting the whole MTCoreAudio framework into the app is feasible, it comes with a ton of nice, complete samples. In fact, even if you aren't going to use the framework, it's worth reading the Overview documentation, and possibly the source code.
I need to find and monitor all the photos on a hard drive or a folder for a photo organizer. Currently I'm doing this naively: recursively traversing, manually marking folders as indexed, and repeating that process to catch when photos are added or moved.
The problem is with a large enough folder tree this is very expensive, so I'm looking for tips to do this differently and/or tips on keeping it a low cpu process.
Ideally solutions would be not platform-dependent.
EDIT: I'm using xulrunner currently, but could compile a module do platform specific stuff.
What about the first run? Is there no solution (even platform-dependent) besides running through the entire folder tree manually.
Ideally solutions would be not platform-dependant.
Impossible. The Win32API has FindFirstChangeNotification, Linux has inotify (and others), Mac OS X has FSEvents, et cetera. This is stuff that's very low-level, and no OS does it the same as any other OS. If you want something cross-platform, you have to find an API with several backends that works on the platforms you want, but if there are any of these, I haven't yet found them.
I don't know of a way to do this in a platform independant way, but on Linux I'd hook into inotify to call something when a file gets added or updated. You could even use inotify-tools to run a script when that happens, so you don't have to be running all the time to capture all these events if they're infrequent. Just have the script update the database, and optionally notify your gallery/display program if it's running.
Are you coding on .NET? If so, you could use the FileSystemWatcher class instead.
Why not user a filewatcher program, which will notify you of changes in particular folder trees?
If you want to write your own you could use the FileSystemWatcher class to do it.
One answer as of 2014 is facebook's watchman: https://facebook.github.io/watchman/
A couple of years ago I ported some functions of Windows API to Linux like (FindFirstChangeNotification, FindCloseChangeNotification ...) it has some limitations but for what you need it could be enough, please take a look at: https://github.com/paulorb/FileMonitor
In the bad old days of interactive console applications, Don Libes created a tool called Expect, which enabled you to write Tcl scripts that interacted with these applications, much as a user would. Expect had two tremendous benefits:
It was possible to script interactions that otherwise would have had to be repeated by hand, tediously. A classic example was dialup Internet access hell (from the days before PPP).
It was possible to write scripts to test one's own interactive applications, programmatically, as part of a regression suite.
Today most interactive applications are on the web, not on the console. Hence my question: is there any tool that provides the ability to interact with web pages and web forms programmatically, much as Expect provides the ability to interact with console applications programmatically?
(The closest thing I am aware of is Chickenfoot.)
You might be looking for Selenium
I've used Selenium RC in conjunction with Python to drive web page interactions programmatically. This has allowed me to write pretty extensive user tests in which forms and inputs are driven and their results are measured.
Check out the Selenium IDE on Firefox (as mentioned above). It allows you to record tests in the browser and play them back, either using the IDE itself, or the Remote Control app.
Perl Mechanize works pretty well for this exact issue.
HTTPS and some authentication issues are tricky at times. I will be posting couple questions about those in the future.
I did a ton of Expect work in a former life and always thought Don Libes' Expect book was one of the best-written and most enlightening technical books I'd ever seen.
Hands down I would say that Perl's WWW::Mechanize library is what you want. I note above that you were having trouble finding documentation. There is good documentation for it! Look up the module's distribution on search.cpan.org and see what all is packaged with it. There's a FAQ, Cookbook with examples, etc. Plus I've always been able to get help on the web. If you can't get it here, try at use.perl.org or perlmonks.org. WWW::Mechanize's author, Andy Lester, is present on Stack Overflow. (He's also an all around friendly and helpful guy.)
I believe WWW::Mechanize also has a program that is analogous to Expect's autoexpect program: you set up a proxy process running this program as a server, point your browser to it as a proxy, perform the actions you want to automate, and then the proxy program gives you a WWW::Mechanize program for you to use as a base for your project. (If it works like autoexpect, you will certainly want to make modifications from there.)
As mentioned above, WWW::Mechanize is a browser (to be more exact, it is a web client or http client) that happens to be programmable. The last time I looked, there was even work in progress to make it support JavaScript.
In addition to Selenium, if you're doing the Ruby/Rails thing, there's Webrat.