Mono, anyone?

Mono, anyone?

[Lincoln Peters]

Has anyone considered taking advantage of Ximian's (Novell's?) Mono
project?  I remember seeing a presentation on Mono by Miguel de Icaza at
LinuxWorld in San Francisco last year, and it sounded like it would
allow us to do some interesting things.  For example:

* 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.
* Write different parts of Xconq in different languages.  This might
make it easier to add scripting capability to Xconq (it might even make
it possible for Xconq to support all the scripting languages that have
been discussed so far).
* Make it easier to support all of the platforms that Xconq is supposed
to run on.

I don't know how well compatibility between Mono and Microsoft's .NET
framework stands, and it wouldn't really surprise me if Microsoft
changed .NET to make Mono incompatible.  However, I imagine that, even
if Microsoft pulled the plug, that Mono would still be a useful tool for
the reasons I listed above.

RE: Mono, anyone?

[Brandon J. Van Every]

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.

> * 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.

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.

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.

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.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Re: Mono, anyone?

[Eric McDonald]

Hi Lincoln,

On Tue, 18 Nov 2003, Lincoln Peters wrote:

> * 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. 

This sounds like a good idea. Gnome (and I think Qt, as well) has 
an embedded object architecture, iirc. And, of course, Microsoft 
does, so one could instantiate a MSExcel object within Xconq, for 
instance. But as a cross-platform solution goes, I would have to 
look; maybe the Ximian stuff is such; I will look at it.

> It might not be quite so bad for Xconq to behave (to some extent) like
> an office application.

As long as Xconq Office does not have any annoying office 
assistants, such as Clippy, the Ammo Clip.

Eric

RE: Mono, anyone?

[Lincoln Peters]

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.

Re: Mono, anyone?

[Lincoln Peters]

On Tue, 2003-11-18 at 13:01, Eric McDonald wrote:
> Hi Lincoln,
> 
> On Tue, 18 Nov 2003, Lincoln Peters wrote:
> 
> > * 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. 
> 
> This sounds like a good idea. Gnome (and I think Qt, as well) has 
> an embedded object architecture, iirc. And, of course, Microsoft 
> does, so one could instantiate a MSExcel object within Xconq, for 
> instance. But as a cross-platform solution goes, I would have to 
> look; maybe the Ximian stuff is such; I will look at it.

I didn't get a chance to attend LinuxWorld in San Francisco this year,
but it sounds as if Ximian is still going strong on this project (I
heard that Mono received some kind of award, something like "#1 open
source project of the year").  And I expect that if they reasonably*
can, they'll use the same protocols as Microsoft applications, so that
you could just as easily embed MS Excel into Xconq as you might embed
Gnumeric.

* It's a totally different story if Microsoft refuses to disclose the
protocols, the protocols contains myriad security holes, or it is
grossly inefficient.

> 
> > It might not be quite so bad for Xconq to behave (to some extent) like
> > an office application.
> 
> As long as Xconq Office does not have any annoying office 
> assistants, such as Clippy, the Ammo Clip.

Although I suppose that, in some games, it might be interesting to have
a comparable assistant.  Perhaps Julius the military adviser could offer
free advice to those who play roman.g.  But I think we can all agree
that, if such a thing is to ever be implemented, it should be manually
enabled and set up by the game module and easily turned off by the
player.

Of course, it would open the door for a new generation of incredibly
annoying game modules ("You are about to send 1 infantry against 3
legions.  Its chance of survival is 15%.  Do you want to proceed?").

RE: Mono, anyone?

[Eric McDonald]

On Tue, 18 Nov 2003, Lincoln Peters wrote:

> 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?

Yes. I did it with g++ last week. There was a small issue with 
sys/time.h not being wrapped in extern "C" which caused some 
link-time troubles. I am committing a fix for that tonight, among 
other things.... I believe Hans has also built it as a C++ app 
recently, perhaps with CodeWarrior.

However, Xconq is still at a C89 compliance level. Hence my 
recent efforts to provide a substitute snprintf implementation....

Eric