From e9ae80694875f869892f13f4fcaf1170a00dea41 Mon Sep 17 00:00:00 2001 From: toma Date: Wed, 25 Nov 2009 17:56:58 +0000 Subject: Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. BUG:215923 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdewebdev@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da --- doc/kommander/Makefile.am | 3 + doc/kommander/basics.docbook | 135 +++++++ doc/kommander/buttongroup.png | Bin 0 -> 648 bytes doc/kommander/checkbox.png | Bin 0 -> 817 bytes doc/kommander/closebutton.png | Bin 0 -> 585 bytes doc/kommander/combobox.png | Bin 0 -> 549 bytes doc/kommander/commands.docbook | 14 + doc/kommander/contents.png | Bin 0 -> 1300 bytes doc/kommander/credits.docbook | 59 +++ doc/kommander/datepicker.png | Bin 0 -> 965 bytes doc/kommander/dcop.docbook | 203 ++++++++++ doc/kommander/editor.docbook | 642 +++++++++++++++++++++++++++++++ doc/kommander/editor.png | Bin 0 -> 29040 bytes doc/kommander/extending.docbook | 440 ++++++++++++++++++++++ doc/kommander/frame.png | Bin 0 -> 521 bytes doc/kommander/glossary.docbook | 39 ++ doc/kommander/groupbox.png | Bin 0 -> 439 bytes doc/kommander/index.docbook | 121 ++++++ doc/kommander/installation.docbook | 50 +++ doc/kommander/interface.png | Bin 0 -> 175153 bytes doc/kommander/introduction.docbook | 134 +++++++ doc/kommander/kfontcombo.png | Bin 0 -> 1194 bytes doc/kommander/kommander.png | Bin 0 -> 1480 bytes doc/kommander/konsole.png | Bin 0 -> 1155 bytes doc/kommander/label.png | Bin 0 -> 953 bytes doc/kommander/lineedit.png | Bin 0 -> 461 bytes doc/kommander/listbox.png | Bin 0 -> 386 bytes doc/kommander/listview.png | Bin 0 -> 759 bytes doc/kommander/multilineedit.png | Bin 0 -> 1031 bytes doc/kommander/parser.docbook | 751 +++++++++++++++++++++++++++++++++++++ doc/kommander/pixlabel.png | Bin 0 -> 1229 bytes doc/kommander/progress.png | Bin 0 -> 609 bytes doc/kommander/pushbutton.png | Bin 0 -> 408 bytes doc/kommander/q-and-a.docbook | 11 + doc/kommander/radiobutton.png | Bin 0 -> 586 bytes doc/kommander/richtextedit.png | Bin 0 -> 834 bytes doc/kommander/shadow.png | Bin 0 -> 213 bytes doc/kommander/shellscript.png | Bin 0 -> 1053 bytes doc/kommander/slider.png | Bin 0 -> 729 bytes doc/kommander/specials.docbook | 371 ++++++++++++++++++ doc/kommander/spinbox.png | Bin 0 -> 455 bytes doc/kommander/statusbar.png | Bin 0 -> 294 bytes doc/kommander/table.png | Bin 0 -> 483 bytes doc/kommander/tabwidget.png | Bin 0 -> 572 bytes doc/kommander/textbrowser.png | Bin 0 -> 514 bytes doc/kommander/textedit.png | Bin 0 -> 497 bytes doc/kommander/timer.png | Bin 0 -> 1462 bytes doc/kommander/toolbox.png | Bin 0 -> 783 bytes doc/kommander/translating.docbook | 72 ++++ doc/kommander/tutorials.docbook | 380 +++++++++++++++++++ doc/kommander/widgets.docbook | 599 +++++++++++++++++++++++++++++ 51 files changed, 4024 insertions(+) create mode 100644 doc/kommander/Makefile.am create mode 100644 doc/kommander/basics.docbook create mode 100644 doc/kommander/buttongroup.png create mode 100644 doc/kommander/checkbox.png create mode 100644 doc/kommander/closebutton.png create mode 100644 doc/kommander/combobox.png create mode 100644 doc/kommander/commands.docbook create mode 100644 doc/kommander/contents.png create mode 100644 doc/kommander/credits.docbook create mode 100644 doc/kommander/datepicker.png create mode 100644 doc/kommander/dcop.docbook create mode 100644 doc/kommander/editor.docbook create mode 100644 doc/kommander/editor.png create mode 100644 doc/kommander/extending.docbook create mode 100644 doc/kommander/frame.png create mode 100644 doc/kommander/glossary.docbook create mode 100644 doc/kommander/groupbox.png create mode 100644 doc/kommander/index.docbook create mode 100644 doc/kommander/installation.docbook create mode 100644 doc/kommander/interface.png create mode 100644 doc/kommander/introduction.docbook create mode 100644 doc/kommander/kfontcombo.png create mode 100644 doc/kommander/kommander.png create mode 100644 doc/kommander/konsole.png create mode 100644 doc/kommander/label.png create mode 100644 doc/kommander/lineedit.png create mode 100644 doc/kommander/listbox.png create mode 100644 doc/kommander/listview.png create mode 100644 doc/kommander/multilineedit.png create mode 100644 doc/kommander/parser.docbook create mode 100644 doc/kommander/pixlabel.png create mode 100644 doc/kommander/progress.png create mode 100644 doc/kommander/pushbutton.png create mode 100644 doc/kommander/q-and-a.docbook create mode 100644 doc/kommander/radiobutton.png create mode 100644 doc/kommander/richtextedit.png create mode 100644 doc/kommander/shadow.png create mode 100644 doc/kommander/shellscript.png create mode 100644 doc/kommander/slider.png create mode 100644 doc/kommander/specials.docbook create mode 100644 doc/kommander/spinbox.png create mode 100644 doc/kommander/statusbar.png create mode 100644 doc/kommander/table.png create mode 100644 doc/kommander/tabwidget.png create mode 100644 doc/kommander/textbrowser.png create mode 100644 doc/kommander/textedit.png create mode 100644 doc/kommander/timer.png create mode 100644 doc/kommander/toolbox.png create mode 100644 doc/kommander/translating.docbook create mode 100644 doc/kommander/tutorials.docbook create mode 100644 doc/kommander/widgets.docbook (limited to 'doc/kommander') diff --git a/doc/kommander/Makefile.am b/doc/kommander/Makefile.am new file mode 100644 index 00000000..41691557 --- /dev/null +++ b/doc/kommander/Makefile.am @@ -0,0 +1,3 @@ +KDE_LANG = en +KDE_DOCS = AUTO + diff --git a/doc/kommander/basics.docbook b/doc/kommander/basics.docbook new file mode 100644 index 00000000..5d7dc2cf --- /dev/null +++ b/doc/kommander/basics.docbook @@ -0,0 +1,135 @@ + + + + +&kommander; Basics + + +Tamara +King +
+tik@acm.org +
 + + +Eric +Laffoon +
+sequitur@kde.org +
 + + + + + + + +&kommander; Basics + + + + +Concepts + + + +&kommander; was originally designed around a simple concept that has proven somewhat revolutionairy among visual design tools. Typically these tools allow you to create dialogs and possibly mainwindow interfaces. Of course a mainwindow interface is the main program window which typically has menus, toolbars, statusbar and the application area. Dialogs are child windows which typically don't have menus and are so named because their purpose is to have a dialog or exchange information between you and the main application. The elements on a dialog are called widgets and you hook your program into these widgets. &kommander; is different because it is inherently nonprogrammatic here. It uses the concept of associating text with the widgets on the dialog. Initially this was called Associated Text but now it is called &kommander; Text. Widgets on &kommander; dialogs can include the content of other widgets by reference and a widget can reference its own content by use of a Special that looks like this, @widgetText. Specials are commands with special meaning in &kommander;. So if you created a dialog with two LineEdit widgets and named the first FirstName and the second LastName you could create a button and set its &kommander; Text to My name is @FirstName @LastName. You would need to set @widgetText in the first and last name widgets. Remember? We need to tell &kommander; to reference the text in them. You could run this from a Konsole and it would output the string for you. So it would reference the first name like so: @FirstName -> get the widget named FirstName(@FirstName) -> @widgetText -> get the contents of the LineEdit widget. So in this case @FirstName returns Eric: @FirstName -> @widgetText -> Eric. + + + +That is the simple core of &kommander;. What you can do with this is where it gets interesting. First of all it is worth noting that compared to the normal approach of a language based tool &kommander; does not need programming statements to define these operations. This makes &kommander; quick for developers. For end users it's much simpler than learning language constructs. For everyone it means you can focus on your task instead of having your reference material eternally at hand. Initially when people are exposed to a tool like &kommander; the first question is Where could I find a use for this cool tool? As it turns out, manipulating strings is used just about anywhere you look. + + + +So what can &kommander; do? Here is the list distilled to the base operations. +&kommander; can: + + + +Pass strings to the calling program via stdout. +Call executable programs. +Use &DCOP; to interact with &kde; programs + + + +If you're not a programmer you may want that in laymans terms. In number one, if you launch &kommander; from a console then the console is the calling program. There is a parent child relationship there. Sending a message to console is done with the standard output (stdout) of the child program, so named because there is also error output. This is interesting because some programs, like &quantaplus;, use stdout to receive information from programs they launch. So &kommander; dialogs can output their text strings directly into &quantaplus;'s editor if they are called from &quantaplus;. This means &kommander; dialogs can be useful extentions to programs. + + + +The second case is calling an executable. Any program that runs on your system is an executable. Even a script program is run by the script's interpreter so technically it's executed too. &kommander; can run commands just like the console even if you run it from the menu. So for instance if you wanted it to open &GIMP; you would have a button derive the string gimp and put it in a special like so: @exec(gimp). Just like that you will see &GIMP; open when using this. You could also exec ls -l too but you would only see the output if you were running from a console. + + + +The third case is very interesting indeed. &DCOP; is short for &kde;'s Desktop COmmunication Protocol and it is very powerful. Go ahead and run the kdcop program and have a look around. You'll quickly see that any &kde; application that is built to standards has things happening in &DCOP; and the well designed ones have a lot going on. With &DCOP; you can query information of all sorts as well as set widget values and more. There is a section on using &DCOP; in this manual. &kommander; can send &DCOP; to any &kde; program as well as be controlled by &DCOP;. In fact you can send &DCOP; from the command line to any &kde; program. So what's the big deal? The deal is, if you want to do any volume of commands you begin to realized that command line &DCOP; is adequate for short commands, but it can cause delays for instance being called from a loop several hundred times. This is why &kommander; has a @dcop special, because this is roughly 1000 times faster. Because &kommander; can send and receive &DCOP;, &DCOP; can be used to script &kommander;. That is why we also have a local &DCOP; special, @ldcop, that allows you to type a lot less to issue a command. + + + +Is that all the core concepts in &kommander;? No, but it should help you to make sense of how it works so that what is covered does not look like a foreign language to you. There are a few more. Signals and slots are how &kommander; handles events. An event in a program basically means something happened like a widget was created or had its text changed. These changes emit signals and you can connect those signals to a receiving slot which will then do something when the event happens. One use of this in &kommander; is the sibling of &kommander; Text, Population Text. Population Text will populate a widget when called. Just like &kommander; Text, Population Text can contain text strings or scripts. + + + +That should give you the base concepts to begin using &kommander;. We try to keep the number of Specials low and we use &DCOP; a lot. The idea is that we want to keep the power of &kommander; as consistent and streamlined as possible. You will find that you can incorporate any scripting language into &kommander; where ever you need to and even multiple scripting languages in a dialog. The rest of the information in this document assumes you are familiar with the concepts and terms presented here. The examples and tutorials are also very useful to understanding what can be done with &kommander;. + + + +&editor; + + +The Executor + + +The executor, called kmdr-executor, runs &kommander; scripts. It loads .kmdr files and dynamically produces a fully functional dialog. +Starting with version 1.3, the executor warns if the script file is not executable. This is an extra security feature that tries to make the user think about the possible bad consequences of running a script from untrusted source. The user can confirm to run the dialog or if he trusts the source, can make the script executable and get rid of the warning completely. +Version 1.3 supports the #!/path/kmdr-executor shebang in the beginning of the .kmdr script files (replace path with path to the +Such files if they are made executable can be run from command line just like any executable application, without the need to pass the script to kmdr-executor as argument. + +Remember, that once you add the shebang at the beginning of the file, the dialog cannot be run or edited with older versions of &kommander;. +The recommended usage is + +#!/usr/bin/kommander + +and create a symlink from kmdr-executor to /usr/bin/kommander. +The shebang can be added to a dialog directly from the editor, by modifying the useShebang and shebang properties for the main dialog. + + + + + +Executor for Programmers + + +C++ developers can easily use the Instance class in their C++ programs so that the execution functionality is embedded in the their application obsoleting the need for running the external executor program. For standard dialog the dialog creation overhead is minimal but the creation of the &kde; application may delay the dialog for around a second. + +Another approach is to use the kommander_part KReadOnlyPart. This KPart can load and execute any &kommander; dialog inside another KDE application. + + + + + +Creating a Dialog + +To learn about how to create a dialog, add widgets, use layouts, modify widgets properties, please consult the &Qt; Designer (version 3.x) manual. You can access it by running designer from the command line or from your desktop menu. + + +The extra functionality that &kommander; offers is the Kommander Text associated with each widget. These texts are the executable (script) part of the dialog, written either in a script language (with the old &kommander; syntax) or using the internal &kommander; language, the so called new parser. + +To learn more about the language syntax, commands and how to use the text editor, consult the upcoming chapters and check the examples shipped with the &kommander; source. + + + +Executable bit - new in 1.3 + +For security reasons we introduced the executable bit requirement in version 1.3. Some will applaud this as long overdue. Others will consider it a terrible annoyance or even too scarey to use. Unfortunately there is no perfect solution. The problem is that you can download a Kommander dialog from anywhere or get one in your email and click on it and run it by accident. Because Kommander can run shell scripts it is sort of in an odd place. While other applications don't nag you this way you actually had to install them so clearly you felt safe and intended to run them. A single line of shell scripting could permanently wipe out your home directory. Our intent is to eliminate an accidental click on an untrusted dialog. We aplogize for any inconvenience, but there is no way to do this to even the developer's satisfaction that it will not annoy you while keeping you safe. + + +You are not prevented from running a dialog, just nagged. You can make it go away by using a file manager or the shell to set the executable bit. Right click on the dialog in Konqueror, select properties from the menu, choose the permissions tab and check the is executable checkbox. Now the nag will be gone from this dialog forever. Check our web site for a tool that searchesfor &kommander; dialogs and allows you to review them and choose whether any or all of them should have the bit set. To use the shell and make all the &kommander; dialogs in a directory executable use this command. + + +chmod u+x *.kmdr + +Do not set dialogs as executable if you are not confident of their origin. + + + diff --git a/doc/kommander/buttongroup.png b/doc/kommander/buttongroup.png new file mode 100644 index 00000000..d89e28fd Binary files /dev/null and b/doc/kommander/buttongroup.png differ diff --git a/doc/kommander/checkbox.png b/doc/kommander/checkbox.png new file mode 100644 index 00000000..ab6f53e0 Binary files /dev/null and b/doc/kommander/checkbox.png differ diff --git a/doc/kommander/closebutton.png b/doc/kommander/closebutton.png new file mode 100644 index 00000000..63903b30 Binary files /dev/null and b/doc/kommander/closebutton.png differ diff --git a/doc/kommander/combobox.png b/doc/kommander/combobox.png new file mode 100644 index 00000000..7d4890a7 Binary files /dev/null and b/doc/kommander/combobox.png differ diff --git a/doc/kommander/commands.docbook b/doc/kommander/commands.docbook new file mode 100644 index 00000000..87a6dc54 --- /dev/null +++ b/doc/kommander/commands.docbook @@ -0,0 +1,14 @@ + + + + +Command Reference + + +Reference + +&widgets; +&specials; +&dcop-functions; + + diff --git a/doc/kommander/contents.png b/doc/kommander/contents.png new file mode 100644 index 00000000..7596e67a Binary files /dev/null and b/doc/kommander/contents.png differ diff --git a/doc/kommander/credits.docbook b/doc/kommander/credits.docbook new file mode 100644 index 00000000..95c38541 --- /dev/null +++ b/doc/kommander/credits.docbook @@ -0,0 +1,59 @@ + + + + +Credits and License + + +Tamara +King +
+tik@acm.org +
 + + + + + + + +Credits and License + + +The &kommander; Development Team + +Britton, Marc consume@optusnet.com.au +Developer and documentation + + +King, Tamara tik@acm.org +Documentation + + +Laffoon, Eric sequitur@kde.org +Project manager and documentation + + +Mantia, András amantia@kde.org +Developer + + +Rudolf, Michal mrudolf@kdewebdev.org +Developer + + + + +&kommander; 2004 - 2008 &kommander; Development Team. + + + +&kommander; User Manual 2004 - 2008 &kommander; Development Team. + + + + +&underFDL; +&underGPL; + + diff --git a/doc/kommander/datepicker.png b/doc/kommander/datepicker.png new file mode 100644 index 00000000..4bcc6450 Binary files /dev/null and b/doc/kommander/datepicker.png differ diff --git a/doc/kommander/dcop.docbook b/doc/kommander/dcop.docbook new file mode 100644 index 00000000..2fbf70a1 --- /dev/null +++ b/doc/kommander/dcop.docbook @@ -0,0 +1,203 @@ + + + + +&DCOP; Functions + + +&DCOP; Functions + + +&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 KDE 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(QString, 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. + + + +&DCOP; for Global Variables + + +global(QString variableName) + + +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. + + + + +setGlobal(QString variableName, QString value) + + +Creates a variable that is global to the window process and assigns the value to it. This value can be retrieved with global(QString variableName) or set again. + + + + + + + +&DCOP; for all Widgets + + +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. + + + +setText(QString text) + + +This removes the text displayed in the widget and replaces it with the text supplied. + + + + +enableWidget(bool enable) + + +Enables or disables a widget. + + + + +associatedText + + +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. + + + + +setAssociatedText(QString text) + + +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. + + + + + + + +&DCOP; for ListBox and ComboBox Widgets + + +addListItem(QString item, int index) + + +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. + + + + +addListItems(QStringList items, int index) + + +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(QString item) + + +addUniqueItem will add an item to the end of the list only if it is unique. + + + + +clearList + + +Removes all items. + + + + +removeListItem(int index) + + +Removes the item at the specified index. + + + + +item(int index) + + +Returns the text of the item at the specified index. + + + + +setCurrentListItem(int index) + + +Set the current (or selected) item to the index specified. Applies to ListBox and ComboBox widgets. + + + + + + + +&DCOP; for CheckBox and RadioButton Widgets + + +setChecked(QString widgetName, bool checked) + + +Checks/unchecks CheckBox or RadioButton widgets. + + + + + + + +&DCOP; for TabWidget Widgets + + +setCurrentTab(QString widgetName, int index) + + +Selected the tab by index for TabWidgets. Index starts at 0. + + + + + + + + diff --git a/doc/kommander/editor.docbook b/doc/kommander/editor.docbook new file mode 100644 index 00000000..3b288e9c --- /dev/null +++ b/doc/kommander/editor.docbook @@ -0,0 +1,642 @@ + + + + +The Editor + + +Tamara +King +
+tik@acm.org +
 + + + + + + + +The Editor + + +The editor is based on &designer;, a tool for designing and implementing user interfaces created by Trolltech. We have modified &designer; in the following ways: + + +Its interface is much simpler +Built in our own widgets +Added the ability to setup &kommander; Text +Various other superficial changes + + +For those of you already familiar with using &designer;, using the &kmdr-editor; will be trivial. + + + +Main Window + + + + + + + + +Toolbars contain a number of buttons to provide quick access to number of functions. +The File Overview displays all of the files. Use the search field to rapidly switch between files. +The Object Explorer provides an overview of the relationships between the widgets in a form. It is useful for selecting widgets in a form with a complex layout. +The Property Editor is where the behavior and appearance of a widget is changed. +The Dialog Editor is where dialogs are created and edited. + + + + +The File Menu + + + + + +&Ctrl;N + +File +New + +Creates a new dialog + + + + +&Ctrl;O + +File +Open + +Search the file system to open an existing dialog + + + +File +Open Recent + +Quick list of the last several files you've opened. This list will change each time you open a file that is not on it with the oldest being bumped off first. + + + +File +Close + +Closes the active dialog + + + + +&Ctrl;S + +File +Save + +Saves the active dialog + + + +File +Save As + +Saves the active dialog with another name + + + +File +Save All + +Saves all open dialogs + + + +File +Exit + +Quits &kommander; + + + + + + + +The Edit Menu + + + + + +&Ctrl;Z + +Edit +Undo + +Undo the last action performed. + + + + +&Ctrl;Y + +Edit +Redo + +Redo the last action undone. + + + + +&Ctrl;X + +Edit +Cut + +Cut the current item and place it content on the clipboard. + + + + +&Ctrl;C + +Edit +Copy + +Copy the current item to the clipbard. + + + + +&Ctrl;V + +Edit +Paste + +Paste the contents of the clipboard at the current cursor position. + + + + +&Ctrl;Z + +Edit +Delete + +Delete the current item. + + + + +Del + +Edit +Select All + +Select all of the items in the current dialog. + + + + +&Alt;R + +Edit +Check Accelerators + +Verifies that all the accelerators are used only once. + + + +Edit +Connectors + +Displays the view and edit connections dialog. + + + +Edit +Form Setting + +Displays the form setting dialog. + + + +Edit +Preferences + +Displays the preferences dialog. + + + + + + +The Tools Menu + + + + + +F2 + +Tools +Pointer + + + + + + +F3 + +Tools +Connect Signal/Slots + + + + + + +F3 + +Tools +Tab Order + + + + + + +Tools +&kommander; + + +Here there are listed all the &kommander; widgets. This widgets are guaranteed to be available on every system running the same (or higher) version of &kommander;. + + + + + +Tools +Custom + + +The widgets provided by the plugins will be listed under this menu entry. The dialogs using these widgets will run only if the plugin that provides them is installed and configured. + + + + + + + + + + +The Layout Menu + + + + + +&Ctrl;J + +Layout +Adjust Size + + + + + + +&Ctrl;H + +Layout +Lay Out Horizontally + + + + + + +&Ctrl;L + +Layout +Lay Out Vertically + + + + + + +&Ctrl;G + +Layout +Lay Out in a Grid + + + + + +Layout +Lay Out Horizontally (in Splitter) + + + + + +Layout +Lay Out Vertically (in Splitter) + + + + + + +&Ctrl;B + +Layout +Break Layout + + + + + +Layout +Add Spacer + + + + + + + + +The Run Menu + + + + + +&Ctrl;R + +Run +Run Dialog + +Runs the current dialog. + + + + + + +The Window Menu + + + + + +&Ctrl;F4 + +Window +Close + +Closes current dialog. + + + +Window +Close All + +Closes all dialogs. + + + + +&Ctrl;F6 + +Window +Next + + + + + + +&Ctrl;&Shift;F6 + +Window +Previous + + + + + +Window +Tile + + + + + +Window +Cascade + + + + + +Window +Views + + + + + + +Window +Views +File Overview + + + + + + + +Window +Views +Object Explorer + + + + + + + +Window +Views +Property Editor/Signal Handlers + + + + + + + +Window +Views +Line Up + + + + + + + + + +Window +Toolbars + + + + + + +Window +Toolbars +File + + + + + + + +Window +Toolbars +Edit + + + + + + + +Window +Layout +File + + + + + + + +Window +Toolbars +Tools + + + + + + + +Window +Toolbars +&kommander; + + + + + + + +Window +Toolbars +Custom + + + + + + + +Window +Toolbars +Help + + + + + + + +Window +Toolbars +Line Up + + + + + + + + + + + + +The Settings Menu + + + + +Settings +Configure Shortcuts + +See and modify the editor keyboard shortcuts. + + + +Settings +Configure Plugins + +Add or remove &kommander; plugins. The editor needs to be restarted after a new plugin is added. + + + +Settings +Configure Editor + +Configure the text editor used for modifying the Kommander text associated with widgets. + + + +Settings +Configure &kommander; + +Configure how the editor looks and works. + + + + + + +The <guimenu>Help</guimenu> Menu + + + + + + +&help.menu.documentation; + + + + + diff --git a/doc/kommander/editor.png b/doc/kommander/editor.png new file mode 100644 index 00000000..6c0db299 Binary files /dev/null and b/doc/kommander/editor.png differ diff --git a/doc/kommander/extending.docbook b/doc/kommander/extending.docbook new file mode 100644 index 00000000..a5b38b05 --- /dev/null +++ b/doc/kommander/extending.docbook @@ -0,0 +1,440 @@ + + + + + + +Andras +Mantia +
amantia@kde.org
 + + +Michal +Rudolf +
mrudolf@kdewebdev.org
 + + + + + + +Extending &kommander; + + +Creating &kommander; Widgets + +With &kommander; you can create new widgets based on non-&kommander; widgets +fairly easily. + +There are two ways of adding new widgets to &kommander;: by creating +plugins or by adding it directly to the &kommander; source. + + +Create the widget class + + The first step is to create the widget class. The approach is to derive your new &kommander; widget class from the +&Qt;/&kde; widget which you wish to integrate with &kommander;, and then also from the +KommanderWidget class. Overriding methods from this class gives the &kommander; +widget its functionality. + + +Most of the code of a &kommander; widget is just template code. +Therefore, you can use the KDevelop &kommander; plugin template to generate +most the &kommander; widget code for you. To do so run KDevelop (3.5 is recommended), +select Project->New Project, tick the Show all project templates checkbox, +select the C++/&kommander;/KommanderPlugin template. Give a name for your plugin and +follow the instructions in the wizard. + + +All you have to do is fill in the +important parts relating to your widget like any state information, widget text +etc. + + +Let's say we want to create a new line edit widget for &kommander;, +based on the KDE widget KLineEdit. Using the &kommander; widget generator +dialog, we get something like this in the generated header file: + + +#include <kommanderwidget.h> + +class QShowEvent; +class KomLineEdit : public KLineEdit, public KommanderWidget +{ + Q_OBJECT + + Q_PROPERTY(QString populationText READ populationText WRITE setPopulationText DESIGNABLE false) + Q_PROPERTY(QStringList associations READ associatedText WRITE setAssociatedText DESIGNABLE false) + Q_PROPERTY(bool KommanderWidget READ isKommanderWidget) + +public: + KomLineEdit(QWidget *a_parent, const char *a_name); + ~KomLineEdit(); + + virtual QString widgetText() const; + + virtual bool isKommanderWidget() const; + virtual void setAssociatedText(const QStringList&); + virtual QStringList associatedText() const; + virtual QString currentState() const; + + virtual QString populationText() const; + virtual void setPopulationText(const QString&); +public slots: + virtual void setWidgetText(const QString &); + virtual void populate(); +protected: + void showEvent( QShowEvent *e ); +signals: + void widgetOpened(); + void widgetTextChanged(const QString &); +}; + +Most of this is just template code that you don't need to worry about. +The only two things you need to take notice of are that the kommanderwidget.h +file is included at the top, and that the class is derived first from the +widget we wish to integrate with &kommander;, and secondly from KommanderWidget. + + +There are a few parts in the cpp file that are important to each particular widget. + + +KomLineEdit::KomLineEdit(QWidget *a_parent, const char *a_name) + : KLineEdit(a_parent, a_name), KommanderWidget(this) +{ + QStringList states; + states << "default"; + setStates(states); + setDisplayStates(states); +} + +In the constructor, we set the states this widget may have. +Our line edit doesn't have any kind of state, so we just +give it one state default. If you were creating a widget +that had different kinds of states, such as a check box, you might +set three states unchecked, semichecked and checked here. + + +QString KomLineEdit::currentState() const +{ + return QString("default"); +} +We set the states in the constructor above, and this just +returns the current state of the widget. For our widget +it will always be default, but you should put code here +that checks what state your widget is currently in and +return the appropriate string here. + + +QString KomLineEdit::widgetText() const +{ + return KLineEdit::text(); +} + +void KomLineEdit::setWidgetText(const QString &a_text) +{ + KLineEdit::setText(a_text); + emit widgetTextChanged(a_text); +} + +These are the two most important methods, where the bulk of the +functional code goes. +QString KomLineEdit::widgetText() const method returns the widget text of the +widget (the text that the @widgetText special is expanded to in text +associations). For our widget, the widget text is simply the text inside +the line edit, so we just return that. Similarly when setting the widget text, +we just set the text inside the line edit. We emit the widgetTextChanged() +signal after setting the widget text so other widgets can recognize the fact +that this widget was updated. + + +In order to add functionality to the widget, you need to register some function and add code to handle them. Here is the code to be used to register, put it in the beginning of the cpp file, above the constructor: + + +#include <klocale.h> //for i18n + +#include "kommanderplugin.h" +#include "specials.h" + +enum Functions { + FirstFunction = 1159, + Function1, + Function2, + LastFunction +}; +KomLineEdit::KomLineEdit(QWidget *a_parent, const char *a_name) + : KLineEdit(a_parent, a_name), KommanderWidget(this) +{ + ... //code like described above + KommanderPlugin::setDefaultGroup(Group::DCOP); + KommanderPlugin::registerFunction(Function1, "function1(QString widget, QString arg1, int arg2)", i18n("Call function1 with two arguments, second is optional."), 2, 3); + KommanderPlugin::registerFunction(function2, "function2(QString widget)", i18n("Get a QString as a result of function2."), 1); +} + +This registers two functions: function1 and function2. The number assigned to the functions (here 1160 and 1161) must be unique, not used in any other plugin or +inside &kommander;. function1 takes two arguments, one is optional, function2 takes no argument and returns a string. The QString widget argument in the signatures notes that this functions work on a widget, like: KomLineEdit.function1("foo", 1). + +To teach &kommander; that the widget supports these functions, add a method like this: + + +bool KomLineEdit::isFunctionSupported(int f) +{ + return (f > FirstFunction && f < LastFunction) || f == DCOP::text; +} + +This means that KomLineEdit supports the above functions and the standard text +function. +The function code should be handled inside the handleDCOP method: + + +QString KomLineEdit::handleDCOP(int function, const QStringList& args) +{ + switch (function) + { + case function1: + handleFunction1(arg[0], arg[1].toInt()); //call your function1 handler + break; + case function2: + return handleFunction2(); //call function2 + break; + case DCOP::text: + return text(); //call the standard KLineEdit::text() method + break; + default: + return KommanderWidget::handleDCOP(function, args); + } + return QString::null; +} + +There are cases when the widget should appear differently in the editor than in +the executor, like the case of ScriptObjects, about dialog, etc. The usual solution is to show a QLabel instead of the widget. For this, your widget must +derive from QLabel, and use this in the constructor: + + + if (KommanderWidget::inEditor) + { + setPixmap(KGlobal::iconLoader()->loadIcon("iconname", KIcon::NoGroup, KIcon::SizeMedium)); + setFrameStyle(QFrame::Box | QFrame::Plain); + setLineWidth(1); + setFixedSize(pixmap()->size()); + } + else + setHidden(true); + +You can create the widget itself (if you need a widget at all, maybe your +"widget" provides only functionality to access e.g databases) in one of your +functions, like in the execute function. Here is an example from the AboutDialog widget: + + +QString AboutDialog::handleDCOP(int function, const QStringList& args) +{ + switch (function) { + ... + case DCOP::execute: + { + if (m_aboutData) + { + KAboutApplication dialog(m_aboutData, this); + dialog.exec(); + } + break; + } + ... +} + +You now have a complete &kommander; widget. All that's left +to do is make it available to the &kommander; system via plugins. + + + + + +Create the &kommander; plugin + +All of the widgets in &kommander; are provided by plugins. +The standard widgets are loaded as widget plugins, but the &kommander; editor +is also linked against this library because certain mechanisms in the editor +are tied specifically to the standard widgets. + + +A plugin in &kommander; is simply a shared library that has the symbol +'kommander_plugin'. This symbol is a function returning a pointer +to an instance of a KommanderPlugin class. + + +&kommander; makes it easy to create a plugin for you widgets, so you don't +need to worry about this low level stuff. The basic idea is to derive +a new plugin class for your widgets from the KommanderPlugin base class +and implement a few specific details. A template code is generated by the above described KDevelop project template. + +The following code continues on our example of creating a Kommander line edit +widget. + + +#include <kommanderplugin.h> + +/* WIDGET INCLUDES */ +#include "komlineedit.h" + + + +First thing we do is include kommanderplugin.h. This contains the definition +of the KommanderPlugin class. We also include all header files of the widgets +this plugin provides - only komlineedit.h in this case. + + +class MyKomPlugin : public KommanderPlugin +{ +public: + MyKomPlugin(); + virtual QWidget *create( const QString &className, QWidget *parent = 0, const char *name = 0 ); +}; + + +We then create a KommanderPlugin sub-class called MyKomPlugin. +This class simply has a constructor and an overridden create method. + + +MyKomPlugin::MyKomPlugin() +{ + addWidget( "KomLineEdit", "My Widget Group", i18n("A Kommander line edit widget") new QIconSet(KGlobal::iconLoader()->loadIcon("iconname", KIcon::NoGroup, KIcon::SizeMedium))); + //add my other widgets here +} + +In the constructor of the plugin, we call addWidget() for each widget we wish +to provide in this plugin. addWidget() takes 6 arguments but only the first 4 +are required. In order, the arguments are the widget's class name, group, +tool tip, an iconset for the icon used in the editor toolbar, what's this information, and a bool indicating whether the widget +is a container for other widgets or not. This information is used +by the editor when grouping your widget in menus, providing help information +etc. + + +Regarding the icon, the above example loads a medium sized icon called iconname from the standard &kde; icon location. + + +QWidget *MyKomPlugin::create( const QString &className, QWidget *parent, const char *name ) +{ + if( className == "KomLineEdit" ) + return new KomLineEdit( parent, name ); + //create my other widgets here + return 0; +} + + +create() is where instances of our widgets actually get created. +Whenever &kommander; wants an instance of one of the classes provided +by our plugin, it will call create() with the name of the class it wants, +and the parent and name that should be used. +If the className matches any widget we know about, we return a new instance +of that class but otherwise we return 0. + + +Finally, we export our plugin. This just provides an entry point to our +plugin so the &kommander; system can get access to it. Without this, +&kommander; will not recognize your library as a &kommander; plugin. + + +KOMMANDER_EXPORT_PLUGIN(MyKomPlugin) + + +To compile your new &kommander; extension, you should compile all files +as a shared library, linking against the kommanderplugin, kommanderwidget +and any appropriate KDE libraries. +With the line edit example, if we had komlineedit.h, komlineedit.cpp and +mykomplugin.cpp, compiling and installing your plugin would involve +something similar to the following commands: + + +libtool --mode=compile g++ -$KDEDIR/include -IQTDIR/include \ + -I. -fPIC -c komlineedit.cpp +libtool --mode=compile g++ -$KDEDIR/include -IQTDIR/include \ + -I. -fPIC -c mykomplugin.cpp + +libtool --mode=link g++ -shared -L$KDEDIR/lib -lkdeui -lkommanderwidget \ + -lkommanderplugin komlineedit.cppkomlineedit.o mykomplugin.o + -o libmykomplugin.so + + +If you want to install new plugin system-wide, root, use: + + +su -c "cp libmykomplugin.so $KDEDIR/lib" + +If you use the KDevelop project generator, you will not need to do the above, but instead adapt the Makefile.am to link against extra libraries. By default, it will link to &Qt; and &kde; libraries and generate all the needed object files. Just run make to build, and su -c make install to install. + + +Configure the installed plugins + +Now that the plugin is installed, run the kmdr-plugins program or choose Settings->Configure Plugins from the Editor. The list in this program displays the +plugins that are currently loaded by &kommander;. Add the new plugin to the +list by clicking the Add button in the toolbar and choosing your plugin. +Closing the program saves changes. + + +If you now restart the &kommander; editor, the widgets your new plugin +provides should be available in the menus and toolbars. You can +now use your new widgets in &kommander; dialogs. + + + +Add the widget directly to &kommander; +This section is for &kommander; developers and describes how to add a new widget directly to &kommander;. + +Ironically, this one is more complicated, especially if the widget needs +extra editing methods. +First you create the widget like above. After that you need to register the +widget to the editor and the executor. +To register it inside the editor, add it to editor/widgetdatabase.cpp: + + +... +#include "mywidget.h" +... +void WidgetDatabase::setupDataBase( int id ) +{ + ... + r = new WidgetDatabaseRecord; + r->name = "MyWidgetName"; + r->iconName = "icon.png"; + r->group = widgetGroup( "Kommander" ); + r->toolTip = i18n("My new widget"); + append(r); + ... +} + + +You need to add to the editor/widgetfactory.cpp as well: + + +... +#include "mywidget.h" +... +QWidget *WidgetFactory::createWidget( const QString &className, QWidget *parent, const char *name, bool init, + const QRect *r, Qt::Orientation orient ) +{ + ... + else if (className == "MyWidgetName") + return new MyWidget(parent, name); + ... +} + + +To register to the executor (actually to the plugin system), add this to +widgets/plugin.cpp: + + +KomStdPlugin::KomStdPlugin() +{ + ... + addWidget("MyWidgetName", group, "", new QIconSet(KGlobal::iconLoader()->loadIcon("iconname", KIcon::NoGroup, KIcon::SizeMedium))); + ... +} + +This is similar to how the widget is registered via the plugin system in the +first case. + + + + + diff --git a/doc/kommander/frame.png b/doc/kommander/frame.png new file mode 100644 index 00000000..e9fd684d Binary files /dev/null and b/doc/kommander/frame.png differ diff --git a/doc/kommander/glossary.docbook b/doc/kommander/glossary.docbook new file mode 100644 index 00000000..b8434888 --- /dev/null +++ b/doc/kommander/glossary.docbook @@ -0,0 +1,39 @@ + + + + + + + +Tamara +King +
+tik@acm.org +
 + + + + + + + + +Keywords + +Text Association + + +A piece of text that is associated or bound to a widget's particular state. + + + + +Widget Text + + +Text associated to a widget. This is represented in &kommander; with the special @widgetText. The widget text varies depending on the widget. + + + + + diff --git a/doc/kommander/groupbox.png b/doc/kommander/groupbox.png new file mode 100644 index 00000000..4025b4dc Binary files /dev/null and b/doc/kommander/groupbox.png differ diff --git a/doc/kommander/index.docbook b/doc/kommander/index.docbook new file mode 100644 index 00000000..71582056 --- /dev/null +++ b/doc/kommander/index.docbook @@ -0,0 +1,121 @@ + +Kommander"> + + + + + + + + + + + + + + + + + + &Qt; Designer"> + + + The GIMP"> + IDE"> + PHP"> + PID"> + + +]> + + + + +The &kommander; Handbook + + + +Marc +Britton + +
consume@optushome.com.au
+ + + +Tamara +King + +
tik@acm.org
+ + + +Eric +Laffoon + +
eric@kdewebdev.org
+ + + +András +Manţia + +
amantia@kde.org
+ + + + + + + + +2008 +&kommander; Development Team + + +&FDLNotice; + + + +2008-02-12 +3.2.95 + + + + +These docs have been partially complete for years, but not always available or easy to find. Since around 2002 little spurts of effort on &kommander; have produced dramtic results. &kommander; is a new approach to development and there have been modifications in approach and features. Consequently much of this documentation is out of date, however still useful due to legacy support. Please refer to our web site at http://kommander.kdewebdev.org for up to date information, news on KDE4 development, new tools, plugins, tips and tutorials. + +&kommander; is a set of tools that allow you to create dynamic &GUI; windows that has been used as a front end for command line programs, database front ends, simple program extentions and much more. The best part of it all? You aren't required to write a single line of code! Okay, that was old text... You can actually use the function browser and even with the new parser write almost none of the code. The inherent difference between &kommander; and other &GUI; scripting tools is that &kommander; doesn't care about how the window gets drawn. &kommander; was designed from the GUI down to the language elements and can embrace multiple languages. &kommander; does not use scripting to draw a window on the screen like other &GUI; scripting tools. As Kommander matures it will expose all it's internals to any scripting language people want to enable. We welcome anyone wishing to enhance support for any scripting language. + + + + + + +KDE +Kommander +Quanta + + + + +&introduction; +&basics; +&commands; +&parser; +&extending; +&translating; +&tutorials; +&q-and-a; +&credits; +&installation; +&glossary; + + \ No newline at end of file diff --git a/doc/kommander/installation.docbook b/doc/kommander/installation.docbook new file mode 100644 index 00000000..707df7a0 --- /dev/null +++ b/doc/kommander/installation.docbook @@ -0,0 +1,50 @@ + + + +Installation + + +How to obtain &kommander; + + + +&install.intro.documentation; + +There is a dedicated homepage for &kommander; at http://kommander.kdewebdev.org. + + + + +Requirements + + + +&kommander; requires the latest version of &kde; 3.x series, currently 3.5.9. It might work with previous 3.5.x versions, but this was not tested throughfully. + + + + + +Compilation and Installation + + + + + +&install.compile.documentation; + + + + diff --git a/doc/kommander/interface.png b/doc/kommander/interface.png new file mode 100644 index 00000000..3cae0ef4 Binary files /dev/null and b/doc/kommander/interface.png differ diff --git a/doc/kommander/introduction.docbook b/doc/kommander/introduction.docbook new file mode 100644 index 00000000..7b40475a --- /dev/null +++ b/doc/kommander/introduction.docbook @@ -0,0 +1,134 @@ + + + + +Introduction + + +Eric +Laffoon + +
sequitur@kde.org
+ + + + + + + + +Introduction + + +&kommander; is a visual dialog building tool which can be used to create +full mainwindow applications, provided the window is initially created in Qt Designer +or from a template in &kommander;. The primary objective is to create as much +functionality as possible with the absolute minimum use of scripting. This is +provided by the following features: + +Please note this document includes legacy documentation for compatibility reasons. In a nutshell &kommander; offers extremely rapid development and extensive abilities and capabilities. Following is a new list, followed by the legacy content. + + + +Capable internal scripting - &kommander; now offers nested logic structures, simple arrays and useful functions + + +Function Browsers - One never need know exact syntax for any function or command, just click the button and point and click your way to a functional program. Even the project lead finds it easier than typos much of the time. + + +Extensive widgets - &kommander; now has a tree/detail widget, spreadsheet like table widget, font dialog, color dialog, about dialog, timer, tab widgets, toolbox, popup menus, date picker and a lot more. + + +Plugins - &kommander; can run easy to create plugins. Plugins as of this writing are a database plugin offering a set of non visual tools, an HTTP plugin offering HTTPS and access to password protected areas and a KPart loader. + + +Scripting language support - The ability to run multiple scripting language in &kommander; scripts, inside your dialog + + +KPart creation - the ability to make your own plugins... and stranger yet you can even make a &kommander; window load a dialog as a KPart and directly access it with &kommander; functions! + + +Look for documentation on tips and tricks like how to make &kommander; fake programming techniques like including a file, creating and using custom widgets, making collapsable panels in windows and other unexpected tricks. Below is our legacy list. + + + +Specials are prefaced with an @ like @widgetText. The offer +special features like the value of a widget, functions, aliases, global +variables and such. + + +&DCOP; integration allows &kommander; dialogs to control and be +controlled in interactions with other &kde; applications. It is a very powerful +feature! + +Signals and Slots is a little less intuitive to a new user. It is +under review for how we process things in the first major release. These +offer a limited event model for when a button is pushed or a widget is +changed. Combined with Population Text it is rather powerful. + + + +The central key feature of &kommander; dialogs is that you can bind text +(&kommander; Text) to a widget. So if you have @widget1 and @widget2 and +they are line edits you can set &kommander; to show their contents by +entering @widgetText in their &kommander; Text area. Then enter hello in +@widget1 and world in @widget2. A button can have the string +My first @widget1 @widget2 program in &kommander; +If you run this dialog from a console it will output +My first hello world program in &kommander; + + + +Hopefully you begin to see a small glimmering of the potential. &kommander; +enables a much faster design model for simple applications because if allows +you to stop thinking so much about language and revert to the more basic and +natural conceptual model. In computers language is a means to define concepts +and as such it is a layer between concept and implementation that can impede +progress with minutia. &kommander; seeks to minimize that layer. + + + +&kommander; also seeks to build on standards. It is built on the &Qt; Designer +framework and creates *.ui files which it renames to *.kmdr. It can easily +import any &kde; widget and this can be done without having to rebuild +&kommander;, by using plugins. + + + +&kommander;'s other significant factor is how it addresses the requirements of +language. Computer languages can be wonderful things but they tend to have +their own dogmas and zealots often seeking to provide an advance to &GUI; +design in an integrated development environment. Ironically the acceptance +of such &IDE;s is limited by the number of people willing to adopt a new new +language to gain access to a desired feature. It is really not reasonable to +expect people to need to change over to a dozen languages to access various +feature sets. By being language neutral and allowing a &kommander; dialog to be +extended by using any scripting language &kommander; positions itself in a +unique position for wide spread adoption. Multiple script languages can be +used in a single dialog and applications can be taken over by people using +a different language than the original developer and gradually converting +and extending it. New widgets and features can be instantly leveraged by all +available languages. + + + +We hope that &kommander; begins to get the developer support and recognition +required to achieve the potential it offers. Our end goal is to make &kommander; +useful for novice users to extend and merge their applications. At the same +time it should become a good prototyping tool. Also it opens the door to the +promise of open source in a new way. We know that people can extend our GPL'd +programs, but the fact remains very few have the skills. With &kommander; those +numbers see a huge multiplier! Some applications may be most logical as a +&kommander; application. We already use it in areas we want to allow +extensibility in &quantaplus;. + + + +We hope you enjoy &kommander;. Please help us with bug reports and example +dialogs, as well as any requests you may have. You can join our user list +for help developing &kommander; applications. + + +Best Regards from the &kommander; development team! + + diff --git a/doc/kommander/kfontcombo.png b/doc/kommander/kfontcombo.png new file mode 100644 index 00000000..87835d6c Binary files /dev/null and b/doc/kommander/kfontcombo.png differ diff --git a/doc/kommander/kommander.png b/doc/kommander/kommander.png new file mode 100644 index 00000000..f14697d6 Binary files /dev/null and b/doc/kommander/kommander.png differ diff --git a/doc/kommander/konsole.png b/doc/kommander/konsole.png new file mode 100644 index 00000000..3e60f289 Binary files /dev/null and b/doc/kommander/konsole.png differ diff --git a/doc/kommander/label.png b/doc/kommander/label.png new file mode 100644 index 00000000..5d7d7b4c Binary files /dev/null and b/doc/kommander/label.png differ diff --git a/doc/kommander/lineedit.png b/doc/kommander/lineedit.png new file mode 100644 index 00000000..dafdfdf3 Binary files /dev/null and b/doc/kommander/lineedit.png differ diff --git a/doc/kommander/listbox.png b/doc/kommander/listbox.png new file mode 100644 index 00000000..d467fc9f Binary files /dev/null and b/doc/kommander/listbox.png differ diff --git a/doc/kommander/listview.png b/doc/kommander/listview.png new file mode 100644 index 00000000..d71cc1c9 Binary files /dev/null and b/doc/kommander/listview.png differ diff --git a/doc/kommander/multilineedit.png b/doc/kommander/multilineedit.png new file mode 100644 index 00000000..e7f6db94 Binary files /dev/null and b/doc/kommander/multilineedit.png differ diff --git a/doc/kommander/parser.docbook b/doc/kommander/parser.docbook new file mode 100644 index 00000000..a008c431 --- /dev/null +++ b/doc/kommander/parser.docbook @@ -0,0 +1,751 @@ + + + + +&kommander; New Parser + + +Michal + +Rudolf + +
mrudolf@kdewebdev.org
+ + + +Eric + +Laffoon + +
eric@kdewebdev.org
+ + + + + +2005-2008 +Michal Rudolf +Eric Laffoon + +&FDLNotice; + + +New Parser Documentation + +The new parser was introduced in &kommander; with version 1.2, released with +KDE 3.4. This document was originally released to show all the features of new parser. +As of &kommander; 1.3, released with KDE 3.5.9, the new parser is now the default, except for MainWindow applications created in &Qt; Designer. Because +the new parser is so much richer in ability, overcomes the limitations of nesting in the +old parser and adds so many new features we strongly recommend using it. + + +&kommander; itself will not be described here. Please refer to other documents to +see what is &kommander; for, how to create dialogs and how to manipulate widgets +on runtime. + + + +Old parser + +Here we compare the two parsers. While we advocate the new one for most purposes the old one is still +supported and useful, particularly when working with other scripting languages. + + + +Old parser + +The old parser was in fact macro parser. Only strings beginning with @ were +recognized, locally parsed and expanded. + +@LineEdit1.setText(@ListBox.selection) + + + + +All the underlying functionality (local variables, expressions, file manipulation) +had to be done in another scripting language, such as Bash. While the intent with &kommander; is to support +all other scripting languages, and this is presently possible to some degree, there +was a need for a fast, native scripting language that was assured to be portable. +The biggest problem with the old parser is that the &kommander; specials are evaluated before the code is passed to the scripting language, making them impossible to use in loops and conditions. + +The developers considered bash slow and not friendly to new users, and the old parser +had been initially bash calling DCOP. The paradox for &kommander; being language neutral +resulted in a need to do more than just functions natively. + + + + +New parser + +The new parser is a full parser. It parses the whole script, not just functions. As we were interested +in GUI interaction, not the proliferation of scripting languages, we made compromises. +As a result you should find &kommander;'s scripting to be capable for most basic tasks +and natural and easy to use. There is also the Function Browser, which will help you +assemble statements. The Function Browser is intended to make &kommander; accessible to complete novice +programmers. It is similar to what you would find in KSpread to help you choose a function +and fill in the parameters. +If you want enhanced functionality found in other languages you can include +them in &kommander; script objects headed with a shebang. While in these scripts the Function +Browser will help you insert references to widgets. Just remember when using this functionality +that the parser makes one pass for the old parser functions and one pass for your script. So if you +try to change something in a widget and read it in the middle of a script you may not get what you expect. + +#!/usr/bin/php + + +The following feature list is from version 1.2 + +local and global variables and associative arrays +numerical expressions +string manipulation +various structure commands: if, while, for, foreach +most functions from old parser +direct widget manipulation +many additional functions +decent execution speed +receive parameters from signals in script slots + +This list is from version 1.3 + +pass parameters and receive them with script execute calls +return a value from a script +create widgets on the fly +connect signals and slots on the fly +use a variable alias for a widget name +simple indexed array functions +directly access a widgets slots + + + + +Invoking new parser + +To enable new parser, set useInternalParser property of the dialog to +true. You can also enable new parser in a single script by putting + +#!kommander + +on the first line of the script. Also note if you are using another scripting language in +a script with a shebang that &kommander; automatically enables the old parser for interacting +with the dialog. + +#!/bin/bash +echo @Self.item(0) +# returns first parameter passed to script +# echo $returnvalue passes back to calling script + + + + + + +New Parser Features + + +Types + +Each value is of one of three types: string, integer or double. Type conversion is +automatic and chooses most appropriate type (for example, if you add double to integer, +result will be double). If one of the values is string, result will be string too. + +Places you can get into trouble here are getting a numerical value from a widget +and trying to perform a mathematical function on it. Since &kommander; uses + +to concatonate two strings of text it can treat LineEdit1.text + 2 as +22 instead of 2. See the conversion functions in +String functions to avoid problems. + + + + +Expressions + +The following mathematical operators are supported: +, -, *, mod, . Standard brackets +are of course supported as well. + + + +All kinds of comparisons are supported: <, >, <=, +>=, ==, !=. Instead of +!= you can also use <>. +Also, logical operators and, or, not +are supported, as well as their C equivalents (&&, ||, !). + + + +For strings you can use + operator for string concatenation. + + + +Some examples of valid expressions: + +2+3 +-5 * (2 - 13 mod 3) +"This list has " + 12 + "items." + + + + + +Variables + +Variables don't need to be declared. Once you use variable, it is considered declared. +Type of a variable is recognized automatically and can be changed later. + + + +Associative arrays are supported as well. They map string keys onto values of any type. To declare +such array, you can just add some element to it, for example: A["Quanta"] = "Web editor". +Arrays are also handled by foreach command and +array functions. + + + +Local and global variables are supported. Global variables are marked by leading underscore. +So, myVar is a local variable, but _myVar is global. The same applies +to arrays. + + + +a = 5 +b = 2 * 5 - (a + 1) +c = "[Item " + b + "]" +d["MyKey"] = "MyValue" +d["MyKey2"] = 5 + + + +Using variables for widgets works much as you would expect. This is useful when looping widgets into a table. + + + +for i=0 to 10 do + mycombo = "ComboTable"+i + createWidget(mycombo, "ComboBox", "Form1") +end + + + + +Comments + +You can use comments in &kommander; using the two traditional program language comment forms for line comments. For those users who are new to programming wondering what traditional form? see below. You can copy and paste the text below into a button or dialog initialization and see how comments behave in action. + + +// this is a comment for one line +message_info("Hello World") //traditional first program +// the above comment also ignored - the messagebox is not +# this is also a comment +message_info("This message will show") + + +Using the following multi-line comment will not work and will cause the rest of the widget execution to fail. + + +/* +Hi, I was supposed to be a comment +None of the script after this will execute +DON'T USE THIS TYPE OF COMMENT IN KOMMANDER! +*/ + + + + +Built in Globals + +&kommander; has some built in globals you may find handy. + + + +_ARGS - the argument string passed to the dialog on opening + + +_ARGCOUNT - the count of arguments passed. These can be retrieved as ARG1 to ARGn where n is the total number of args passed + + +_KDDIR - the directory from which the dialog was run. &kommander; will default to your home directory, or a directory change if asked for it's current directory. This is useful for saving and reading files with the &kommander; file. + + +_NAME - there is no reason to use this so don't + + +_PID - the process id the current dialog is being run from - also available as just pid Avoid using this name for your variables! + + +_VERSION - this is handy if you want to display the version of &kommander; that is running + + + + +Passing arguments in &kommander; +You can pass arguments via script parameters, signals and slots, command line parameters and DCOP. Let's look at scripts. Call your script like: +result = ScriptObject1.execute("Hello World") +debug(result) +Inside your script you might have the following +var = str_upper(Self.Item(0)) +return(var) +Now you will get a return in your Stderr message log of HELLO WORLD + +Receiving a signal connected to a script slot works the same way. Self.Item(0) is parameter one and so on. You can retrieve the count of arguments passed with ScriptObject.count. + +Command line parameters allow for named or unnamed arguments. Unnamed look like +kmdr-executor myprog.kmdr 100 red +Where you will find _ARG1 = 100 and _ARG2 = red. One quirk is passing strings with spaces as an argument means they need to be quoted. Using the dialog command complicates matters as the entire argument string must pass as one string, meaning in quotes. +dialog("mydialog.kmdr", 100+" \"Hello World\"") +This returns _ARG1 = 100 and _ARG2 = Hello World. Without the escaped quotes you would have _ARG2 = Hello and _ARG3 = World. Using Named Parameters is rather nice and potentially less confusing. +dialog("mydialog.kmdr", "xcount=100 xquote=Hello world") +And now you access those with _xcount and _xquote global variables. + + +DCOP can be complex, which is why we recommend using the tools we develop to enable creating DCOP for remote &kommander; dialogs with something like a function browser. Here is an example DCOP call issued from a dialog opened from a parent &kommander; window. Since it knows who its parent is it can send information back while it is open and freely access all its parent's functionality with the exception of slots. Of course that can be done internally with a script which can be called externally, so in practice there is no limit to what can be done. +dcop("kmdr-executor-"+parentPid, "KommanderIf", "setText(QString,QString)", "StatusBar8", "Hello") +Let's look at this piece by piece. First of all we add parentPid to "kmdr-executor-" as we make no assumption a &kommander; window was the caller. You could use this with Quanta or KSpread or whatever. Next we are addressing KommanderIf, which is a nice interface for end users which has been cleaned up. We hope eventually as KDE moves from DCOP to DBUS on KDE4 that more applications adopt a nice interface for integration. The next parameter, "setText(QString,QString)" is important because it prototypes the parameters allowed. Otherwise &kommander; could not validate the call. So without a definition of the DCOP call being used you will get an error. The remaining parameters are of course what is being passed. We recommend you look at applications with kdcop to see how this works and practice dcop calls from the shell to get your syntax right. + + + + + + +Commands + +Various structure commands are supported. They can be freely nested. + + + +There are also three special commands: exit, break and continue. +The first one ends script execution and returns. The second exits current block (while, +for or foreach and the third exits just a current step, restarting +from the beginning of the loop. + + + + +if + +Command if has following syntax: + + + +if condition then +code elseif condition +then code else +code endif + + + +Both elseif and else parts are optional. Condition +is any expression. Code is executed if condition is true. That means: + +non-zero for integers and double +non-empty for strings + + + + +if a * 2 > 7 then + b = 1 +elseif a < 0 then + b = 2 +elseif + b = 0 +endif + + + + +while + +while condition do +code end + + + +Condition is recalculated each time loop is executed. + +while i < 15 do + i = i + a +end + + + + + + + +for + +Command for has following syntax: + + + +for variable = +start value to end value +step expression do +code end + + + +Loop is executed starting from start value and it is ended when variable's value is +bigger then end value. If step part is specified, on each step +variable's value is increased by given value instead of 1. + +foreach i = 1 to 20 step 5 do + a = a + 2 * i +end + + + + + +foreach + +Command foreach has following syntax: + + + +for variable in +array do +code end + + + +Loop is executed for each key in given array. In each step variable is assigned the next key from the array. + + +sum = 0 +foreach i in myArray do + sum = sum + myArray[i] +end + + + + + + + +Functions + +Most old parser functions are supported by new parser. Also, some new functions were added. + + + + +String functions +String functions are the same as in old parser, the only difference is that their names +are preceeded by str_ instead of @String. + + + +str_length(string) - returns length of string + + +str_contains(string, text) - returns 1 if string contains text + + +str_find(string, text, start) - returns position of the first occurrence of text in string; optional start + specifies start of the search + + +str_find(string, text, start) - returns position of the last occurrence of text in string; optional start + specifies start of the search + + +str_left(string, count) - returns first count characters of string + + +str_right(string, count) - returns last count characters of string + + +str_right(string, start, count) - returns substring of string starting from start and containing count +characters (or everything to the end of the string if last parameter is not specified) + + +str_remove(string, text) - returns string with all substrings equal to text removed + + +str_replace(string, text, text2) - returns string with all substrings equal to text replaced with text2 + + +str_lower(string) - returns string converted to lowercase + + +str_upper(string) - returns string converted to uppercase + + +str_section(string, separator, start, +end) - returns substring containing appropriate sections of string determined +by separator; if no end is given, single start section is returned + + +str_args(string, ...) - returns string with %1, %2, %3 replaced with following parameters. + + +str_isnumber(string) - returns 1 if string is a valid number + + +str_isempty(string) - returns 1 if string is empty + + +str_toint(string, default) - returns string converted to integer; if conversion is not possible, optional default value is returned + + +str_todouble(string, default) - returns string converted to double; if conversion is not possible, optional default value is returned + + + + + +&kommander; functions + +Most &kommander; functions are supported; some (such as expr) +were obsoleted by new parser and are not available. + + + + +debug(string, ...) - writes all parameters on stderr + + +echo(string, ...) - writes all parameters on stdout + + +dcop(string, ...) - calls DCOP function + + +exec(string, shell) - executes external program +(using optional shell); block the execution of the current dialog until the program passed as the parameter exits; returns output of that program + + +i18n(string) - marks string for future translation + + +env(string) - returns a value of environmental variable + + +readSetting(key, default) - returns a value stored in config +file with given key; if there is no such value default is returned + + +writeSetting(key, value) - writes pair +key and value in config file + + +New in &kommander; 1.3 + + +execBackground(string, shell) - executes external program +(using optional shell) in the background, without blocking the current dialog; contrary to the above exec function, it will not return the output of the program. + + +return(value) - returns a value to the calling object (script, button...) + + +createWidget(widgetname, widgettype, parent) - creates a new widget. You can then place it in a table or toolbox, for example and use mywidget.show(true) to make it visible. If you are putting an new widget on the form you need to consider layout issues. &kommander; will not create layouts on the fly or edit pixel by pixel positioning (in most cases). This is confusing even in C++ development. We recommend you use a groupbox and do a layout in the dialog +for best control. + + +connect(sender, signal, receiver, slot) - connect a widget signal to a widget slot. See the connection dialog and select similar widgets for possibilities. If for instance a signal looks like looks like execute(const QString&) that is exactly what must be in quotes there. + + +disconnect(sender, signal, receiver, slot) - undo the connection as listed above. Again, exact syntax is essential. + + +widgetExists(widgetname) - remember you can use a variable name to reference a widget now. Use this when accessing created widgets to insure they are there. Calling a non-existant widget obviously will throw an error. + + + + + +Array functions + +Most array functions are supported; some (such as value) +were obsoleted by new parser and are not available. The only difference is that their names +are preceeded by array_ instead of @Array. + + +Due to parser limitation, name of array has to be specified as string now; for example +array_count("MyArray"). + + + +array_clear(array) - removes all elements from array + + +array_count(array) - returns number of elements in array + + +array_keys(array) - returns string containing EOL-separated keys of array - note that if you had imported a scalar (keys without values, see below for an example) into an array with &kommander; you would not be able to access it with array_values("myarray") as you might think (since it seems to only have values) but would instead need to use array_keys("myarray"). You might find a better choice for this is to use the new indexed arrays described below. + + +array_values(array) - returns string containing EOL-separated values of array + + +array_tostring(array) - returns string containing whole array +as EOL-separated pairs containing key and value separated with TAB character + + +array_fromstring(array, string) - reads array from string (usually provided by array_tostring function) + + +array_remove(array, key) - removes item with key +key from array + + +Here is an example for array manipulation: + +array_fromstring("myArray", "1\tA\nsecond\tB\n3\tC") +foreach key in myArray do + debug("myArray[" + key + "]= " + myArray[key]) +end + +This will print out the following to the stderr. It is visible that there is no guarantee about the order of array elements, as well that the keys are strings, not numbers. + +myArray[1]= A +myArray[3]= C +myArray[second]= B + +Another example for keyless arrays: + +array_fromstring("myArray", "A\nB\nC") +foreach key in myArray do + debug(key) +end +debug("Array elements:\n" + array_keys("myArray")) + +This results in: + +A +B +C +Array elements: +A +B +C + + +New in &kommander; 1.3 + + +array_indexedFromString(array, string, separator) - this compensates for &kommander; not having indexed arrays. it creates an array with a zero based sequential index. Remember to use quotes on the array name and any strings not represented by a variable. The separator argument is optional and defaults to "\t" [TAB] which is used to separate fields reading and writing tables, arrays or detail widgets. Remember this array index does not enforce any rules on its self. It is just like you created it with a for loop, just more convenient. + + +array_indexedInsertElements(array, key, string, separator) - this function is part of the indexed array suite and enables you to insert elements in your array while maintaining an index that is sequential, contiguous and unique. Set the index key to start at and the text string and how it is separated. The elements will be added shifting all the index numbers after by the number added. + + +array_indexedRemoveElements(array, key start, number) - this enables you to remove elements from an indexed array and avoid gaps in your index. Specify the key to start at and optionally how many to remove. The default is one. You will end up with a re-indexed array less the removed elements. + + +array_indexedToString(array, separator) - this enables you to convert your indexed array back into a string, particularly useful for detail widgets. For instance if you are displaying a database query result in TreeWidget1 and it has six columns you can use TreeWidget1.selection to get the selected row. it will be separated by tabs and you could look at a the fifth element by using str_section(TreeWidget1.selection, "\t", 4) (remember it is zero based). That's nice for reading a value, but if you want to change it you can see you have a lot more work to do. After you split that string you have to reassemble with val1+"\t"+val2... Using indexed arrays you could edit that fifth element like so... + +idx = TreeWidget1.currentItem +array_indexedFromString("z", TreeWidget1.selection) +z[4] = "new value" +TreeWidget1.removeItem(idx) +TreeWidget1.insertItem(array_indexedToString("z"), idx) + +Note that only two short lines were added to accomplish this! This was very welcome for database use. + + + + + + +File functions + +All file functions are supported, the only difference is that their names +are preceeded by file_ instead of @File. + + + + +file_read(name) - returns content of file name + + +file_write(name, ...) - writes all arguments +to file name + + +file_append(name, ...) - appends all arguments +to file name + + + + + + +Input functions + +These functions show some dialog allowing user to enter some value. They are accessible in the old parser using @Input.. For most functions all parameters are optional, exception is +input_text which requires 2 parameters and input_value which requires 5 parameters. + + + + +input_color(caption, default) - returns color in #RRGGBB format + + +input_text(caption, label, default) - returns text entered by user + + +input_value(caption, label, default, +min, max, step) - returns value entered by user + + +input_directory(startdir, filter, caption) - returns directory selected by user + + +input_openfile(caption, label, default) - returns existing file entered by user + + +input_savefile(caption, label, default) - returns file entered by user (if file exists, confirmation will be required) + + +input_openfiles(caption, label, default) - returns string of EOL-separated existing files entered by user + + + + + + +Message functions + +These functions show some message for user or ask user to confirm some action. In the old parser use @Message. instead. + + + + +message_info(text, caption) - shows information text + + +message_error(text, caption) - shows error text + + +message_warning(text, caption, button1, +button2, button3) - shows question with warning and up to three buttons; number +of chosen button is returned; if no button names are specified, Yes and No will be displayed + + +message_question(text, caption, button1, +button2, button3) - shows question and up to three buttons; number +of chosen button is returned; if no button names are specified, Yes and No will be displayed + + + + + + + + diff --git a/doc/kommander/pixlabel.png b/doc/kommander/pixlabel.png new file mode 100644 index 00000000..32b90d82 Binary files /dev/null and b/doc/kommander/pixlabel.png differ diff --git a/doc/kommander/progress.png b/doc/kommander/progress.png new file mode 100644 index 00000000..29416702 Binary files /dev/null and b/doc/kommander/progress.png differ diff --git a/doc/kommander/pushbutton.png b/doc/kommander/pushbutton.png new file mode 100644 index 00000000..61f779ce Binary files /dev/null and b/doc/kommander/pushbutton.png differ diff --git a/doc/kommander/q-and-a.docbook b/doc/kommander/q-and-a.docbook new file mode 100644 index 00000000..2b76331c --- /dev/null +++ b/doc/kommander/q-and-a.docbook @@ -0,0 +1,11 @@ + + + + +Questions and Answers + + +Questions and Answers +The list of Frequently Asked Questions can be found on our home page. + + diff --git a/doc/kommander/radiobutton.png b/doc/kommander/radiobutton.png new file mode 100644 index 00000000..10c1d8c3 Binary files /dev/null and b/doc/kommander/radiobutton.png differ diff --git a/doc/kommander/richtextedit.png b/doc/kommander/richtextedit.png new file mode 100644 index 00000000..73573a8a Binary files /dev/null and b/doc/kommander/richtextedit.png differ diff --git a/doc/kommander/shadow.png b/doc/kommander/shadow.png new file mode 100644 index 00000000..37c44694 Binary files /dev/null and b/doc/kommander/shadow.png differ diff --git a/doc/kommander/shellscript.png b/doc/kommander/shellscript.png new file mode 100644 index 00000000..59de8cfe Binary files /dev/null and b/doc/kommander/shellscript.png differ diff --git a/doc/kommander/slider.png b/doc/kommander/slider.png new file mode 100644 index 00000000..525bd1ca Binary files /dev/null and b/doc/kommander/slider.png differ diff --git a/doc/kommander/specials.docbook b/doc/kommander/specials.docbook new file mode 100644 index 00000000..ddd3e3b6 --- /dev/null +++ b/doc/kommander/specials.docbook @@ -0,0 +1,371 @@ + + + + +Specials and Built-in Global Variables + + +Specials and Built-in Global Variables + + +Specials are functions that are processed by &kommander;. You should be aware that whe using the old style parser all &kommander; specials will be executed first and then the script will be executed. In most cases this is not a problem, but in a few (mostly in loops, conditions) it is. + +The below list might be slightly outdated. It is recommended to use the Function Browser to get help about the available functions. +The Function Browser can be reached from inside the Kommander Text editor, by clicking the Function... button. + + + + + +@dcop(appId, object, function, arguments) + + +Make a &DCOP; call. @dcop(kmail, KMailIface, checkMail(), ) + + + + + +@dcopid + + +The &DCOP; id of the process. (kmdr-executor-@pid) + + + + + +@dialog(dialog[,parameters]) + + +Launches the specified Kommander dialog. Dialog is sought in dialog directory and in current directory - in that order. This prepends the call to the executor and sets the default directory to the one the Kommander application is in. Parameters can be passed in the usual Unix way or you can pass named parameters like variable=value. You can then find passed parameters in the global pool. @global(variable) would return value. + + + + + +@env(environmentVariable) + + +Expands to the specified environment variable. @env(PWD) expands to $PWD. Remember that $ is part of the shell and shouldn't be used. + + + + + +@exec(command) + + +returns the output of executing the specified command. @exec(ls -l). + + + + + +@execBegin ... @execEnd + + +same as @exec, but supports shebang and multiline scripts. This serves for various scripting languages either by decalring them or using a shebang. + + +@execBegin(php) +@execBegin(#!/usr/bin/php) + +The first one uses the name of the PHP executable. &kommander; searches PATH for php and if it is not found looks to see if it is registered with &kommander; in a location outside of your path. If not it tells the user it cannot be found. The second examples uses the classic shebang which can have some benefits and also problems. If you have a beta copy of PHP5, for instance, in /usr/local/bin which would not be found because it would find on in /usr/bin this is useful. If, however, you distribute the dialog to someone who has PHP in /usr/local/bin only it will not be found with the shebang used. So using shebangs is cautioned and using the executable is recommenede if you are sharing files. + + + + +@global(variable) + +expands to the value of the specified global variable. + + + + + +@null + +Returns null. Now that Kommander checks for empty widgetText on execution this will prevent erroneous errors in the case of an unset state on a widget. + + + + +@parentPid + + +The &PID; of the parent process. + + + + + +@pid + + +The &PID; of the process. + + + + + +@readSetting(key, defaultValue) + + +reads a value from kommanderrc. See also @writeSetting. + + + + + +@selectedWidgetText + + +the selected content in a widget that can show more than one value, like list widgets + + + + + +@setGlobal(variable, value) + + +Sets the global variable to the specified value. + + + + + +@widgetText + + +the content of a widget + + + + + +@writeSetting(key, value) + + +write value to kommanderrc. All &kommander; dialogs share the same kommanderc file, each one will have its own section inside it. + + + + + + +Array Function Group + + + +@Array.values(array) + +Returns an EOL-separated list of all values in the array. Can be used to walk through an array. + + + + +@Array.keys(array) + +Returns an EOL-separated list of all keys in the array. + + + + +@Array.setValue(array, key, value) + +Sets a key and value for an element of an array. If no array exists it is created. + + + + +@Array.clear(array) + +Remove all elements from the array. + + + + +@Array.count(array) + +Return number of elements in the array. + + + + +@Array.value(array,key) + +Return the value associated with the given key. + + + + +@Array.remove(array,key) + +Remove element with the given key from the array. + + + + +@Array.fromString(array,string) + +Add all elements in the string to the array. String should have key\tvalue\n format." + + + + +@Array.toString(array,string) + +"Return all elements in the array in key\tvalue\n format." + + + + + + + +File Function Group + + + +@File.read(file) + +Return content of the given file. + + + + +@File.write(filestring) + +Write given string to a file. + + + + +@File.append(filestring) + +Append given string to the end of a file. + + + + + + + +String Function Group + + + +@String.length(string) + +Return number of chars in the string. + + + + +@String.contains(string,substring) + +Check if the string contains given substring. + + + + +@String.find(string) + +Return position of a substring in the string, or -1 if it isn't found." +This will have an optional integer start postion for find next uses in Alpha 6. + + + + +@String.left(string, int) + +Return first n chars of the string. + + + + +@String.right(string, int) + +Return last n chars of the string. + + + + +@String.mid(string, int start, int end) + +Return substring of the string, starting from given position. + + + + +@String.remove(string, substring) + +Remove all occurences of a given substring. + + + + +@String.replace(string, substring find, substring replace) + +Replace all occurences of a given substring with a given replacement. + + + + +@String.upper(string) + +Convert the string to uppercase. + + + + +@String.lower(string) + +Convert the string to lowercase. + + + + +@String.compare(string, string) + +Compare two strings. Return 0 if they are equal, -1 if the first one is lower, 1 if the first one is higher + + + + +@String.isEmpty(string) + +Check if string is empty. + + + + +@String.isNumber(string) + +Check if string is a valid number. + + + + + + + +Built-in Globals +Built-in globals are accessed just like regular global variables with @global. + + +@global(_KDDIR) + +The directory the current dialog is in. + + + +@global(_NAME) +The name of the dialog + + + + + diff --git a/doc/kommander/spinbox.png b/doc/kommander/spinbox.png new file mode 100644 index 00000000..7ae20630 Binary files /dev/null and b/doc/kommander/spinbox.png differ diff --git a/doc/kommander/statusbar.png b/doc/kommander/statusbar.png new file mode 100644 index 00000000..ac08552d Binary files /dev/null and b/doc/kommander/statusbar.png differ diff --git a/doc/kommander/table.png b/doc/kommander/table.png new file mode 100644 index 00000000..4bbd9c2d Binary files /dev/null and b/doc/kommander/table.png differ diff --git a/doc/kommander/tabwidget.png b/doc/kommander/tabwidget.png new file mode 100644 index 00000000..1254bb63 Binary files /dev/null and b/doc/kommander/tabwidget.png differ diff --git a/doc/kommander/textbrowser.png b/doc/kommander/textbrowser.png new file mode 100644 index 00000000..090e2f84 Binary files /dev/null and b/doc/kommander/textbrowser.png differ diff --git a/doc/kommander/textedit.png b/doc/kommander/textedit.png new file mode 100644 index 00000000..823d0818 Binary files /dev/null and b/doc/kommander/textedit.png differ diff --git a/doc/kommander/timer.png b/doc/kommander/timer.png new file mode 100644 index 00000000..e2e17452 Binary files /dev/null and b/doc/kommander/timer.png differ diff --git a/doc/kommander/toolbox.png b/doc/kommander/toolbox.png new file mode 100644 index 00000000..2ab71dc7 Binary files /dev/null and b/doc/kommander/toolbox.png differ diff --git a/doc/kommander/translating.docbook b/doc/kommander/translating.docbook new file mode 100644 index 00000000..15db90bd --- /dev/null +++ b/doc/kommander/translating.docbook @@ -0,0 +1,72 @@ + + + + + + +András +Mantia +
amantia@kde.org
 + + +Michal +Rudolf +
mrudolf@kdewebdev.org
 + + + + + + +Translating &kommander; dialogs + + +Translating &kommander; dialogs + +&kommander; dialogs can be translated to different languages. The mechanism is similar to the translation of other &kde; applications. The dialog is written in English, the texts that are needed to be translated are specially marked. A tool extracts these strings, another tool can be used to translate them. The translation then can be compiled and installed and the dialog will automatically recognize and use it. + + +Here is a short description about the needed steps to make a dialog translatable and translated it: + +How to prepare dialog to be translated? +Always use @i18n("This is my text") when you use some English text. This marks "This is my text" as a text to be translated. + + +How to extract the messages and create the .po file? + + Use the kmdr2po script to extract the strings. The script is inside the working directory of the source release tarball and should be installed to $KDEDIR/share/apps/kommander/translating as well. + + +Just run: + +kmdr2po <your-kommander-dialog.kmdr> + +An appropriate <your-kommander-dialog.po> file will be created. + + + + +How to translate it? +Use KBabel to translate it. Use msgfmt to compile the translation. Look at http://i18n.kde.org for help on this subject. + + +How to install the translation? +Put the compiled *.mo file either to +$KDEDIR/share/locale/<your language>/LC_MESSAGES/ (will be available globally for all users) +or to +$HOME/.kde/share/locale/<your language>/LC_MESSAGES/ (will be available only for the current user) +directory. + + + + + +To open a different catalog (translation *.mo file) for a dialog, use the -c argument for kmdr-executor. The below example will take the translations from the Quanta translation file: + +kmdr-executor mydialog.kmdr -c quanta + + + + + + diff --git a/doc/kommander/tutorials.docbook b/doc/kommander/tutorials.docbook new file mode 100644 index 00000000..095e9a28 --- /dev/null +++ b/doc/kommander/tutorials.docbook @@ -0,0 +1,380 @@ + + + + +Tips and Tutorials + + +Eric +Laffoon +
+eric@kdewebdev.org +
 + + + + + + + +Tips on use &kommander; +In this section we go beyond listing widgets to actually using &kommander;. If you want to have a good experience you will find this section very helpful. + + +Using the Editor + +At first glance the editor looks pretty obvious, and in many ways it is. Click on the icon to create a new form, then click a widget and click or click and drag on the form. There are the widget handles that will be familiar to anyone who ever put a picture in a word processing document. What is less obvious are the little things. One thing to mention up front is widget naming. Names must be unique and &kommander; employs a naming scheme of the formal widget name and a number unique to that widget type. You can rename a widget and &kommander; will not allow a duplicate name. However if you build a complex dialog and decide to start renaming you're going to have problems. Signals and slots will manage naming for you and any widget you change will be reflected in the signals and slots connections. Unfortunately we never got this feature in the widget functions. So ever call to that widget will be wrong. You could close the dialog and open it in a text editor like KWrite and do find and replace. A better solution is to start out with some idea what kind of descriptive names you want to give to key widgets. It may be a waste of time naming Labels, but scripts and container widgets for data quickly prove a real mistake not to name. You can also set icons for scripts making them even quicker to visually identify. + + + + +Editor Tools + +The first thing you will notice is a properties window, generally docked on the left. Explore this! Here you will find many useful settings for forms and widgets. Some of them would be layout settings, icons, if something is active, text and more. For instance if you put a TreeWidget in a form you can change the default path separator, which is useful if you have data in there. It's easy for a slash to create a sub-item accidentally. Here you will also find selection modes, whether to highlight the whole row in multi column widgets and more. Before you assune something is just how &kommander; is check this. + + +If you play with layouts and lose a widget behind another or off the form the object explorer will come in handy. It's also nice for seeing structure. The next very useful view is the log view which shows stdout and stderr. The error view is indispensable. This is where your debug() commands prints and where you get detailed information. For instance when using the database plugin this gives you additional information with data errors. It also shows you all shell calls and more. The Stdout view lets you see what would go to the shell or an application using this like Quanta. The dialog view is of little use unless you have a lot of dialogs open. The Action view is only active with MainWindow use and in that case it is the only way to add Actions, menu and toolbar items. + + + + +Adding Custom Tools + +&kommander; makes it easy to add custom tools, which you can develop in &kommander;, to the editor. We will be shipping some with &kommander; as well as making some available for download. You can add your own easily. First have a look and see where they are. If they are installed they are on the tools menu below the splitter. The &kommander; menu offers access to widgets. The Custom menu offers access to installed plugins. The Editor menu is where your custom tools go. To manually add a tool first decide if you are going to make it available system wide or just to your desktop. System wide start from the directory KDE is installed in. For your desktop user start in the hidden KDE directory in your home directory, usually ~/kde. From either the path is/share/apps/kmdr-editor/editor/ If the dialog you add needs access to tools or files you can put them in a subdirectory. Whatever &kommander; dialogs you put there will be recognized and added to your menu on startup. Clicking the menu will load the dialog. You will note there is a templates directory there too and you can add templates for new dialogs. + + + + +Included custom tools + +Several tools are included with this release, already installed on the tools meu under editor. More tools are under development for project management, database front end development, code snippets and more. The most imporant and useful tool to look for is the examples dialog. As the editor is no longer under development for KDE3 it cannot insert a dialog in the current editor, but it will open any selected dialog in a new instance of the editor. There are old dialogs from the early days of &kommander;, tutorials from more recent development and the current section showing new features of this release. Looking at these should help. Keep an eye on our web site for more. + + + + +Using Layout + +People love to share &kommander; dialogs. Almost without fail they don't know about laying them out. Make a dialog and then try resizing it and see what happens. Wouldn't it be nice if it behaved like it should instead of leaving your widgets the same? It gets worse when you share it and differences in fonts, monitor size and X pixel resolution conspire to make your masterpiece look like it was put together by a three year old using bubblegum and thumbtacks. Always, always always... Lay out your dialogs! + + +Okay, you're sold you don't want a frustrated email from me asking you to please layout your dialog. How do you do it. There are layout buttons on the toolbar and the context menu. Since &kommander; is based on an older version of Qt Designer you can look at Qt Designer docs and tutorials here. I'm just going to mention a few basics and a few tips. + + +Use the Grid. This will place everything in a best guess location +Remember containers are separate. A TabWidget, GroupBox or layout group has it's own layout. So don't forget the window. +Widgets that are not visible during execution can make layout seem more challenging. What to do with them? I recommend grouping them in their own layour next to or below your main layout. Your visible widgets will simply push these aside and give you a predictable result. +Look at your properties were you can set a widget to expand or do other things as well as minimum and maximum size. A little experimentation will teach you a lot. You can also set a tighter spacing here, + +And now for a few tricks and tips. + +Along with basic layout you can use splitters. When your dialog is running you can drag the splitter up and down or right and left to get a better look at things. It may look like there is a limitation here or it doesn't work. It works and has no limitations. Just make sure to put multiple widgets into two layouts and make sure when you click or right click to get the layout and not just a child widget. You are free to create a maze of splitters as long as you adhere to the rules. +Fake docs are possible! Create a GroupBox and drop widgets on it. Position it in your layout so that when it's invisible other widgets/layouts will expand to take it's place. Now toggle it's visibility with a button or menu. +ToolBox tricks - The Toolbox has an editor bug where you can't add widget panels in the editor without it going nuts. As a result you need to add them at run time. However it looks for one widget and if you want something complex you should use a groupbox and lay it out. then layout your dialog with the groupbox at the outside, even if it goes off the edge of the window. Now load it on initialization into the ToolBox. Your window layout will snap into place. +Layout glitches can occur where widgets set to something like Minimum/Expanding can end up obscured before you complete layout on the window. The layout system will honor your oddness and can be shrunk to obscure scrollbars and more. Make sure all is visible before finishing layout and consider not using minimum in that case. + +For more on this look up the Qt Designer docs for Qt 3.x. + + + +Signals and Slots + +One of the very useful features inherited from Qt Designer was signals and slots. Of course the interface has been redesigned in an attempt to make it friendly to &kommander;. Signals and slots are internal event control for Qt/KDE applications. We try to make it so you don't have to know the difference between C++ data types, but if you use the new function to create connections on the fly it is handy to be able to copy that information from the connection tool. Let's look at what all this means. Something happens in one of you widgets. It could be click on, double clicked, have it's value changed, something selected or a menu could be requested. That is just some of the possible events that would enable a signal to be sent. You may want to change the list in a ListBox if a new selection is made in a ComboBox. That's a useful feature in a sophisticated application and the only way to do it without having to press a button next is to have a signal connected to a slot. That slot could be in a script or button. When the slot receives the signal it goes about doing what it was told. There is a tool to edit these connections. Pay attention when do this as there are a good number of inherited signals and slots. Telling a script which is invisible when the dialog is run to adjust it's size by accident when you meant to execute will have you wondering what happened. + + +To access the connection tool you can open it by right clicking anywhere on the dialog and selecting it. Click the menu and you will see a list of connections made at the bottom. Above that are two lists of signals and slots and above them the respective sender and receiver are selected. An easy way to make connections is visually. Look at the toolbar or the Tools menu. There are three items grouped there. A pointer, signals and slot connections and the tab order or widgets. Selecting this sets connection mode for the curios. Click on your widget to send the signal and drag it to your widget to receive it in a slot. As you do this you will see a line and drop indications on the widget under the mouse. The StatusBar on the Editor will tell you what is being connected. + +In version 1.3 there is a &kommander; function connect() which allows you to connect signals and slots on the fly. This is useful if you just used createWidget. Obviously you can't use the dialog for something &kommander; doesn't yet know exists. Unfortunately there are too many combinations to list so you have to type out signals and slots. These must be typed verbatim or they will fail. This is where the connection tool is handy again. Open it and select two widgets like the two you want to connect and read the connection information. if it says execute(const QString&) that is exactly what you must type. + + + +Slot Functions + +As of version 1.3 &kommander; adds Slot functions. You can see this in the Function Browser, which is uncharacteristicly less than friendly with descriptions here. What &kommander; is doing is reading every slot registered for a given widget and making it available directly. This is very useful. For instance the Table widget doesn't have a default method to auto adjust column width. You may find this annoying, but if you look under slots there it is. The TextEdit is also lacking in built in functions for any real editing, but look under slots and there is anything you could wish for. You may have to reference some docs or just experiment. It is simply too difficult to document every slot available in builtin widgets and plugins. Most slots however are self explanatory. + + + + + +Basic Tutorials + +Most of the information in this section is based on example dialogs some time ago, which unfortunately were not widely available as they were shipped with the source, but not installed. You should find them in your tools menu under examples in the tutorial section. Keep in mind most of these particular examples use the old parser. That is neither good nor bad. Most of the functionality in &kommander; is shared in both parsers. It's just each is particularly suited to do a better job with a given task. As &kommander; now defaults to the new parser you can set either one. Please see the New Parser docs for more information on the two parsers. + + +When examining example dialogs remember to look in the following places to see how things are done. + + +Dialog Initialization - middle click on the dialog face or right click and select &kommander; Text. Here you see what is run when the dialog starts. +Buttons - middle click the button, or right click. Scripts are typically here. +Widgets - some widgets like Timers and Konsoles will hold instructions inside them. +Signals and Slots - this is how Qt/KDE programs internally communicate. + + +The following list of dialogs may be brief so as to focus on where more information is required to explain more complex tasks possible with &kommander;. They were copied from Michal's notes. + + + +Globals +Shows using global and setGlobal &DCOP; calls to provide global variables for script +
+Functions/concepts: +- global +- setGlobal +- changeWidgetText +
+ + + +&DCOP; +Shows how to use both local and external &DCOP; calls to communicate with external application (here: KMail). +
+Functions/concepts: +- external DCOP +- addListItem +- enableWidget +- @selectedWidgetText +- @widgetText +
+ + + +Slots +Shows how to us connections/slot to handle events. Both population and standard slots are used. +Population text was originally developed before &kommander; DCOP, specials and scripting. Given that everything it does can be done in other ways and that it is easy to forget to look here for problems, along with the inherent difference of introducing an additional behavior to explain, this is a deprecated function. It is left in for illustration, however while &kommander; dialogs will be easy to port to KDE4 this feature is not assured to work in the future. Don't use it! +
+standard slots are used. +- slots/connections +- populate() +
+ + + +Settings +Shows how to use @readSetting and @writeSetting functions to write/restore widget content. Also, show how to use populate() slot to initialize widget content. +
+Functions/concepts: +- @readSetting +- @writeSetting +- populate() +- slots/connections +- destroy +
+ + + +Append +Shows how you can append text to TextEdit and how you can use it to display formatted text. See newer examples for how to use slots to edit rich text and new font and color dialogs too. +
+Functions/concepts: +- changeWidetText +- RichTextEdit +
+ + + +Command Line +Shows how you can pass parameters to &kommander; dialog via command line. Also, shows how to change list content and button text. See the section on passing arguments in the new parser for more on this. +
+Functions/concepts: +- command-line arguments +- global +- changeWidgetText +- addListItem +- clearList +
+ + + +Initialize + +Shows how you use 'initialization' to 'destroy' scripts of main dialog to initialize and store some settings. + +
+Functions/concepts: +- initialization +- destroy +- readSetting +- writeSetting +
+ + + +Array + +Shows how to use associative arrays to store and restore information +associated with container items. +
+Functions/concepts: +- @Array functions +
+ + + +Strings + +Shows how to use string-handling functions +Functions/concepts: + +
+- @String functions +- rich text editor +
+ + + +Tree + +Shows how to use tree widget + +
+- tree widget +- FileSelector +- initialization +- env +
+ + + +Widgets + +Shows how to get widget information + +
+- type method +- children method +
+ + + +StatusBar + +Shows how to use statusbar widget + +
+- statusbar widget +- populate +
+ + + +Loop + +Shows how to use internal loops + +
+- for +- forEach +
+ + + +Calc + +Shows how to use @expr function to do some calculations + +
+- expr +- String.replace +
+The @expr() function is no longer required in the new parser as expressions can be directly interpreted anywhere you would logically want to use them. + + + +Picview + +Shows how to use PixmapLabel widget using populate() function + +
+- PixmapLabel +- populate +- FileSelector +- slots/connections +
+ + + +Table + +Shows how to use Table widget + +
+- insertRow +- insertColumn +- currentRow +- currentColumn +- setColumnCaption +- setRowCaption +- removeRow +- removeColumn +
+ + + + + +Current Examples + +These examples reflect the most recent development state of &kommander;. In its current state &kommander; has few limitations for developing small to medium applications. It certainly is not suitable for building a KWord clone, but for a simple editor, database frontend, GUI for commandline programs or any application in the spirit of Unix/Linux small applications it is a good choice. The examples presented here are intended to show the potential as well as how to work around limitations. There are some useful tricks included in these if you want to do a more capable small application with &kommander;. Remember &kommander; is not intended to do everything, but to do most things. For this concession you should be able to build something in &kommander; faster than other alternatives ad add GUI to scripting languages not otherwise supported in KDE. + + +The examples are installed to $KDEDIR/share/apps/kmdr-editor/editor. In case you do not have them there, get from our home page, by downloading the latest release. + + + + +editor-poc.kmdr + +The little dialog that grew into a Mainwindow. As &kommander; does not have a native MainWindow widget it has been assumed it only does dialogs. In fact only dialogs are officially supported... but you can run MainWindows in &kommander;. This is an example editor. If you want to create a MainWindow application in &kommander; just open Qt Designer and make one, save it and rename the *.ui file to a *.kmdr file. Now open it in &kommander; and do what you would do normally. + +As of this writing what is known not to work on the &kommander; side is the settings read and write. There is no Initialize or Destroy section as there is no &kommander; Text, however there are signals for this on the window, so the functionality is intact. On the MainWindow side it is not possible to talk to any actions via DCOP as these are QActions from Designer and KActions are not derived from QActions in KDE 3.x. This means a DCOP call to list actions or set states will not work. It is also not possible to talk to the Statusbar. Also submenus on the menubar and dropdown actions on the Toolbar will not work. Even though this is not a &kommander; widget, or officicially supported, it seems suitable for many small application uses. + +There is a quick help dialog this editor launches that discusses in depth what is happening inside. + + + + +kevaluecombo.kmdr + +&kommander; can be used with databases and has an optional database plugin. One shortcoming is not being able to store key/value pairs in the ComboBox. An ingenious trick was realized for this. It requires only that the content of the ComboBox not be changed unless it is done using the arrays that go with it. As this is commonly used with SQL in small data sets it's quite fast even to reload the whole Combobox. The inherent problem is that &kommander; does not have internally indexed arrays by default. This is compounded by the fact that to accommodate shell commands that return lines separated by newlines &kommander;'s array functions will load what is effectively an array of keys. Such an array can only be accessed with a foreach loop. This is the reason new indexed array functions were added. It is important to remember that these arrays are not self maintaining, but their insert and delete functions will help you. + + +Getting back to the ComboBox, it will return selected text, but it also will return the current index. It does rigidly maintain a contiguous zero based array. That's the key. We loop through a data set with a zero based index counter and create two arrays, as &kommander; also cannot create arrays of arrays. It can however use an array value to represent a key just like any value could. .If you look at the included dialog the code actually managing this is in ScriptObject36. We will extract the key code here. + + +c = ListBox1.count-1 +for i = 0 to c do + array_indexedFromString("x", ListBox1.item(i)) + _a[x[0]] = x[1] + _b[i] = x[0] + ComboBox10.insertItem(_a[_b[i]], i) +end + + +There is more going on, like checking for duplicate keys, but this is the core. You can right click on the ListBox and try menu items. The net result is that it is using keyed index by proxy and returning both the key and the value. Use this code if you want to be 100% certain your key/value relationship is accurate. + + + + +Kpart demo + +As of Kommander 1.3 Kommander automatically makes KParts using the libkommander_part.la. In addition to this there is a KPart plugin which allows Kommander to load plugins. Being curious developers we tried loading a Kommander part into Kommander. Why do that? Why not? The results were interesting and are demonstrated here. One interesting thing is the parent part can directly access all of the child part. While this is handy it has a down side. Any child widget being called with the same name as a parent widget will cause a lock up! In addition to that the DCOP interface is generated all over again for the part which wipes out the parent interface and disables most of the old parser functionality as well as Kommander specific DCOP to the parent. This is too difficult to fix for the remaining life of the KDE3 version. Even with these limitations and cautions this can be useful, if used carefully. The example files to look at this are in the current examples as kpartmwframe.kmdr and kpartpart.kmdr. Remember you will need the KPart plugin to fully run this example. + + +You can also load KMail, KOrganizer and many other KDE applications right into Kommander, of course without the problems. KHTML and KDE's file manager widgets seem not to have some functionality but there is a special KHTML plugin if you really want to incorporate a browser. + + + +passvariables.kmdr + +As of &kommander; 1.3 you can pass and return variables with scripts. This dialog demonstrates that. Look carefully at the content of the buttons. You will see that neither button directly writes to any of the LineEdit boxes receiving text from the script. While one is written directly from the script another is written with the content passed from the button. The third is not written at all but passed back in a return() function where it is received by the button and written. This is also shown on the right side using PHP so you can see how this might work with Python, Ruby, Perl or even a less commonly used language like Rexx. Languages that Speak DCOP can do a lot more in &kommander; too. The point of this demo is the freedom provided. &kommander; does not have functions, yet it does. Create a script, declare some globals if you like, pass some parameters to another script and return a value. For an intentionally simplified GUI scripting tool that is capable behavior. This behavior is only in the new parser and is documented here. + + + + +tableselect.kmdr + +This example demonstrates how to use the new select function in the table widget. It is now possible to get four coordinates to enable a block selection. This also shows how it would have had to be done prior to this function. and how to use the parameters passed to a script. In addition this demonstrates a simple block copy and paste function for a table as well as summation of a block. + + + + + diff --git a/doc/kommander/widgets.docbook b/doc/kommander/widgets.docbook new file mode 100644 index 00000000..fa187cfc --- /dev/null +++ b/doc/kommander/widgets.docbook @@ -0,0 +1,599 @@ + + + + +Widgets + + +Widgets + + +The building blocks of a &kommander; dialog are the widgets. They are like any other widget in the &Qt; and &kde; libraries except they have some extra functionality that allows them to have a text association. Text is associated with a state of the widget or its populate slot. The number of states depends on the widget. If a widget only has one state, that state is called default. + + + +The main dialog has two special states for &kommander; text. They are Initialization and Destroy. These are run when the dialog is initialized and when it is destroyed. These protect against what is know as race problems on open and mean that you do not require any special procedures on close to manage housekeeping. +In case of using a MainWindow based application (created with &Qt; Designer), there are no Initialization and Destroy states, instead the initialize and destroy signals can be used to get information when is the application constructed or closed + + + +Below are the standard &kommander; widgets. Each of them has numerous functions, you can learn about them by looking at the widget functions in the Function Browser. Many of them have signals and slots as well, documentation about these methods can be found in the &Qt; and &kde; API documentation. Each &kommander; widget has a note about its base widget. + + + + + + + + + +Label + + + +A simple widget that contains a piece of text. This widget lets you set a pixmap too. + + +See the QLabel documentation to learn more about text labels in &Qt;. + + + + + + + + + +PixmapLabel + + + +A simple widget that contains an image or text label. The pixmap to display is set in the pixmap property. The text is set in the text property. Only one of these properties can be set at the same time (I think, I can't get the editor to set both at the same time). If scaledContents is set to true the image will be scaled to fit the size of the widget. The format of the text can be set with the textFormat property. + + +See the QLabel documentation to learn more about text labels in &Qt;. + + + + + + + + + + +LineEdit + + + +A LineEdit widget is a one line text editor. It allows the user to enter and modify a single line of text. Initial text for the editor can be set in the text property. The widget can be set to read-only with the readOnly property. There are 3 modes for the widget, Normal, NoEcho, and Password. The mode is set with the echoMode property. + + +LineEdit has one state, default. + + +The widget text for LineEdit is the text contained in the editor. + + +See the KLineEdit documentation to learn more about text labels in &kde;. + + + + + + + + + +TextEdit + + + +A simple multi-line text editor. + + +See the KTextEdit documentation to learn more about multiline text edit in &kde;. + + + + + + + + + +TextBrowser + + + +A simple reach text browser with hyperlink navigation. + + +See the KTextBrowser documentation to learn more about it. + + + + + + + + + +ListBox + + + +A ListBox widget provides a list of selectable items. Normally one or no items are selected. This behavior can be changed with the selectionMode property. Items are added to the ListBox using the edit window. + + +A ListBox has only one state, default. + + +The widget text for a ListBox is the items contained in the ListBox. @selectedWidgetText will return only the items that are currently selected. + + +See the KListBox documentation to learn more about it. + + + + + + + + + +ComboBox + + + +ComboBox is a selection widget that combines a button and a pop-up menu. It shows the user's current choice from a list of options in minimal space. Items are added to the list using the edit window. If the editable property is set to true the user can enter arbitrary strings. + + +ComboBox has one state, default. + + +The widget text for a ComboBox is the text of the selected item. + + +See the KComboBox documentation to learn more about it. + + + + + + + + + +TreeWidget + + + +A widget that provides a list in the form of a tree structure. You can add child items and multi-column data. The current limitation is that you cannot modify columns. To add a child node use / as a separator. To add column data use the escaped tab \t character between columns. + + +See the KListView documentation to learn more about it. + + + + + + + + + + +Table + + + +A table widget that support different widgets in its cells. + + +See the QTable documentation to learn more about it. + + + + + + + + + +ExecButton + + + +A button that when clicked executes its text association. The label on the button is set with the text property. Output from the text association (how to say that) will be echoed to stdout if the writeStdout property is set to true. The button can be the default action for the dialog if the default property is set to true. + + +ExecButton has one state, default. + + +There isn't widget text associated with ExecButton. + + +See the KPushButton documentation to learn more about it. + + + + + + + + + +CloseButton + + + +A button that when clicked, executes its text association and then closes the dialog. The label on the button is set with the text property. Output from the text association (how to say that) will be echoed to stdout if the writeStdout property is set to true. The button can be the default action for the dialog if the default property is set to true. + + +CloseButton has one state, default. + + +There isn't any widget text associated with a CloseButton. + + +See the KPushButton documentation to learn more about it. + + + + + + + + + +Konsole + + + +A widget that captures the output of scripts in a text browser. The default state is executed and the output of those commands (internal or external) are shown in the widget. + + + + + + + + + +FileSelector + + + +The FileSelector widget combines a LineEdit with a button when clicked will present the user with dialog for the selection of files/folders. The file/folder selected is stored in the LineEdit. The type of the FileSelector is set with the selectionType property. Available types are Open, Save, and Directory. Multiple files/folders can be selected if the selectionOpenMutliple property is set to true. A caption for the FileChooser can be set with the selectionCaption property. This is display as the window title of the dialog. If a caption isn't specified, the type of selection will be display in the title. The files displayed in the dialog can be limited using the selectionFilter property. + + +FileSelector has one state, default. + + +The widget text for a FileSelector is the text contained in the LineEdit (the file chosen by the user). + + + + + + + + + +CheckBox + + + +A button that can be checked on and off. It can also be semi-checked if the tristate property is set to true. The label associated with the CheckBox is set in the text property. Setting the checked property will have the CheckBox initially checked. + + +A CheckBox has 3 states, checked, semichecked, and unchecked. + + +The widget text for a CheckBox is the value from the text property. + + +See the KCheckBox documentation to learn more about it. + + + + + + + + + +RadioButton + + + +A button that can be checked or unchecked, usually used in the ButtonGroup to make an exclusive choice. A label associated with the button can be set in the text property. A button can be initialized to checked by setting the checked property to true. If all RadioButtons in a ButtonGroup have the checked property set to true, then the last button will be the one that is checked. + + +RadioButton has 2 states checked and unchecked. + + +There is no widget text associated with a RadioButton. + + +See the KRadioButton documentation to learn more about it. + + + + + + + + + +ButtonGroup + + + +A container to organize buttons into a group. An optional title can be set using the title property. The frame can be adjusted with the lineWidth property. The button group can be set to exclusive by setting the exclusive property to true. This means when one toggle button is clicked all other toggle buttons will be set to off with the exception of radio buttons that are always mutual exclusive even if the group is non-exclusive. Radio buttons can be set to non-exclusive using the radioButtonExclusive property. (I am not so sure that this property actually works.) + +ButtonGroup has one state, default. + +The widget text for a ButtonGroup is the text associations for each of the buttons in the order they appear in the ButtonGroup. + + + + + + + + + +GroupBox + + + +A container widget that holds other widgets. The frame is adjusted with the lineWidth property. A title can be added by setting the title property. + + +GroupBox has one state, default. + + +The widget text for GroupBox is the text associations of each of the widgets it contains combined. They will be in the order they appear inside of the GroupBox. + + + + + + + + + +TabWidget + + + +A widget that provides multiple tabs each may contain other widgets. + + +See the KTabWidget documentation to learn more about it. + + + + + + + + + +SpinBoxInt + + + +A widget that allows the user to change a integer value by either press up and down arrows or entering a value into the box. Minimum and maximum values for the widget can be set with the minValue and maxValue properties. The specialValueText property is used to set a text value that will be displayed instead of the minimum value. + + +This widget has only one state, default. + + +The widget text for a SpinBoxInt is the currently displayed integer. + + +See the QSpinBox documentation to learn more about it. + + + + + + + + + +Slider + + + +A widget that provides horizontal or vertical slider. + + +See the QSlider documentation to learn more about it. + + + + + + + + + +RichTextEditor + + + +This widgets provides a text editor that allows for simple text formatting. + + +RichTextEditor has one state, default. + + +The widget text for RichTextEditor is the text contained in the editor in rich text format. Selected text can be returned with @selectedWidgetText. + + + + + + + + + +StatusBar + + + +A widget to display status information, usually used at the bottom of the dialogs. + + +See the KStatusBar documentation to learn more about it. + + + + + + + + + +ProgressBar + + + +A widget to display progress information. + + +See the KProgress documentation to learn more about it. + + + + + + + + + +ScriptObject + + + +This is a pseudo-widget, it does not appear when the dialog is run. It can be though about as a function. A ScriptObject holds code that can be executed anytime from the dialog by calling its execute function. Arguments can be passed to the ScripObject with the above method and accessed inside the ScriptObject as @Self.item(0), @Self.item(1), etc. if using the old style parsing or Self.item(0, Self.item(1), etc. with the new parser. + + +Signals can be connected to the execute function as well, as it acts also as a slot. + + + + + + + + + +Timer + + + +This is a pseudo-widget, it does not appear when the dialog is run. It can be used to perform an action after a specified time once, or regularly. Set the timeout interval in milliseconds, choose if it should run once (singleShot) or not. Connect its timeout signal to a slot, which will be executed once the specified time passes. + + +The timer is not started by default, run the execute function to start it. + + +See the QTimer documentation to learn more. + + + + + + + + + +DatePicker + + + +A widget used to select a date. The default date can be set in the date property or with the setText function in ISO format: YYYY-MM-DD. + + +The widget text is the currently displayed date. + + +See the KDatePicker documentation to learn more. + +New in Kommander 1.3. + + + + + + + + +AboutDialog + + + +This is a pseudo-widget, it does not appear when the dialog is run. It stores information about the application, the authors, the license. Shows the about dialog +when the execute function is called. +The initialize function must be called before anything else, including the execute function. + +New in Kommander 1.3. + + + + + + + + +FontDialog + + + +A pseudo-widget, that can be used to get a font selection dialog. The default font can be set with the setFont function, and the selected font's properties retrieved with the family, pointSize, bold, italic functions. The dialog is shown when the execute function is called. + +New in Kommander 1.3. + + + + + + + + +PopupMenu + + + +A pseudo-widget, that can be used to display a menu. Use the insert... functions to add menu entries. Whenever the user clicks on a menu entry, the specified executeWidget's execute function will be run. It is possible to connect the menu entries to the popupmenu's own execute function, in which case the text assigned to the default state is run. When adding menu items you can assign an index to them and handle the all the items on a menu in the menu widget as the request passes this index back. To see how this works look at the current example keyvaluecombo.kmdr included with this release. To find it look on the tools menu of the editor for the examples dialog. + +To show the menu, use popup slot. Usually this is connected to another widget's contextMenuRequested signal. +A menu can contain other PopupMenu submenus. +New in Kommander 1.3. + + + + + + + + +ToolBox + + + +A container widget, like TabWidget. It has several pages, each page can hold other widgets. + +This widget has an editor bug that does not affect it's use in execution, but does affect it's use in the editor. If you try to add pages in the editor it will become unreadable. Don't do this. If you want to use the ToolBox please use fill the widget on the fly using the addWidget command. If there is time an example will be added to the 1.3 release, or check the web site. +See the QToolBox documentation to learn more about it. +New in Kommander 1.3. + + + + + + -- cgit v1.2.1