gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

work on text


From: Nicola Pero
Subject: work on text
Date: Thu, 28 Dec 2000 03:11:48 +0100 (CET)

Hi

In the past weeks, I worked on the gui text view.  I must apologize for
having had to temporaneously interrupt my work on it - I had actually
planned to work on the text view during these holidays too, but I am
finding out that - due to the fact that I live away from Italy - when I
come back to Italy during holidays my relatives and friends are absorbing
me the whole of my time.  I realize I can't really stop this without
loosing friends and relatives :-) so I have to postpone any proposal for
serious work to after the end of holidays.  I will also be in Spain -
without even an internet connection - from the 29 Dec to 4 Jan. 

The main visible changement is that NSText was made abstract, and all the
text view code is now in NSTextView.  The code was also heavily reshaped.

NSMutableAttributedString and NSTextStorage (the actual fix was done by
Richard, I wrote the guile tests) were fixed - now they should be quite
reliable.

The structure of the text system, from low level to high level, is as
follows:

NSTextStorage - keeps the actual text <Done!>
NSLayoutManager - manages layout of text <code based on layout code in
                  the old gnustep's NSText, currently kept in the
                  concrete subclass GSSimpleLayoutManager>
NSTextContainer - manages the shape of the area text is drawn into <class 
                  quite easy, nearly done>
NSTextView - puts the text system inside the view subtree, manages user 
             input, high level control of text <class under work,
             starting to get into a more final shape>

I have mainly worked on the higher level, NSTextView.  I start to be a bit
familiar with this part, so I plan to go on working on it.

The first item in my TODO list for the text view is implementing complete
and proper sizing/resizing interaction between the text view, the text
container etc.  I plan to implement this - I `take' the job.  So - unless
strictly necessary to work out other parts now, people can assume it will
be done by me in the near future (basically after holidays).

There are quite other parts of the NSTextView which can be improved
separately.  Most of these constitute little tasks - since I had to
interrupt my work (temporarily!) I encourage other interested developers
to pick up things from list, and work them out making sure all is working,
conforming to spec, and well done.  It is *extremely* important to make
sure that you are not breaking existing code.  The existing code has a
very long and complex history - as a result very refined and tuned parts
are mixed to drafty and buggy (or even missing) parts and it's important
that people make sure they are only improving things when they do
modifications - ie, they do not accidentaly break the finely tuned parts
while working on the buggy ones.  I say it because I found it very
difficult myself to modify things without breaking anything - and even
more difficult to put things back in order once they are broken :-).  But
it must be said I was doing large-scale reshaping of code.  Anyway, here
is a first task list. 

.1. cut/copy/paste can be worked out quite separately.  It should be
working, but there is a problem with fonts: when pasting in Ink.app, fonts
get corrupted during pasting.  For example, the first word (`INK') is
`Nimbus Sans L 16 pt' on my system but when I copy and paste it, it is
pasted in the different font `Nimbus Sans L Bold-Condensed 16 pt'.  Some
comments inside the cut/copy/paste code suggest also that improvements can
be made on the way it's implemented internally.

.2. implementing a blinking cursor could probably be done quite separately
again.  [But please make sure this can be disabled with a user default as
I am a traditional-emacs-guy and don't like blinking stuff on my screen
:-)]. 

.3. spelling 

.4. smart insert/smart delete

.5. making sure moving the cursor works (there are still problems)

I will implement all this stuff myself (leaving .1. as the last one) 
[since I consider them part of the text view] as soon as I get the time to
do it. 

The other big task is rewriting from scratch the layout manager.  This is
really an important task now - mainly most bugs in the text view, most
slowness, most things you may want to improve are in the end in the layout
manager.  The rest still needs work - but I have to admit at this point it
can even be difficult to work on the rest if the layout manager does not
work.  The good news is that the layout manager is quite a localized,
encapsulated class, and shouldn't be so difficult to implement.  My strong
suggestion is that we do all complete from the very beginning - with
glyphs and all the stuff.  Once the data structures to use are chosen, and
the basic algorithms are designed, it shouldn't really be difficult.  I'd
really like to help with this if we can do a coordinate effort.  I can
probably spend time implementing, testing and debugging it in January - a
bit per day - in the evening before going to bed ? :-) - once the basic
design is ready. 

Ah - a last thing - I did some experiments in optimizing.  For example,
when you move the cursor, there is a check to see if you are moving past
the end of the text.  If you follow the path of the code, you will find
out that this check requires *copying* the full text into a temporary
string!  I think this is quite inefficient - if not a real bug - it can
very easily be improved but in my rough experiments with Ink.app I could
see no difference in performance - reasonaly because the string is quite
little and copying it for each keypress is reasonably fast on my 433 but
if the text were big it could be quite different - so just as a curiousity
I'd really like to measure with big texts before doing the change.  But I
had a bit the impression that the current layout manager is so slow that
this copying of the string is really a drop in the sea now, that's why no
difference is seen.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]