From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10138 invoked by alias); 18 Nov 2003 21:22:33 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 10091 invoked from network); 18 Nov 2003 21:22:29 -0000 Received: from unknown (HELO smtp800.mail.ukl.yahoo.com) (217.12.12.142) by sources.redhat.com with SMTP; 18 Nov 2003 21:22:29 -0000 Received: from adsl-64-175-251-31.dsl.sntc01.pacbell.net (HELO odysseus.peterslan) (sampln@sbcglobal.net@64.175.251.31 with plain) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 18 Nov 2003 21:22:28 -0000 Subject: RE: Mono, anyone? From: Lincoln Peters To: "Brandon J. Van Every" Cc: Xconq list In-Reply-To: References: Content-Type: text/plain Message-Id: <1069190544.29637.105087.camel@odysseus.peterslan> Mime-Version: 1.0 Date: Tue, 18 Nov 2003 21:28:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00777.txt.bz2 On Tue, 2003-11-18 at 12:56, Brandon J. Van Every wrote: > Lincoln Peters wrote: > > > > Has anyone considered taking advantage of Ximian's (Novell's?) Mono > > project? > > Have you? I can think of a zillion things Xconq *could* have in it... > but I concentrate on the ones I'm fully willing to implement myself. No > harm in asking if someone else is also interested in Mono, but my point > is you have to be the one to lead the effort for that sort of thing. There are only a few things I clearly remember about Mono. One was that, during the presentation, Miguel de Icaza used some kind of CGI script via a web browser to interact with Gnumeric (which was running on another part of the screen). > > > * Allow Xconq to talk to a other application. This may > > initially sound > > silly, but imagine how much easier it might be to play games such as > > bellum.g if you could use a spreadsheet to represent various > > aspects of > > your empire (particularly such things as supply of 'c') using charts. > > It might not be quite so bad for Xconq to behave (to some extent) like > > an office application. > > What I *have* considered, is writing the Windows UI in C# and .NET. I'm > a .NET nunce, I don't know what its GUI features are. Maybe it has some > kind of applicable "spreadsheet form." Thanks for reminding me that > right-click popups won't solve all UI problems, I'll need a National > Budget screen somewhere. As I recall, the .NET UI is not significantly different from the traditional Windows UI. Although I recall him saying that it was rather frustrating, because it doesn't work as well as the widget trees used by GTK+ and GNOME (which can re-size and re-position themselves on their own when needed). While there is a GTK+ widget to reproduce the style of Windows (widgets on a static grid), I don't think that the reverse is true. Maybe I'll have to dig through Ximian's website and try to figure out how he did that Gnumeric trick. It might save a lot of code when you try to create a National Budget screen. > > If I go the C# .NET route, then I'll simply leave it to others to worry > about porting it to Mono. But one thing I've discovered, that I didn't > realize before, is that C# is not exactly a good language for interoping > with C directly. You have to create DLLs and do all this marshalling > stuff, it's a tedious function-by-function job. Either that or wrap > stuff up in Managed C++. Neither would be so bad if the C was legacy > code awaiting conversion to something more modern, but I expect it will > be a live target for some time. I have no interest in chasing the C > coders' tails with my manual labor. My understanding was that if a C# .NET application compiles and runs on Windows, it should work immediately using Mono on Linux (sort of like Java). Although the UI might be tricky, for the reasons I mentioned above. > > So today, I'm looking at Python / C interop. Possibly a "make this more > OO" effort needs to precede C# .NET efforts. Once I have a higher level > construct summarizing the Xconq interactions, use that to bridge to C#. > NET. This is like the idea of wrapping stuff up with Managed C++, > except I'm wrapping stuff up with Python. And then accepting possibly > some more difficulty implementing the interop bridge. You're probably right. I know that, if I wanted to make any significant changes to the Xconq code base, I would want to write OO code, probably in C++ rather than C (for obvious reasons). And I remember that someone was able to successfully compile Xconq as a C++ program a while ago. Does anyone know if that still works? > > Or there's Door #3: finding a Python GUI that has the right-click popup > and spreadsheet tables I need. Another thing I'll be looking at today. > But my concern is there's probably no RAD tool at the same level of > quality as C# .NET in the Python world. I want to bang out GUIs > quickly, not futz manually. There is probably a way, using the .NET developer tools (which I assume you have), to make the Windows version of Xconq talk to Microsoft Excel, thereby allowing Excel to do all of the spreadsheet things. Hopefully, it would be just as easy to make it also work with Gnumeric.