[Kommander-devel] Kommander 2 (KDE4) planning

[Eric Laffoon]

Hi all,
I was taking a minute to look though some docs. Sebastian Sauer had mentioned 
using Qt Plugins and I was reading up on them as well as the new Qt Designer. 
Refernces...
http://doc.trolltech.com/4.2/plugins-howto.html
http://doc.trolltech.com/qq/qq16-designer.html
http://doc.trolltech.com/4.2/qtdesigner.html

One thing I have found with C++ and Qt/KDE is that it fits the definition 
of "like peeling an onion". It's amazing how much a few lines of code can  do 
and exceedingly difficul to comprehend everything going on without building 
it and seeing what it did. Not bing a guru in this department I thought I'd 
put out my current thoughts and observations and get some feedback, ideas and 
clarification.

As I see it one chief advantage offered in KDE4 is that Kommander could exist 
less as Kommander and more as a set of plugins. Issues, like Widgets. While 
we started out subclassing widgets it appears Qt pugins offer more than just 
a method of shared access for DBUS enabled languages. It looks like we can 
create a plugin from a widget and merely add Kommander distinct functions. 
Instead of having to write functions to set and get properties it looks like 
we could just write a standard inteface module to retain consistent Kommander 
syntax, and other scripting languages could do the same.

Effectively this has the potential to turn the application development process 
on it's head. While there could be standard widgets shipped as there are now, 
it would also be possible to release individual widget updates separately as 
ever widget would be a pugin, whether packaged or not. This brings up 
something Michal and I discussed... How to validate what version is requred 
for a program developed with Kommander. I have an idea for this, as well as 
security, but first, the executor and editor. For the executor, again it 
looks like a program similar to what we have now, but loading the plugins 
being called. 

For the editor, I am not sure the full considerations with using Qt Designer, 
but from what I can see the only real issue is how much work we want to make 
for ourselves. First of all I think Desiger is built around the concept that 
you will be mostly doing GUI design there and editing elsewhere. That concept 
is worth looking at. Possibly a KDevelop platform integration would make 
sense. My preference is to have some form of tabbed editing, and what Andras 
did making it possible to view a second instance read only is very handy. I 
tend to think the dialog should float and the editors should be in the MDI, 
but I'm finding the improvements in Kommander 1.3 very agreeable. So possibly 
just using Designer with new modules might be acceptable. While I want to 
extend the power of Kommander I also want to avoid intimidating novice users.

The big question in using Designer seems to be how do we get it to block non 
Kommander widgets, or do we even want it to. For instance let's look at the 
simple LineEdit. If we used a KDE widget that was not a Kommander widget, and 
we have access to all it's properties as well as signals and slots... Do we 
even need to have it be a Kommander widget? I think maybe for legacy usage. 
So this potentially simplifies (or maybe complicates) things more. I am still 
considering how this affects our dealing with types as Kommander attempts to 
be typless by default. I would like to retain the simple while making less 
simple things possible.

At the heart of everything it appears we can mix and match Designer parts as 
well as create our own. My inclination is as always to achieve as great a 
result as possible with as little effort as possible. This appears possible 
as it looks for the first time like we would not have any sane reason to fork 
Designer like we did before. After the basic setup to integrate Kommander 
functionality my objective is to expose an interface to develop Kommander 
extentions with Kommander. In fact I'd like as much as possible of the next 
Kommander Editor to be developed with Kommander. Those would include project 
management and custom tools.

Kommander requirements validation - this is what I propose. Any part plugged 
into Kommander should have version information included. We should have an 
automated method of listing functions and parameters on release of any 
package or plugin. We then offer an analysis tool. You take your application 
and expose it to the tool, which is aware of the latest version of everything 
you developed. It then scans calls against the database and indicates the 
version required to run it. This is then put in a requirements file. If you 
download an application packaged with this file a program can run it and 
compare to your installed information database and tell you what plugins you 
need to install or upgrade to run it. What would really be cool is to offer 
to download and install these.

Developer support - I think we should begin planning the next level of 
application developer support to organize an army of "everyman developers". 
For starters they register on the user/developer web page and get an account. 
Then they fill out a form to create a template based web page describing 
their development efforts. When they release a package they post it on out 
site with Kommander tools that validate their user ID. If they have 
additional resources they can upload them. When a user is notified or checks 
for updates they can see the latest updates and download and install them. 
Users will also have a KStuff like repository to share, but unlike KStuff it 
will incorporate user accounts and digital keys. 

Here is my next gen security proposal. The executable bit is lame for 
security. I mean I could distribute a dialog that created a cron job to set 
the bit on every Kommander file it found every 5 minutes. We should keep it 
to have it, but we shoudl do something elegant that works. Here's my 
proposal.

People distributing apps through our web site will have an advantage... When 
the program is run for the first time if the bit is not set it will look for 
an embedded developer key. This key would be obtained when you signed up and 
when you develop it would embed automatically. It would basically be a short 
unique string identifying the developer. Here is how it works:
1) a non executable script is called which contains a developer key beginning 
the enhanced security process
2) the Kommander executor checks for internet access and then either asks the 
user to authorize the recommended security check or to connect
3) once connected to the account indicated by the key the executor gets the 
dialog internal name and runs a crc check, both of which are sent to the 
server
4) the server compares that specific window ID and crc with what is on file
5) if the program has multiple dialogs listed with it a list is sent back and 
the user is asked to authorize tests for a list of included parts
6) if all tests are clean the executable bits are set
7) if something doesn't validate it is logged on the server and the user is 
instructed the dialog has been altered and is advised to contact the 
developer before running it

If a pattern is detected the developer is notified. I think we can generate 
these crc files online. Ultimate security could be obtained by having the 
developer place a private key in the database and distribute dialogs with the 
public key embedded. The point is this distributes packages with 
accountablity. If a user reports a valid package damages their system we can 
suspend authoriation for that user/developer and investigate the suspect 
file.

To my mind this offers excellence.
1) real secutiry
2) stops scaring users
3) bands developers to a portal with support

We can then offer application and author approval ratings and reviews. We can 
probably rally this to greater financial support, if nothing else offer a 2 
Euro a month subscription to a developer advanced monthly publication or 
something.
-- 
Eric Laffoon
Project Lead - kdewebdev module