Re: xlib library and window server
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/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
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
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.
