[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Why not to use implement functionality using X mechanisms
From: |
Richard Frith-Macdonald |
Subject: |
Why not to use implement functionality using X mechanisms |
Date: |
Thu, 10 Jan 2002 09:12:37 +0000 |
OK, this is about the pasteboard ... but the 'X' in the subject equally
applies to various
other platform specific functionality, so the 'X' could actually be the
algebraic 'x' for
unknown.
OpenStep was originally supposed to a cross-platform system designed to
insulate the programmer
and user from system dependencies (though commercial realities forced
NeXT to drop this radical
approach and concentrate on the modest one of making it a system to help
programmers port apps).
I believe that this aim is one that GNUstep inherited, and I certainly
did ... The developers
of GNUstep certainly put quite a lot of thought into making it as
portable and flexible as
possible, and trying to make it simple/consistent so that it's easy to
port ... we *do* want
to eventually run on many platforms.
So, if there is a practical, portable way to implement required
functionality, we should always
implement that mechanism rather than using a platform specific one.
One of the biggest factors (probably *the biggest*) in determining what
is 'practical' is the
fact that we are a small development team, with a huge task. So we
always have to be very
careful to spend our time effectively. We need to keep the codebase as
small as possible
with as little system specific code as possible, so we can maintain and
port it. If we
implement OpenStep functionality using platform specific code, we are
effectively locking
ourselves into that platform. If on the other hand, we use generic
code, there is no such
lockin.
When it comes to communicating with other non-GNUstep systems, we
sometimes have to use the
platform specific code compatibility code. In this case it makes sense
to -
1. Use as little platform dependent code as possible (keep the codebase
small)
2. Implement generic code first and add the compatibility code as an
optional extra (avoid lockin)
Now, we have to be particularly careful about the X-window system ...
since there really is no
alternative platform yet, anything that makes GNUstep apps work better
in an X environment
will be used by everyone and will be supported at the expense of generic
mechanisms, thus
locking us even more into X. So we need to do our utmost to make sure
that we implement these
improvements in a generic way.
People are working on getting the gui stuff running in Windows-NT ...
if/when that is done and
windows users start really playing with GNUstep, I imagine the problem
will become much more
severe, but it will be dependency on microsoft specific code we will be
fighting to avoid.
On the other hand, having real competition between X and windoze systems
might encourage us to
write generic code ... I really hope so.
Back to the pasteboard ... recent discussions have highlighted two
flaws -
1. The appkit doesn't know about remote hosting, so doesn't currently
connect to the correnct
pasteboard server when you use the X specific DISPLAY environment
variable to get the app to
display on a remote host. Actually, this is not limited to the
pasteboard. the gui layer
won't handle workspace interaction properly either. However, this is
all simple to fix and
I'll probably add a -NSHost command line option to do it soon.
2. There is a theoretical situation where two GNUstep apps run on
separate hosts which have no
network connection between them, and display on a third host which won't
run the pasteboard
server. In this case pasteboard operations can't work using the GNUstep
pasteboard server
directly, but would work using the X-clipboard, because the X server
would mediate the
communications between pasteboard servers used by the apps. So here our
implementation would
be very inefficient.
Normally, I'd say that if someone was willing to implement an contribute
a native implementation
of some functionality to supplement a generic mechanism, that would be
great. In this case I
think that the benefit is so small that any such work should be
discouraged, and adding such
a thing to the codebase might even be more of a maintenance liability
than it's worth.
PS. This does not apply to use of the drag-and-drop clipboards, in this
case the complexity of
integrating the X mechanisms into generic code is higher than that of
writing a relatively
standalone X implementation in the backend, so here we are pretty much
forced to use the
native clipboard mechanism directly, and only referring to the
pasteboard server for DnD
of complex/large items of data being transferred between GNUstep apps.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Why not to use implement functionality using X mechanisms,
Richard Frith-Macdonald <=