I have some knowledge about Human computer interaction and some basic knowledge programming scripts (Python) that run from start to finish and automate some tasks I want to do or calculations. In the past I built interfaces in HTML with PHP behind it.
I would like my python scripts to evolve from the command line and build some applications with GUIs that would allow the user to drag files and push buttons to initiate operations and check progress graphically.
Since I write my scripts in Python I looked at some of the options (Tkinter, wxPython, PyQt) but I can't make a decision between them to invest my time learn one and not the other. My criteria:
Has a introduction for programmers for GUI (what are the differences from a script, examples of some simple interfaces)
A framework that would allow me to run my programs on the platforms I use most (Windows) but that can also run on Mac and maybe Linux, without too much modification.
Very shallow learning curve (easy to make first interfaces) but flexibility later on to customize the interface beyond what the typical OS allows (different colors, size and shapes of buttons, for example)
If not the same, similar to how you program GUI for Android and/or Nokia smartphones. I'm planning to write some programs for these platforms in the near future so I would like to carry over some of the lessons here onto those platforms, if possible.
I did find this previous question but none of the answers are satisfactory.
Does any of the frameworks fit these requirements better than the others or are they essentially similar and I would be happy with any of them?
Note: If you think I should consider other language rather than Python to achieve this, which one? I really like Python whitespace syntax and have grown used to it so I would prefer to stick with it.
PyQt and/or the very similar Nokia-sponsored PySide (with a more "relaxed" license, LGPL instead of GPL, and the same underlying toolkit, Qt) do offer the advantage of similarity with Nokia's smartphones GUI toolkit (your fourth point) -- Nokia purchased Trolltech, the makers of Qt, exactly because Qt was the fundamental GUI toolkit for their mobile offerings.
All the toolkits you mention satisfy the conditions you pose about operating systems (Windows, Mac, Linux), your second point.
Your first and to some extend third points depend in good part of what learning materials you have available for each of the toolkits. To my tastes, it seems that wxPython's tutorial (the new one in wiki form is what I'm pointing to and recommending) is really good, and PyQt's not bad at all; PySide's docs don't include a good tutorial (that I know of), I believe PySide's intention is that you first learn PyQt (with the reasonable available materials), then apply these few differences to be programming in PySide instead of PyQt;-). Tkinter's tutorials that I can find are either very old or focused on the underlying toolkit's multi-language nature, which I think makes them inferior.
If you can afford a book, PyQt has a good one (also applies to PySide, as above) -- this excellent and free one is unfortunately very old, so I don't think it helps. wxPython's own book is also quite good; tkinter's, again, is very dated.
Personally I recommend PyQt / PySide: overall power A+, ease to get started (with the above tutorial and book) A-, Nokia-phone programmer similarity A. For wxPython I'd say power A, ease A, Nokia-similarity B. Tkinter's dated tutorials and book are important negatives.
You also mention Android, but I don't see how anything could be similar to both Android and Nokia's phone-GUI programming at the same time. Maybe I'm not familiar enough with Android GUI programming, but it seems to me that it differs from every one of the toolkits you've mentioned.
PyGTK fufills at least the first three points. I'm not sure on the fourth. It has a nice tutorial here: http://www.pygtk.org/pygtk2tutorial/index.html
I guess you are looking for Glade.
The site says:
Glade is a RAD tool to enable quick & easy development of user
interfaces for the GTK+ toolkit and the GNOME desktop environment.
The user interfaces designed in Glade are saved as XML, and by using
the GtkBuilder GTK+ object these can be loaded by applications
dynamically as needed.
By using GtkBuilder, Glade XML files can be used in numerous
programming languages including C, C++, C#, Vala, Java, Perl,
Python,and others.
I am a pretty noob programmer yet, but I am having just a few issues to get things started with C and Glade. So I guess you will run smoothly here with your snake. Take a look.
Related
What are good libraries for creating a python program for (visually appealing) 3D physics simulations/visualizations?
I've looked at Vpython but the simulations I have seen look ugly, I want them to be visually appealing. It also looks like an old library. For 3D programming I've seen suggestions of using Panda3D and python-ogre but I'm not sure if it is really suited for exact simulations. Also, I would prefer a library that combines well with other libraries (E.g. pygame does not combine so well with other libraries).
3D support for python is fairly weak compared to other languages, but with the way that most of them are built, the appearance of the program is far more mutable than you might think. For instance, you talked about Vpython, while many of their examples are not visually appealing, most of them are also from previous releases, the most recent release includes both extrusions, materials, and skins, which allow you to customize your appearance much moreso than before.
It is probably worth noting also, that it is simply not possible to make render-quality images in real time (cycles is a huge step in that direction, but it's still not quite there). I believe that most of your issue here is you are looking for something that technology is simply not capable of now, however if you are willing to take on the burden for making your simulation look visually appealing, Vpython (which is a gussied up version of PyOpenGL) is probably your best bet. Below is a run down of different technologies though, in case you are looking for anything more general:
Blender: The most powerful python graphics program available, however it is made for graphic design and special effects, though it has very complex physics running underneath it, Blender is not made for physics simulations. Self contained.
Panda3D: A program very often compared to Blender, however mostly useful for games. The game engine is nicer to work with than Blender's, but the render quality is far lower, as is the feature-richness. Self contained
Ogre: A library that was very popular for game development back in the day, with a lot of powerful functionality, especially for creating game environments. Event handling is also very well implemented. Can be made to integrate with other libraries, but with difficulty.
VPython: A library intended for physics simulations that removes a lot of the texture mapping and rendering power compared to the other methods, however this capability is still there, as VPython is largely built from OpenGL, which is one of the most versatile graphics libraries around. As such, VPython also is very easy to integrate with other libraries.
PyOpenGL: OpenGL for Python. OpenGL is one of the most widely use graphics libraries, and is without a doubt capable of producing some of the nicest visuals on this list (Except for Blender, which is a class of its own), however it will not be easy to do so. PyOpenGL is very bare bones, and while the functionality is there, it will be harder to implement than anything else. Plays very will with other libraries, but only if you know what you're doing.
Try PyOpenGL. It is a library that provides Python bindings to OpenGL through the Python ctypes library.
Heres a demo of this:
If I needed a visualization package for python, I would start with Processing.py:
https://github.com/jdf/processing.py
This is a python binding for the java-based Processing.org codes. A quick comparison can be found here:
http://wiki.processing.org/w/Python_Comparison
Of course, if you are not constrained to python, then Processing itself would also be a good starting point:
http://processing.org
There are also python bindings out there for Visualization Toolkit (VTK), but most of their examples are either C++ or Tk.
If all you're looking for is scene graph to move geometries around, not native vis, then I have seen some python binding for Open Scene Graph out there, eg: http://code.google.com/p/osgswig/
Good Luck!
From your question, it is not clear what you want to achieve. Do you want to create a standalone application that can be used to control the simulation at runtime, or, create a simulation using Python that can then be viewed offline?
For the latter, you could look at Blender, an open source 3D content creation suite which includes a python scripting interface giving access to most (if not all) of the internals of the application. Blender comes with some physics and particle libraries which might be of use and as an application is indicative of the type of software used to make visual effects for films etc.
If you want to make a standalone application to control the simulation at runtime, this is most likely not a suitable option. However if you want to produce a series of viewable images it might be worth a look.
I've decided to start working on a personal project, attempting to develop a cross platform, MSPaint like app. Oddly enough, I find mspaint is one of the applications I miss the most on Linux or OS X, so I want to try to make something similar. Tuxpaint, mtpaint, gpaint, etc. are all old and inactive and ugly. I don't want to make GIMP, just the basics, similar in features to MS Paint.
I'm thinking of doing it in python with the pygtk toolkit, but I was interested to hear your suggestions. Would C/C++ be a better choice, or even C# (gasp!) with mono? How about using Qt as opposed to GTK, or maybe some other fancy library I don't know about (Please, not FLTK!). I'd be curious to hear your thoughts.
Thanks!
Qt's canvas object (or its newer replacement QGraphicsView) can do pretty cool things. Whether you choose C++ or python is a matter of personal choice, as Qt is supported in both languages. For a simple project like this I'd choose python because killer performance is not much of an issue, and it will be much easier to write.
Another thing to look into is making this app web based with HTML5's canvas object and Javascript. It can be surprisingly robust, and anything that can be put on the cloud is a win in most cases.
If you decide to go with Python (which would be my choice because it's such a simple language), then TkInter is considered the de-facto standard GUI package. That link should send you to some excellent starting references for TkInter, although I also really like Not_a_Golfer's suggestion of an HTML5 web-app.
Short: You can use both, no third party library is guaranteed to be distributed with all major distributions.
Long:
Gtk+ vs. Qt
What do you want incorporate into your application. If it is just selecting a brush, selecting color you could pretty much use any gui toolkit.
If you are going to run it as a web-based tool, Gtk+ has an html5 backend renderer (I don't know about Qt)
A sidenote:
I recommend to use the toolkit's native programming language (gtk+ C, Qt C++) - if you don't, you will suffer from delays with bugfixes, generally more bugs and delayed releases, though for that case it shouldn't really matter.
Everything else boils down to personal preferences and there already exist some questions to tackling that issue.
if you are using qt,you can use QtitanRibbon
I am a linux (mostly ubuntu) user with a reasonable understanding of how the system works (although I am certainly not a linux guru!). In the past I have developed small cross-platform desktop applications in python/GTK and I delivered them to clients as self-contained filetrees, so that the only dependencies were Python itself and GTK.
Now I would like to develop a small applet for ubuntu, that I would like to release under GPL 2 or 3.
In particular these are the new steps I know I must learn in order to achieve my goal (it is very possible there are a few more that I am unaware of, though!):
Integrating with gnome: I want my application to be available as an applet in the taskbar.
Using D-bus: In particular I want my applet to use the new osd-notification framework for ubuntu, but communication with other applets is also a possible feature for a second iteration.
Packaging: I would like to setup a public PPA as soon as the application will reach alpha stage, but I also would like to use dependencies from existing packages in the official repos, rather than include the libraries again in my own package.
Of course official documentation will be my first source of knowledge, but - basing my judgment on the very useful answers that I received on another topic here on SO - I decided to turn to the SO community to collect additional advice like for example:
Are there additional steps to those I outlined before, that I have to learn in order to be able to implement my project?
Based on your own experience, would you advise me to learn those steps in advance (as the knowledge of those will influence my way of coding the core functionality) or would you consider integration with gnome / d-bus and packaging as "higher encapsulating levels" that can be added on top of core functionality afterwards (note: D-bus will be used at first just for pushing data. Input data will be retrieved with a webservice)?
Would you advise me to separate my application in two packages (back-end and front-end) or to keep it together in a single package?,
Do you know of any useful resource that you would advise me to look at, for learning any of the things that I have to?
Are you aware of any common "beginner's mistakes" that I should be aware of?
These questions are not meant to be exhaustive, though: if you feel that I am missing something from the general picture, you are more than welcomed to point me in the right direction!
PS: Should I have failed in explaining my final goal, take a look at project hamster: what I want to achieve is similar in terms of user interface (meaning: the applet should display the status and clicking on it should open the application itself, from which you could both configure the applet and perform various operations).
Well, you list python, so you'll want to have pynotify in your arsenal. It wraps DBus, and gives you a direct api for manipulating the osd-notification system.
>>> import pynotify
>>> pynotify.init("Lil' Applet")
True
>>> note = pynotify.Notification(
... pynotify.get_app_name(),
... "Lil' Applet wants you to know something's up.",
... "/usr/share/icons/Human/48x48/status/dialog-information.png")
>>> note.show()
True
This displays a notification that looks like this:
[ ] **Lil' Applet**
[ICON]
[ ] Lil' Applet wants you to know something's up.
As you already know, your first and best friend will be the code written by others - copy, paste, dissect, understand.
Luckily there are a few projects that do what you intend to achieve.
I can recommend conduit's code as a prime reference how to do things in a clean fashion. I think they also have stuff on dbus. Others to keep an eye on, would be deskbar-applet, hamster (heh), and any other app you remember having feature X. Sometimes it might require some C code deciphering though (like the applet button bit - i suggest you better take it from hamster as i was having some major time getting the thing straight)
Then the "devhelp" app will be of great assistance - it allows you to read and search in man pages fast and easy. Make sure that you also have the -doc packages for all the modules you intend to use.
For user interface i strongly suggest using glade, as that will allow you to change interface later much easier. Where you can't use glade - add and alignment box and add the widget in the box in the code.
There certainly will be quirks and things that you will learn the hard way. Should not be too hard though!
The packaging, especially the autotools will be bit of a struggle, but you will get it right. For how to do debians (and from there to PPA), you can dig in the hamster's repository history. There was once a "debian" folder.
I would suggest to start small - see if you can get a window. Then put a button on it.
You don't have to do it "right" the first time. For first time it will be ok, if something works at all.
As for the separation - i would not bother about it until you get there. Splitting up into two parts and have a core, should not be too hard later. But that all depends on your priorities.
Last thing - getting friends who know the field helps too. And one way to get new friends, is by taking part in other projects, heh.
There are some very good recommendations here already, but let me suggest that you develop your applet not so much "for Ubuntu" as "for Gnome". It doesn't take much extra effort to also make RPM packages for distributions such as Fedora, and Arch Linux packages, to name two examples. There is one major disadvantage though -- to stay compatible with Debian stable you have to stick to ancient versions of GTK and GLib, or at least make any functionality depending on newer versions optional. It's painful, but apparently Debian stable users appreciate it.
I'd also suggest setting up a source code management system somewhere as early as possible. You may not be worried about your disk crashing, but sometimes it saves you a lot of trouble just to be able to revert everything you did since the last commit.
Here's the link to the documentation on the official Gnome Panel Applet library. I don't know if it has Python bindings or not.
When I asked this question two years ago Ubuntu and Gnome were much closer to each other than they are today. At present (end of 2011) gnome adopted the gnome-shell, while Canonical decided to develop their very own UI (unity)...
Part of the tension that brought to the split specifically involved libappindicator, which makes the way I formulated this question (and probably part of the answers) obsolete.
Besides, there is now AskUbuntu on stack exchange, that would probably be a much better forum to ask about ubuntu-specific question.
How do you embed a vpython plot (animated) within your Qt GUI? so that it has its own display area and would not need to created a new window anymore.
vpython's FAQs claim that vpython's architecture make any embedding a problem...:
Q: Is there a way to embed VPython in another environment?
This is difficult because VPython has
two threads, your computational thread
and a rendering thread which about 25
times per second paints the scene
using the current attributes of the
graphics objects. However, Stef
Mientki has managed to embed VPython
in a wxPython window on Windows; see
the contributed section.
So if with wxPython it takes heroic efforts ("has managed to" doesn't sound like a trivial achievement;-) AND only works on a single platform, I fear it won't be any easier with Qt... one hard, uphill slog separately on each and every single platform.
If you're up for a SERIOUS challenge, deeply familiar with vpython, reasonably familiar with Qt, and acquainted with the underlying window-level architecture on all platforms you care about (and with a minor in wxPython), the place to start is Mientki's amazing contribution. He's actually working well below wxPython's level of abstraction, and in terms of win32gui calls, win32con constants, plus "a finite state-machine, clocked by a wx.Timer" at 100 milliseconds (though he does admit that the result from the latter Frankenstein surgery is... "not perfect";-). Extremely similar approaches should see you home (in a similarly "not perfect" way) on any other framework on Windows, including Qt.
However, nobody's yet offered any ports of this to Mac OS X, nor to any window manager of the many that are popular on Linux and Unix-like architectures (I'm not sure whether the feat could be achieved just at xlib level -- window decoration aspects do seem to be involved, and in the X11 world those DO tend to need window manager cooperation).
So, the literal answer to your question is, "with a huge amount of work requiring lots of skills and/or incredible perseverance, and probably in a platform-dependent way that will require redoing on each and every platform of interest"... sorry to be the bearer of pretty bad news, but I prefer to call them as I see them.
I contacted maintainer of VPython and he confirmed, that he is not aware of any working solution where Visual is embedded into QT window.
That turned me to try VTK and so far I'm pretty happy, no problem with using VTK within PyQT framework.
So I'm aware of the big ammount of general-purpose scripting languages like Ruby, Python, Perl, maybe even PHP, etc. that actually claim being usable for creating desktop applications too.
I think my question can be answered clearly
Are there actually companies using a special scripting language only to create their applications?
Are there any real advantages on creating a product in a language like Python only?
I'm not talking about the viability of those languages for web-development!
Should I stick with C(++) for desktop apps?
best regards,
lamas
The company I work for uses Perl and Tk with PerlApp to build executable packages to produce or major software application.
Perl beats C and C++ for simplicity of code. You can do things in one line of Perl that take 20 lines of C.
We've used WxPerl for a few smaller projects. We'd like to move fully to WxPerl, but existing code works, so the move has a low priority until Wx can give us something we need that Tk can't.
Python is popular for building GUI apps, too. You may have heard about Chandler. That's a big Python app. There are many others as well.
Ruby is also a suitable choice.
PHP is breaking into the world of command line apps. I am not sure about the power or flexibility of its GUI toolkits.
The languages you list aren't really scripting languages, as that tends to describe languages designed to work inside of a larger framework (like javascript) that provides its interface to the world. While you can certainly write scripts in those languages, each is a proper programming language (referred to as a dynamic or interpreted language, in contrast to compiled languages like C or C++).
There are many mature gui toolkits for creating desktop apps with interpreted languages. A search for any of those languages with "gui" on SO will yield many results.
The advantage of the languages you list are rapid development and concise code.
The advantage of compiled languages is mainly speed, and deeper ties with the internals of the operating system. But for most desktop apps, the ease of development in an interpreted language outweighs any small performance gains (unless you are writing a cpu intensive app, in which case, write the cpu heavy bits in C, and then call them from the interpreted language, which can handle the gui)
Many interpreted languages offer easy escapes to C or other languages (often with a nice inline syntax).
I would encourage you to take a look at some examples on http://rosettacode.org to see the fundamental differences between how programs come together with the languages you are interested in.
Python (combined with PyQt) is a very solid combination for GUI desktop applications (note that while QT is LGPL, PyQt (the Python bindings) is dual licensed: GPL or commercial).
It offers the same (GUI library-wise) as Qt on C++ but with Python's specific strenghts. I'll list some of the more obvious ones:
rapid prototyping
extremely readable (hence maintainable) code
Should I stick with C(++) for desktop apps?
In general: no, unless you want to / need to (for a specific reason).
I would recommend you not try to look for a language that is best for GUI apps but instead look for the language that you like the most and then use that to write your app.
Ruby, Python, Perl all have GUI tool kits available to them. Most of them have access to the same often used tool kits like TK, GTK, and Wx. The look and feel of a an app will be dependent more on the GUI tool kit than on the language, and performance wise your likely to see more impact for how you write your app than language choice.
If your comfortable with C++ then you should also look at C# or Java as options. While not scripting languages they have many of the same benefits like memory management and more sane string implementations.
I have used a number of programs that were developed using scripted languages. Several embedded device vendors ship my group Windows-based configuration and debugging utilities written in TCL. Google's drawing program SketchUp has a lot of Ruby inside it (and users can create add-ons using Ruby). I have seen many Linux applications written in Python. There are many more examples out there, but often times finished applications are bundled up to the point where you can't really tell what's powering it on the inside.
Yes, there can be advantages to working with scripted languages. Some scripted languages make it easier to do specific tasks; for example, text processing is much easier (IMO) in a language like Ruby that has regular expression support and a robust String class than it is in plain old C. Generating a UI using a scripted language may make it easier to support multiple platforms, as all the platform-specific code is taken care of inside the language interpreter or pre-compiled libraries. For example, our suppliers who build TCL-based apps claim they can build the UI for an app using TCL in a fraction of the time it would take them to build it in C++ or VB, and then they can port it to Linux almost effortlessly.
On the other hand there are a few things that scripted languages typically aren't suited for, such as writing drivers or doing anything that requires low-level hardware access.
Most importantly, however, is this: modern languages have become quite powerful to the point where choice of language doesn't make as big of a difference as it used to be. Use the language you are most comfortable with. The learning curve associated with learning a new language will usually have a much larger impact on your project.
http://www.pygtk.org/applications.html
Seems like a really long list of GUI applications in Python using just one of the frameworks.
Some part of MPICH2 is written in Python. I didn't check everything, but many parts of it used for running mpi applications are written it Python. Maybe MPICH2 is not used by everyone, but for sure it is good piece of software.