|  | | Re: how to use
Apr 24 2008 on content Kommander Interactive Help dialog |
There's -no- install! Cheeze n crackers man, fire it up. It's a help dialog and at the risk of being overly rational I have it load up help on how to use it when you open it.
It's pretty simple. There's a file for topics and one for content and they are both holding Kommander arrays. You never need to touch the dialog. In fact... As I recall I set it up to auto generate those files if it didn't find any files already made. So if you forget how to use it, move your help files away and it creates it's own help again.
I'm sure it's going to surprise people, because you don't expect a recursive help dialog to offer help on how to use the dialog in the help... Call me crazy, I just had to do it. ;) |
| | | Re: For what this tol?
Apr 6 2008 on content Portage Info |
Did you look at Kommander? The tool you mention could easily be incorporated or have it's own front end. That's the great thing about Kommander. You can look at any Kommander script and see how to build the one you want. |
| | | Re: wrong link
Apr 1 2008 on content Date Time Functions |
I don't think it was the wrong link, but I know the server was down for a bit. I checked on the newest version and downloaed it just to be sure. If it's not working now something would have to be really weird. |
| | | Avoid KDialog
Mar 21 2008 on content Kalasnikof |
Hi,
looks popular. If you want to run a bash shebang then you can use the old parser @functions. In your zombie code try replacing:
kdialog --msgbox "No zombies found!"
with
@Message.info("no zombies found")
Notice how much faster the dialog comes up? bash in general is pretty slow and KDialog going back and forth to the shell is unfortunately glacial in Kommander which already has an internal KDialog process loaded as part of the executing window. ;) |
| | | Re: Re: Re: essential problems
Feb 27 2008 on content Kommander |
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. ;-) |
| | | Re: essential problems
Feb 25 2008 on content 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. |
| | | Re: window positioning
Feb 25 2008 on content Kommander |
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. |
| | | Re: Unable to run
Feb 23 2008 on content Set exec bit |
This is not going to crash like this just from executing a dialog, though it's possible some features introduced in the new version are not handled as well by older versions.
The key point is, are you running the version of Kommander that shipped with KDE 3.5.9? If not then why are you running this dialog, which is for setting the executable bit which is only tested for in the just released version?
If you are getting a crash of this dialog like that, then likely it would happen on every dialog, in which case it would probably be an install problem, but I'm thinking it's that you're not running the just released version of Kommander (1.3) from KDE 3.5.9. As this does not contain usable information, which a proper bug report would, I can only speculate. |
| |
Search people
Current visitors
New users
Birthdays
Most active users
Back
|
|
| |
|
