plib-devel

Re: [Plib-devel] Creating shared libs or plib under Linux

[steve <sjb...@ai...>]

Hans de Goede wrote:

> It seems to me that plib development is a bit stuck at everyone waiting
> one Steve and Steve not having time todo any work on plib, why don't you
> (the community) take over / why doesn't Steve hand over leadership to
> someone else?

I've certainly been too busy with paying work to give PLIB the time it
deserves.

However:

* I don't run this like Linus runs the kernel - I'm not the sole
   'gatekeeper' of the golden sources.

* There are 24 registered developers - any of whom can incorporate
   patches into CVS, update documents, maintain the website, etc
   You don't need me to do this.  Here are the 24 developers:

   Alex Perry  		alexperry
   Bram Stolk 		bram
   Curtis Olson 		curt
   Gerard Decatrel 	deca
   Bert Driehuis 	driehuis
   John F. Fay 		fayjf
   Gil Carter 		gilcarter
   J�rgen Marquardt 	j_marquardt
   Giancarlo Niccolai 	jonnymind
   Will Lachance 	lachancew
   Per Liedman 		liedman
   Mark K Vallevand 	markus5
   Dave McClurg 		mcdave
   Norman Vine 		nhv
   Nick McEvoy 		nmcevoy
   James Jones 		puggles
   J. Nathan Matias 	rubberpaw
   Steve Baker 		sjbaker
   Eric Lavigne 		smokydiamond
   Sam Stickland 	sps196
   M�rten Str�mberg 	stromberg
   Sebastian Ude 	ude
   Wolfram Kuss 		wolfram_kuss
   Ben Woodhead 		zander76

* I don't believe I've ever turned down anyone who requested developer
   status.  If you plan to regularly commit patches and you aren't a
   developer - let me know and I'll give you CVS access.

* The only tasks you really need me to help out with are those that
   require admin privilage:

   + Mailing list settings.
   + Making releases.
   + Creating new developers.
   + Doing stuff like transitioning CVS to SVN.

Sooner or later my workload will reduce and I'll get active again - it's
just not practical right now - sorry.

Re: [Plib-devel] Creating shared libs or plib under Linux

[steve <sjb...@ai...>]

Hans de Goede wrote:
> 
> Bram Stolk wrote:
> <snip>
> 
>>But first: what is the exact reason for you wanting to have shared libs?
>>Do you want to package multiple plib games for a distro and need to spare
>>the redudancy?
>>
> 
> 
> We already ship multiple plib games and plan to package more in the
> future. It isn't about sparing the redundancy in terms of diskspace, let
> alone the very theoretically lower memory usage when running multiple
> plib using games at once (who would want to run multiple games at once).
> 
> There is only one reason for wanting shared libs and thats a very good
> reason: with shared libs if a bug is found in plib (and no piece of code
> is bugfree) we only need to release an updated plib package which the
> fixed shared libs and all plib using programs / games will magicly pick
> up the bugfix.

That's another urban legend.

I've been supporting these kinds of applications since before Tux the
Penguin - A Quest for Herring was released in 1998.  Here is the
truth:

All it takes is something like:

   class ssgThing
   {
     char *second ;
     int first ;
   public:

     void setFirst ( int x ) { first = x ; }
     void setSecond ( char *y ) ;
   }


...then in the '.cxx' file:

   void ssgThing::setSecond { char *y ) { second = y ; }

...then, a year later, some enthusiastic contributer looks at
'class ssgThing' and thinks it would look nicer if the
fields 'first' and 'second' were in the right order...

   class ssgThing
   {
     int   first ;
     char *second ;
   public:

     void setFirst ( int x ) { first = x ; }
     void setSecond ( char *y ) ;
   }

(or he adds a variable - or changes it's type or adds a virtual
function or changes a defaulting parameter or...almost anything
acutally)

...now we recompile the library and rerelease it - and KABLOOIE - every
single dynamically linked binary crashes because 'setFirst' in the
application scribbles over 'second' in the library and you get the
weirdest crashes in formerly working applications.

To be clear here - there was no bug in the older PLIB, no bug in the
newer PLIB and no bug in the application...yet still it crashes.

Dunno about you - but I don't fancy trying to debug a fatal crash
in a working program running on a working library - when the only
feedback we get from end users is "It crashed".

Since the poor end user has NO IDEA that some application happens to
use PLIB, he'll have no idea why installing some library that some
new game needs causes his favorite old game to crash when it worked
perfectly before.

So whilst there are times when upgrading PLIB might fix bugs in older
applications - there are just as many times when it CAUSES bugs in
perfectly working programs.

If those old applications had actually been TESTED, released and
were working when whatever version of PLIB they compiled against
couldn't possibly have had any really serious bugs that those
applications cared about.

So - no - this doesn't help the stability of PLIB applications - it
makes them MUCH less stable.

Re: [Plib-devel] Creating shared libs or plib under Linux

[steve <sjb...@ai...>]

Hans de Goede wrote:
> 
> Martin Spott wrote:
> 
>>I suggest to put this idea of adding such a 'shared-library-mode' to
>>the 'official' PLIB source tree on hold as long as there's no
>>maintainer who'll try to take care of backwards compatilbility with
>>previously issued binaries.
>>
> 
> 
> I agree indeed the most important thing for plib now is to someone
> actually stand up and say this looks like a cool project for me and then
> starts pulling the kart, he doesn't need to be alone, but someone has to
> take the lead. Preferably this someone would be approved by Steve.

My reluctance to go with shared libraries relates to the nature of
a C++ package.

With a C library, the interface to the package is essentially defined
by the library.  So long as you don't add or subtract parameters from
functions, you can pretty much compile against any header and link to
a dynamic library and either it'll work - or you'll get linker errors.

You can use (for example) the OpenGL header from OpenGL 1.0 and if your
program compiles OK, it'll link just fine against any version of OpenGL
after 1.0.   If you link against the OpenGL 2.0 header then if you only
use functions from the 1.0 subset, your code will STILL link and run
against OpenGL 1.0 libraries - and even if you use one of the more
modern features, you'll get a runtime linker error and you'll know
you have a problem - cleanly and clearly.

With a C++ library - a substantial fraction of the code is defined by
the classes in the '.h' files - and there are frequently a bunch of
things like inline functions and such.

Someone can do something a simple as changing the order of function
definitions within a class - and if they are virtual functions, the
application will compile and link - and yet fail totally mysteriously
at runtime if it's not linked against precisely the right version
of PLIB.  The failure will be some very strange core dump that will
not immediately scream "WRONG VERSION!"...this is a pain to diagnose.

We know this is a problem even for OS'es where code is predominantly
distributed as binaries - but when you have source distro's for so
many games and such you end up depending on header files being
up do date with whatever '.so' is going to be picked up at runtime.

This is bad enough - but if there are multiple '.so' files on the
hard drive - some installed by the distro and others by the end user -
the result is frequently a horrible mess.  Yes, if it's "done right",
it all works OK - but look back through the archives and you'll see
that the number of users who screw up their setups is horrifyingly
large.  If you have one set of PLIB headers in /usr/include
and another installed (perhaps by the distro) in /usr/X11/include
and yet a third set in /usr/local/include ...then you don't know
for sure whether the application linked against /usr/lib or
/usr/X11/lib or /usr/local/lib....you truly have no idea what's
going on.

This causes a LOT of complaints about non-working code that crashes
in totally strange ways that are virtually impossible for us to
diagnose via email...especially with just a handful of people who
are prepared to help out.

So these are all the reasons why '.so' files are a pain.

The positive benefits of '.so' files IN THIS CONTEXT are less:

1) By sharing libraries, application binaries consume less space
    both on disk and in RAM.  This is great for libc libm and so
    forth - but how many PLIB applications do we have on disk and
    in RAM?  It's negligable.

2) There are horrible problems with commercial apps linking against
    GPL'ed libraries unless they are '.so'.   This is urban legend.
    A "GPL" library would indeed be a problem for commercial code
    that had to link as a '.a' - but go read the PLIB license.  We
    use 'LGPL' - it specifically allows commercial apps to link to
    the '.a' without nasty encumberances.  This is a total red
    herring.  Forget about it.

So - I'm very reluctant to have PLIB build as a '.so' - it'll cause
no end of maintenance problems with essentially zero benefits.

With '.a' files, at least you can distribute binaries that are
pretty much guaranteed to work - and so long as we stick with the
rule that PLIB is *ONLY* installed in /usr/include/plib and /usr/lib,
we'll have sources that always compile against matching headers and
libraries - so we won't have problems with source builds.

This approach hasn't been arrived at lightly - we thought A LOT
about this in the very early days of PLIB and I don't think much
has changed since.

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

Fay John F Dr CTR USAF AFSEO/SK wrote:
> Folks,
> 
> 	To Hans de Goede, hello and welcome to the PLIB community.  I am
> also relatively active in PLIB, particularly the PUI part of it.
> 

Hi,

Nice to meet you.


> 
> 	Steve Baker decided to make PLIB statically linked, and only
> statically linked, so that game executables would be self-contained rather
> than having to link at runtime to half a dozen libraries.  He made that
> decision a decade ago, however, and you might want to ask if he wants to
> reconsider.
> 

Copy and paste from my reply to Bram:

It seems to me that plib development is a bit stuck at everyone waiting
on Steve and Steve not having time todo any work on plib, why don't you
(the community) take over / why doesn't Steve hand over leadership to
someone else?

You still didn't answer my question, does a proper written shared lib
support patch have a chance of getting merged? I know ask Steve, well
since he is not answering I'm asking you (the community) so what do you
think?

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

Martin Spott wrote:
> 
> I suggest to put this idea of adding such a 'shared-library-mode' to
> the 'official' PLIB source tree on hold as long as there's no
> maintainer who'll try to take care of backwards compatilbility with
> previously issued binaries.
> 

I agree indeed the most important thing for plib now is to someone
actually stand up and say this looks like a cool project for me and then
starts pulling the kart, he doesn't need to be alone, but someone has to
take the lead. Preferably this someone would be approved by Steve.

Notice that I'm not that someone, I'm interested in plib, willing to
create patches etc, but I'm not going to pull the kart.

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Martin S. <Mar...@mg...>]

Hans de Goede wrote:

> Yes, proper library versioning is always important when creating shared
> libs and often is used as an argument against shared libs, but one would
> expect a library to have a stable API/ABI only changing it on a major
> new release.
> 
> If you need to change your API/ABI often you didn't do a good job with
> your API design in the first place.

As Bram already wrote there was no focus on creating shared libraries
from PLIB at all - your criticism is waste. You'd probably better
discuss such issues with Steve, not with the poeple who spend their
time for keeping PLIB alive,

	Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

Bram Stolk wrote:
> Bram Stolk wrote:
> 
>> Let me see if I can dig up the original reasoning for not doing shared
>> libs, and see if they hold up today. (I'm affraid they do, though :-)
> 
> These arguments from 1999 still seem quite compelling :-)
> 
> http://lists.debian.org/debian-mentors/1999/11/msg00038.html
> 
>    bram
> 

Yes, proper library versioning is always important when creating shared
libs and often is used as an argument against shared libs, but one would
expect a library to have a stable API/ABI only changing it on a major
new release.

If you need to change your API/ABI often you didn't do a good job with
your API design in the first place.

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Martin S. <Mar...@mg...>]

Hans de Goede wrote:
> Bram Stolk wrote:
>> I believe that it was Steve Baker's intention to do static only,
>> to avoid issues with incompatibilities.
>> 
>> Basically, static libs are more foolproof.
> 
> Actually static libs are a very good ways to keep being bitten by old
> bugs.

I agree that in most situations this is actually the case. PLIB is a
bit different here ....

When you look at the facts, PLIB, still having active contributors, is
actually without maintainer. The former maintainer, as Bram already
noted, intended to have static PLIB only.  Previously, backwards-
compatibility was intentionally and explicitely not cared about - and I
myself have been bitten by this several times when I was maintaining my
own PLIB-shared-library patch for a while.
Currently PLIB is a moving target, the most actual 'release' is what
you get out of CVS today; sometimes people add patches that break
building PLIB on other people's platform and nobody cares .... (I've
been bitten by this as well).

I suggest to put this idea of adding such a 'shared-library-mode' to
the 'official' PLIB source tree on hold as long as there's no
maintainer who'll try to take care of backwards compatilbility with
previously issued binaries.

Cheers,
	Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

Bram Stolk wrote:
<snip>

> But first: what is the exact reason for you wanting to have shared libs?
> Do you want to package multiple plib games for a distro and need to spare
> the redudancy?
> 

We already ship multiple plib games and plan to package more in the
future. It isn't about sparing the redundancy in terms of diskspace, let
alone the very theoretically lower memory usage when running multiple
plib using games at once (who would want to run multiple games at once).

There is only one reason for wanting shared libs and thats a very good
reason: with shared libs if a bug is found in plib (and no piece of code
is bugfree) we only need to release an updated plib package which the
fixed shared libs and all plib using programs / games will magicly pick
up the bugfix.

The other scenario requires me (the plib maintainer) to poke everyone
who maintains a plib based package todo a rebuild and requires end users
to download many updated games instead of a single update.

This is only one reason but a _very_ important reason. Actually one of
the things I as a packager (and others) spend quite a bit of time on is
to remove copies of library-sources from sources as distributed by
upstream. You have no idea how many times upstream developers think lets
make it easier for end users to compile this and drop copies of
libraries they need into the source tarbal. I think before we started
cleaning things like this up an average linux distro had atleast 30
copies of zlib in its source archives, until the zlib security bugs
started hitting us, scrambling out 30 security fixes which should have
been just 1 is no fun (at all). Now the zlib scenario was even worse,
because the packages did not only need a rebuild but all those separate
copies needed separate patching first!

So now most distros (atleast Debian and Fedora) try to avoid this as
much as possible. Debian has been shipping a plib patched to build .so
files for ages, Fedora hasn't been shipping plib for long and fixing
this has been on our todo from day one.

Just to make things clear the question isn't if Fedora is going to be
shipping shared libs for plib, the question is if this is going to be a
patch on top of plib which we will have to maintain for as long as we
ship plib or if this can be integrated upstream. Where I ofcourse prefer
getting things integrated upstream.

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Bram S. <br...@sa...>]

Bram Stolk wrote:

> Let me see if I can dig up the original reasoning for not doing shared
> libs, and see if they hold up today. (I'm affraid they do, though :-)

These arguments from 1999 still seem quite compelling :-)

http://lists.debian.org/debian-mentors/1999/11/msg00038.html

   bram

Re: [Plib-devel] Creating shared libs or plib under Linux

[Bram S. <br...@sa...>]

Hans de Goede wrote:
> 
> Bram Stolk wrote:
> 
>>Hans,
>>
>>There is a whole list of pending bugfixes on the mlist.
> 
> 
> Is there a single place where one can easily see an overview of these
> fixes? That would be of great help to people building plib packages for
> Linux distros like me.

Well... the submissions come in from the mailing list, so you can
check the mailing list archive, or else check cvs logs.

> 
> Do these patches apply against 1.8.4 or against CVS?

Depends on what the submitter used.

> Talking about CVs is the current CVS significantly different from 1.8.4,
> any API changes?

I know of at least some api changes: classes were moved (and renamed)
from pu to puAux.

> 
> 
>>The development of plib is awaiting a migration.
>>sf cvs service is f****d up.
>>
> 
> I'm a contributer to other sf hosted projects and sf CVS is working fine
> for them. I would like to suggest to not freeze development and instead
> keep using CVS for now. Once a SVN move is iactually going to be happen,
> then its time to freeze. I don't see how freezing now, while the SVN
> migration has no clear timeline, is going to help plib development.

Well... it may not be the fastest way for plib devel, but at least
it avoids double work where patches may have to be applied twice.

And yes... I just checked the SF status page, and CVS seems to be back up.

> 
> 
>>Steve mentioned his intent on moving to SVN, and then
>>plib dev can resume.
>>
>>Steve, do you have a status update to the svn migration?
>>
> 
> 
> It seems to me that plib development is a bit stuck at everyone waiting
> one Steve and Steve not having time todo any work on plib, why don't you
> (the community) take over / why doesn't Steve hand over leadership to
> someone else?

I don't have time to maintain plib.
I have some spare time to assist with some work on it, but not to be
the main maintainer.

I just want plib to be in a stage as fit as possible, when I release
my own plib based game. For this I'm helping out both plib and opende
to get a solid release.

> 
> Regards,
> 
> Hans
> 
> 
> p.s.
> 
> You still didn't answer my question, does a proper written shared lib
> support patch have a chance of getting merged? I know ask Steve, well
> since he is not answering I'm asking you (the community) so what do you
> think?

Well, I've come to know Steve as a very knowledgable engineer. Often, what
seemed to be reasonable suggestions, were quite professionaly analyzed by
him, and afterwards you had to agree that his insights were pretty spot on.

Let me see if I can dig up the original reasoning for not doing shared
libs, and see if they hold up today. (I'm affraid they do, though :-)

But first: what is the exact reason for you wanting to have shared libs?
Do you want to package multiple plib games for a distro and need to spare
the redudancy?

   Bram

> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

Bram Stolk wrote:
> Hans,
> 
> There is a whole list of pending bugfixes on the mlist.

Is there a single place where one can easily see an overview of these
fixes? That would be of great help to people building plib packages for
Linux distros like me.

Do these patches apply against 1.8.4 or against CVS?

Talking about CVs is the current CVS significantly different from 1.8.4,
any API changes?


> The development of plib is awaiting a migration.
> sf cvs service is f****d up.
>
I'm a contributer to other sf hosted projects and sf CVS is working fine
for them. I would like to suggest to not freeze development and instead
keep using CVS for now. Once a SVN move is iactually going to be happen,
then its time to freeze. I don't see how freezing now, while the SVN
migration has no clear timeline, is going to help plib development.


> Steve mentioned his intent on moving to SVN, and then
> plib dev can resume.
> 
> Steve, do you have a status update to the svn migration?
> 

It seems to me that plib development is a bit stuck at everyone waiting
one Steve and Steve not having time todo any work on plib, why don't you
(the community) take over / why doesn't Steve hand over leadership to
someone else?


Regards,

Hans


p.s.

You still didn't answer my question, does a proper written shared lib
support patch have a chance of getting merged? I know ask Steve, well
since he is not answering I'm asking you (the community) so what do you
think?

Re: [Plib-devel] Creating shared libs or plib under Linux

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Folks,

	To Hans de Goede, hello and welcome to the PLIB community.  I am
also relatively active in PLIB, particularly the PUI part of it.

	Yes, PLIB is licensed under the LGPL, but this does not mean that
you can't build commercial games with it.  To the best of my knowledge, you
only need to submit your code to the community (make it open-source under
LGPL) is if you modify the _source code_ of PLIB.  Using the object
libraries in your executable does not count and you can keep your
application source closed.

	Steve Baker decided to make PLIB statically linked, and only
statically linked, so that game executables would be self-contained rather
than having to link at runtime to half a dozen libraries.  He made that
decision a decade ago, however, and you might want to ask if he wants to
reconsider.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-883-1284
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Hans de Goede
Sent: Friday, June 02, 2006 3:58 PM
To: PLIB Developers
Subject: Re: [Plib-devel] Creating shared libs or plib under Linux



Bram Stolk wrote:
> I believe that it was Steve Baker's intention to do static only, to 
> avoid issues with incompatibilities.
> 
> Basically, static libs are more foolproof.
> 

Actually static libs are a very good ways to keep being bitten by old bugs.
What happens when a static lib gets a bugfix? Either all packages build
against the previous version must be rebuild, or they keep the bug.

> Then again, is plib LGPL?
> If so, you cannot create a commercial game with plib and use a static 
> lib. LGPL requires dynamic libs.
> 

Yes PLIB is LGPL, but that is a rather black and white explanation of the
LGPL (I'm not saying its wrong though).

But you seem to be the most active plib developer at the moment, are you
interested in a patch adding sharedlib support. (Notice this will require
that you keep the ABI to plib stable between major releases.
Expanidng is ok, changing not. See my fullscreen patch as an example how you
can safely expand the ABI (99% == API)).

Regards,

Hans


_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Creating shared libs or plib under Linux

[Bram S. <br...@sa...>]

Hans,

There is a whole list of pending bugfixes on the mlist.
The development of plib is awaiting a migration.

sf cvs service is f****d up.
Steve mentioned his intent on moving to SVN, and then
plib dev can resume.

Steve, do you have a status update to the svn migration?

  Bram

Hans de Goede wrote:
> 
> Bram Stolk wrote:
> 
>>I believe that it was Steve Baker's intention to do static only,
>>to avoid issues with incompatibilities.
>>
>>Basically, static libs are more foolproof.
>>
> 
> 
> Actually static libs are a very good ways to keep being bitten by old
> bugs. What happens when a static lib gets a bugfix? Either all packages
> build against the previous version must be rebuild, or they keep the bug.
> 
> 
>>Then again, is plib LGPL?
>>If so, you cannot create a commercial game with plib and use
>>a static lib. LGPL requires dynamic libs.
>>
> 
> 
> Yes PLIB is LGPL, but that is a rather black and white explanation of
> the LGPL (I'm not saying its wrong though).
> 
> But you seem to be the most active plib developer at the moment, are you
> interested in a patch adding sharedlib support. (Notice this will
> require that you keep the ABI to plib stable between major releases.
> Expanidng is ok, changing not. See my fullscreen patch as an example how
> you can safely expand the ABI (99% == API)).
> 
> Regards,
> 
> Hans
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

Bram Stolk wrote:
> I believe that it was Steve Baker's intention to do static only,
> to avoid issues with incompatibilities.
> 
> Basically, static libs are more foolproof.
> 

Actually static libs are a very good ways to keep being bitten by old
bugs. What happens when a static lib gets a bugfix? Either all packages
build against the previous version must be rebuild, or they keep the bug.

> Then again, is plib LGPL?
> If so, you cannot create a commercial game with plib and use
> a static lib. LGPL requires dynamic libs.
> 

Yes PLIB is LGPL, but that is a rather black and white explanation of
the LGPL (I'm not saying its wrong though).

But you seem to be the most active plib developer at the moment, are you
interested in a patch adding sharedlib support. (Notice this will
require that you keep the ABI to plib stable between major releases.
Expanidng is ok, changing not. See my fullscreen patch as an example how
you can safely expand the ABI (99% == API)).

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Bram S. <br...@sa...>]

I believe that it was Steve Baker's intention to do static only,
to avoid issues with incompatibilities.

Basically, static libs are more foolproof.

Then again, is plib LGPL?
If so, you cannot create a commercial game with plib and use
a static lib. LGPL requires dynamic libs.

  Bram


Hans de Goede wrote:
> Hi,
> 
> First a short intro (again). I'm a Linux enthousiast / programmer and a
> packager for Fedora Extras which is an online community that packages
> software in the native package format for Fedora Core a (well known)
> Linux distribution.
> 
> I've recently taken over as the plib Fedora package maintainer and I'm
> going to create a new plib-1.8 package which will create shared
> libraries (.so) files instead of the .a files which plib-1.8 currently
> creates. Note that other distros like Debian and Ubuntu already do this.
> (there are very good reasons to prefer .so files even for very small
> pieces of shared code)
> 
> Now I can quickly hack something together for the .so file creation (as
> debian has done) or do this properly. Hacking something together is much
> quicker for me. Thus the question is are you (the plib developers)
> willing to merge proper written shared lib patches into plib cvs and
> thus plibs next release? If you are then I'll go and create proper
> patches if not the hackish way sounds tempting.
> 
> Thanks & Regards,
> 
> Hans
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

Hi,

First a short intro (again). I'm a Linux enthousiast / programmer and a
packager for Fedora Extras which is an online community that packages
software in the native package format for Fedora Core a (well known)
Linux distribution.

I've recently taken over as the plib Fedora package maintainer and I'm
going to create a new plib-1.8 package which will create shared
libraries (.so) files instead of the .a files which plib-1.8 currently
creates. Note that other distros like Debian and Ubuntu already do this.
(there are very good reasons to prefer .so files even for very small
pieces of shared code)

Now I can quickly hack something together for the .so file creation (as
debian has done) or do this properly. Hacking something together is much
quicker for me. Thus the question is are you (the plib developers)
willing to merge proper written shared lib patches into plib cvs and
thus plibs next release? If you are then I'll go and create proper
patches if not the hackish way sounds tempting.

Thanks & Regards,

Hans

[Plib-devel] PATCH: (proper) fullscreen support for plib

[Hans de G. <j.w...@hh...>]

Hi,

First a short intro. I'm a Linux enthousiast / programmer and a packager
for Fedora Extras which is an online community that packages software in
the native package format for Fedora Core a (well known) Linux distribution.

I've send the mail below to sjbaker about 2 weeks ago, but got no
response. Further investigation has learned that plib now a days seems
to be maintained by other people, thus I now send this to the plib-devel
list.

I've been busy the last 2 days packaging tuxkart which uses plib. During
this packaging I've found both a bug and a missing feature in plib, wich
are both fixed by the attached patch:
-The bug is that plib (pw) creates a resizable window, but that tuxkart
  expects the window to always be the size it has specified iow it
  expects a non resizable window. Now one could concider this a bug in
  tuxkart, but its not uncommon for games to be written to a hardcoded
  resolution and not written for a resizable window. Besides making the
  window non resizable is much easier then fixing tuxkart. To fix this
  I've added a new function:
  void pwSetResizable ( bool enable ) ;
  The default behaviour is still to create a resizable window because I
  didn't want to break the api and/or change any default behaviour.
-The missing feature is the fact that plib doesn't have fullscreen
  support, atleast not really:
  * Its possible to create a fullscreen window by passing -1
    for width and height and disabling the border. But I've tried this
    (6 months ago or so) and there were issues (If I remember correctly
    the gnome panel was on top of the window).
  * Besides the issues their is the problem that in that case your
    desktop size gets used and the application thus cannot specify the
    size it wants (see above). Also the desktop size usually is a rather
    high resoltution which peformance wise is not ideal for 3D games.
  * Last but not least with the current "fullscreen" code its not
    possible to switch between fullscreen <-> window easily.
  * The attached patch uses XF86VidMode to switch to the requested
    resolution instead of always using the desktopsize and it allows
    easy fullscreen <-> window switching:
    void pwSetFullscreen () ;
    void pwSetWindowed () ;
    void pwToggleFullscreen () ;
  * Notice that I've choosen not to reuse the border flag for the new
    fullscreen support, so that the behaviour of plib is 100% identical
    for apps who do not use these new functions. If an app wants to use
    the new fullscreen code it must call pwSetFullscreen () after
    pwInit.
  * Some apps don't want to show a cursor when fullscreen, whereas a
   hidden cursor in windowed mode is annoying. Thus I've added a new
   function which allows an app to specify seperate cursors for
   fullscreen and windowed mode:
    void pwSetCursorEx ( int wm, int fs ) ;

Phew, long story. Well thats it I hope you like it! One problem though,
I only implemented this for Unix, I hope / think it will be easy to
implement for window, and maybe you can just add empty stubs for a start?

Also I didn't add support for this to the configure script and makefiles
(yet). I've tested it by using:
./configure CXXFLAGS="-O2 -DXF86VIDMODE"

Regards,

Hans

Re: R: [Plib-devel] mirrored billboards

[Bram S. <br...@sa...>]

Paolo Leoncini wrote:
> Bram,
> 
> Do you use png textures? I noticed that png textures get actually mirrored.
> 
> My billboarded rgba trees look fine.

I've seen it with rgba and bmp.

  Bram

> 
> Greetings -
> 
> Paolo
> 
> 
> 
>>-----Messaggio originale-----
>>Da: pli...@li... 
>>[mailto:pli...@li...] Per conto di 
>>Bram Stolk
>>Inviato: sabato 27 maggio 2006 22.28
>>A: pli...@li...
>>Oggetto: [Plib-devel] mirrored billboards
>>
>>
>>Hi,
>>
>>
>>I just found out that the textures on my billboards are 
>>mirrored, when using ssgaBillboards.
>>
>>I've been able to fix this by specifying a negative width.
>>
>>I suggest we avoid breaking existing apps, and not fix this, 
>>but if you stumble onto this bug, this is how to work around it.
>>
>>   Bram
>>
>>
>>
>>-------------------------------------------------------
>>All the advantages of Linux Managed Hosting--Without the Cost 
>>and Risk! Fully trained technicians. The highest number of 
>>Red Hat certifications in the hosting industry. Fanatical 
>>Support. Click to learn more 
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&
> 
> dat=121642
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
> 
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."

R: [Plib-devel] mirrored billboards

[Paolo L. <p.l...@ci...>]

Bram,

Do you use png textures? I noticed that png textures get actually mirrored.

My billboarded rgba trees look fine.

Greetings -

Paolo


> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto di 
> Bram Stolk
> Inviato: sabato 27 maggio 2006 22.28
> A: pli...@li...
> Oggetto: [Plib-devel] mirrored billboards
> 
> 
> Hi,
> 
> 
> I just found out that the textures on my billboards are 
> mirrored, when using ssgaBillboards.
> 
> I've been able to fix this by specifying a negative width.
> 
> I suggest we avoid breaking existing apps, and not fix this, 
> but if you stumble onto this bug, this is how to work around it.
> 
>    Bram
> 
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost 
> and Risk! Fully trained technicians. The highest number of 
> Red Hat certifications in the hosting industry. Fanatical 
> Support. Click to learn more 
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&
dat=121642
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] mirrored billboards

[Bram S. <br...@sa...>]

Hi,


I just found out that the textures on my billboards are mirrored,
when using ssgaBillboards.

I've been able to fix this by specifying a negative width.

I suggest we avoid breaking existing apps, and not fix this,
but if you stumble onto this bug, this is how to work around it.

   Bram

[Plib-devel] [BUG] puInput() cursor doesn't scroll text

[Melchior F. <mf...@us...>]

Here's yet another puInputBase-change related bug. The cursor
doesn't scroll the text in input fields any more. Works with
1.8.4. Example attached.

m.


PS: I've got another patch for puaList that I'd like to see
    committed. But I guess it's better to wait for the pending
    stuff to be done. :-)

[Plib-devel] Conversion to SVN?

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Gentlemen,

	I now have access to SourceForge again and CVS appears to be
running.  What is the status of the SVN conversion?

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 

[Plib-devel] [PATCH] puListBox::setTopItem(): don't scroll off the list

[Melchior F. <mf...@us...>]

This isn't really a bug, but still something that should be "fixed":
puListBox::setTopItem() allows to scroll off a list until only one
entry is left on the top and the rest empty(C). This is useless and
doesn't buy us anything -- on the contrary: it's very annoying
because you shoot over the goal and have to scroll back for no reason.
The list view is really a viewport to the list, so there's no reason
to display anything else than list members. Empty space doesn't
belong to the list. And if leaving the list is possible on the bottom
then why not on top? (C) & (D)? This would at least be consistent. :-}

Current behavior:  (A) & (C)
Desired behavior:  (A) & (B)


(A) correct with top=0        (B) correct with top=max (but not in plib)
                                
                                       aaaaa
  _________                          __bbbbb__
  | aaaaa |                          | ccccc |
  | bbbbb |                          | ddddd |
  | ccccc |                          | eeeee |
  | ddddd |                          | fffff |
  ---------                          ---------
    eeeee
    fffff


(C) silly (current plib)       (D) even sillier, but consistent with (C)!

    aaaaa                             _________
    bbbbb                             |       |
    ccccc                             |       |
    ddddd                             |       |
  __eeeee__                           |_aaaaa_|
  | fffff |                             bbbbb
  |       |                             ccccc
  |       |                             ddddd
  |       |                             eeeee
  ---------                             fffff


Index: src/pui/puListBox.cxx
===================================================================
RCS file: /cvsroot/plib/plib/src/pui/puListBox.cxx,v
retrieving revision 1.26
diff -u -p -r1.26 puListBox.cxx
--- src/pui/puListBox.cxx       18 Apr 2006 16:50:17 -0000      1.26
+++ src/pui/puListBox.cxx       21 May 2006 08:45:08 -0000
@@ -74,10 +74,11 @@ void puListBox::newList ( char ** _list
 void puListBox::setTopItem( int item_index )
 {
   top = item_index ;
-  if ( top < 0 )
+  int visible = getNumVisible();
+  if ( top < 0 || num <= visible )
     top = 0 ;
-  else if ( num > 0 && top > num-1 )
-    top = num-1;
+  else if ( num > 0 && top > num-visible )
+    top = num-visible;

   puPostRefresh () ;
 }

[Plib-devel] Re: [PATCH] puAux.h: add missing methods setTopItem/getTopItem (urgent)

[Bram S. <br...@sa...>]

Melchior FRANZ wrote:
> Hi,
> 
> just noticed that puaList has methods getTopItem() and setTopItem()
> declared, but not defined. Could you please commit that before the
> release. (I need that for FlightGear and it would be a pity if I had
> to wait for the next release.)
> 
> It just forwards the methods to the subwidget that is resposible
> for this feature. Tested and works.
> 
> CC to Bram because the sf.net is quite flakey these days.

I have to wait for svn service before I can fix this.
I think this is the sequence of events:

1) we wait for SF to fix cvs service
2) Steve migrates plib from CVS to SVN
3) Important bugfixes are applied
4) Release Candidate tarball
5) Release

> 
> m.
> 
> 
> 
> Index: puAux.h
> ===================================================================
> RCS file: /cvsroot/plib/plib/src/puAux/puAux.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 puAux.h
> --- puAux.h     25 Mar 2006 00:34:08 -0000      1.11
> +++ puAux.h     14 May 2006 09:01:16 -0000
> @@ -914,8 +914,8 @@ public:
>    virtual void   setSize (int w, int h);
> 
>    int  getNumItems ( void ) const ;
> -  int  getTopItem  ( void ) const ;
> -  void setTopItem  ( int item_index );
> +  int  getTopItem  ( void ) const { return _list_box->getTopItem(); }
> +  void setTopItem  ( int item_index ) { _list_box->setTopItem(item_index); }
>  };
> 
>  #endif


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."