PlasMate ~ UI and other stuff

[Chani]

On October 23, 2009 01:18:11 Yuen Hoe Lim wrote:
> > you really work like that?? one file at a time? o.0
> 
> No no that's not what I meant xD And no I don't and can't work like that :)
> I meant being able to have all the files open at the same time with unsaved
> changes strewn all over the place - but being able to save the files one at
> a time. ie - can the user decide *when* to save and *which* files exactly
>  to save. Let's say I have file a b c and d open and all have unsaved
>  changes. Can I choose to save only file b and c to disk and leave the
>  stuff in a and d unsaved, as you could in Kate and any other regular
>  tabbed editor?
> 
> the actual files should be saved to disk automagically so that the user
> 
> > doesn't
> > lose work if there's a crash or power loss or something.
> 
> I guess this means the answer is no? I don't really have hard objections
> against this, but I do sometimes find it convenient to be able to leave a
> file with changes unsaved and be able to simply revert by reloading the
>  file from disk later if I want to. I know you could achieve a similar
>  effect with save-point, but you don't always know you're doing something
>  awful until you're several files worth of changes in :)
> 

you could add a feature to the save-point so that you could save or revert 
only certain files. "git checkout foo.cpp" isn't any harder than reverting an 
unsaved file - heck, it's easier, because you don't have to worry about losing 
"unsaved" changes in a crash or anything.

but how would you represent that nicely in the UI?
for saving it could be easy, just a checkbox beside each file that's checked by 
default. for reverting a file that hasn't been checked in ("saved"), it could 
be the same UI as in regular editors.

for the more advanced feature of reverting one file to an arbitrary save-point 
(say when you check in some stuff and then realise one of those changes was a 
mistake)... well, this is outside of what's offered by normal editors, and 
depends on how the timeline thing and reverting the whole codebase to a 
previous save-point works. I haven't looked at that.

but preserving the "save only these files" and "revert this to the last save" 
parts of regular editing is no problem. remember, the version on disk is the 
"unsaved" version, with the benefit of not being lost if something goes wrong. 
the versions committed to git are the "saved" versions, with the benefit of 
being able to travel back and forth in time between those save-points, and 
have other information associated with them.

we're completely replacing save-to-disk with commit-to-git. we don't have to 
lose anything in the process, but we gain a lot.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091023/364db1ca/attachment.sig