RE: [LINUX5250] win32 update

[Scott Klement <tn5250@xxxxxxxxxxxxxxxx>]

> It seems that Jay 'Eraserhead' Felice <jfelice@xxxxxxxxxxxx> was the guy 
> doing the python port. But seeing that is last check-in was in 2001, I 
> would simply ignore the changes.

So, your suggestion is to throw away Python support altogether?  That's 
actually just fine with me, I've never used it, so not having it won't 
bother me at all!

However, there have been several requests for it, so I think there are 
probably people who are interested in seeing it happen.  Unfortunately, 
none of them have picked up the reins and done the job.

> The python code could be branched since it seems it will never be 
> updated, we could:
> - branch the current HEAD to b0-17-python and not use it anymore.
> - update the b0-16 branch with the latest code of the current HEAD without the python code.
> - promote the b0-16 branch to HEAD.
> - go the 1.0 :) I hate 0.x version numbers :)

There are some other minor changes (aside from the Python and GLIB 
support) in the 0.17 branch. I don't really want to throw them away. If 
nobody is going to develop the Python code, I could see removing just that 
code from HEAD and making that into our branch for development.

> Three is a limit of keeping 2 branches over 3 years if you want active 
> developpement...

Don't blame the messenger...  Mike Madore and Jay Felice have done the 
majority of development on this project. They're the ones who decided what 
goes in which branch.

> Otherwise, we could simply add
> #define g_malloc malloc
> #define g_free   free
> in tn5250-private.h in the b0-16 branch just to have much less 
> discrepancy between the branches.

I think we should either use GLIB or not use GLIB. I don't think using 
#define hacks to work around it is a good solution. If we're going to use 
GLIB as Mike wanted to way back when, then let's actually use it instead 
of using #define trickery.


> For instance, the only differences in macro.c between the branches are 
> allocation functions. This doesn't need to be. I'm willing to do the g_ 
> adding to the b0-16 branch. As you can see, I have some time to put on 
> the project. But I'd prefer my first solution, i.e. create a new 
> "stable" release soon and stop keeping unfinished (?) code indefinitely.

Like I said, I'd be quite happy to throw away the Python code -- it 
doesn't do me any good, I don't know any Python programming at all.  I'd 
be completely happy to get rid of it.

S/Lang is another thing that I think is just bit-rot waiting to happen. 
Does anyone use S/Lang support?  Does anyone even care about it?  When you 
guys are making all of these changes to the terminal objects, are you also 
changing slangterm?

What about the GTK terminal?