On 01/05/2010 23:00, Hans-Peter Diettrich wrote:
Martin schrieb:
-----
About the german translation:
1) Editoren mit selben Kriterien, => die 2te uebersetzung ist
fehlerhaft. Im englischem heisst es "zuletzt fokussiertem Fenster"
(Fenster fehlt derzeit in der Uebersetzung)
2) "Kriterien nach denen ein Editor gewaehlt wird" muesste sein
"Prioritisierte Kriterien-liste, nach denen ...."
The list is evaluated top-down (entries are ordered by priority)
?
The list is ordered, with the most recently used page/window(?) at the
begin(?)
I was speaking about the list of rules on the config page. not any list
of editors.
See also the wiki/help with F1 => it has additional explanations.
-----
"in view" versus "in centered view"
The english choice of description is already bad, and better
suggestions are welcome.
The background:
In the past many function that set the cursor (current debug line,
jump to bookmark, jump to...) have in the past *always* set the
cursor to the *exact* center of the screen.
Why that? :-(
Don't know. they did
As a result the editor always would scroll, even if the line was well
within the visible area. That is irritating if you jump between 2
points that are both visible. Or in debugging, pressing F8 would
always scroll (which again according to feedback I had, was seen as
irritating)
+1
The new concept (still work in progress), is to define an area of the
screen as acceptable centered area. (depending on the height of the
editor, between 2 and 8 lines from top/bottom), and avoid scrolling,
if the jump-target-location is in this area. ( locked-editors can
use the full visible are, as they will not scroll, even if your jump
target is right on the first (or last) visible line)
I remember a ScrollIntoView method, that can (should?) do nothing when
the caret already is in the visible part of the text.
yep, within SynEdit,
but SourceEditor goes a step further, it kicks in, when the caret goes
into the last few rows before the end (or start) of the screen. Usefull
with debug-exe-line, => you keep seeing the next few lines (rather than
pressing F* into the unknown, when at the bottom line of the editor)
An unlocked editor should only be choosen, if the jump-target is in
this area, because this means it will not need to scroll (not always
true yet, work in progress)
Again, better naming is welcome.
Again, we IMO should wait for a final implementation, before
describing technical details.
there may be extensions, but the foundation has been layed, and I am
hopeful it will not need to change.
e.g. editor locking as such does exist as featur, and will keep doing so.
But then again, if need to change is there (not talking about bugs, but
talking about the idea behind the implementation) => so if anyone thinks
the idea, I tried to implement is wrong and should change => then best
to tell me now.
I have updated some of the english descriptions, after reading the
german translations.
------
unrelated
In der deutschen Uebersetzung ist die Meldung fuer das erfolgreiche
Kompilieren der IDE: ">>IDE<< beendet"
Sollte besser "IDE kompilieren beendet" sein? Schliesslich ist die
IDE selber ja nicht beendet.
Stimmt.
BTW, which text and translation are we talking about? ;-)
kompiliere die IDE (via tools menu) => die letzte Meldung im messages
Fenster.
English: ""IDE" completed"
Deutsch: ">>IDE<< beendet"
actually t isn't >> / << but the single char quotes of that kind
Die englische Nachricht ist auch recht kurz. Aber im deutschem muesste
es dann heissen: "IDE fertig" (as in Die neue IDE ist fertig)
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
