<li>@if (a, b, c)? - or is BASH enough?<br /><span style="font-style:italic">This will be solved by new parser.</span></li>
<li>add @include and @includelocal commands - to include external script or local (project script); that should make code more readable</li>
<li>add @call to call local script (no need for external @call, as it is equivalent to @exec<br /><span style="font-style:italic">Naming: use @execlocal for consistency?</span></li>
<li>add @requireVersion(command, version) that would detect version of program (presumably script language, like perl), compare it to given minimum and fail if it is not matched</li>
<li>add function for string conversion (@String.cvs2tab, @Stringcvs2eol ...)</li>
<li>add @ldcop for calling local DCOP functions</li></ul>
<p><span style="font-weight:600">If we keep the old parser.<br /><br /></span><br />Make it possible to use any language with Kommander. The idea is to replace Kommander specials with language specific code in a way that it will not break conditions and loops, like now. example:<br />#!/bin/bash<br />array="1 2 3 4 5"<br />for i in $array do<br /> @Label.setText($i)<br />done<br /><br />This does not work now. The idea is to replace @Widget.method() with a language specific DCOP call.<br />If the language has DCOP bindings, use those bindings to execute the dcop call. If not, use the command line<br />DCOP application. This is slower, but always works. In the above case, Kommander would replace <br />@Label.setText($i) <br />with<br />dcop kmdr-executor-PID KommanderIf setText Label $i<br /><br />Kommander will have description files for each supported language about how to execute DCOP calls.<br />If the language has DCOP bindings, this description tells the syntax of the bindings. If it doesn't have, the description gives a way how to execute external applications. This should always exists, as all languages can execute external applications.<br /><br />In KDE4, of course use DBUS instead of DCOP.<br /><br /></p>
<p><span style="font-weight:600">New signals for existing widgets</span></p>
<ul type="disc"><li>add signals for D&D<br /><span style="font-style:italic">Requires dragContent and dragType, perhaps dragSource to be set.</span></li>
<p><span style="font-weight:600">Kommander Release Do list</span></p>
<ul type="disc"><li><span style="color:#00ff00">Add missing functions in FB</span></li>
<li>KPart create to go with KPart load</li>
<li><span style="color:#ff0000">executor version required field/command - enable someone sharing dialogs to have an executing window check if the executor is capable of fully supporting it - Not the self checking Michal suggested, but better than nothing by far</span></li>
<li><span style="color:#ff0000">ability to identify calling table widget from signal in a script slot - ideally by row and column in table grid </span></li></ul>
<ul type="disc"><li>We need to look at how to emulate KStfuff using HTTP and a Kommander dialog... will require KStuff back end and some PHP scripts</li>
<li>Samples go into the install for use</li>
<li>Web site needs docs and tutorials updated</li></ul>
<p><span style="font-weight:600">Things to look into</span></p>
<ul type="disc"><li>Qt database connection?</li>
<li><span style="color:#ffff00">Code completion? If easy to do, otherwise we recommend users try the Kate completion plugin</span></li>
<li><span style="color:#ffff00">D&D of text/selection data</span></li>
<li>simple DCOP functions in editor to enable Kommander based tools to call the editor and open a dialog to edit - otherwise any interfaces can at least make use of D&D from file manager (KPart) views</li>
<li><span style="color:#ff0000">Additional XML fields in dialog for author name, version of Kommander required, etc... - not required as TDEAbout would be better</span></li></ul>
<ul type="disc"><li>link handling in TextBrowser opens file manager in execute directory even if calling another Kommander dialog. First it opens the file, then konqeror.</li></ul>
<p>New widgets include the DatePicker, Popup Menu and Toolbox. New functions inlcude widget creation, hooking and unhooking signals and slots and full slot access as well as passing and returning parameters in scripts. WooHoo! Take that do list!<br /></p>
<p>The Kommander editor is effectively dead for KDE3. Porting is senseless as it is an old Qt Designer hack. Since Designer for Qt 4x is actually designed this time to be easy to extend and modify the first generation of the editor will be scrapped.<br /><br />Other parts of Kommander like the parser should be much more portable.<br /><br /> - creating table widgets means if you need to know the calling widget you need create scripts on the fly for this.</p>
<ul type="disc"><li>move all widgets into a library (mostly done)</li>
<li>widgets should contain the code how they are displayed in the editor</li>
<li>widgets should contain the functions they support. Share only very common functions, like show, execute, etc, otherwise soon it becomes confusing if insertItem expect and int, a string, or and int and a string. </li>
<li>widgets and plugin should query the plugin manager for available method IDs (and register how many they need) OR on registering do not pass the ID, but get back. This makes sure you don't have plugins/widgets using the same function IDs. </li>
<li>check if we can live without making specials.h public</li>
<li>the icons used in the editor should be returned by the widgets itself (partly done)</li>
<li>check if it is enough to have a public KommanderWidget instead of making KWidgetPlugin as well public</li>
<li>get back a version number from plugins and from Kommander. This way both the plugins and the executor can decide if they are compatible or not.</li></ul>
<p>This file should document both what should be done in Kommander and what was done.</p>
<p>All entries marked with a date without an author were made by Michal Rudolf</p>
<p>When adding something important, please enter it in ChangeLog or Done and mark it with current date (in yyyy-MM-dd, hh:mm format) and your name.</p>
