[Lazarus] RFC: remove StayOnTop for splash screen

[Flávio Etrusco]

Can you (people) stop hijacking my thread? :-P

On Tue, Mar 2, 2010 at 10:50 AM, Hans-Peter Diettrich
<DrDiettrich1 at aol.com> wrote:
> Martin schrieb:
>
>>> IMO the IDE should use an cache for the SynEdits, that must contain at
>>> least the currently active text file. More opened files can be parsed and
>>> added to the cache later, when they are really activated. When the systems
>>> runs out of memory, old entries can be removed from the cache. Inactive
>>> files can be parsed in the background, when the system is idle.
>>
>> Well there are 2 option. Actually both can exist at the same time.
>>
>> 1) SynEdit scanning on idle. I had that idea for a long time already, but
>> a lot more needs to change in SynEdit, before this can be done.
>> 2) The IDE only opening a tab, and defer creating the SynEdit. I haven't
>> looked into this.

3) SynEdit defer the parsing of files until they are shown.
4) All options above. Actually I don't think 1 is necessary if the
bottlenecks are found.


> With multiple editor windows, the files must be kept (and parsed...) in
> their own pool, separate from the SynEdit viewers.

Why?

>> Then again. My PC is about 3 years old, with an average of 10 - 20
>> SynEdits, it takes 1 to 2 seconds of parsing. Opening a 100 files on loading
>> of the IDE may be a legitimate action, and may have good reasons, and
>> certainly can be justified by personal choise => but how many people are
>> affected by it?

We should make this better. Martin Waldenburg would die in disgust if
he reads this hehe

>
> That depends on the meaning of "open". The filenames can be imported from a
> project or desktop layout file, into the file pool. Actual loading can be
> deferred until the files really are required in the IDE.

Deinfetely.

> Even if newer machines have enough power to process a huge number of files
> within a few seconds, I'd take care for users with old equipment - who else
> would do, if not Lazarus? Virtual machines also can have less RAM, and
> performance can become very poor once such a system starts swapping.
>
>
>> Caching, and removing? why re-invent the wheel. It has a similar effect
>> than the OS doing swaping memory to swap-file...; And you have to keep a
>> copy of all open files, just in case they get modified on disk, while they
>> are in memory.
>
> When the user has not seen an file already, it doesn't matter whether it was
> modified on disk. Whenever a modified file becomes active in the editor, the
> user should be asked whether the file should be reloaded, so that parsing of
> inactive files may be a waste of resources.
>
>
>> Also having looked at the gprof numbers, the time seems to be lost while
>> assigning the keycodes. Which seems to be done in a very inefficent manner.
>> My guess is that the IDE-defaults/user-configs are merged with the SynEdit
>> defaults, and during this probably each code is tested for existence (looked
>> up) first, before potentially being added. Given that there are 100of key
>> combos, which have to be iteraded a 100 times (and this is for each
>> synedit...) => well (rather not so well).
>

... ok.

> I just don't understand what you mean. The SynEdits should *perform* edit
> commands, but the *detection* of keycodes is the job of the framework (IDE).
>

Yeah. But we must implement two/multiple keystroke ActionList handling.


 Maybe creating just

>> It get's on the todo list now (but little priority).
>> one merged list, and then simply clear+copy for each synedit.
>
> That's a wrong approach, IMO.
>

(Now I'm lost)


Best regards,
Flávio