--- Marco Cimarosti <marco.cimarosti@...>
wrote:

> Andrew Dunbar wrote:
> > > As Uniscribe module and the editing module run
> > > at the same time, the net effect is that typing
> > > on the keyboard you see text changing on the
> > > screen. But, actually, there is no interaction
> > > between the two modules apart the fact that they
> > > access the same text data in memory.
> >
> > I agree with all of this up until I read "the
> > editing module" - what on earth is that? I've
> > never heard of it before! I guess you mean the
> > application itself (in most cases).
>
> The term "module" may be pretty generic.
>
> I meant, that "part" ("piece", "chunk", whatever) of
> software which handles cursor movements and editing
> actions, including deleting, backspacing, mouse
> actions, etc. This "thing" is distinct from both the
> "thing" which handles the keyboard and the "thing"
> which handles text display.

Well there is no such thing. Certainly no part of the
OS. The keyboard map is part of the OS. Input methods
are part of the OS. Rendering is part of the OS. And
all of these are modular.

There is no central place which handles deleting etc.
For widgest/gadgets/controls (whatever each OS calls
them) there may be OS code which treats these events
in a uniform way. Outside these, in the main window
of an editor or anything else which is not a standard
control, there are only events which are passed to
the application. Every application can do whatever it
wants.

> Of course, this "module" can just be a piece of an
> applicative program (also the display module can:
> not all applications use Uniscribe or similar
> system-level facilities), but most typically it is a
> service supplied by the system.

Well there are very few Windows applications which
don't use Uniscribe at all. Adobe Acrobat would be
one. Other than that, probably just games. All of the
older functions for drawing text are now routed
through
Uniscribe - that's how fancy languages kinda work in
a lot of apps. But they are not Uniscribe aware -
which
is why they only "kinda work".

> E.g., in a typical object-oriented GUI environment,
> the "editing module" is the class which implements
> text boxes. I.e., it is probably a collection of
> methods in a DLL, which implements this logic on
> behalf of all the active instances of the text box
> object.

Well it all depends on the system architects and
developers. In most cases the backspace and delete
keys are handled right in the event loop. In better
designed systems there might be event handler member
functions of classes but in my experience it's all
pretty ad-hoc. Microsoft is an exception.

> In a typical console environment, the "editing
> module" will be the part of operating system which
> handles line-level editing in the TTY console.

Actually I think there are few OSes these days where
the console is part of the OS. They're just programs
these days.

> (BTW, I wonder how much off-topic we are now, in a
> scale ranging from 1 to 100...)

Probably only about 50% (-: I think the people on this
list would be interested to know that editing
characteristics are not modularized and standardized
by the OS or any part of it and are different from
other internationalization aspects for this reason.

Hope I've cleared things up a little but I'm aware I'm
not so great at explaining things.

Andrew Dunbar.

> --
> Marco
>

=====
http://linguaphile.sf.net/cgi-bin/translator.pl http://www.abisource.com





___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com