1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
|
---|
2 | <html>
|
---|
3 | <head>
|
---|
4 | <meta HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
|
---|
5 | <meta name="keywords" content="Virtual Screen, Open Source, Software" />
|
---|
6 | <meta name="description" content="Mouse and Keyboard Sharing" />
|
---|
7 | <link rel="stylesheet" type="text/css" href="synergy.css" media="screen" />
|
---|
8 | <title>Synergy Roadmap</title>
|
---|
9 | </head>
|
---|
10 | <body class="main">
|
---|
11 | <p>
|
---|
12 | </p><h3>Synergy Roadmap</h3><p>
|
---|
13 | </p><p>
|
---|
14 | This page describes the planned development of Synergy. There are
|
---|
15 | no dates or deadlines. Instead, you'll find the features to come
|
---|
16 | and the rough order they'll arrive.
|
---|
17 | </p><p>
|
---|
18 | </p><h4>Short term</h4><p>
|
---|
19 | </p><p>
|
---|
20 | Synergy should work seamlessly. When it works correctly, it works
|
---|
21 | transparently so you don't even think about it. When it breaks,
|
---|
22 | you're forced out of the illusion of a unified desktop. The first
|
---|
23 | priority is fixing those bugs that break the illusion.
|
---|
24 | </p><p>
|
---|
25 | Some of these bugs are pretty minor and some people would rather
|
---|
26 | have new features first. But I'd rather fix the current
|
---|
27 | foundation before building on it. That's not to say features
|
---|
28 | won't get added until after bug fixes; sometimes it's just too
|
---|
29 | tempting to code up a feature.
|
---|
30 | </p><p>
|
---|
31 | The highest priority feature is currently splitting synergy into
|
---|
32 | front-ends and a back-end. The back-end does the real work. The
|
---|
33 | front-ends are console, GUI, or background applications that
|
---|
34 | communicate with the back-end, either controlling it or receiving
|
---|
35 | notifications from it.
|
---|
36 | </p><p>
|
---|
37 | On win32, there'd be a front-end for the tray icon and a dialog to
|
---|
38 | start, stop, and control the back-end. OS X and X11 would have
|
---|
39 | similar front-ends. Splitting out the front-end has the added
|
---|
40 | benefit on X11 of keeping the back-end totally independent of
|
---|
41 | choice of GUI toolkit (KDE, Gnome, etc.)
|
---|
42 | </p><p>
|
---|
43 | One can also imagine a front-end that does nothing but put monitors
|
---|
44 | into power-saving mode when the cursor is not on them. If you have
|
---|
45 | one monitor auto-senses two inputs, this would automatically switch
|
---|
46 | the display when you move the cursor to one screen or another.
|
---|
47 | </p><p>
|
---|
48 | </p><h4>Medium term</h4><p>
|
---|
49 | </p><p>
|
---|
50 | Some features fit well into Synergy's current design and may simply
|
---|
51 | enhance it's current capabilities.
|
---|
52 | </p><p>
|
---|
53 | <ul>
|
---|
54 | <li>Configurable hot key to pop up a screen switch menu
|
---|
55 | <li>Configure screen saver synchronization on or off
|
---|
56 | <li>Graphical interface configuration and control on all platforms
|
---|
57 | <li>Graphical status feedback on all platforms
|
---|
58 | <li>More supported clipboard formats (particularly rich text)
|
---|
59 | </ul>
|
---|
60 | </p><p>
|
---|
61 | A popup menu would be new for Synergy, which currently doesn't have
|
---|
62 | to do any drawing. That opens up many possibilities. Ideally,
|
---|
63 | front-ends request hot keys from the back-end and then tell the back
|
---|
64 | end what to do when they're invoked. This keeps the back-end
|
---|
65 | independent of the user interface.
|
---|
66 | </p><p>
|
---|
67 | </p><h4>Long term</h4><p>
|
---|
68 | </p><p>
|
---|
69 | Two features stand out as long term goals:
|
---|
70 | </p><p>
|
---|
71 | <ul>
|
---|
72 | <li>Support <span class="arg">N</span> computers on
|
---|
73 | <span class="arg">M</span> monitors
|
---|
74 | <li>Drag and drop across computers
|
---|
75 | </ul>
|
---|
76 | </p><p>
|
---|
77 | The first feature means sharing a monitor or monitors the way the
|
---|
78 | keyboard and mouse are shared. With this, Synergy would be a full
|
---|
79 | KVM solution. Not only would it support a few computers sharing
|
---|
80 | one screen (still using the mouse to roll from one screen to
|
---|
81 | another), but it should also support dozens of computers to provide
|
---|
82 | a solution for server farm administrators. In this capacity, it
|
---|
83 | may need to support text (as opposed to bitmap graphics) screens.
|
---|
84 | </p><p>
|
---|
85 | The second feature would enhance the unified desktop illusion. It
|
---|
86 | would make it possible to drag a file and possibly other objects
|
---|
87 | to another screen. The object would be copied (or moved). I expect
|
---|
88 | this to be a very tricky feature.
|
---|
89 | </p>
|
---|
90 | </body>
|
---|
91 |
|
---|
92 | </html>
|
---|