I should say I'm looking for something interactive, equivalent to what Nevron offers in it's .NET Diagram product, where a user can create nodes, interact with them by dragging them around, etc. I know there's GraphViz, but as far as I know it's static, and just renders a graph/diagram, there is no interaction with it.
I have a bad feeling there is nothing as rich as this in the cross platform world for Python or any other script language, but maybe I've missed it.
Ubigraph is probably not what you want, but is still really excellent.
I have been searching for a solution to this myself for quite some time, and have just come across an Apache 2.0 licensed project based on Cairo and GTK, called Gaphas.
It has diagram widgets allowing user placement and interaction, and appears to be quite active.
There's also a python-code generated diagram library (appropriately, and perhaps confusingly) called Diagrams, which you may be able to borrow from, though doesn't appear interactive.
Writing graphviz dot files is a good way to go. Google for graphviz and see http://code.google.com/p/pydot/ for a python wrapper.
Related
I'm looking for a framework for drawing 2D scenes in Python. Not for game programming, but for 'office' like applications (e.g. drawing diagrams, mindmaps etc).
Preferable something that can be used with wxPython.
wxPython comes with OGL, but that is very old and no-one seems to use it any more (I couldn't find a reference to it in any recent project in sourceforge or google code).
The Qt (PyQt) framework has the Scenegraph thing, which I've used in some C++ projects, but I think PyQt with the Qt dependencies is too big.
Requirements are :
- managing objects
- hit-testing of objects
- ability to print the scenes
- modern look (at least anti-aliasing of lines)
I've been looking for some days now, but can't find anything that even comes close to PyQt's Scenegraph. I've been thinking about modifying OGL to use a wxGraphicsContext...
P.S. Anyone using OGL, please shout 'OGL is not dead' :-)
You might be able to use floatcanvas for this. Joran mentioned PyGame, which is certainly a legitimate option. I would also take a look at the WhyteBoard project (https://code.google.com/p/whyteboard/) which is written in wxPython and does a few of the items you mentioned. Finally, wxPython supports Cairo, which you also might find helpful. There are several demos of Cairo in the wxPython demo. By the way, wx.GraphicsContext (which you had mentioned) supports anti-aliasing, as does Cairo.
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 not sure if my question title makes sense to you or not. I am seeing many cool applications which have cool animations/effects. I would like to learn how to use python to create this kind of GUI applications under Linux.
"cool animation/effects" like 3D wall in Cooliris which is written in flash and compiz effects with opengl.
I also heard of some python GUI library like wxPython and pyQT. Since I am completely new to python GUI programming, can anyone suggest me where to start and what I should learn to achieve and create such application? maybe learn pyQT with openGL feature? pyopengl binding? I have no clue on where to start. thank you very much for your time and suggestion.
By the way, in case if someone need to know which kind of application I am going to create, well, just any kind of applications. maybe photo explorer with 3D wall, maybe IM client, maybe facebook client etc...
http://techbase.kde.org/Development/Languages/Python
Many KDE styles use SVG and plenty of animation. The user can always change themes. I think you should be more specific about what kind of animations you want to do. I don't think 3D wall type affects really fall into the widget category that QT is. It sounds to me like you want to make a 3D interface for an application. If that is the case, you may want to look more into 3D engine type libraries used mainly in games. I know that some have excellent GUI widgets for programming game menus and the like. I guess you'd decide on your engine and the see if there are python language bindings. One of my favorite engines: http://irrlicht.sourceforge.net/links.html
Another thing you would want to consider is how you want to handle the window management. Do you want to make a full screen interface? Or is to to be windowed? Also how would such an application integrate into a 3D window manager or rather a window manager with compositing.
Edit:
In that case the qtopengl module is probably something to look into: http://doc.qt.nokia.com/4.6/qtopengl.html
I do recommend QT. It's clean and easy to use and cross platform. So your app could run on windows as well.
One thing you'd want to think about before hand is the type of FX you want to perform. For example, if you want to create a page curl type effect when renaming the image, you'd have to think about how to program that, or look for libraries/code snipets that do that math. 3D engines that are used in games often have a lot of support for those kind of typical FX or animations that you'd see in a game. If you use something like qtopengl, you'd need to think about this as well. qtopengl can pretty much only render. Think of it as a viewport. However, it is the correct approach to making a 3D application for the desktop.
Programming 3D applications is really interesting and fun. I enjoyed it a lot. However, don't get discouraged be the math. I recommend getting a book about it if you are serious. I liked this one: http://www.amazon.com/Primer-Graphics-Development-Wordware-Library/dp/1556229119
However, IIRC the examples are C++ which you may not be comfortable with. When you understand such mathematical concepts, it easier to think about how you would make a page curl type affect. Of course, if you find libraries or code that shows you how to do the math, that may be fine.
May be, just create a GUI and all effects will make compiz?
Anyway, as I know QT have ability to use openGL.
http://doc.qt.nokia.com/4.1/examples.html#opengl-examples
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.
I'm currently working on a simple wxPython app that's essentially document based. So far I've been manually implementing the usual open/save/undo/redo etc etc stuff.
It occurred to me that wxPython must have something to help me out and after a bit of searching revealed the docview package.
At this point though I'm just not quite sure how to hook everything up and get things started. Anyone got any good links or hints about places to start?
The docs seems to be a little thin about this and Robin Dunn's wxPython book doesn't really cover this package at all.
You might take a look at the docviewdemo.py from the wxPython Docs and Demos:
on my machine they are located:
C:\Program Files\wxPython2.8 Docs and Demos\samples\pydocview\
C:\Program Files\wxPython2.8 Docs and Demos\samples\docview\
In addition to the ones mentioned, there is quite an extensive example docview/pydocview in the samples\ide. If you want it to run you will have to make a few code corrections (I have submitted a ticket that outlines the fixes at trac.wxwidgets.org #11237). It is pretty complex but I found it handy to figure out how to do some more complex things. For example, samples\ide\activegrid\tools\ProjectEditor.py is built from scratch and has undo support etc rather than just relying on a control that does everything for you already. That way you can see how things are supposed to be done at the detailed level. The documentation is rather useless in that regard.
If you have decided against using docview/pydocview I have a spreadsheet application built on wxPython that you may find useful as an example. While it does not implement a document view framework it does have some characteristics of it and I've implemented an undo/redo system. Check it out at http://www.missioncognition.net/pysheet/ I'm currently working on a pydocview based app so I expect that to be up on my site eventually.