This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: OT Python stuff (was RE: Python in Xconq)


Bruno Boettcher wrote:
>
> uhm perl-gtk, perl-tk?

There is also Py + tk, pygtk, pySDL, pyKyra... basically Python has all
those typical bindings too.

Everyone is going to have their favorite language.  If we can't settle
on someone else's language, then we need interop capabilities.

Which furthermore implies an architecture where that's possible /
reasonable without pouring blood on the table.  I think a major
OO-ification of the code base needs to happen to make it usable /
extensible to people who aren't intimately familiar with it already.  We
need an OO migration path.  Nobody has the resources to swallow the
problem all at once, there are hundreds and hundreds of functions to
contend with.

Eric McDonald wrote:
>
> (1) Richard mentioned to me yesterday that each additional piece
> of external software that becomes an Xconq dependency is an
> additional annoyance. If you build tkconq then you need Tcl/Tk,
> and if you build sdlconq then you need SDL. Do we really want to
> say that we also need Perl (which is fairly ubiquitous on Linux,
> but not necessarily so on other platforms) or Python (which is
> admittedly a nice language, but still not as widespread as Perl,
> AFAICT)?

If you are a developer, and there are docs on how to install all these
packages, and they actually work, then you have no buisiness
complaining.

If you are a game player, then everything has to install as one big app,
so that people don't have to chase it.  Python has to be embedded, Perl
has to be embedded, TCL has to be embedded....


Cheers,
Brandon


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]