Kommander began accessing it's widgets internally with DCOP, which evolved to widget functions. DCOP is still available and can be used to share information between dialogs. It can also be used to extend and integrate nearly every existing KDE application. DCOP can be called in several ways in Kommander. First is the console method. Open a Kommander dialog and open a console and try this.
This is largely focused on the old parser. If you are looking for internal widget functions please see the new parser. This information is particularly relevent to communicating between dialogs and applications, or running other scripting languages inside Kommander as scripts.
dcop | grep kmdr dcop `dcop | grep kmdr` dcop `dcop | grep kmdr` KommanderIf
This will show you what dialogs are running and what interfaces are available, as well as what is available to call in the Kommander special interface to internals. In the explanation of DCOP here remember that DCOP is used internally by TDE applications (replaced with DBUS in KDE4) and it is very useful. Have a look at kdcop by pressing Alt-F2 and typing it in a run dialog. Here you can explore everything running. Now back to DCOP in Kommander.
dcop kmdr-executor-@pid KommanderIf setText myWidget “new text”
This assumes you are inside a Kommander file and have access to the special @pid which contains the process ID. In fact it is simpler to replace “kmdr-executor-@pid” with @dcopid. However, you can use this syntax (obviously without the specials) from the command line or any external script to alter the Kommander window.
Kommander evolved the much faster internal DCOP function. Using it from another application window (console DCOP is very slow) is more complicated because you must give lots of information, including a prototype of the call. The above call would become: (Note that @dcopid is actually internal to the dialog, but you could replace it with a valid process ID)
@dcop(@dcopid, KommanderIf, “enableWidget(TQString, bool)”, Widget, true)
In the early Kommander nesting DCOP calls inside script language structures (like bash) used console method calls. If you use internal DCOP all Kommander specials will be executed first and then the script will be executed. Please read that again as it will cause you no end of grief with a bash loop using Kommander specials.
There is a new simplified way to use DCOP inside Kommander using an object syntax. Let's say you want to change the text in a widget name @LineEdit1. It would look like this.
@LineEdit1.setText(New text)
As you can see the new syntax is very easy, as well as consistent visually with function groups. All the DCOP reference here will use the new object syntax listed above. Please note that if you are referencing a widget using DCOP from another window or another application the first parameter will always be the widget name. All functions are listed here starting with the second parameter.
Returns the value of the specified global variable. When a script is run from within a Kommander window any (non-global) variables set in that script will cease to exist after the script completes and therfore will not be available to other script processes or in a new instance of the calling process. The global “scope” means the variable will exist for any process of the window until that window is closed. You may change these variables at any time with a new call to @setGlobal
.
Creates a variable that is global to the window process and assigns the value to it. This value can be retrieved with global(TQString variableName) or set again.
The following list is old and left here for reference purposes only. For a complete and current reference to all widget functions please look at the Function Browser which is available from any Kommander text editor window by pressing the lower left button. These are now widget functions, not DCOP functions but the DCOP functions are published in the KommanderIf DCOP interface as described above. Dialogs for listing and constructing calls for this functionality are available at our web site.
This removes the text displayed in the widget and replaces it with the text supplied.
Enables or disables a widget.
Returns the text associated with the specified widget. This is not the same as the displayed text. It would be “@widgetText” or the text and/or scripting used to arrive at the displayed value.
This sets the Kommander Text default string. This is typically set to “@widgetText” to display what is entered into the widget. It is unlikely you will have much need for this, but if you do it is there. Applies to all widgets that can contain data.
Adds an item to a ListBox widget at the specified index. List index starts at zero. To add to the end of the list use -1.
This adds a list of strings all at once. The list should be delimited by EOL (\n - newlines). This is handy as you can use bash to derive the list rather easily. For instance, using @exec(ls -l ~/projects | grep kmdr) for items will give you a directory listing of Kommander files in your projects folder. List index starts at zero. Use -1 to add to the end of the list.
addUniqueItem will add an item to the end of the list only if it is unique.
Removes all items.
Removes the item at the specified index.
Returns the text of the item at the specified index.
Set the current (or selected) item to the index specified. Applies to ListBox and ComboBox widgets.
Checks/unchecks CheckBox or RadioButton widgets.
Would you like to comment or contribute an update to this page?
Send feedback to the TDE Development Team