What is interesting is that they can require virtually no scripting languages to produce a result, or you can use the scripting language of your choice. Internally everything is done with DCOP. What is even more interesting is that soon Kommander will not be limited to dialogs, it is easy and fast to build programs with and the internal DCOP executes extremely fast. Kommander could become one of the most exciting things to happen on the desktop ever when combined with existing KDE technologies. Currently most Kommander development is done by Michal Rudolf who is sponsored part time by the Quanta/kdewebdev sponsors.
Let's look first at how Kommander can impact newbies. As a newbie you could grab a Kommander program, for example my "Simple Installer", and install it with great ease. This is because it doesn't have to be compiled first, but it also doesn't have binary compatibility issues with libraries because it's not binary. Kommander usones functionality compiled in using DCOP. The executor is more of a pre processor than an interpreter. So internally everything happens just about as fast as a compiled program. As we add the capability for main windows, toolbars and menus to our projects it will continue to be very easy to grab a program, install it and run it. The only thing you need is KDE and the Kommander executor installed. This bypasses binary RPM issues as well as problems for people not prepared to compile from source.
For users Kommander adds something interesting. You can edit Kommander applications in the form they are run in since they are not compiled. Using the Kommander Editor you can make changes to an application you have downloaded or create new ones. You can also use the DCOP capabilities to extend your existing KDE applications and communicate with them. This makes it possible to merge your KDE desktop into your own personal super application with custom dialogs and DCOP. If you're unfamiliar with DCOP try running kdcop.
Power users who are knowledgable about how programs work, but perhaps lack the time or skills to program in C++ now have a new option. Sure you can find the script language application you want with bindings, but that has limitations.
A power user can use Kommander's built in functions or easily shell out to the language of their choice. The language can interact with the application through calls to Kommander's special instructions which are parsed before sending it to the script interpreter, and by DCOP calls. However with Kommander's specials it is unlikely that you will need to use scripting for 80%-90% or more of what you have to do in even more complex tasks, unless you want to. This means that Kommander opens the door to application development to an admin level user! The potential for the growth of applications with Kommander is unprecedented because this opportunity has never been opened so widely, and Kommander is a very easy and productive environment. Also the widgets are very easy to add from KDE widgets as plugins so even a beginning C++ coder can add a widget.
So what does Kommander do for developers? Put them out of work? Hardly! Larger applications will probably always be compiled, but Kommander offers them some interesting things they never had... With Kommander developers can take a feature that is difficult to define and offer a user extensible component. An important fix or addition can be offered outside of a release schedule that users can download and run without having to compile. Developers can also prototype on Kommander, and even distribute features in development to testers who can submit working GUI alterations for refinement of the development cycle. In fact, since Kommander uses XML files developers could even create dialogs on the fly when the application runs.
What does Kommander offer a company looking at Linux on the desktop? It's been estimated that over 80% of software is custom made and not shrink wrapped. For a company looking at desktop applications the odds are excellent they will need to have some custom applications done for their business services. Commercial applications rarely fill the bill for companies. The odds are good they already have custom applications developed in various languages with various tools. They probably also have in house programmers familiar with Basic, Pascal, Perl, bash, Python, Java, Javascript, even Rexx. What's great about Kommander is that any language that can be run in a shell can be used. This means some code can be reclaimed and developers can be more productive. It is also probably the fastest easiest platform they have ever worked with. Most significantly it removes all traditional limits and obsolescence as applications are modular and they can transition languages as well as augment features with any language skill set.
Clearly Kommander has some amazing potential, but it's not ready to realize all of it just yet. We hope soon. Michal Rudolf has been sponsored part time for Quanta and Kommander and is largely focusing on Kommander right now. The possibility of sponsoring him full time as well as getting more volunteer developers would make this task a lot easier because there is a lot of work. Maybe you would like to get involved helping us to sponsor or develop Kommander. Now let's look more briefly at how Kommander works.
As you may have guessed Kommander is not your usual tool. Typical application design starts with a concept, translates it into a language and this is translated into the application. If you've ever had difficulty expressing yourself you've experienced the problem with language. It adds complexity to concepts. As the saying goes, a picture is worth 1000 words. Development using Kommander takes a more conceptual and visual path, intentionally minimizing the constraints of language. Kommander supports object oriented design by it's nature as all data is bound to objects. Kommander stores information in widgets (GUI elements). So if you have a LineEdit you want to call "mystuff" you would reference it internally with @mystuff. When you ask for @mystuff, whatever has been entered into the mystuff widget will be returned. In this way you can create strings. For example, if @mystuff = "Hello" and @morestuff = "World" you could have a button with the value "@mystuff @morestuff!" Which would return "Hello World!". You really have to play with it to for it to suddenly dawn on you how simple it is. Reading about a conceptual visual tool is much like trying to get a picture through a radio. Kommander does not have a scripting language in the traditional sense. It uses custom functions called "specials" that begin with an "@" like @dcop() and it uses DCOP to control it's widgets. Our focus has been to keep Kommander specials easy to work with by using consistent naming (some will be renamed shortly for consistency) and groups where ever possible. Eventually we will have a function wizard for them too. As an example of groups, in CVS we have a new @String special. You can access it's functions like so @String.length("@LineEdit1"). This would return the length of the contents of LineEdit1.
So the question is what can Kommander do and what still needs to be done? Currently we're releasing a new Alpha every weekend. It is an Alpha because it introduces new features, but it's usually stable enough for production work. Kommander is fairly simple internally so stability is not generally an issue. Here is a list of some of Kommander's current features.
Kommander has a number of things in work right now including KPart creation, a KPart loader, project tools, enhanced plugin widget capability, KStuff repository and more. As soon as plugins are brought to full capability we will be adding database widgets too. Hopefully very soon you will be able to load a Kommander program and if it does not have a widget it will tell you and ask you if you would like to search the global repository and get it.
To bring Kommander to where we want to will take a lot of work, but we hope we are on track for KDE 3.3. It will need i18n functionality, new widgets and the editor needs to be improved or rebuilt. There is a much longer list of things to do than what is done and we really need help doing it. I hope you'll consider helping by testing, feeding back to our list and donating or developing with us.
Comments:
Addendum - Eric Laffoon - 2004-06-17
We're working on getting docs in order but Kommander is also progressing quickly so it's hard to keep up. A preview of the docs can be seen at http://kommander.kdewebdev.org/docs/ but it is not currently up to date with Alpha 4. On the next update it is planned to cover features for Alpha 5, but this could be prior to it's release.
Docs are fairly important for Kommander to become familiar with key concepts. There are a number of examples and tutorials in the release to help you see how these features are used. They're generally pretty simple once you see them work.
Enjoy!
Re: Addendum - dwt - 2004-06-17
Looks promising. Just a while back I wrote a small frontend to a couple of
scripts that I wrote. I guess I went through too much trouble. Next time I'll use kommander.
(If I figure out how to use it ;-))
Any example of connecting console app with gui? - John Underground Porgramming Languages Freak - 2004-06-17
Hello,
I do mainly scientific (manly theoretical, not very tech) work, UIs are only useful to me in the sense that they might make the process of testing my apps less tedious. I want to waste a less time as possible with them.
Admittedly I only took a quick look at the documentation, but I didn't see any example of how to connect a simple console application with the GUI. How should they communicate? Send strings via pipes? Using sockets? But One would need 2 parsers right (one in the console app and one in the GUI)?
Simple examples, common approaches and general tips, maybe using easy to understand languages like C or Pascal, would be very nice. Not only would it save much time to many potential users, but also reduce the risk of them comming up with bad solutions on their own.
Re: Any example of connecting console app with gui? - mukuka - 2004-06-17
if you look at the examples in the source, it is very clear how you can use dcop or just plain output redirection to set variables in widgets etc. This app has a lot of promise. It is also done very unix-like. Think Bash with scripting a gui.
Dcop is really the star of the show at the end of the day. Good work kommander team.
I am tempted to ask where those ?nomes are hiding...
Re: Any example of connecting console app with gui? - GeekBoy - 2004-06-18
My only problem with dcop is that there seems to be a lack of standard conventions for dcop apps. For example, the media players have different dcop functions for the basic play functions, next, previous, play, pause, volume up or down, etc. I think what we need are some standards for dcop. Each application should have things like, bool isTopLevel(), or the dcop server should have a function itself to return the dcop identifier of the current top level window, or active application. Maybe we should have classes of applications too like mediaplayer, browser (file or web), so that from an application we can find out what is the top level window, and what type of application it is, so that controlling an application from a script or multimedia key (using something like lineak, or hotkeys) is very straight forward and coders/scripters don't have to program for each different application.
Re: Any example of connecting console app with gui? - Eric Laffoon - 2004-06-18
> My only problem with dcop is that there seems to be a lack of standard conventions for dcop apps.
Yes and no. Some are created by default. After that you're right, it lacks a degree of convention. In fact Kommander will probably be the first time a lot of users really get into DCOP because it's primarily a tool for developers, even though it's so plainly exposed. Two things will assist us. First there is kdcop, which allows you to look at and play with DCOP until you find what you want. This is actually where you see what is standardized.
Our second benefit is a planned innovation... user DCOP registration. The purpose here will be to enhance DCOP browsing and usage by enabling a registration database for applications to use. For instance in Quanta our primary user support is WindowManagerIf and in Kommander it's KommanderIf. There is other useful DCOP in there but this is where we put out added funtions that aren't generated. The idea is that this registration could have additional information as well as remapping. For instance Quanta has several DCOP interfaces inherited for editors which you might go between to interact with the editor component. They could be mapped merged or common actions could be grouped or merged. If what you need is not there you can go to kdcop, but the idea is to make DCOP less confusing for users.
Our hope is with this idea in place developers will become more concerned with DCOP organization and presentation. However as for the rest of your comment... this can be addressed in two ways. First, kdcop. Second, DCOP functionality has to be specifically addressed in the application. You can walk though a window's widgets with a script much like you can in Javascript with a web page. However we are adding a DCOP function for this to return an answer to "What kind of widget are you?" I don't remember if it is in there or still on the do list.
I'm afraid in the end you will have to script for each application in your example, however with Kommander's new string functions we get a step closer to being able to do a translation layer. That is, call a script with a call to do something which is then translated for the correct application. This can be done now with scripting, but bash is quite a bit slower and of course other languages can create a dependency.
Re: Any example of connecting console app with gui? - Eric Laffoon - 2004-06-17
> I didn't see any example of how to connect a simple console application with the GUI. How should they communicate?
There are examples, but you really need to look at it to see how blindingly simple it is.
1) buttons can output strings to stdout and you can assemble the string with the ui
2) calls to exec interface the console (in fact if you type bash they are currently assumed but that may change with parser advances)
3) you can use any scripting language from directly within Kommander, which of course means if you want to use pipes or sockets that's possible
> But One would need 2 parsers right (one in the console app and one in the GUI)?
Kommander's executor has a parser that is evolving, but this is not required. Typically the console app just sees Kommander as the console.
> Simple examples, common approaches and general tips, maybe using easy to understand languages like C or Pascal, would be very nice. Not only would it save much time to many potential users, but also reduce the risk of them comming up with bad solutions on their own.
There are examples and tutorials in the source and we're working on the docs. It's unlikely we will be using language examples as they are not necessary and we don't want to show language bias. In particular you listed compiled languages but Kommander is XML so those would need tobe externally called. It appears you're looking at Kommander as if it were language bindings and it's anything but. Kommander strives to be more visual than language oriented.
If you look at it more carefully you will see the obvious conclusions.
1) The way Kommander encapsulates language means you only really need to show people where it goes. (This promotes small encapsulated code bound to objects)
2) The need for using languages (beyond the specials and DCOP controls) will decrease with development making it more a user choice than anything.
3) Any heavy use of scripting languages will produce a slower result than using the built in functions. I explained this in the article.
I believe the problem with your approach here is that you don't yet understand how Kommander works and are trying to make it a lot more complex than it really is. In your case think of it as a quick to make adjunct to your console. If you want a very fast hookup and your languages you are using are DCOP enabled it will be very easy to integrate.
For console use Kommander can...
1) enhance console - call it from console to have a collection of commands for stdout
2) replace console - use it to make the calls and retrieve the results
3) tie a collection of scripts or executables together
4) hold various scripts with various dialogs as a complete program
5) probably some things I never thought of ;-)
KommanderKard -- A Eerie Similarity? - Bob Tilley - 2004-06-17
Many users of the Macintosh platform remember the HyperCard environment, created by Bill Atkinson.
HyperCard is an application program and a simple programming environment produced by Apple Computer which runs only in Mac OS versions 9 or earlier. It most closely resembles a database application in concept, in that it stores information, but unlike traditional database systems HyperCard is graphical, very flexible and trivially easy to modify. In addition HyperCard includes HyperTalk, a powerful and easy to use programming language to manipulate data and the user interface. HyperCard users often used it as a programming system as opposed to a database. HyperCard gave the Macintosh platform a development platform which was easy to learn and utilize in the production of independent programs, or HyperCard "Stacks".
The connection between HyperCard and KDE/Kommander is easy development. Kommander gives developers a tool which will be almost as effortless as HyperCard, for the creation of specialized tools.
An array of pre-built utilities should be included with the base Kommander install. KDE has the potential of becoming a desktop which, through SuperKaramba/Kommander-type tools, could be individually customized.
Picture an office with thirty different desktops, all based on KDE but with additions and customizations so that the job of each user is minimized.
* Travel agents could use KDE with custom applications to connect to airline
databases and arrange new bookings.
* Health studios could use the base KDE install to manage customer with
an application scripted in DCOP.
KDE Dot News is not the format or place for imaginative writing, given it's blog-style discussions. I hope I've planted a few seeds.
Re: KommanderKard -- A Eerie Similarity? - Eric Laffoon - 2004-06-17
It may appear similar at a glance. Whatever similarity you are seeing I ran OS/2 and am unfamiliar with this app. My limited experience with the Mac was at Kinkos where I couldn't believe it had a single tasking interface when I scanned an image and had to call for help before I would drag the floppy to the trash to eject it. So my impression was that it was overhyped and OS X was a good move for them.
Your ideas begin to see the potential of Kommander but I would point out some differences...
1) Kommander is not data-centric, it is UI-centric which means that it is less constrained than a data-centric application.
2) Kommander actually binds data and actions to interface objects... This is quintessential object oriented thinking and varies from most data-centric apps.
3) Kommander does not really have a language. It has a collection of functions but it stays away from the constraints of language... It doesn't really have a syntax, it's not interpreted in the traditional sense (more pre processed) and it's not compiled. At this time it lacks a complete parser, and any language *must* have a parser more extensive than Kommander is planned to have. The *last* thing I wanted to introduce is another language! Language neutrality is central to removing the divisiveness of this type of tool, which is why you don't even have to use any of our functions but can go directly to the language of your choice if you prefer. Our functions though are designed to be easier and faster and integrate with your scripting, if you choose to script.
Keep in mind a key advantage for Apple. They are able to avoid many problems with binary distribution of programs because they control the platform. The PC is different and Linux is anything but totally consistent from PC to PC. Kommander achieves small package sizes, quick installs and side steps binary compatibility issues.
Another very important thing related to data... Apple's program was limited to one database. With Kommander you will be able to interface with complete database front ends like Kexi or Knoda, or use their widgets, or use Qt widgets, or roll your own widgets, or use PHP or perl, or interface with the command line. In addition to this you can already save and restore widget contents and associative arrays as well as read, write and append files and process strings. Kommander is vastly more flexible than a dedicated program and will achieve varying degrees of ease at data manipulation based largely on the accomplishments of other tools.
I would also invite you to see if it is not easier to learn and use in a month or two as I would be curious about this.
So you're very right about the potential. On the surface or for specific uses it may appear similar to apps like you mentioned, but that is only because it can. The other way around it quite a bit more challenging. ;-) While you are right about the potential uses, your analogy of similarity is like the story of the blind men and the elephant each describing a part of it. In fact Kommander really is "something completely different", but can appear to be like a rope, a tree, a snake... It will get more interesting as more widgets are enabled for Kommander when our new plugin system goes on line.
Dependencies? - Jeroen - 2004-06-17
What software is needed on the client side? You say no compilation is necessary, but the client still needs the executor, right? If that's true, the Kommander idea only comes to its full right if the executor would be standard on every KDE desktop.
That said, adding a GUI to script (whatever kind) is extremely cool. Of course we have kdialog (and /me also coded a simple xmessage clone on a sunday afternoon), useful but not very powerful.
http://kile.sourceforge.net
http://www.science.uva.nl/~wijnhout/kmessage/index.html
Re: Dependencies? - Eric Laffoon - 2004-06-17
You only need the executor, as well as any special plugins or custom programs accessed, if there are any. I agree with you. I would like to see the executor in kdelibs, but it was not compelling enough before. Maybe soon it will be. It is in kdewebdev right now which is part of the official packages. It's there because we develop it and rely on it heavily.
kdialog is fine for single purpose stuff and using just with konsole. However I have used it for some quick and dirty messageboxes and I note that it takes at least as long to come up as a heavily populated Kommander dialog. Because of this we are considering duplicating this functionality within Kommander so dialogs come up quicker. It's the reliance on the shell that is slow.
We will continue to make the executor available stand alone, but if you install kdewebdev you have all of Kommander. Feel free to make noise about putting the executor in kdelibs. ;-)
WOW - Alex - 2004-06-17
This really is a cool tool, I never knew it could do so much soeasily! Thanks!
Re: WOW - Eric Laffoon - 2004-06-17
It was never really that difficult and should get easier, but doing so much is really recent. The version shipping with KDE 3.2x doesn't do near so much, but it was still usefull.
using awk - carlos oliveira - 2004-06-17
Is there any chance that this can be used
together with awk? I like to use awk as
a scripting language, but there is not
graphic interface for it. I would love
if I could use if with Komander.
Re: using awk - Eric Laffoon - 2004-06-17
Kommander will work with any program you care to run and works great with awk and sed. The issue from the point of use is whether others have these installed.
How about security - AC - 2004-06-17
First of all, thanks a lot for the great apps you and the kdewebdev-team produce. I really like your passion for the things you do and your vision about how to improve user/developer experience.
I have one question though; how about security?
It seems that kommander with dcop is very powerful, how about the following scenario; an kommanderfile is executed, opens kmail and create and sends the kommanderfile to everybody in your addresslist and wipes the homedirectory with konqueror. Just like Windows KDE have users as well that open everything from somebody they know.
I hope you know what I mean by this example. Short question is thus how are users protected for KDE-virusses?
Thanks.
Re: How about security - koos - 2004-06-17
IIRC, this same issue was discussed on news of kdebinding.
Are you sure kmail also mails the execution bit when sending a script? (otherwise opening it would launch kwrite, no?)
Why do you thing that loosing your home dir is comparable with a virus infection on a MS system? (there is no way a normal user can changes system files, other than known exploids of course)
Re: How about security - AC - 2004-06-18
I don't think that the execution bit is required because kommander is the executor not the file itself. The kommanderfile is associated with the executor.
I agree with you that the consequences are not as dramatic as in Windows, in the sence of damage to the system, however losing everything in your homedirectory can be very dramatic.
My point is, without going to much in the specific example I gave, does this have any effect on the security of your system?
Re: How about security - koos - 2004-06-18
> The kommanderfile is associated with the executor.
Ah, in that case you're right and it would make sense Kommander files requiring #!/../kommander as first line then. Or Kommander could check the x bit nonetheless and refuse execution then.
Re: How about security - Eric Laffoon - 2004-06-18
The file could also be associated with the editor as well, depending on the user. The point is that KMail does not execute it on retrieval. It does the same thing as any other file, offering to view it, but it's only going to offer this if it has the .kmdr extention.
The potential for a damaging payload is the same as as any script, but the potential for replication is not there. Anyone sending this as a malicious exploit would be limited to a very tightly targeted audience. The only place this could increase risk over existing conditions is if someone was not aware they were executing a program instead of just looking at data.
I just did some tests and it appears that Kmail does some extra security measures which in effect are circumvented by the Kommander model. I don't believe it's inherently insecure as it still requires a user interaction and will not replicate. We have arrived at a solution for additional security...
We will contact the kmail people about Kommander so they can be aware, but we have noted that mail and web attachments are run from /tmp. As of 1.0 Alpha 5 if you try to run a dialog from /tmp it will be interrupted and give you a security warning that it could possibly do destructive things and ask if you want to continue. This should provide additional protection against accidentally launching dialogs that are not tested.
Re: How about security - foo - 2004-06-18
Actually, I really care more about my home directory getting thrashed than the system.
Re: How about security - Eric Laffoon - 2004-06-18
That's logical. Try Kdar for backups. However it is bash that can trash your home directory. As I pointed out, there is nothing inherent to Kommander that can do this that is not already there and with time and resources we could even require user authorization for potentially destructive operations... but then that would make us a rare program to operate at that level of paranoia.
Re: How about security - Joe...some dude - 2005-08-27
Perhaps you could give the 'Executor' a security level setting in the configuration. "Paranoid," and "Normal," and "Careless," might be examples. You could choose to ship the executor with the 'appropriate' security level setting... of course, that would mean building in all of those measures throughout the codebase. Oh joy.
- Joe
Re: How about security - ahmed - 2006-05-12
the question is.. do you trust the sender (and trust the message contents?)
How about security - AC - 2004-06-17
First of all, thanks a lot for the great apps you and the kdewebdev-team produce. I really like your passion for the things you do and your vision about how to improve user/developer experience.
I have one question though; how about security?
It seems that kommander with dcop is very powerful, how about the following scenario; an kommanderfile is executed, opens kmail and create and sends the kommanderfile to everybody in your addresslist and wipes the homedirectory with konqueror. Just like Windows KDE have users as well that open everything from somebody they know.
I hope you know what I mean by this example. Short question is thus how are users protected for KDE-virusses?
Thanks.
Re: How about security - Eric Laffoon - 2004-06-18
First of all, thank you. Second, security? What's that? :-O
Just kidding. I suppose this is a fair enough question. Now for a fair answer...
DCOP is available through the command line, so Kommander is not bringing anything to the table here except a fancy wrapper. So the question is, could this happen with bash and would a GUI somethow make it worse?
The short answer is I don't see how your scenario could be played out. Due to the nature of things it's doubtful this could be done and even more doubtful it could be a threat. Security starts with good architecture but always finishes with good user decisions. An unwise user can compromise the best security. In Kmail you must choose whether to execute or view an attached file and it still arrives without the execute bit set. I mean realistically you can send people a script containing "rm -Rf ~/*" but you still have to explain to them how to run it and they still have to choose to. (Don't try this at home kids unless you want to say goodbye to your home directory.)
Let's look at your scenario... I just strolled through KMail in kdcop with my black hat on and it looks like it is easy to create a message. It would take some creativity if it is possible and if it were possible the same could be done with a bash script. I suspect you would need to also physically open windows todo this and I think you would notice this. I don't see an easy way to create even the least viable exploit. Anyway this question is better asked of the Kmail guys and my understanding is that they have been addressing security. While Kommander brings new capabilities to that table for applications it is not brining any risks that are not already there WRT using DCOP with other applications or using scripting in the shell. It looks to me like it would be easier to grep suspcious directories for email addresses and look for sendmail, none of which requires anything from KDE.
I would add something else. Because Kommander files are XML you can view them in an editor and even filter them or test for exploits if you are so inclined. You can also use the Kommander editor and look at what executes...
- main dialog initialization and destroy scripts
- button scripts
- slots from signal and slots relationships, except Population Text which can only produce text for it's widget
Future versions will have an easy way to review all actions. It is also possible for the executor to trap suspicious commands. So it would be possible to add additional security measures, like a shell that doesn't allow destructive commands for testing new programs. We could even do a sandbox mode to just print out commands without executing them... if we had time and/or help. ;-)
Re: How about security - Andras Mantia - 2004-06-19
Your scenario is not that different from all the other cases that might happen on a system. What if you
execute a shell-script which has dcop commands that causes KMail to send the script itself? Kommander is
just as safe as any other application on your system. If you deliberately execute a malitious application it is
your problem. ;-) The fact that "don't execute files from untrusted source" is valid also in case of Linux,
not just Windows. I can send you an script called "ls" which does ls and "find . | xargs rm -f". I can do the
same in Kommander, or C++ or whatever. The problem would happen if KMail would automatically execute the
script when you receive the mail, but thankfully it does not.
Looks like an extended version of InterfaceBuilder - Marc J. Driftmeyer - 2004-06-18
Looks like a more abstract version of InterfaceBuilder.app from OS X (really first seen in NeXTSTEP). Instead of having to actually write your ObjC classes you can plug-in the interpreted language of your choice, right?
Re: Looks like an extended version of InterfaceBuilder - Eric Laffoon - 2004-06-18
That's fundementally correct. I'm not familiar with that tool. Kommander also goes futher with native functions called "specials" which enable you to process strings, arrays, files and such. So you don't really need to use a language in some cases. Soon we hope to have a complete parser which will enable structural logic specials. However we're not planning any mathematical function groups at this time as they are more parser intense. So for something like that you could use the language of your choice.
Additionally Kommander will allow you to use different script lanaguages in the same dialog, which I don't know if the tool you referenced will. "More abstract"? I like that. ;-)
dependencies? - probono - 2004-06-18
Kommander will be a real killer application for KDE. For the first time, it allows to do the equivalent of shell scripting and pipes in a graphical environment. This takes the Unix philosophy to a completely new level. Congratulations!
Will there be a standalone binary Kommander version that runs on KDE 3.1.x systems? There are many out there (Fedora 1, many of the commercial distros, etc.) and it would be nice to have a binary that could easily be used on these sytems as well.
For kommander it is crucial to make it run just about everywhere.
Re: dependencies? - Eric Laffoon - 2004-06-18
Thanks for your kind words. There is currently a release of the executor that can be compiled for standalone use. There is also a release of a packaging system that allows you to create a binary by packaging the executor and files. These are all in the link at the top of the article. Our plan is to have an online resource repository using KStuff. This would mean that people could build binaries of Kommander on various platforms which could be uploaded and made available to those who, for whatever reason, can't compile it.
As far as dependencies go, at this time I don't see why it would not run on KDE 3.1. (BTW the largest user base of commercial distros supports 3.2) Our current philosophy is to use what works so if we need something in 3.2 that could become a requirement, but it doesn't look like we need anything from 3.2 yet. Also Kommander can use plugins, so if a widget is not widely available it would not be be required by Kommander as a whole, only an application plugging it in.
I don't see a need to make Kommander require KDE 3.2 for some time, but Kommander applications could make use of KDE 3.2 features and require it.
Kdevelop integration? - CML - 2004-06-19
Hi, great application! Are there any plans for integration with Kdevelop? Kdevelop + Kommander + CVS instead of M$ Visual Studio + M$ Visual Sourcesafe.
A dream come true?
Re: Kdevelop integration? - Eric Laffoon - 2004-06-19
Dot stories usually don't get comments this far down. ;-)
There are no plans for use with Kdevelop, though initially it seems not it's target it might be interesting so it's worth pondering. We do want to keep it fundamentally simple, but we want to extend it's abilities too.
Now, as to addressing more of your question. There are plans for a new editor component and integration with CVS would be quite easy. There's a lot of work to do, but it will be a great tool.
Using Python or other scripting languages - Joachim Werner - 2004-06-19
Kommander has a really interesting concept. But you really need to work on the documentation ;-)
I've looked at some of the examples, and there's one thing I didn't find anywhere: You say that one can use any scripting language. But all examples use bash. Let's say I want to build a simple dialog with a line edit field and a button. I enter a URL into the line edit field and press the button. Then the URL should open in your default browser.
In Python I'd say
import webbrowser
webbrowser.open('url')
Where would I put that code to make the little example script work?
I get it to work if I write
python -c "
import webbrowser
webbrowser.open('@urlField')"
(@urlField is what the line edit passes to the button). But that's still bash calling Python, not scripting in Python ;-)
Re: Using Python or other scripting languages - Eric Laffoon - 2004-06-19
Actually this is in the docs... Do this:
@execBegin(python)
import webbrowser
webbrowser.open('@urlField')
@execEnd
Alternately you could use...
@execBegin
#!/usr/bin/python
import webbrowser
webbrowser.open('@urlField')
@execEnd
If for some reason you still feel it's not right let me know. ;-)
Re: Using Python or other scripting languages - Joachim Werner - 2004-06-19
> If for some reason you still feel it's not right let me know. ;-)
Thanks! I finally found it in the documentation, too. But an example like the one above would really help a lot.
One additional comment:
I've seen that you have already implemented an almost complete set of string functions. Be aware that this is the beginning of yet another scripting language. All this could be done using Python or Perl as well, so replicating it as part of the Kommander "language" is not really necessary. I remember the early days of Zope, the Python-based web application server framework. They also didn't want to reinvent Python. They just needed a simple set of tags to be used for inline code in HTML. The resulting DTML (Dynamic Template Markup Language) was extended again and again and became a full-blown scripting language. This wasn't the plan. It just happened over time. So even if you don't intend it, if you take the first step, you might still end up inventing a new language ...
Re: Using Python or other scripting languages - Michal Rudolf - 2004-06-19
All this could be done using Python - but what if you want to use Bash instead? Our goal is to make it easy for non-advanced programmers. Advanced programmers could use language of their choice (Python, Perl, PHP...).
So, I don't see any harm done by those functions. But if you prefer to use Python for that, you are free to do it.
Re: Using Python or other scripting languages - Eric Laffoon - 2004-06-20
I don't want to invent a language, unless you consider offering some basic functions and some structural logic a language. I want to offer a limited conceptual group of functions that enable someone to work without having to go to the constraints of language if they choose not to, and I have good reasons for doing it.
1) This does not preclude the use of any scripting languages for these purposes. That's an important point. Don't want it? don't use it. Prefer to create new functionality with Python, Perl or Ruby? Go for it. Net effect on you? If it was in Perl and you wanted to edit it in Python there is no difference. If it uses Kommander functions it will offer tools to make editing this fundamentally not limiting.
2) How do we know that scripting language will be on a user's system? If you want to specify a dependency on Python or Ruby go ahead. If you want to insure it's run everywhere you have bash, probably perl and maybe Python. Bash is both painful for novice users and slow to execute.
3) Execution speed of internal compiled functions is really fast. Let's not forget that. It could be noticably faster than many scripting languages in some cases. There will be a number of things you will need a scripting language for, but why make those more numerous than need be?
4) All Kommander functions will be supported with wizard like dialogs, similar to what you have in Kspread to help users make use of these functions. This would be quite hard to support for every language, though it can be done with Kommander add ons. We also do not want to operate from a language bias. Currently we have been promoting bash. I don't like that.
My vision for the functionality added to Kommander is that it will be similar to a spreadsheet in offering functions to perform an information, it will just offer different functionality. I have no interest in doing numerical functions but I do want the ability to do "if", "case" and probably some simple loops. Beyond that it looks mostly finished now. All this means is that you can do some things without having to make a choice about which language to use. Other things will require that choice up front. I don't think you can say a spreadsheet introduces a language, but I think you can say it benefits from being able to use language based scripting in many places. Conceptually that is where I want to go with Kommander.
Re: Using Python or other scripting languages - Ville Vainio - 2004-06-24
"""If you want to insure it's run everywhere you have bash, probably perl and maybe Python. """
Yup, I think bash, perl and python are everywhere these days. At least in the Linux world, not in the BSD world if that matters.
"""Bash is both painful for novice users and slow to execute."""
It's painful for everybody :-).
One interesting idea for Python/perl use - it might be interesting to be able to specify a certain interpreter instance where the code snippet is executed. That way you could avoid the interpreter launch overhead (it might matter on slow machines) and also provide some extra power by enabling the users to keep the state in the global vars of that interpreter. It would also make importing modules in every branch unnecessary (i.e. the user would just put 'import os, sys' in some place that gets invoked when the python interpreter is first instantiated).
Obviously this would mean implementing a small proxy on the python side, but that is a trivial excercise.
Re: Using Python or other scripting languages - Eric Laffoon - 2004-06-24
I have done the same concept with Perl and Kaptain, creating a pipe to a forked process. It is not too difficult, however this has gotten me thinking and we're tossing an idea around on the developer list. The idea is that you could initiate a process that was local or remote and send instructions to it and retrieve the result. This could work for remote shells like SSH and should be able to do the same to keep an interpreter loaded. It would be nice to make it as easy as possible for people.
BTW maybe it's the down time on the dot but I've never seen a story buried so deep continue to get posts. Usually they die after 3 deep, but I keep checking. ;-)
kconfig_compiler... not found - probono - 2004-06-19
Too bad, at compile time I get the following error:
checking for kconfig_compiler... not found
configure: error: The important program kconfig_compiler was not found!
Please check whether you installed KDE correctly.
Are there any binaries out yet?
Re: kconfig_compiler... not found - Anonymous - 2004-06-19
Seems that it depends on KDE 3.2 despite other saying on kde-apps.org.
Re: kconfig_compiler... not found - Eric Laffoon - 2004-06-19
I do not believe that it does have KDE 3.2 dependencies. Michal may have forgotton to switch to an older admin directory when making the package. If there is problem and no new package when I get home I'll repackage for 3.1 compatibility... unless there is something in there I don't know about.
Re: kconfig_compiler... not found - Michal Rudolf - 2004-06-19
That's strange - we have no kconfig file to compile. It seems like configure problem - do you have KDE 3.1.x?
If so, could you try replacing
#MIN_CONFIG(3.2)
with
#MIN_CONFIG(3.1)
I'd love if someone with KDE 3.1.x can verify that Kommander compiles there. We want to support KDE 3.1.x for some time, but we need someone to help us checking it.
Please report Kommander compilation problems/success on KDE 3.1.x to me:
mrudolf (at) kdewebdev.org
Re: kconfig_compiler... not found - Archibald - 2004-11-01
If you are using KDE 3.1. Ghanging #MIN_CONFIG will not help you. I have looked at the configure script, there are small mistake on line 31091. Just comment this line, and you will have passed the kcompiler test.
Re: kconfig_compiler... not found - Archibald - 2004-11-01
I am sorry very much. I have placed wrong lineno in the previous reply.
You should comment line 31093 containing:
kde32ornewer=1
DCOP API documentation - Kevin Krammer - 2004-06-19
I think Kommander increased the need for better (or actually any) documentation of the applications' DCOP APIs
Currently DCOP is mostly limited to developers, because you have to guess by a method parameter's name what it means.
Sometimes you even have to check the respective C++ header file to look at its documentation, for example to know what value can be used for parameter "present" in knotify/Notify/notify
Perhaps there is way to autogenerate at least the C++ API docs for DCOP methods of applications like it is done for the KDE Libs API.
Cheers,
Kevin
Re: DCOP API documentation - Eric Laffoon - 2004-06-20
As I've mentioned, I would like to have a special DCOP registration browser in Kommander where enhanced definitions could be added and specific uses could be remapped in a user oriented way. kdcop is always there and it would be nice if everyone focused more on making DCOP accessible to users. I hope Kommander driving this focus helps.
#!/usr/bin/kmdr-executor - Tomas Pospisek - 2004-06-24
You are trying to make computing easier - I suggest being a bit more consequent then:
1) Just because you (kommander's authors) are faking to not understand unix' tradition/philiosophy/base principle [1], I'm re-suggesting you make kmdr-executor usable as a "filter":
$ cat myproggie
#!/usr/bin/kmdr-executor
<...
$ ./myproggie
[...program executes...]
2) Additionaly, calling kommander "kmdr" is irritating. A programm named strangeonix should be callable as strangeonix from the CLI.
Greets,
*t
[1] https://mail.kde.org/pipermail/quanta/2004-January/002489.html
Re: #!/usr/bin/kmdr-executor - Eric Laffoon - 2004-06-24
This is not entirely clear, maybe because I haven't had my morning coffee yet. (Or maybe it's this cat in my face?) Kommander is part of KDE so if you have a new version it will set up a file association so that Kommander files can be run directly by clicking in konqueror. From the shell you do have to call the executor but it's not so bad because it auto completes. It also accepts parameters now and you can write a script to launch it almost as easy. I suppose we could look at allowing a shebang to be passed over by the executor. However while this is easy to do with the executor it is a pain with the editor, which may choke on a shebang or overwrite it. We are working to "peacefully coexist" with the editor until KDE 3.3 at which time we are doing a rewrite. It will be less work in the long run. So while we could enable this in the exectuor, the editor won't get it unless it isn't a nightmare change.
One planned feature involves using projects. Any program installed as a project will be listed by typing kmdr-executor with no arguments.
As for the other, create an alias in your bashrc. Kommander is two programs and typing kommander-executor seemed tedious. As the files are saved as *.kmdr this naming scheme sounded like the best solution.
Re: #!/usr/bin/kmdr-executor - Matthew C. Tedder - 2004-08-27
If that were true.. we should have "list" instead of "ls" and ruin every other short-hand that makes shell so quick to use..for the experienced.
Kommmander's "kmdr" short-hand is quite intuitive.