[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Backup application for KDE data/settings
From:       Aaron Seigo <aseigo () kde ! org>
Date:       2005-04-20 21:32:37
Message-ID: 200504202132.38100.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On April 20, 2005 19:39, Douglas Ward wrote:
> On Wednesday 20 April 2005 04:58, Sven Burmeister wrote:
> > Here are my first thoughts.
> >
> > The apllication contains just one tab displaying backup-profiles, i.e.
> > collections of applications (modules) to be backed up. There should be
> > some pre-defined, like PIM+Internet+Passwords. Each profile displays the
> > date of the last backup and maybe the size of the backup file. Further
> > three buttons, backup now, restore now and edit profile. To create a new
> > profile, one could either put a button there, or simply always display an
> > empty profile. The reason why I consider profiles useful is that there
> > are things that need to be backed up more often than others.
>
> Summary:
> * Profiles could be used in repairing broken settings, i.e. only restore
> "safe" settings/data

hum.. how would we know what "safe settings" were? per-application 
descriptions (e.g. "KMail settings", "KMail filters", etc...) would be 
useful, that much i can certainly see.

> * I believe the options you describe could be placed into a clean,
> single-view dialog

yes.

> * Several interfaces exist that could be used for models (KControl->Theme
> Manager, KControl->KHotKeys, KControl, Konserve)

i'm not particularly a fan of any of these, to be honest =)

> * The settings for the backup utility/module should be editable by hand

this is covered by using the standard KDE config system.

> * The settings for the backup utility/module should be resilient against
> KDE upgrades, and application changes

there's only so much we can do here, i fear. =/ perhaps the best we can do is 
include the verson of the application the current backup (or application 
description) applies to; perhaps find some way to make it work with 
kconfupdate would also be useful.. hum.

> The backup utility Konserve uses the concept of profiles.
>
> http://konserve.sourceforge.net/screens.html

i wonder if we need multiple profiles here, though. it would be easy enough to 
add later on, but a single profile per user should be enough for this i would 
think. just to keep it simple for the first version, at least. then we can 
see if it turns out that we (or rather, our users) actually need/want 
multiple profiles.

this should be a personal tool, after all, not a complex system admin tool =)

btw, i just downloaded and tried both konserve and kdar. there are some things 
to be gleaned from each. dar, in particular, seems interesting.

> Profiles should be used, even if only for resolving the problem that some
> types of settings can break when trying to migrate from one KDE release to
> another.

not sure what the connection here would be. can you explain futher?

> If the scope of the tool includes repair abilities, then, a method for
> clearing a data set (e.g., clearing data/settings so they can be re-added
> or replaced with distro. defaults).

yes, i think having the ability to "remove kmail's configuration" with a 
simple button click is useful.

> Would it be more useful to having a default location for the backup, and
> only asking for a location for the backup when an export is performed?

we could suggest a default and have a first-run wizard to help the user step 
through the customization process.

> If the utility wants to be eventually usable as a KControl module, perhaps

this is a very good question. my gut says "NO!", but the control center is 
such an obvious place to look for such a facility. maybe. heh. 

> A process to eventually have all apps announce backup settings would be
> great. Before that happens, would it be good enough to generate the
> application-files list by searching through share/apps and share/config in
> addition to including some defaults?

i think that generating a default set of such files and then distributing them 
to each project (e.g. kmail's profile in kdepim/kmail) would be the goal. it 
would just be asking for trouble to ship with a set of application 
descriptions separate from the applications themselves.

> A nice feature would be to use text files (in apps/xutility/foo?) to store
> application data, i.e. list of applications->files,filetype (with filetype
> being something like setting/appearance, data, etc.), that is generated by
> the config program. That would make it easy to check for errors and add
> non-kde programs.

i'm 99% certain i'll use XML files for this which will be located in a generic 
location. if the XML format is Good Enough(tm) it can be submitted to 
FreeDesktop.org for inclusion there.

-- 
Aaron J. Seigo
Society is Geometric

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]