The philosophy of the UNIX system
Scenario 1: Scripting GUI Applications
Many advanced tools in Linux, like inkscape and gimp, tried to provide this: a non GUI interface that can be accessed via scripts. But sometimes this interface lacks many of the functions, and we can't see what we are doing in live until we open output files.
bus = dbus.SessionBus()
ro = bus.get_object("org.inkscape",
Using a simple DBus API like above, we have all the benefits united, we can access the application from outside, script it, and we have the possibility to see the result live on the application canvas, we can modify script options, or directly manipulate objects for operations that is easy to perform without a script. DBus has many language bindings, so we can use any interface we want.
Scenario 2: Interactive programming
We can see the animation directly, and we can export a new image each time. The set of image can be combined to create a video or any animation.
Scenario 3: Factorisation of application programming
Solving tools inconsistency
What if we can be able to share functionalities in a core-app, but make the interface pluggable depending on the use ? If we want to draw, we show a simple drawing GUI on top of the canvas. If we want sketching we show another one with sketching templates. If we want to animate, we show a timeline of animation.
The benefit here is that a huge amount of code is shared and developers will need to write less code.
Solving one device inconsistency
Adding more input options
The solution was quite simple:
Get gesture event, get the active app, Read the wishes of the user (configuration file), Convert these advanced events into something the application already understand: keyboard taps and mouse clicks.
That simple solution allowed us to show to the world the beauty of what we are doing. But we were limited to mouse and keyboard shortcuts. Beside the performance issues, just imagine the power of matching such events directly to internal applications functionalities through DBus.
Solving platform inconsistency
What will remain is just the canvas which will serve as the feedback for the operations, along with the included algorithms. All of the functionalities will be exposed through the DBus Software Bus.
Scenario 4: Application composer
Scenario 5: Interactive DocumentationA new way of building applications needs a new way of building documentation.Now there are two famous ways to create tutorials:
1. Record videos of a users using the software,
2. Take screenshots of the steps and write an accompanying article.
In the two cases user needs to switch back and forth between his software and the tutorial. This can be a problem for novice users as they can lost the step they are in, or fed up by pausing and playing the video each time.
What if we can create a tutorial which is aware of the current step of the user?
Application aware Documentation
This frees the user from switching between the application and the tutorial, and avoid being lost in a lot of information.
Generating usual documentation
(This article is currently a draft that stayed at this state a long time.
Please be free to help improving the concept and idea by some brainstorming or/and critics
I may add more information that I have in an independent paper with some testing code in the coming days.)
Things that still need to be discussed:
Standardization, Drawbacks, "microcloud" (per House), ...