As promised...
Quoting meself:
> Here are the thing I know I need/should/want to do, in no particular order:
>
> Make sure Y is 64-bit clean.
I should be able to get this done today. It should be a case of looking through
the code for "int" and "unsigned" and replacing them with int32_t, uint32_t,
size_t, off_t, ptrdiff_t, etc as appropriate.
> Implement a shared memory transport mechanism -- should give local apps a bit
> of a speed boost.
I'm going to do this with shm_open/mmap rather than shmat/shmget. It's just a
wee bit easier to manage the namespace if you're working with strings rather
than 32-bit ints. I'll extend the network protocol to include a
try-and-negotiate-shared-memory phase, so apps shouldn't know which one they're
on.
> Port gvim.
So I can develop Y in Y.
> Implement a screen lock.
Shouldn't be too hard -- replace the whole desktop with a plane in a cheap
colour (black for CRTs white for LCDs), and stick an unlock box in the centre
of each viewport.
> Get a list of every known widget on the face of the earth, and use it to:
> * work out the simplest set of primitives required to make it possible to
> build every widget
>
> * work out which [widgets] need to be implemented for v1.0
These are hard. Getting the list probably involves trawling the docs on msdn,
adc, motif, qt, gtk, et al.
> Come up with a way of doing themes which does not preclude building a
> hardware Y terminal.
Something like nvidia's Cg, but for theming (Ct?). Some language which can
express everything you might need to express in order to theme something, but
is simple enought that we can check it for security. Bytecode compiled from
this language could then be JIT compiled and executed within the server at
runtime.
> Work out the API for video playback.
This'll involve a nasty trawl through the xine-lib source to see what would be
the easiest API to provide.
> Work out the sound API -- will need to coordinate it with the above.
As above really. Will probably want a non-video-coordinated version first so we
can write yTunes...
> Build all the regular desktop apps (file manager, etc).
Too obvious to comment on. Some of these will need to be heavily commented so
people can use them as crib sheets.
> Remote viewports, input devices etc.
So we can do desktop forwarding, hotdesking (terminal services style), and
remote control big screen demos for trade shows...
> XFree86/X.Org driver stealing.
So I can use native Y without wasting my GeForce FX.
> Port Gecko (probably as a widget), then firefox+thunderbird.
Self explanatory.
> GL support.
Shouldn't be too hard to rig up a pass-through for the SDL hosted versions.
Doing it native will be trickier unless we've managed to nick X drivers.
> X protocol emulation.
So I can emerge -C x11-base/xorg-x11.
> Suspend/resume of entire Y sessions.
Will be realistically impossible without app support. We're going to need
callbacks here.
Any comments are of course welcome,
Regards,
Phil
--
Quanti canicula in illa fenestre?
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.