C&P support would add insignificant size to the library. networking,
graphix, sound, all the stuff you mention a
“Perhaps the same reasons that keep SDL, SDL_net, SDL_gfx, SDL_Mixer,
SDL_Image, SDL_ttf and your favorite GUI library separate: The
resulting libary would be so huge that noone would use it.”
C&P support would add insignificant size to the library. Networking, gfx,
sound, all the stuff you mention are seperated for the simple reason that
not everyone will want to use SDLs version of networking in favor of one of
many other alternatives out there. Same for sound support, image support,
certainly gui library, and ttf support. Further, most of those addons
require significant dependencies to function. C&P is a function provided by
pretty much every OS out there, and would ideally be wrapped up and
presented to the user in a platform independent manner, like the keyboard,
mouse, etc that is in the core library now. There is no reason for a
developer to use a ‘different c&p library’, so maintaining separation is a
inconvenience at best.
I see no reason why it needs to be part of the core library. All it has to
do is fetch stuff to/from the OS specific API and convert it to text,
surfaces or samples. SDL API already alows you to perform the second part
with relative ease, all that is needed is the first.
Yes, that’s ‘all it has to do’ which should make it a trivial inclusion into
the core library. Certainly more trivial to implement and include and more
convenient to the end users than making them download yet another add-on for
such standard OS functionality.
As a standard feature of the library it would enable developers to
significantly increase the usability of their programs for very little
effort. A separate library for C&P is overkill. That’s akin to having a
separate mouse library, and a joystick library. This is basic OS
functionality that most people expect, as they do keyboard, mouse support.
Not having it in the core is inconveniencing SDL developers, certainly much
more than an insignificant library ‘bloat’ it would result in.
JOn 1/10/07, Mattias Karlsson < betasoft at acc.umu.se> wrote:
On Wed, 10 Jan 2007, Jeremy wrote:
SDL mailing list
SDL at libsdl.org