barrier/doc/roadmap.html

93 lines
3.7 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<meta name="keywords" content="Virtual Screen, Open Source, Software" />
<meta name="description" content="Mouse and Keyboard Sharing" />
<link rel="stylesheet" type="text/css" href="synergy.css" media="screen" />
<title>Synergy Roadmap</title>
</head>
<body class="main">
<p>
</p><h3>Synergy Roadmap</h3><p>
</p><p>
This page describes the planned development of Synergy. There are
no dates or deadlines. Instead, you'll find the features to come
and the rough order they'll arrive.
</p><p>
</p><h4>Short term</h4><p>
</p><p>
Synergy should work seamlessly. When it works correctly, it works
transparently so you don't even think about it. When it breaks,
you're forced out of the illusion of a unified desktop. The first
priority is fixing those bugs that break the illusion.
</p><p>
Some of these bugs are pretty minor and some people would rather
have new features first. But I'd rather fix the current
foundation before building on it. That's not to say features
won't get added until after bug fixes; sometimes it's just too
tempting to code up a feature.
</p><p>
The highest priority feature is currently splitting synergy into
front-ends and a back-end. The back-end does the real work. The
front-ends are console, GUI, or background applications that
communicate with the back-end, either controlling it or receiving
notifications from it.
</p><p>
On win32, there'd be a front-end for the tray icon and a dialog to
start, stop, and control the back-end. OS X and X11 would have
similar front-ends. Splitting out the front-end has the added
benefit on X11 of keeping the back-end totally independent of
choice of GUI toolkit (KDE, Gnome, etc.)
</p><p>
One can also imagine a front-end that does nothing but put monitors
into power-saving mode when the cursor is not on them. If you have
one monitor auto-senses two inputs, this would automatically switch
the display when you move the cursor to one screen or another.
</p><p>
</p><h4>Medium term</h4><p>
</p><p>
Some features fit well into Synergy's current design and may simply
enhance it's current capabilities.
</p><p>
<ul>
<li>Configurable hot key to pop up a screen switch menu
<li>Configure screen saver synchronization on or off
<li>Graphical interface configuration and control on all platforms
<li>Graphical status feedback on all platforms
<li>More supported clipboard formats (particularly rich text)
</ul>
</p><p>
A popup menu would be new for Synergy, which currently doesn't have
to do any drawing. That opens up many possibilities. Ideally,
front-ends request hot keys from the back-end and then tell the back
end what to do when they're invoked. This keeps the back-end
independent of the user interface.
</p><p>
</p><h4>Long term</h4><p>
</p><p>
Two features stand out as long term goals:
</p><p>
<ul>
<li>Support <span class="arg">N</span> computers on
<span class="arg">M</span> monitors
<li>Drag and drop across computers
</ul>
</p><p>
The first feature means sharing a monitor or monitors the way the
keyboard and mouse are shared. With this, Synergy would be a full
KVM solution. Not only would it support a few computers sharing
one screen (still using the mouse to roll from one screen to
another), but it should also support dozens of computers to provide
a solution for server farm administrators. In this capacity, it
may need to support text (as opposed to bitmap graphics) screens.
</p><p>
The second feature would enhance the unified desktop illusion. It
would make it possible to drag a file and possibly other objects
to another screen. The object would be copied (or moved). I expect
this to be a very tricky feature.
</p>
</body>
</html>