I'm planning on using an embedded browser in my pygtk application and I'm debating between gtkmozembed and pywebkitgtk. Is there any compelling difference between the two? Are there any third options that I don't know about?
It should be noted that I won't be using this to access content on the web. I'm mainly using it for UI purposes.
My priorities are:
It needs to be stable.
It needs to be cross-platform.
It should be easy to use.
It should be actively maintained.
It should be extensible.
It should be fast.
gtkmozembed is not available on Windows, although you can use the gecko embedding interface directly. This would require you to write some C++ code.
As far as I know, the gtk webkit port is not available on Windows yet, and still appears to be undergoing a lot of change.
For an example of a cross-platform gecko embedding solution, check out Miro.
Miro is python, and they've written just a couple of C++ classes to embed gecko on Windows, while using gtkmozembed on linux.
if you judge by the web pages then definitely pywebkitgtk
pygtkmoz from this page
"Note: this project is no longer maintained. Please use gnome-python-extras (http://www.pygtk.org) instead. I apologize for any trouble this might cause, but this is better in the long run. Python bindings for GtkEmbedMozilla."
and pywebkitgtk looks like active project changes
Related
How can I use the functionality of a Java library I have in JAR format (no sources) in a wxPython front-end app running on OS X 10.8?
I can use the library in Jython, everything works fine, but of course wx is CPython-only so I could not find anything better than this: http://jpype.sourceforge.net/doc/user-guide/userguide.html :(
Needless to say, JPype is really cumbersome, at least for the extensive use I need to make of the JAR in question.. are there better ways to do this or more advanced systems?
I can't change wxPython as the GUI as all the toolchain depends on it, up to the latest packaging step of PyInstaller.. and I can't rewrite the JAR nor replace it with some open-source package..
I would suggest running it in a different process as a java application, and then communicate with the Python application using some form of IPC.
I'm planning to take a non-GUI Linux distro (no Gnome, KDE, etc) and build my own front-end GUI for it. While I have a few years of Python programming experience, I have never attempted to do something quite like this.
To be more specific about my project, I'm building a CarPC and I have everything pretty much worked out so far, except the front-end. Most pre-existing front-ends for CarPCs run on Windows and the ones that run on Linux are hard to find (they either quit development or only run on specific hardware). My front-end will always be full-screen and I do not want to run a desktop environment unless I absolutely have to; it would just slow down the boot time and provide unnecessary features.
My question is basically where I should start. What Python graphics libraries are out there that would allow me to build a front-end GUI without a desktop environment?
You'll probably want to look at other answers and questions on this topic such as this one
Another good link is this one on the Python websitewhich lists different GUI toolkits.
While I haven't used it, Kivy looks like a good place to start. It's apparently got touch screen capabilities which I assume you would use and it doesn't look constrained to a GUI desktop env.
Hopefully you can find a way to do this without a desktop env. If not perhaps consider using X11 as your layer and go from there.
You should probably consider DirectFB. You can even use a DE on it if you like (although not required).
WxPython is awesome. I use it with Python and plain WxWidgets in C++ too. I've had great luck with making native GUIs from it and internationalization is supported too. Good luck!
Edit: I missed the "without a desktop environment bit". I'm not sure my answer is relevant. You should edit the Title of the question. Just disregard.
The docs I've found on NPAPI plugins explain how to write plugins to be loaded by browsers, but how hard is it to write an application that loads existing NPAPI plugins?
(My ultimate goal here is to find a way to use SWF content inside an application written with Python and wxPython in Linux. I've accomplished this on Windows by using the comtypes module to load the ActiveX Flash player. For Linux, I'm thinking that wrapping the Gnash NPAPI plugin in some C/C++ code and making this a Python extension seems like it would work, albeit a bit convoluted...)
Your best bet (assuming basing your hosting code on open source software isn't an issue for you licensing-wise) is probably to look at the implementation of NPAPI host in WebKit, Chromium, and/or Gecko.
The Mozilla documentation for the browser side of NPAPI will help, but there are a lot of little corner cases where plugins expect certain behavior because some early browser did it, and now everyone who wants to support those plugins has to do the same thing even if it's not part of the standard; the only way to learn about those is to look at existing implementation.
I've been playing with PyWinAuto today and having fun automating all sorts GUI tests. I was wondering if it is still state of the art or if there might be something else (also free) which does windows rich client automation better.
pywinauto is great because it's Python.
Perhaps a bit more full featured is AutoIT, which has a COM server that you can automate (from Python using win32com), and some cool tools, like a "Window Info" utility, which will give you the text (title), class, size, status-bar text, and so on for the window currently under the mouse cursor.
There are some cases where pywinauto is a bit harder to use than AutoIt, and seems a little less polished. One example is automating Inno Setup programs. The Inno Setup "setup.exe" program launches a separate application that actually performs the install, and it's a pain to track this down with pywinauto, but AutoIt makes it easy.
I used to do test automation on our projects with AutoIt but switched over to pywinauto 3 months ago and have been very happy with that decision. There are some rough edges, but I've been able to fill them in with my own supplementary test functions. In addition I find that coding tests and support code in Python is much easier and more manageable compared to AutoIt. With Python I have way more powerful options for logging, debugging, documentation, process management and test configuration. For me it was absolutely the right way to go.
I am going the same way, bit by bit and I have to say that python + pywinauto is good stuff!
New pywinauto 0.6.0 has introduced MS UI Automation support under the hood. So that WinForms, WPF, Qt, Store apps etc. could be automated almost the same way as an old native Win32 application.
Moreover it's possible to use mouse and keyboard modules out of a window/control context. These modules work on Linux as well!
New module win32_hooks is inspired by pyHook and similar libraries, but it doesn't require compilation.
Yeah, this post is a kind of ad. But I just wanna say pywinauto is still useful and I believe it will be even more useful in the future. The developers community currently consists of 2 mature developers and 3 talented students and we have long term plans on Linux and Mac OS X.
P.S. There are some more open source tools:
similar tools overview in the pywinauto docs
UI Automation tools rating by GitHub stars and SO stats.
I'm interested in making desktop widgets, similar to Apple's Dashboard or what Vista has. I'd like to make them cross-platform, if possible. Opera's widgets are cross-platform but require the user to have Opera installed, so that's a big limitation.
I know most widgets are made with HTML/XML, CSS, and Javascript. Is there a way to create them using Python?
Update: I did find a site talking about Pyjamas. Does anyone have experience with it and, if so, what are its capabilities/limitations?
You should take a look at what the guys at Digsby are doing. Basically, they've written a port of WebKit to wxWidgets, and then use WebKit to render the interface, and wxPython for writing the rest of the app. Pretty neat, but very alpha at the moment.
Take a look at gDesklets. AFAIK they're UNIX only, but mabybe porting them to other platforms make more sense than starting from scratch?
They use python to create widgets (desklets).
Screenlets is designed for this task.
The Screenlets project is both a Python framework to simplify writing Cairo-drawn desktop widgets, similar to those found in the "Dashboard" feature of OS:X.
Widgets can be written entirely in Python. A collection of widgets using the framework have already been developed.
It is designed to work with Linux desktop. But it should be easy to port to other platforms, since Cairo is cross-platform, in my opinion.
Disadvantages
It's not updated frequently. The latest version, 0.1.6, was released on 2012-01-27
Its home page has been down for some time. Launchpad works though.
Only Python 2 is supported.
You can check out PyGTK, which will allow you to create desktop widgets, but they won't be managed by OSX's Dashboard. If you'd like to develop an OSX widget, you'll want to stick with HTML/CSS/JavaScript.
Take a look at pyqt4. It has webkit integration. I was looking into this myself but haven't really had time to dig into the API.