[Gtk-sharp-list] New (stupid) application :)
Tue, 11 Nov 2003 19:20:12 -0500
I could go for a complete example, too...
On Tue, 2003-11-11 at 10:23, Philip Van Hoof wrote:
> With complete I mean:
> - Multi languages support (po)
po is rather Unix specific.
The .NET approach would be "manifest resources" and
In general, it's similar to Java's .properties files for language
The benefit to this is that the apps could run unchanged under .NET,
while .po files would likely require the gettext libraries.
Alas, I have no examples to point you to, but MSDN should have some.
> - A correct build procedure with automake/autogen/autoconf
I believe the current verdict is to avoid the auto* tools unless you
need them. C/C++ code needs them, but managed code shouldn't (unless
you're also building native libraries for P/Invoke purposes).
This is the general strategy for most of the purely managed tools in
> - The right files in CVS, the right files in .cvsignore
Everything goes in CVS. :-)
.cvsignore should have anything that's automatically generated, and
would likely include:
> - The correct programming methods for
> - Glade-Sharp
Use the [Widget("widget-name")] attribute and Glade.XML.Autoconnect:
Glade.XML gxml = new Glade.XML (null, "myglade.glade",
Note that the first parameter is the Assembly to read the .glade file
from; if null, it reads the .glade file from a resource compiled into
Use "-resouce:filename" to add a filename resource on the mcs command
> - OO techniques and GUI programming with Gtk-Sharp
I can't help you there.
> - HIG correct
Read the HIG?
Granted, I *still* haven't read the HIG (and I've been wanting to!), so
I'm not one to talk. But reading the HIG and talking asking questions
on email@example.com is probably the safest bets:
> Basically I want this application to be as correct as humanly possible
> and I want it to be like a sample application for Gtk-Sharp projects. So
> that I can use it to teach people how to actually correctly prepare and
> create Gtk-Sharp projects succesfully.
I agree that this is a desirable goal. It's one of my unstated goals
with type-reflector (CVS module: type-reflector).
However, there isn't a whole lot of documentation running around about
what the best practices are (at least, I haven't sen any), so it seems
that a lot of this is up-in-the-air.