KDE/kdevplatform/shell

[Niko Sams]

>> > 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