[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: PlasMate ~ UI and other stuff
From: Yuen Hoe Lim <yuenhoe86 () gmail ! com>
Date: 2009-10-24 6:01:54
Message-ID: 26362f480910232301v45731cc3j1282adc1afa63c01 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
aah, ok cool makes sense :)
----
Jason "moofang" Lim Yuen Hoe
http://yuenhoe.co.cc/
On Sat, Oct 24, 2009 at 4:22 AM, Chani <chanika@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
>
>
[Attachment #5 (text/html)]
aah, ok cool makes sense :)<br><br clear="all">----<br>Jason "moofang" Lim \
Yuen Hoe<br><a href="http://yuenhoe.co.cc/">http://yuenhoe.co.cc/</a><br><br> \
<br><br><div class="gmail_quote">On Sat, Oct 24, 2009 at 4:22 AM, Chani <span \
dir="ltr"><<a href="mailto:chanika@gmail.com">chanika@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div \
class="h5">On October 23, 2009 01:18:11 Yuen Hoe Lim wrote:<br> > > you really \
work like that?? one file at a time? o.0<br> ><br>
> No no that's not what I meant xD And no I don't and can't work like \
that :)<br> > I meant being able to have all the files open at the same time with \
unsaved<br> > changes strewn all over the place - but being able to save the files \
one at<br> > a time. ie - can the user decide *when* to save and *which* files \
exactly<br> > to save. Let's say I have file a b c and d open and all have \
unsaved<br> > changes. Can I choose to save only file b and c to disk and leave \
the<br> > stuff in a and d unsaved, as you could in Kate and any other \
regular<br> > tabbed editor?<br>
><br>
> the actual files should be saved to disk automagically so that the user<br>
><br>
> > doesn't<br>
> > lose work if there's a crash or power loss or something.<br>
><br>
> I guess this means the answer is no? I don't really have hard objections<br>
> against this, but I do sometimes find it convenient to be able to leave a<br>
> file with changes unsaved and be able to simply revert by reloading the<br>
> file from disk later if I want to. I know you could achieve a similar<br>
> effect with save-point, but you don't always know you're doing \
something<br> > awful until you're several files worth of changes in :)<br>
><br>
<br>
</div></div>you could add a feature to the save-point so that you could save or \
revert<br> only certain files. "git checkout foo.cpp" isn't any harder \
than reverting an<br> unsaved file - heck, it's easier, because you don't \
have to worry about losing<br> "unsaved" changes in a crash or \
anything.<br> <br>
but how would you represent that nicely in the UI?<br>
for saving it could be easy, just a checkbox beside each file that's checked \
by<br> default. for reverting a file that hasn't been checked in \
("saved"), it could<br> be the same UI as in regular editors.<br>
<br>
for the more advanced feature of reverting one file to an arbitrary save-point<br>
(say when you check in some stuff and then realise one of those changes was a<br>
mistake)... well, this is outside of what's offered by normal editors, and<br>
depends on how the timeline thing and reverting the whole codebase to a<br>
previous save-point works. I haven't looked at that.<br>
<br>
but preserving the "save only these files" and "revert this to the \
last save"<br> parts of regular editing is no problem. remember, the version on \
disk is the<br> "unsaved" version, with the benefit of not being lost if \
something goes wrong.<br> the versions committed to git are the "saved" \
versions, with the benefit of<br> being able to travel back and forth in time between \
those save-points, and<br> have other information associated with them.<br>
<br>
we're completely replacing save-to-disk with commit-to-git. we don't have \
to<br> lose anything in the process, but we gain a lot.<br>
<div><div></div><div class="h5"><br>
--<br>
This message brought to you by eevil bananas and the number 3.<br>
<a href="http://www.chani3.com" target="_blank">www.chani3.com</a><br>
</div></div><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> \
<br></blockquote></div><br>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic