Re: [9fans] plan9port libdraw

Re: [9fans] plan9port libdraw

[David Leimbach]

Seems I spoke a bit too soon on this port.  SDL is really great if you
are just going to allocate a statically sized screen and then never
resize but X11 seems a bit better if you need windows to expand and
shrink.

I'm not very sure an SDL port would be either easy or a very good idea.

I'll have to learn to live with running X11.app until I learn otherwise.

That or porting to Carbon might be a good idea but I have 0 experience
with that, and it would only help Mac OS X users.

It was an interesting head-first dive into libdraw though :)... not a
complete wash.

Dave

Re: [9fans] plan9port libdraw

[David Leimbach]

Alright I don't know how the heck I missed this... I was just looking
through my old SDL
code and never once dealt with any kind of resizing.  I guess I need
to think again on this.

http://sdldoc.csn.ul.ie/sdlresizeevent.php  <-- clearly can handle resize...


Dave


On Sat, 15 Jan 2005 11:18:01 -0800, David Leimbach <leimy2k@gmail.com> wrote:
> Seems I spoke a bit too soon on this port.  SDL is really great if you
> are just going to allocate a statically sized screen and then never
> resize but X11 seems a bit better if you need windows to expand and
> shrink.
> 
> I'm not very sure an SDL port would be either easy or a very good idea.
> 
> I'll have to learn to live with running X11.app until I learn otherwise.
> 
> That or porting to Carbon might be a good idea but I have 0 experience
> with that, and it would only help Mac OS X users.
> 
> It was an interesting head-first dive into libdraw though :)... not a
> complete wash.
> 
> Dave
>

[9fans] plan9port libdraw

[David Leimbach]

a while back someone mentioned porting libdraw to Carbon.  Would it
not be better for overall portability to move it to SDL?  Someone
ported Inferno to the Linux Framebuffer but I think if they had done
it with SDL we'd have it for Carbon as well now.

I'm giving serious thought to taking this one on as a native Sam/Acme
on many of my OSes would be better than requiring X IMO.  [even
windows perhaps.]

Dave

Re: [9fans] plan9port libdraw

[William Josephson]

On Wed, Jan 12, 2005 at 01:13:55PM -0800, David Leimbach wrote:
> a while back someone mentioned porting libdraw to Carbon.  Would it
> not be better for overall portability to move it to SDL?  Someone
> ported Inferno to the Linux Framebuffer but I think if they had done
> it with SDL we'd have it for Carbon as well now.
> 
> I'm giving serious thought to taking this one on as a native Sam/Acme
> on many of my OSes would be better than requiring X IMO.  [even
> windows perhaps.]

If you submit some patches I'm sure Russ or I would be more
than happy to take the time to consider them.  I think, however,
that we would like to retain the ability to support platforms
that have only the standard X libraries.  At least I would since
there are machines of interest that I don't have root on and don't
have SDL.  In other words, another implementation of the interface
would probably be warmly received.

 -WJ

Re: [9fans] plan9port libdraw

[Russ Cox]

> a while back someone mentioned porting libdraw to Carbon.  Would it
> not be better for overall portability to move it to SDL?  Someone
> ported Inferno to the Linux Framebuffer but I think if they had done
> it with SDL we'd have it for Carbon as well now.
> 
> I'm giving serious thought to taking this one on as a native Sam/Acme
> on many of my OSes would be better than requiring X IMO.  [even
> windows perhaps.]

Go for it.  The X11 code needs to be separated a bit better
from the rest of the code, but it's not too bad (it was completely
separate once).  Please feel free to contact me if you get even
just a little stuck or need help getting your bearings.

I would never dream of dropping the X support though.  
I run acme all the time over ssh -X -C and it is fantastic.

Russ

Re: [9fans] plan9port libdraw

[David Leimbach]

On Wed, 12 Jan 2005 16:38:02 -0500, Russ Cox <russcox@gmail.com> wrote:
> > a while back someone mentioned porting libdraw to Carbon.  Would it
> > not be better for overall portability to move it to SDL?  Someone
> > ported Inferno to the Linux Framebuffer but I think if they had done
> > it with SDL we'd have it for Carbon as well now.
> >
> > I'm giving serious thought to taking this one on as a native Sam/Acme
> > on many of my OSes would be better than requiring X IMO.  [even
> > windows perhaps.]
> 
> Go for it.  The X11 code needs to be separated a bit better
> from the rest of the code, but it's not too bad (it was completely
> separate once).  Please feel free to contact me if you get even
> just a little stuck or need help getting your bearings.
> 
> I would never dream of dropping the X support though.
> I run acme all the time over ssh -X -C and it is fantastic.

SDL can use X11 as a backend, or the Linux framebuffer, or GGI or whatever
other backends they've implemented.

> 
> Russ
>

Re: [9fans] plan9port libdraw

[William K. Josephson]

On Wed, Jan 12, 2005 at 04:12:25PM -0800, David Leimbach wrote:
> SDL can use X11 as a backend, or the Linux framebuffer, or GGI or whatever
> other backends they've implemented.

Yes, but I really, really don't want to have to depend on it.
It is one thing to support and an entirely different thing to
require it.  I use the Plan 9 ports in some pretty minimal
environments where I don't want to have to pull in SDL.

 -WJ

Re: [9fans] plan9port libdraw

[David Leimbach]

On Wed, 12 Jan 2005 21:24:42 -0500, William K. Josephson
<jkw@eecs.harvard.edu> wrote:
> On Wed, Jan 12, 2005 at 04:12:25PM -0800, David Leimbach wrote:
> > SDL can use X11 as a backend, or the Linux framebuffer, or GGI or whatever
> > other backends they've implemented.
> 
> Yes, but I really, really don't want to have to depend on it.
> It is one thing to support and an entirely different thing to
> require it.  I use the Plan 9 ports in some pretty minimal
> environments where I don't want to have to pull in SDL.
> 
>  -WJ

I have no intention to remove the X support :).
>

Re: [9fans] plan9port libdraw

[David Leimbach]

> Go for it.  The X11 code needs to be separated a bit better
> from the rest of the code, but it's not too bad (it was completely
> separate once).  Please feel free to contact me if you get even
> just a little stuck or need help getting your bearings.

Heh.... well this does look like it will be a little bigger a job than
I originally thought.  Still I think it's probably worth it but I don't
think it's any "weekender" :).

Looking at files like keyboard.c vs x11-keyboard.c a lot of
functions are pretty close to the same except inner I/O 
handling functions.  Part of my problem is not really knowing
the X11 APIs very well and as a result trying to understand 
what some of the code is doing is getting tricky.

I was a decent SDL programmer a few years back but I never 
really did much with X11. :)

Hopefully this will be more educational than frustrating.

Dave

Re: [9fans] plan9port libdraw

[Russ Cox]

> Looking at files like keyboard.c vs x11-keyboard.c a lot of
> functions are pretty close to the same except inner I/O
> handling functions.  Part of my problem is not really knowing
> the X11 APIs very well and as a result trying to understand
> what some of the code is doing is getting tricky.

Note that keyboard.c and mouse.c aren't actually
compiled.  They're just reference copies of the Plan 9
versions.

> I was a decent SDL programmer a few years back but I never
> really did much with X11. :)
> 
> Hopefully this will be more educational than frustrating.

If what you say about SDL being somewhat model-independent
is true, then it shouldn't be too bad.  The only files you'll need
to provide are equivalents to the x11-*.c in libdraw.
Some you can stub out (like x11-cload.c, where you
can just remove the if and its body), some will translate
fairly directly (like x11-mouse.c and x11-keyboard.c),
and others should have the non-X-dependent pieces split
out of them (like x11-init.c).  In all, though, it's only 2,500
lines of code, so it shouldn't be too bad.  And you definitely
don't need to understand X.  

If you have questions, feel free to ask.

Russ

Re: [9fans] plan9port libdraw

[David Leimbach]

> Note that keyboard.c and mouse.c aren't actually
> compiled.  They're just reference copies of the Plan 9
> versions.

I figured as much when looking at the duplicate functions.

> 
> > I was a decent SDL programmer a few years back but I never
> > really did much with X11. :)
> >
> > Hopefully this will be more educational than frustrating.
> 
> If what you say about SDL being somewhat model-independent
> is true, then it shouldn't be too bad.  The only files you'll need
> to provide are equivalents to the x11-*.c in libdraw.
> Some you can stub out (like x11-cload.c, where you
> can just remove the if and its body), some will translate
> fairly directly (like x11-mouse.c and x11-keyboard.c),
> and others should have the non-X-dependent pieces split
> out of them (like x11-init.c).  In all, though, it's only 2,500
> lines of code, so it shouldn't be too bad.  And you definitely
> don't need to understand X.
> 

I guess what I need to know is what is expected in and out of some
of these functions and the best description I get is the existing X code.

Sometimes the data in  is just a void * like in the _ioproc function for 
keyboard.c... It's immediately handled through a Keyboardctl pointer though
so that's not so bad.

I've already done a copy of all the x11-*.c to sdl-*.c and am working on those.

> If you have questions, feel free to ask.

I certainly will :)


Dave

> 
> Russ
>

Re: [9fans] plan9port libdraw

[Charles Forsyth]

>>not be better for overall portability to move it to SDL?  Someone
>>ported Inferno to the Linux Framebuffer but I think if they had done
>>it with SDL we'd have it for Carbon as well now.

possibly, but having looked at SDL quickly just now,
i'd say that if the framebuffer man had done that, it would
have complicated things for me with Inferno: SDL doesn't just implement the graphics
level, but everything else as well.  it's effectively a plan9ports with
a different programming interface: it has got its own threads,
mutexes, events, ..., all of which i suppose get involved at some point
when invoking the graphics.

Re: [9fans] plan9port libdraw

[David Leimbach]

On Wed, 12 Jan 2005 22:40:29 0000, Charles Forsyth
<forsyth@terzarima.net> wrote:
> >>not be better for overall portability to move it to SDL?  Someone
> >>ported Inferno to the Linux Framebuffer but I think if they had done
> >>it with SDL we'd have it for Carbon as well now.
> 
> possibly, but having looked at SDL quickly just now,
> i'd say that if the framebuffer man had done that, it would
> have complicated things for me with Inferno: SDL doesn't just implement the graphics
> level, but everything else as well.  it's effectively a plan9ports with
> a different programming interface: it has got its own threads,
> mutexes, events, ..., all of which i suppose get involved at some point
> when invoking the graphics.
> 

Having actually written code and maintained another library on top
libSDL I'd say
that's not quite fair :).  SDL isn't as rigid as you might think.  Yes
sometimes you have
to lock a surface for direct access but you can directly access it.  

That said, it's been years since I've done anything significant with
SDL and this wouldn't
be a bad way to get back into it.  

Also the popular QEMU emulator doesn't seem to have problems with
using SDL for it's
purposes and it works on a lot of platforms too.

Let's see how far I get before we declare defeat.

Dave

>

Re: [9fans] plan9port libdraw

[Charles Forsyth]

>>SDL isn't as rigid as you might think.

i wasn't criticising its rigidity, so much as scope.
even then, i wasn't criticising the scope, so much as
observing that it's really a different plan9port (portability layer), so
if you use SDL to port plan9port, then you've got
an extra portability layer in the way.  English as She is Spoke.
perhaps the analogy is porting things to plan 9 using APE.