A desktop framework/daemon

[Philip Van Hoof <spamfrommailing freax org>]

Hi there,

I am the author of the current GNOME Clipboard Manager application.
Being aware that only a clipboard manager is not what people actually
really need, I am planning to create a new type of daemon.


My plans are to create a desktop-daemon that serves all types of desktop
services. My plans are to make this desktop-daemon platform independent
and network transparant.


The first module that I am planning to create is a clipboard-daemon.
This clipboard daemon will keep a small history of clipboards and will
talk XML with it's clients;


Applications (on the network and/or the localhost) can then ask the
daemon to get a layer of a clipboard in the history (A clipboard can
have different layers, or targets. For example the HTML view of such a
clipboard, or the TEXT view, the PNG view or whatever format the
application desires). Because such clipboards can be binary the content
will be or UUEncoded or served as a HTTP url 

'example' :

<clipboardlayer>
<mimetype>image/png</mimetype>
<sourcetype>url</sourcetype>
<url>http://computername:pppp/clipboardmanager/binitem?clipboard=current/image.png</url>
</clipboardlayer>

or

<clipboardlayer>
<mimetype>image/png</mimetype>
<sourcetype>embedded</sourcetype>
<embedded>UUENCODED DATA</embedded>
</clipboardlayer>


Of course can the client also request a preview of such a clipboard.
This request will result in clipboard manager having cropped the content
(in case of UTF8-data) or resized content (in case of image-data) or ...

Sample clients that will want such a preview will be the TrayIcon-client
(see below).


I want to make this application network and platform independent.
Therefor I am choosing to develop the application in as much C# as
possible. I am planning to create a few platform dependant plugins (like
the ClipboardManager plugin for Gtk+ which will use the GtkClipboard
C-API object) and a plugin for Microsoft Windows and a plugin for KDE
and a plugin for MacOS X (once Mono works on MacOS X) and and and.


My plans are to not restrict the daemon for clipboard purposes only. I
have the most experience with the clipboard so this module will be the
first service that I will be completing (as a prove of concept).


I am now searching for both ideas and developers who share the same
view. I hope that people who do will not only share the same view but
will also help me develop this daemon. 


Some clients for the clipboard-plugin that I am planning to create are 

 - An editor GUI
 - A PanelApplet or TrayIcon (this will be like Klipper on KDE)
 - A hotkey-popupmenu (for example CTRL+ALT+V will show a menu
   with all available clipboards in the daemon's history at the
   current mouse position)

All clients that I am planning to create will also be network
transparant (so you can choose to copy and paste from any source that is
running the daemon on your network)


My first idea for such a pluggable framework is to create a lot abstract
classes in C#. Then, to create a valid plugin for the framework you will
have to implement the abstract methods. The ClipboardManager plugin will
be a first implementation of such a plugin (prove of concept). Plugins
will be normal .NET assemblies (DotNET .dll files).


I have already developed a standalone ClipboardManager in C# using Mono
which does work. During the development I noticed that I was just
rewriting the current GNOME Clipboard Manager in C#. Having a very rich
framework (the .NET framework) I feel that I could create a much better
thing.

You can find the sources of the current .NET version of GNOME Clipboard
Manager (only the daemon, no GUI code -client- is finished atm)

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gcm/Gcm.Net/

I kindly invite people who are interested in this idea to join the
mailinglist of gcm. Once I actually started this project I will most
likely rename, recode and redesign it and start a new project on
sourceforge. 

http://lists.sourceforge.net/lists/listinfo/gcm-devel

Note that this might be a very good project to learn about gtk-sharp, C#
and Mono for a lot people :-).

Sample applications that could use such a Clipboard Manager Plugin are
Word processors, Integrated Development Environments, Spreadsheet
applications, Chat applications and browsers.

Extra benefits of such a clipboard manager plugin :

 - A history of clipboards
 - This will fix the GNOME Clipboard (closing an application will not
   mean that its clipboard gets removed)
 - Saving clipboards between sessions
 - Using clipboards across your networks
 - Previewing clipboards in the history


Maybe you think that the idea of creating the clipboard as a service
might sound stupid .. well, storing and saving settings in GNOME (GConf)
is also a daemon... and imho it's not stupid to use a daemon for that
purpose. And a clipboard imho, is a lot like: "hey give me the
clipboard", and "hey, this is the new clipboard". So it actually
"should" be a service in stead of every desktop application being a
service when it ownes the clipboard -which is how things are now-.


My opinion is that a lot desktop-things could be like a service :

 - The list of open windows (for taskbars)
 - The current song playing in your audio application (and the available
   songs)
 - The people who are online at this moment (msn, AOL, Yahoo, IRC, ...) 
 - Your E-mails
 - The history in your browser and bookmarks
 - ...


ps. It's not because these items are very often private items on your
desktop that it's a horrible thing to make a service for it. Just make
it a secure service and everything is fine. We are opensource, right? So
doing things with private data is okay (users know that we are not
abusing their data, because they can read our sourcecode!).

Some day we will have computer screens all over the place in our homes:
in the kitchen, in our bed, a large computer screen in stead of a
television, PDA's and other small devices, in our car, .. I can imagine
that if the desktop will be GNOME .. GNOME will have to behave much more
service-oriented than it does right now (Bonobo is not enough). 

My opinion , short: Lets take care of the future in stead of trying to
become what Windows was in 1997. With Mono (or any other programming
language) we (will) have the correct tools.


ps. I also have a daytime job and a girlfriend so don't expect me to
finish this project is a short time :-))) -it is, atm, only an idea-



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
work: Philip dot VanHoof at cronos dot be
http://www.freax.be, http://www.freax.eu.org