nanogui: gdk port and nano-X
Subject:
Re: gdk port and nano-X
From:
"Greg Haerr" ####@####.####
Date:
31 Mar 2000 07:03:51 -0000
Message-Id: <038001bf9add$c744fba0$15320cd0@gregh>
: > I think we should certainly change nano-X to address some of these
: > issues. We can certainly look at how these changes may affect
:
: Very good news.
Paolo -
I've commented on some of your needs for porting
GDK to Microwindows.
: > : 5) no properties on windows
: : This are just like X properties, Atom-type-data pairs that are stored
: in windows.
This should be no problem. I'll look into your proposed api.
:
: > We definitely need arcs. line-widths and line-join
: > is more complicated, and probably will come later.
: > Dashes is fairly straight forward. Do we need just
: > plain arcs, or chords and filled pie-slices?
:
: Plain arcs and filled arcs, IMHO.
filled arcs: you mean pie slices or ellipses or filled chords?
This stuff is hard to get right, I might grab the X stuff for implementation.
: Not everyone uses select() to check for input available on the
: socket and it's not safe the way events are stored now (you need
: a list, not a single storedevent to make it right).
You mean that we need to keep lists of events that haven't yet
been delivered to clients?
:
: The window manager in npanel.c is really an hack, you need to
: now when a window is destroyed, you'll need to reparent the window
: in the window manager's own frame window to avoid races, etc.
: For "internal" here I meant a wm internal to the application itself,
: not nano-X, that could be called *bloat*:-)
I hadn't considered that idea before. Keeping the "window
manager" in the client is a potentially interesting idea. But how
would multiple top level windows from multiple clients
look the same?
:
: > We need to fix the external symbol issue ASAP. I can work
: > on that immediately. Shall I start with namelisting the
: > binaries? I've also been working on cleaning up the exported
:
: Actually, the other symbols are all prefixed with either nx or Gr.
: Maybe we can unify them all to Gr, though.
I've fixed this. All API calls start with Gr, as before. All other
extern helper procs and data start with nx.
.
: The problem is that nano-X.h includes device.h and that defines
: all sorts of stuff: MODE, WHITE, BLACK, ...
: This has not been a big issue so far for the port, but still
: having a clean interface makes also for clean programming.
I'll work on this. I'm going to take device.h apart into
a couple of separate files, with attention making it very
clean. We will only export structures when absolutely required,
and all will use a similar naming scheme.
Regards,
Greg
