Re: X and MS .Net
Hi, There is quite a lot of difference between displaying a client in your C# code and embedding an X server in it! Displaying clients in other programs actually has some history in X.org in the Broadway extension to the X server. Basically this is an extension that gives you some of the hooks you need to be able to take the native window handle of a window in another Windows or Mac application and use it in the X server as a client X window handle. When I worked for WRQ, I implemented this feature for their Broadway extension. Any effort to do the other project, porting the whole X server code base to another language, is an enormous project if your goal is to obtain the same levels of performance and reliability. Generally it takes a team of 3 or 4 almost a year to add a DDX layer to support a new graphics hardware device, much less port the DIX layers below that. Doing something along the lines of the Broadway extension is much cleaner, as long as you can run a standard X Server on its own, either on your device as another process or even on a separate machine. The X client is the only process that will absolutely need to run on the device that owns the window you want to display in. One hint though if you go this route. Find a copy of the ICCCM and make sure that the environment that hosts your X Client conforms to any pertinent parts of this document. It is the document that describes how X Window Managers are supposed to behave. Your X Client host will have to act like a window manager to the extent that the client is dependent on the behavior of window managers to display correctly. Bill Asmodehn Shade wrote: Hi, Thanks for the quick reply ;-) Well my program will not be entirely C# I guess as I dont plan to rewrite everything ;-) The goal is just to display a remote X client inside a .Net GUI... I m just looking for the best place to plug my code, so I dont have to reinvent the wheel once more :-p Thanks for the tip, but as I havent read the doc yet, can you give me a quick description about what a DDX is ?? ;-) I will read the doc soon enough Thanks a lot ! 2006/10/8, James Supancic [EMAIL PROTECTED]: On 10/8/06, Asmodehn Shade [EMAIL PROTECTED] wrote: However, I now have to, somehow, embed a Xserver inside a .Net/C# application for my work... and I am wondering how I should do that. I just feel like a cat with a mouse bigger than him ;) Has anyone an idea or just a clue about this ? I just fetched the source, and I am browsing it now... If on the way there are stuff you need help with, that may be related to it, just let me know ;-) Are you sure there is no way around this? Why exactly do you want to do this? The Xorg reference implementation is written in unmanned C. There are DDXs that operate like that, but they are integrated with the X server and written in C. If your program doesn't have to be entirely .NET/C#, you *might* be able to use C# to implement the DDX (or at least part of it) Sorry if this kind of question has already been asked, but I found nothing about it, neither with google, or mailing lists... ( by the way is there a subscription scheme to those ? ) I think the NoMachine NX client is an Xorg DDX based upon the Xnest DDX. I don't think they used C#, but they did build an application around an X server, you might look into how they did it. If you can't use any unmanned code, you can will either have to write a translator to convert the C in Xorg code to C#, find some other X server you can use (I am not aware of any free X servers other than Xorg) or implement a new X server from scratch. Thank you for your time, James Steven Supancic III -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: MultiWindow versus MWExtWM
The issues that arose over the six or seven years were various and particular to each application that some customer was dependent upon. One class of problems you could describe as a clash between window managers, Windows and X . This could easily occur for modal popup windows, override redirect, always on top(Windows) and just the general problem of trying to maintain focus in various focus policies that might conflict between the two management styles. Focus fights were fun to watch... Joe Krahn wrote: billh wrote: Any discussion of internal vs external window management cannot take place without acknowledging the fact that we are talking about XWindows operating within another window system, Cygwin/X. The immediate fact here is that any action that a window manager takes that is synchronous to the actions of the clients, such as on an xterm resize, when the window manager may inforce an incremental sizing based on the character width or heighth has to be handled in the window proc of the X server running as a Windows client, otherwise the sequence of events cannot be the same as in a native X Windows environment. In the case of window resizing, the first order solution has the window being resized to any arbitrary size by the Windows window system, and then a second event where an external window manager would resize the window to a size based on window hints registered with the X Window system. Though this can happen very quickly, there are always side effects typically in older programs that are perhaps more reliant on past behavior of X and even in some cases certain window managers. Okay, I'll fess up. I used to work for WRQ on the ReflectionX server. We found that in fact there were financial reasons, meaning enough customers, to support both approaches. Some customers wanted a more Windows centric look and feel and some needed for compatibility reasons an X window manager. I'm not trying to discuss Win32 WM-proxy versus a true X Window Manager. I'm simply comparing how the Win32 WM is implemented. I think most people would prefer using the Win32 WM, if there were no compatibilty problems. (BTW: what types of compatibilyt problems were there?) What I am aiming toward is Windows-managed windows, but proxied in a way that works more like a native X window manager. This means that most of the WndProc handling needs to be handled by Window Manager code. That's why I suggested WndProc Hooking. I ported GWM to our environment and my associate Kyle went through the ICCCM documents and made our Windows management mode honor all of that documents guidelines for window management. This gave us both modes at the flip of a switch in the control interface gui. For a commercial product, we could justify both. My idea is that WndProc hooking can allow you to turn the internal WM on or off by adding/removing WndProc hooks (or possibly internal hooks.) I'm just suggesting that using the external WM approach will simplify the code; it's rather messy right now. THings may have changed, but i tend to doubt it. PS This is offered in the spirit of openness. I am not saying that you should 'go commercial' for your X in Windows needs. Actually I am currently working on a Linux on Windows product that has its own X Server port via a frame buffer driver. Very cool! Don't port your Linux code, run it natively!!! Joe Krahn wrote: What is the history of internal versus external Win32 WMs? It seems that Cygwin/X is favoring the internal WM, even though the external WM is a better fit to the X server design. I was looking into adding some NET_WM/EWMH features (mainly icons for now), and realized that most things have to be done differently on an internal WM, meaning extra work making non-reusable code. The current external WM is implemented using a proper X extension, which might be the source of some problems with the external WM. Maybe an efficient solution for the external WM would be to use WndProc hooks, so that window message passing can be done natively instead of through an X extension. Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http
Re: MultiWindow versus MWExtWM
Any discussion of internal vs external window management cannot take place without acknowledging the fact that we are talking about XWindows operating within another window system, Cygwin/X. The immediate fact here is that any action that a window manager takes that is synchronous to the actions of the clients, such as on an xterm resize, when the window manager may inforce an incremental sizing based on the character width or heighth has to be handled in the window proc of the X server running as a Windows client, otherwise the sequence of events cannot be the same as in a native X Windows environment. In the case of window resizing, the first order solution has the window being resized to any arbitrary size by the Windows window system, and then a second event where an external window manager would resize the window to a size based on window hints registered with the X Window system. Though this can happen very quickly, there are always side effects typically in older programs that are perhaps more reliant on past behavior of X and even in some cases certain window managers. Okay, I'll fess up. I used to work for WRQ on the ReflectionX server. We found that in fact there were financial reasons, meaning enough customers, to support both approaches. Some customers wanted a more Windows centric look and feel and some needed for compatibility reasons an X window manager. I ported GWM to our environment and my associate Kyle went through the ICCCM documents and made our Windows management mode honor all of that documents guidelines for window management. This gave us both modes at the flip of a switch in the control interface gui. For a commercial product, we could justify both. THings may have changed, but i tend to doubt it. PS This is offered in the spirit of openness. I am not saying that you should 'go commercial' for your X in Windows needs. Actually I am currently working on a Linux on Windows product that has its own X Server port via a frame buffer driver. Very cool! Don't port your Linux code, run it natively!!! Joe Krahn wrote: What is the history of internal versus external Win32 WMs? It seems that Cygwin/X is favoring the internal WM, even though the external WM is a better fit to the X server design. I was looking into adding some NET_WM/EWMH features (mainly icons for now), and realized that most things have to be done differently on an internal WM, meaning extra work making non-reusable code. The current external WM is implemented using a proper X extension, which might be the source of some problems with the external WM. Maybe an efficient solution for the external WM would be to use WndProc hooks, so that window message passing can be done natively instead of through an X extension. Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: re Cygwin/X
Thank you for asking the obvious. I was considering installing cygwin elsewhere on my system. By coincidence this was exactly what I needed. - Original Message - From: Raman [EMAIL PROTECTED] To: cygwin-xfree@cygwin.com Sent: Wednesday, January 19, 2005 6:59 AM Subject: re Cygwin/X Hi I had written to you a couple of minutes back. I think I was able to locate the cygx11-6.dll file. The problem was that the path has to be defined in the cygwin.bat for the XP system to locate the files while executing. I defined the following path SET PATH=%PATH%;C:\cygwin\usr\X11R6\bin;c:\cygwin\bin in the batch and it worked. Sorry for the trouble! Raman
