KDE Framework Addition: Koto

Synopsis

Goals

The world of web deployed applications is chaotic, and amidst it all are web developers hacking together ways to make their webpages look like desktop applications with a bizarre mix of CSS, client side scripting and java applets. HTML was designed for the dissemination of documents, but today's websites are pushing it's limits. Issues of browser compatibility plague web programmers and HTML coders, and designers still have no idea what it means to design a page with semantic markup in mind

I want to fix this.

In the same way that one browses web pages, one should be able to browse applications on the web, and locally. I imagine an application development framework that provides a way for developers to address the needs of their clients and of the open source community quickly and easily, focussing on the important elements of a program such as usability, feature enhancement and operational flow, unfettered by issues such as platform/browser dependence, closed standards formatting, database and network connectivity.

Project Details

The core is a pre-compiled class library of GUI controls similar to HTML's form controls, but enhanced to include control scripts that are downloaded to the users machine. You can script the control of your application in languages like Python or PHP5. The class library contains an enormously feature rich display control suite that will allow the design of high level design elements such as shading, contours, fonts, colours etc., removing the need for the use of images to create nice looking layouts. I think it would be useful to create a button in the same way that you do using photo-shop, or the GIMP, sending only a few instructions rather than an entire image.

As well as GUI controls, there would be cross platform network controls etc. The whole thing is pretty similar to Java, except that a) it's non-proprietory, and b) it's not slow as hell. It's also kind of like CSS except that a) the display instructions are in the same markup specification as the controls and b) it's highly centralised, feature rich and not terminally frustrating to use.

I am imagining something like this:

<menu class="SlidingMenu" name="FileMenu" appearance="menu1.xcf">
    <position left-reference="parent" max-width="485px" max-height="500px"
overflow="cutoff" />
    <menu class="SlidingMenu" appearance="sub-menu1.xcf">
        <position left-reference="parent" right-reference="PageDisplay"
max-height="500px" overflow="scroll" />
        <menu-item class="KDEAppMenuItem" name="ExitButton"
appearance="exit-button.xcf" control="do_exit.php" />
    </menu>
    <menu-item         [... etc ...]
    </menu-item>
</menu>

do_exit.php:

<?php
    Application::exit();
?>

Where Application is one of the pre-compiled classes. There would be a HUGE focus on making the process of writing custom library classes very straightforward. This would mean that a developer could still utilise the cross platform power of the framework whilst still having access to the full power of developing extensions to the default behvaiour as necessary. You could write your entire application in PHP5, using it to control the base level classes, then discover that you need more power, and write a very simple C++ application extension. The source code for this extension would then be downloaded by the user and compiled before it is run.

Version control is inherent to the compilation and deployment process. The compilation and deployment process are inherent in the testing process. The testing process is inherent in the design process. The design process is inherent in the development process.

Database connectivity is optimised when an application is deployed for distributed application environment. a Compiled Remote Stored Procedures System (CRSPS) ensures that when a client application requests data from the server, only data that will be used by the application during that execution path is sent, and multiple queries are optimised into table joins etc, so that a script can begin executing whilst it is still receiving the data that it will eventually need to display the results to the user. 'Data Holes' are left in the executed code, which are then plugged up when the data has finished being received from the server.

Improved access to a 'sandbox' type protected file system means no more pesky 'chmod 777' from the web developers frustrated with file permissions when developing web applications that need to handle files.

So what the does this all have to do with KDE? WELL!! at first, this system can be developed as an intra/extranet builder for companies. Many companies want the power of an extranet, but then discover that the world of web based deployment doesn't provide them with the power they require, or it costs a lot to actually develop a useable product.

Having something like this could mean that KDE could provide an office workstation environment that would allow a single DAML browser to be used to provide access for all employees to centralised applications from home or office, in a highly customised way (ie. the sys-admins could custom build mail applications with the appropriate proxy and firewall settings that were then distributed to each user, rather than having to traipse about the building fixing everyone's account settings on Outlook all the time). We could take the best of breed of all open source applications and compile them into a class library controllable from a scripted environment. So a sys-admin could take an IMAP mail control, tack on an IM client control and an RTF/PDF interpreter, then patch in a telephone headset via Asterisk, all running in a KDE windowed environment and distribute the application instantly over a network with different parts of the application running locally or from a centralised server, with database and network connectivity all just HANDLED in the same way that a PHP programmer just has to do 'mysql_connect()'.

KDE would become the number one choice for extremely large scale office local and wide area networks!!!!! this would then allow the development of DAML into a fully fledged web based deployment system.

Project Schedule

well, i reckon it'll take a fair while... but you did ask for visionaries!!

Motivation

i hate java, i hate HTML, i hate CSS, i hate Javascript, i hate flash, i hate all things microsoft, i hate trying to choose an application development platform, i hate thinking about all this stuff that detracts from the main focus of programming: creating tools for people to use their computers better. DAML needs to be created because it will usher in a new era of highly productive program development in a truly open source environment.