Add a professional user interface

[GoogleCodeExporter]

More professional users will likely shy away from the wizard interface.

A more professional interface option should be avalible, preferable a
list/grid with user configurable columns.

Once the server/client seperation is done, the interface should be able to
display backups from multiple machines in the same interface.

Original issue reported on code.google.com by kenneth....@gmail.com on 9 Feb 2010 at 7:20

[GoogleCodeExporter]

Hi Kenneth,

After replying to the last issue, I mentioned that I wanted to focus on 
something
else other then the issue regarding Linux's issue with *. What that was that I 
was
going to look at talking to you about reimplementing the user interface. I've 
just
noticed this issue and I would be interested in putting some time into this and 
I've
had my head around the current GUI's source and as far as I can see I'm across 
the
process it takes on most tasks.

I'll be giving it a go and I've got a good idea in my of some changes I was 
going to
make, so before jumping in too much could you share any ideas you have

So far I was thinking:

duplicati master program - runs in the same network as the master file server
containing duplicati backups, can create shares and set user/passwords for
ftp/share/sftp etc, can create exportable config files for. this is the main
administration tool for the master. used for technician's access, verification,
restores and others. while it works, the current gui is a little round about to 
be
able to have a third computer that has saved configs of all of the backups 
available
on the ftp server while not being able to overwrite or delete existing data. 

duplicati client program [server] - runs on a user's main server across the 
internet,
automated scheduled backups to master server - wizard style interface and/or 
command
line interface for windows schedule

duplicati client program [individual desktop] - runs on individual user pc's - 
needs
to be extremely accessable and straight forward. can either backup to user main
server or master server. initial configuration would be wizard style and then
streamline the restore/backup process through easy customized right click 
context
menus. this program's look, feel and configuration could all be generated from 
the
master program to make rapid deployment straight forward.

Like I said, just a few thoughts that I was looking at going ahead with anyway, 
may
as well offer the help. I can see that you've listed what I was thinking so any
further thoughts, or would you like to palm the GUI work off to someone else?

Original comment by dddan...@gmail.com on 15 Feb 2010 at 11:35

[GoogleCodeExporter]

Huh, since I just built svn I got up to the 'Direct from files' option. Nice 
touch!

Original comment by dddan...@gmail.com on 15 Feb 2010 at 1:07

[GoogleCodeExporter]

Yes, the "Direct restore" makes it much more accesible, thanks :).

I have added issue #9 for the client/server seperation.

My idea for issue #9 is that the non-GUI part should be running as a 
service/daemon.
I was thinking something like the Scheduler and backup process.

The GUI client should then connect to the local service/daemon and communicate 
either
through named pipes or a network socket.

I am planning to find/develop a module that allows the two components to 
communicate.
I think .Net remoting is the wrong tool for this. The client should send 
commands to
the service, like "Create backup", "Pause", etc. And the server should send 
responses
and status updates, so the GUI can look like it does now.

Once this seperation is done, it should not be a problem to merely direct the 
GUI to
another machine (using TCP).

A client could then have only the service/daemon part installed, and an admin 
could
check up on backups by connecting to the service, from an admin interface. A 
simpler
end-user interface (eg. readonly) could then be installed on the client.

I think your idea is targeting a much larger corporation than what I had in 
mind.
(not a bad thing, just different). The "master program" sounds like something a
hosting company would run? If this program is supposed to create shares and 
setup
accounts, it would be hard to make it support multiple os/ftpd/sshd 
configurations.

If the client perform backups to the server, why would there be an application 
on the
server? Would the client and the server communicate (other than transfer backup 
files)?

Would each client/user have a dedicated server or would there be like a cluster 
of
machines, all monitored by the "master program", or just one server?

If you would like to work on this, I can create a sandbox for you where you can
commit changes as you please.

Original comment by kenneth....@gmail.com on 15 Feb 2010 at 8:46

[GoogleCodeExporter]

I think the ideas you've brought up here were exactly on the money, and you are 
right
in your assumption of duplicati's use. If the service can be run the gui can be
handed off to .NET application or a PHP webpage from the server to run commands
breaking the whole process up. 

If you can, make me that sandbox and I'll add the changes I've been fiddling 
with
today/tomorrow to the latest checkout version for a bit of review.

Original comment by dddan...@gmail.com on 15 Feb 2010 at 8:59

[GoogleCodeExporter]

Issue 228 has been merged into this issue.

Original comment by kenneth....@gmail.com on 12 Jul 2010 at 8:52

[GoogleCodeExporter]

Issue 300 has been merged into this issue.

Original comment by kenneth....@gmail.com on 8 Nov 2010 at 9:23