Re: xlib library and window server

2011-03-28 Thread EBo

On Mon, 28 Mar 2011 08:51:23 -0700, ron minnich wrote:

oh, geez, how did I so misread yiyus' fine idea. I'm like a living ad
for caffeine and healthy sleep schedules :-)


Sorry Ron but this is such a quotable quote, and one I have so often 
been a runner up for ;-)


  EBo --

--
You received this message because you are subscribed to the Google Groups Plan 9 
Google Summer of Code group.
To post to this group, send email to plan9-gsoc@googlegroups.com.
To unsubscribe from this group, send email to 
plan9-gsoc+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/plan9-gsoc?hl=en.



Re: xlib library and window server

2011-03-28 Thread yy
2011/3/28 Jeff Sickel jeff.sic...@gmail.com:

 Speaking as an Inferno and P9P user on OS X, I definitely do not want
 more X11 libraries linked in as that would prevent emu from launching
 on certain hosts.  So I'm not inclined towards a libxdraw on my
 primary 9vx, p9p, and Inferno hosts.

OS X support is not going away from Inferno, p9p or 9vx with this
project. The xlib dependent code is already there, and is almost the
same in all of them. The idea behind this project is refactoring
existing code in a new library, to avoid duplicated code, but from the
point of view of an user you won't see any difference. In fact, if you
are an OS X user you won't notice any difference at all, since the
build process will take care of not building the X11 support.

I don't mind getting rid of the x in the xwsys name, but a window
server for OS X or Windows would be a different project. I don't have
the experience (or even testing equipment) to work on a multi-platform
solution. This proposal is only for the X implementation.

As I said I tried to do this project past years. One of my main goals
was indeed to turn devdraw into a 9P server, but it has its own
problems (I changed some mails with Russ, I can share them with you if
you are interested). At the end of the day, the only advantage of a 9P
drawing device would be that it will let you to run graphical apps in
the same window that you are running 9term, but you would need
9pclient and, therefore, libthread (now, it is possible to write a
single-threaded p9p graphical program). I don't think this should be a
priority, a standalone wsys which could be used from 9vx, drawterm and
Inferno would be far more useful. Do you (or anybody else) have a real
need for a devdraw 9P server in p9p?


-- 
- yiyus || JGL .

-- 
You received this message because you are subscribed to the Google Groups Plan 
9 Google Summer of Code group.
To post to this group, send email to plan9-gsoc@googlegroups.com.
To unsubscribe from this group, send email to 
plan9-gsoc+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/plan9-gsoc?hl=en.



Re: xlib library and window server

2011-03-28 Thread ron minnich
Yep, this is a great idea :-)

ron

-- 
You received this message because you are subscribed to the Google Groups Plan 
9 Google Summer of Code group.
To post to this group, send email to plan9-gsoc@googlegroups.com.
To unsubscribe from this group, send email to 
plan9-gsoc+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/plan9-gsoc?hl=en.



Re: xlib library and window server

2011-03-28 Thread Jeff Sickel
Libdraw, libmemdraw, and libmemlayer, among others, have
diverged in all four of your targets.

I'm just pointing out that there are subtle differences that
are not X11 specific.  All the projects have cleanly broken
out code for handling x11:

drawterm/gui-x11/*
inferno/emu/port/win-x11*.c
$PLAN9/src/cmd/devdraw/x11*
vx32/src/9vx/x11/*

They all leverage an API presented in libdraw.

P9p's devdraw presents the best case as it is run as a
separate process that helps minimize problems with a program
not having the native window event handler running in the
main thread.  Yes you can write a single threaded p9p program,
colors(1), you just get a multi-threaded devdraw running in
the background doing the dirty work.

My question is: why write libxdraw from paragraph two in your
draft?  I'm suggesting mergin the changes found in p9p's
libdraw, libmemdraw, etc and rolling them into the drawterm,
9vx, and Inferno versions.  I know that at least for Inferno
that's larger task than a simple refactoring, but worth it.

The best part, paragraph three, is creating a devdraw
replacement ala xwsys that also talks 9p (authenticated of course).
The stubs are already in drawclient.c _displayconnect() (it
would be nice to have it be accessed as a flag on the command
line in addition to the DEVDRAW environment variable).
This would be good not only for X11, but for anyone willing
to take the time to port to OSX, QNX, Windows, Android, iOS,
etc.  If you need to bypass the overhead of devdraw, you
can add your own routines to statically link into a Plan 9
influenced code instead of using execl() to launch devdraw.

-jas

-- 
You received this message because you are subscribed to the Google Groups Plan 
9 Google Summer of Code group.
To post to this group, send email to plan9-gsoc@googlegroups.com.
To unsubscribe from this group, send email to 
plan9-gsoc+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/plan9-gsoc?hl=en.