Just only because your issue was not answered. The following error messages are not so serious: kommanderfactory.cpp:32:23: error: database2.h: No such file or directory . . . They can be fixed easily, but you cannot compile it after, because much more serious problems are present in the source. I think, it works only on the developer's system. It cannot be compiled on debian and on suse. You had better wait to the patched distribution release or a new version of Kommander.

Nice troll. I hoped I'd never see the day... Let's inject some facts here. 1) It's Kommander, not Commander 2) With Python you have to learn a language whereas with Kommander you can point and click with a function browser... which is why there are so many Kommander scripts here that it has it's own content category. 3) With Py-Qt you are directly accessing the C++ class structure to do things and manually writing your windows scripting instead of drawing them visually and rendering them with a Qt library. I found it easier to learn C++ and use Designer without the extra layer of Python to learn. 4) The editor has had syntax highlighting for several years. The new release adds highlighting for the new parser. In fact it's been the Kate part for a few years so it has Python highlighting too. 5) The help file is included and it's 946 KB in my source directory. (That's larger than the entire initial release of Quanta Plus) However I can point you to numerous applications where people never wrote any code and had great success with Kommander. I also have a mailing list and answer every user question on it. It must be a lot easier to tell people not to use Kommander here than to ask me for help via email. As to whether you should use Py-Qt or Kommander, why choose? Python can easily be used within Kommander using #!/usr/bin/python which means full access with DCOP bindings and the ability to use PyQt also, which can further extend Kommander by accessing Qt's QObject class. You know what that is right? It means anything you can do in C++... and you're not using Python to draw your window, but C++, though you didn't write it, you drew it. You can also use PHP, Ruby, Perl, Rexx or if you're truly insane, scheme, in Kommander, which you can't do with Py-Qt. I'd like to think you don't mean to be some kind of a rude dumbass, but after staying up till 4 AM every night the last 6 weeks working on this and falling behind in my work you make a summary judgement without even reading the changelog, let alone downloading, then advise others to ignore my work? I think I'd rather buy Steve Ballmer lunch than take this from a member of the community, and I'd rather have my head shaved with a rusty knife than be in the same room with baldy. Your opinion seems rooted in fertilizer, not factual relevent and up to date observations. If there is anything people should be wary of it is taking counsel no more researched or thought out than yours.

I need e.g. 3 days for a small python-qt application, but I need a whole week if I use Kommander. I am not a beginner, and the upside-down logic of Kommander is strange for me, and remains strange forever. It is a sufferig for a practiced user to work with Kommander (It is a fact not a troll.) I know, it is simplier to create a qt/kde binding for an object-oriented language like python. One need not to fill up the gap between the C++ library and the script. (It does not apply to the scripting format of python.) Your task is not easy. Kommander is useful for a beginner, but bash and sh deserve more attention. I think, it must be a work of a team. (It is only an opinion not a troll.) I will not use Kommander for python. How can I set the widget flags, for example?

There's a sizable difference between approaching with a different mind set and recommending others not use it. If for instance you are an avid Python programmer and used to PyQt that is another matter, and hardly relevent to most users. It is the fact that you had your information incorrect and advised people not to use it that prompted the troll response. Sorry if inaccurate, but your post was not in the best form. First of all you may be surprised to know that many KDE developers feel it is easier to just use C++ and don't see the logic in Kommander. So you're not alone, you're just not in the majority. The logic with Kommander is you draw your interface and then run your logic in widgets, which is an object oriented type of thinking. Before answering your question I contend that with PyQt, KJSEmbed or any C++ bindings you have to know what is being done with the classes and architecture of Qt/KDE to effectively use the bindings. I've sat through numerous sessions of developers proudly extolling how accurately they follwed the KDE model. I haven't done much but look at some docs, so maybe you have contrary experience. To access settings in Kommander with Python you have several ways. Up front though I do admit, it's not what I plan to have in KDE4 where it will be functionaly identical. First off Python has DCOP bindings. The initial parser in Kommander was little more than a DCOP interface. However it's rather limited, but useful if you don't need to do anything fancy, just practical. Using PyQt you can access the QObject. Don't ask me how Python does it, but I know it has many of the types of Qt whereas Kommander is simply text. So in C++ it would be const QObjectList * QObject::children () const This returns a list of children. You should be able to use the interface to QObject, get that list and reference child("isChecked") for instance to see if a checkbox is checked. The research I've done for this has been related to KDE4 where I understand from my friend Sebastian Sauer who wrote Kross that it is easy to expose virtually every property and slot of an object to any DBUS enabled language. The paradox is I need people working with those languages to help insure the interface works well for them. The function browser makes coding easy if you just have a vague idea what the functions are, and my objective is to add support for other languages here. Even in the worst case, if you find all the current methods too difficult, it's quite easy to create a plugin, which will put your functions in the function browser. So for instance even in the KDE3 version one could create a map of functions including the bindings and make native Python function calls for anything Kommander does, and anything C++ does that Kommander does not. At a base level though, if you are more comfortable typing commands to draw a window than visually drawing it then you are both statistically unusual and not a good prospect for Kommander. Nothing wrong with that. The point is that Kommander does have extensive docs now, does have an excellent text editor and can be accessed internally with DCOP enabled Python and PyQt. If you were to decide to try it and were interested in helping I'd be happy to work with you on one of our lists to help to make sure Kommander is more useful to more developers. I think your evaluation was out of date, but it's also true that some people have enough difference in their approach as not to be compatible. Kommander was initally modelled after a program called Kaptain, which at first I could not see any use for. It was a paradigm shift for me. If there is a way you and I can make the "big tent" fit what you do that would be great, and if not we both have something we like. ;-)

That depends on what window you're talking about. The editor is a hacked early Qt Designer and as such is only partially right with KDE. I have set up the special window settings on the text edit dialog for the editor no problem. In the just released version you have full access to slots, so while window and widget position and size information are blocked normally in the signal/slot dialog and functions you can call the slot directly for a window to set this on a Kommander dialog.

which distro ? On suse: yast2 -i kdelibs3-devel

hi! // do this in execbutton.h #include "myprocess.h" do "make" again bye.

this->> http://kommander.no-ip.com Does not work or is slash-dotted???