aah, ok cool makes sense :) ---- Jason "moofang" Lim Yuen Hoe http://yuenhoe.co.cc/
On Sat, Oct 24, 2009 at 4:22 AM, Chani <chan...@gmail.com> wrote: > 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 > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel