Re: Progress of text system

[Richard Frith-Macdonald]

On Wednesday, February 19, 2003, at 10:03  am, Fred Kiefer wrote:
> > > extension methods are needed here, we should move them to a GNUstep
> > > category. Similar changes should be done to the layout manger files. 
> > > The
> > > current separation into GSLayoutManager and NSLayoutManager is more 
> > > or
> > > less arbitrary.
> > There is nothing arbitrary about this split.
> > GSLayoutManager is a generic layout manager, capable of dealing with
> > arbitrary layouts (horizontal, vertical, mixed, or even more complex
> > stuff). GSLayoutManager is only a dumb storage class for layout; it 
> > has
> > little knowledge about the layout, and can't implement all the methods
> > that NSTextView requires. When you want to handle generic layouts (eg.
> > if you want a layout manager that lets you use vertical layouts in a
> > text view), you subclass GSLayoutManager to get all basic glyph and
> > layout handling (and impose constraints on the layout), implement the
> > methods that NSTextView requires, and subclass GSTypesetter to make a
> > typesetter that lays glyphs out according to your constraints.
> > NSLayoutManager is a layout manager that supports only heavily
> > constrained layouts (normal left->right layout with line frags 
> > strictly
> > arranged in lines, and lines strictly ordered vertically, etc.; a
> > detailed list can be found in NSLayoutManager.m, and includes a lot of
> > things ranging from trivial (but important for simplifications) ~"each
> > text container has at least one line frag", to more complex ~"layout 
> > is
> > affected by context only as far back as to the previous line"). Thanks
> > to these constraints, NSLayoutManager knows a lot about the layout, 
> > and
> > can implement all the methods that NSTextView requires. 
> > NSLayoutManager
> > should be compatible with OPENSTEP's NSLayoutManager (except for
> > "internal, do not call" methods), and will probably be compatible with
> > most of apple's extensions eventually.
> > Merging these classes would severely limit their usefulness. We need a
> > standard layout manager for text views (and its behavior matches what
> > OPENSTEP calls NSLayoutManager), so we would lose GSLayoutManager. 
> > This
> > would make any work on anything more exotic than standard left->right,
> > top->down layout practically impossible.
>
> I have to disagree on this. Even after you put a few more 
> optimisations that only work for left-to-right top-to-bottom layout 
> into NSLayoutManager there are plenty of methods in this file that 
> rather should be in GSLayoutManager according to your definition. I 
> would name the drawing methods, the handling of text container, typing 
> attributes,  text view ruler markers. Other methods should be 
> implemented by calling abstract interfaces that provide the same 
> interface indepenend of the specific layout strategy. This would leave 
> us with only a few methods with internal knowlegde of the layout 
> strategy of NSLayoutManager and of course this are the ones that a 
> subclass must overwrite.
> I don't see any lose in extensability if this is done in one file as 
> opposed to two. Or am I missing your point here? Would you like to 
> have GSLayoutManager for a totally different reason? Could you give an 
> example of using a subclass of GSLayoutManager without a text view?

I haven't looked at the classes in detail, so I'm just talking from 
general principles here ....
I don't see any problem with having multiple implementations in 
separate files, and it makes some sense to me to have a simplified 
implementation for handling layout of western languages. I can see that 
that might allow for some optimisation and might lead to more readily 
comprehensible code ... and the inherent complexity of the text system 
makes code readability particularly important.

However, from Alexanders description, the current layout contravenes 
the standard usage of classes/class clusters ...
NSLayoutManager should be the abstract class providing the general 
implementation, and GSLayoutManager (or perhaps a more meaningful name 
like GSWesternLayoutManager) ought to be the subclass providing the 
specialised/optimised implementation.   When NSLayoutManager is 
instantiated, it would provide a concrete instance of GSLayoutManager 
to actually do the work.  This is the way the naming conventions for 
class clusters normally work, and doing things the other way round 
might confuse programmers.  However, this is just a matter of the 
naming conventions for the classes and does not effect the real 
structure.

So NSLayout manager would provide the capabilities of storing layout 
runs and glyph storage etc, wheras the concrete subclass would provide 
the optimised generation algorithms.  Indeed, if the concrete 
subclasses provided no ivars of their own, it would be possible for 
them to mutate at runtime depending on the
languages used ... so when NSLayoutManager is instantiated it could 
create a  GSWesternLayoutManager, but storage of chinese text might 
make it mutate into a slower but more general GSChineseLayoutManager 
for instance.