[Gtk-sharp-list] New (stupid) application :)

[mefreaxspam@freax.be]

Quoting Jonathan Pryor <jonpryor@vt.edu>:

Sorry or formatting, I am replying this using a webclient (horde)

> I could go for a complete example, too...
> 
> More below...
> 
> 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
> System.Resources.ResourceManager.

Okay, But I was hoping on a way to convert po to manifest resources. The reason
why is because all current translator software is based on the po format. Also
are the current GNOME and Gtk+ translation teams focussed on that format and
way of working.

We (Gtk-Sharp) programmers will have a hard time trying to convince those people
to switch to another format. IMHO it would be better if somebody builds a
convertor and a way to get it into the compilation steps. So the po-convertion
should happen before the compilation, and the compilation could include them as
resource-files into the build.


> In general, it's similar to Java's .properties files for language
> translation.
> 
> The benefit to this is that the apps could run unchanged under .NET,
> while .po files would likely require the gettext libraries.

Indeed, I agree that there are benefits in using the standard .NET way for this.
Thats why I think that a convertor for po to manifest resources should be
written at some point. Or is there such a tool available already?

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

But I like the auto* tools :-)!

No, not really. However. Using the auto* tools "correctly" will make it a lot
more easy for packagers to package the application. I am building a Linux
application. Platform indendancy is nice but it's not what I am trying to do.
Okay, it would be nice if my application could run on both Windows and Linux.
But my primary goal is to get it run on Linux, and then make stuff work on
Windows. I know that this goal is not very nobel for the Windows people :-).


> This is the general strategy for most of the purely managed tools in
> Mono.
> 
> > - The right files in CVS, the right files in .cvsignore
> 
> Everything goes in CVS. :-)

Except when you use the auto* tools :-)

> .cvsignore should have anything that's automatically generated, and
> would likely include:
> 
> 	*.dll	
> 	*.exe
> 	*.pdb
> 	*.dbg

Okay

[CUT about Glade and OO]

> 
> >   - 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 usability@gnome.org is probably the safest bets:

I have read it. Everybody should do that ! :-)

> 	http://mail.gnome.org/archives/usability/
> 

> 
> I agree that this is a desirable goal.  It's one of my unstated goals
> with type-reflector (CVS module: type-reflector).

Okay, I will checkout that module soon and try to mimic those parts that
actually look good (in terms of getting things as correctly as possible).

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

It seems that somebody needs to start thinking about such issues (like, when
once should use the auto* tools or when once should use Nant or or or custom
Makefiles or build using whatever new tool shipped with Mono. And how to do
multi languages correctly, and stuff like that). Then somebdoy should write
everything down :). Soon!

Maybe we could start a draft ?