[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: Re: KDE/kdevplatform/shell
From: Aleix <aleixpol () gmail ! com>
Date: 2008-11-08 16:49:55
Message-ID: 757d9a550811080849h351f701x57d8455b21abf63c () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
What about the files that have been modified but not yet saved? how does the
user keep track on that?
On Sat, Nov 8, 2008 at 4:41 PM, Niko Sams <niko.sams@gmail.com> wrote:
> >> > Whats the problem with the documents list or the first 8 files in
> >> > quickopen? I understand that you want to keep an overview of what
> you're
> >> > working on right now, but 8 tabs already fail to work for me on my
> laptop.
> >> > I already have 2 of them not visible, even more if the filenames are a
> bit
> >> > longer.
> >>
> >> I agree.
> >> Usually I don't close files, so usually I have many open files, more
> than 50.
> >> Why should I actually close them ? The open-files is for me more like a
> >> history of files which I used recently and may use again soon. If I save
> the
> >> files I'm working on from time to time it should be enough. I actually
> also
> >> don't really care if they are indeed open and loaded or not.
> >> Would it make sense to have a maximum number of files remembered as open
> ?
> >> E.g. if I exit with 60 open files only the 50 most recently used files
> are
> >> opened again ?
> >> Maybe indeed this is just more like a history function, and when
> starting
> >> kdevelop only one file has actually to be opened and all others are
> loaded on
> >> demand (easier if there are no tabs ;-) ).
> >
> > Well, loading on demand means switching to another file might be pretty
> > slow. OTOH if you happen to have 50 files that need to be opened during
> > startup, startup slows down. So what we probably actually should have is
> > asynchronous opening of files, though I guess we can't simply put
> > kate::document into a thread :( And IIRC using timers+eventloop still
> means
> > a slightly lagging Ui while actually loading the document into memory -
> > especially for larger documents.
> What about dropping this "open files" idea completely? We have quickopen,
> we
> have a Context-Browser "back" action and we could probably have a
> recently opened
> files list. There could also be favorite files list - so you can mark
> the files your are working on.
>
> Internally the latest files can still left open (faster).
> Files with unsaved changes also must stay opened.
>
> Niko
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel@kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
[Attachment #5 (text/html)]
What about the files that have been modified but not yet saved? how does the user \
keep track on that?<br><br><div class="gmail_quote">On Sat, Nov 8, 2008 at 4:41 PM, \
Niko Sams <span dir="ltr"><<a \
href="mailto:niko.sams@gmail.com">niko.sams@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 class="Ih2E3d">>> > \
Whats the problem with the documents list or the first 8 files in<br>
>> > quickopen? I understand that you want to keep an overview of what \
you're<br> >> > working on right now, but 8 tabs already fail to work \
for me on my laptop.<br> >> > I already have 2 of them not visible, even \
more if the filenames are a bit<br> >> > longer.<br>
>><br>
>> I agree.<br>
>> Usually I don't close files, so usually I have many open files, more \
than 50.<br> >> Why should I actually close them ? The open-files is for me \
more like a<br> >> history of files which I used recently and may use again \
soon. If I save the<br> >> files I'm working on from time to time it should \
be enough. I actually also<br> >> don't really care if they are indeed open \
and loaded or not.<br> >> Would it make sense to have a maximum number of files \
remembered as open ?<br> >> E.g. if I exit with 60 open files only the 50 most \
recently used files are<br> >> opened again ?<br>
>> Maybe indeed this is just more like a history function, and when \
starting<br> >> kdevelop only one file has actually to be opened and all others \
are loaded on<br> >> demand (easier if there are no tabs ;-) ).<br>
><br>
> Well, loading on demand means switching to another file might be pretty<br>
> slow. OTOH if you happen to have 50 files that need to be opened during<br>
> startup, startup slows down. So what we probably actually should have is<br>
> asynchronous opening of files, though I guess we can't simply put<br>
> kate::document into a thread :( And IIRC using timers+eventloop still means<br>
> a slightly lagging Ui while actually loading the document into memory -<br>
> especially for larger documents.<br>
</div>What about dropping this "open files" idea completely? We have \
quickopen, we<br> have a Context-Browser "back" action and we could \
probably have a<br> recently opened<br>
files list. There could also be favorite files list - so you can mark<br>
the files your are working on.<br>
<br>
Internally the latest files can still left open (faster).<br>
Files with unsaved changes also must stay opened.<br>
<font color="#888888"><br>
Niko<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" \
target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic