Cut and Paste in SDL

SDL Development
21

Hi,

I personally don’t see the purpose of supporting
cut and paste in a multimedia library.

It seems that the only reason is for people using
SDL as a base for a windowing library, and for
that I would support an extra library.

After that is why we have so much SDL_* libraries.

Cheers,
Paulo

Quoting Bill Kendrick :> On Wed, Jan 10, 2007 at 11:31:44PM +0100, Mattias Karlsson wrote:

Why must it be part of the core libary and not a add-on, like say SDL_net?

Well, as someone else said… then you may as well make keyboard, mouse,
video, etc.
all add-ons. (I might have a game for a touch screen device that has no
keyboard,
so why would I want keyboard support in my app?) :^)

If it IS a matter of "cut and paste functionality is too large to add to the
core lib,"
then so be it, but it sounds like it’s relatively trivial.

In either case…

Am I the only one who have a nagging feeling that the core SDL library is
becoming more and more bloated? Or am I part of a dying breed of
developers that think that size realy do matters?

… isn’t that what "./configure --without-foo-support"
is for? :slight_smile:

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

This message was sent using IMP, the Internet Messaging Program.

22

Why can’t you look past your personal desire for SDL to do only what YOU
want and support the rather trivial functionality that would not only
benefit others but that you could also take advantage of easily as well.
Many games support c&p in their in-game consoles now, which more SDL games
could do if it was added to the core. Sure it’s not NEEDED, but nor is it
ever NEEDED. It’s a very useful convenience functionality that makes the end
users life easier. Surely you can understand the value of users being able
to c&p into text fields in your game gui, the game console, maybe even your
chat input. Personally it annoys the hell out of me when games don’t support
such things for their text input.

I can’t speak for linux or mac support, but c&p functionality is pretty easy
on windows. I’d be happy with simple string support, since it is likely the
most common and useful one, though bitmap support should also be easy to do.
I’m asking for an SDL wrapper for basic cut, copy, and paste functionality
through a generic interface, for strings primarily, possibly images. This
isn’t something that is going to bloat SDL at all. Support compiling it out
for all I care as well, for the people counting bits.

JOn 1/11/07, Kuon - Nicolas Goy - ??? (Goyman.com SA) wrote:

On Jan 10, 2007, at 11:31 PM, Mattias Karlsson wrote:

Why must it be part of the core libary and not a add-on, like say
SDL_net?

Am I the only one who have a nagging feeling that the core SDL
library is
becoming more and more bloated? Or am I part of a dying breed of
developers that think that size realy do matters?

I agree, for me, having a lib as little as possible, doing only what
I want is my need.

I use SDL as a low level API to access OpenGL in a cross platform
way. And in our game, C&P is not needed.

It’s a feature which is nice, and I think it should be implemented as
an addon. Or maybe #define CP_SUPPORT, so we could compile from
scratch without it. (remember what the S in SDL stand for)

Just to clarify, we speak about C&P interaction with the OS right?
The ability to access OS last copy (or maybe history) and the ability
to put a new buffer in the OS stack? I think it’s not a trivial
feature, as OS can copy many things as already discussed.

I’m not an SDL coder, but as a user, I can say I want to keep the lib
as clean and small as possible.

Regards

–
Kuon
Programmer and sysadmin.

“Computers should not stop working when the users’ brain does.”

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

23

Aha,

But what you said and what Jeremy said point out this problem: To cut & paste a picture, you’d have to interpret the type of picture, right? That’s means making SDL_Image (and probably an extension to that) a part of the core API as well. Maybe you could interpret a full screen shot, but I have a feeling that would suck.

I think it’d be great as a separate library. Someone get on that :slight_smile:

-Jon> Date: Thu, 11 Jan 2007 07:15:27 -0800> From: nbs at sonic.net> To: sdl at libsdl.org> Subject: Re: [SDL] Cut and Paste in SDL> > On Wed, Jan 10, 2007 at 11:31:44PM +0100, Mattias Karlsson wrote:> > Why must it be part of the core libary and not a add-on, like say SDL_net?> > Well, as someone else said… then you may as well make keyboard, mouse, video, etc.> all add-ons. (I might have a game for a touch screen device that has no keyboard,> so why would I want keyboard support in my app?) :^)> > If it IS a matter of “cut and paste functionality is too large to add to the core lib,”> then so be it, but it sounds like it’s relatively trivial.> > In either case…> > > Am I the only one who have a nagging feeling that the core SDL library is > > becoming more and more bloated? Or am I part of a dying breed of > > developers that think that size realy do matters?> > … isn’t that what “./configure --without-foo-support”> is for? :)> > – > -bill!> bill at newbreedsoftware.com> http://www.newbreedsoftware.com/> > _______________________________________________> SDL mailing list> SDL at libsdl.org> http://www.libsdl.org/mailman/listinfo/sdl

Type your favorite song.? Get a customized station.? Try MSN Radio powered by Pandora.
http://radio.msn.com

24

Every game in existence pretty much has a GUI. Pretty much all of those have
some sort of textual input widgets. If you honestly think it’s not useful to
provide c&p functionality for these things then theres nothing more that can
be said to convince you otherwise, as you clearly don’t understand the
convenience of providing common functionality from within your SDL
application.

JOn 1/11/07, Paulo Pinto wrote:

Hi,

I personally don’t see the purpose of supporting
cut and paste in a multimedia library.

It seems that the only reason is for people using
SDL as a base for a windowing library, and for
that I would support an extra library.

After that is why we have so much SDL_* libraries.

Cheers,
Paulo

Quoting Bill Kendrick :

On Wed, Jan 10, 2007 at 11:31:44PM +0100, Mattias Karlsson wrote:

Why must it be part of the core libary and not a add-on, like say
SDL_net?

Well, as someone else said… then you may as well make keyboard, mouse,
video, etc.
all add-ons. (I might have a game for a touch screen device that has no
keyboard,
so why would I want keyboard support in my app?) :^)

If it IS a matter of "cut and paste functionality is too large to add to
the
core lib,"
then so be it, but it sounds like it’s relatively trivial.

In either case…

Am I the only one who have a nagging feeling that the core SDL library
is

becoming more and more bloated? Or am I part of a dying breed of
developers that think that size realy do matters?

… isn’t that what "./configure --without-foo-support"
is for? :slight_smile:

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

This message was sent using IMP, the Internet Messaging Program.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

25

Well, not everyone would use the cut & paste functionality if built into the core. Many, many people use SDL just to load up a window, maybe process some input, and for nothing else. To stick to them a functionality that, in my opinion, would indeed bloat the core, would be pretty careless. That’s not to mention the load you are asking of the nice people who write the core and would have to work this in. A single nice person could make an extension library that would be just as easy to install as SDL_Image instead of making someone delve into the core and shove this functionality in.

-Jon

Hi,I personally don’t see the purpose of supportingcut and paste in a multimedia library.It seems that the only reason is for people usingSDL as a base for a windowing library, and forthat I would support an extra library. After that is why we have so much SDL_* libraries.Cheers,PauloQuoting Bill Kendrick :> On Wed, Jan 10, 2007 at 11:31:44PM +0100, Mattias Karlsson wrote: > > Why must it be part of the core libary and not a add-on, like say SDL_net?>> Well, as someone else said… then you may as well make keyboard, mouse,> video, etc.> all add-ons. (I might have a game for a touch screen device that has no > keyboard,> so why would I want keyboard support in my app?) :^)>> If it IS a matter of “cut and paste functionality is too large to add to the> core lib,”> then so be it, but it sounds like it’s relatively trivial. >> In either case…>> > Am I the only one who have a nagging feeling that the core SDL library is> > becoming more and more bloated? Or am I part of a dying breed of> > developers that think that size realy do matters? >> … isn’t that what “./configure --without-foo-support”> is for? :)>> --> -bill!> bill at newbreedsoftware.com> http://www.newbreedsoftware.com/>> _______________________________________________> SDL mailing list> SDL at libsdl.org > http://www.libsdl.org/mailman/listinfo/sdl>----------------------------------------------------------------This message was sent using IMP, the Internet Messaging Program. _______________________________________________SDL mailing listSDL at libsdl.orghttp://www.libsdl.org/mailman/listinfo/sdlDate: Thu, 11 Jan 2007 07:42:57 -0800From: jswigart at gmail.comTo: sdl at libsdl.orgSubject: Re: [SDL] Cut and Paste in SDLEvery game in existence pretty much has a GUI. Pretty much all of those have some sort of textual input widgets. If you honestly think it’s not useful to provide c&p functionality for these things then theres nothing more that can be said to convince you otherwise, as you clearly don’t understand the convenience of providing common functionality from within your SDL application. J
On 1/11/07, Paulo Pinto wrote:

Get the Live.com Holiday Page for recipes, gift-giving ideas, and more.
www.live.com/?addtemplate=holiday

26

Not really. The image format the windows clipboard uses is CF_BITMAP, which
SDL I believe can interpret by default(assumed due to presence of saving bmp
screenshot). I would imagine most platforms copy their images to their
clipboard in a standard format like this to avoid knowledge about a ton of
different formats. There are only 2 clipboard formats that SDL could
interpret, CF_TEXT for ascii text, most important, and CF_BITMAP. Even if
the clipboard seperated image formats the SDL implementation doesn’t have to
be responsible for converting it into a surface. I’d prefer it not to in
order to keep external dependencies out of it. I would imagine SDL could
return a raw memory buffer with an enumerated type of the clipboard data and
the user then has the responsibility of getting the data to the appropriate
format. As I said before, I’m more interested in text clipboard data myself,
and only speak of supporting image because IMO it would be useful for
clipboard support to be a bit more thorough implementation than just
text.Ultimately I’d personally be fine with just string support, though
others may find image support useful also, and I’m not so selfish as to
defend vehemently features that I myself may not use if they are indeed
rather trivial to support as well.

JOn 1/11/07, Jonathan Dearborn wrote:

Aha,

But what you said and what Jeremy said point out this problem: To cut &
paste a picture, you’d have to interpret the type of picture, right? That’s
means making SDL_Image (and probably an extension to that) a part of the
core API as well. Maybe you could interpret a full screen shot, but I have
a feeling that would suck.

I think it’d be great as a separate library. Someone get on that :slight_smile:

-Jon

Date: Thu, 11 Jan 2007 07:15:27 -0800
From: nbs at sonic.net
To: sdl at libsdl.org
Subject: Re: [SDL] Cut and Paste in SDL

On Wed, Jan 10, 2007 at 11:31:44PM +0100, Mattias Karlsson wrote:

Why must it be part of the core libary and not a add-on, like say
SDL_net?

Well, as someone else said… then you may as well make keyboard, mouse,
video, etc.
all add-ons. (I might have a game for a touch screen device that has no
keyboard,
so why would I want keyboard support in my app?) :^)

If it IS a matter of "cut and paste functionality is too large to add to
the core lib,"
then so be it, but it sounds like it’s relatively trivial.

In either case…

Am I the only one who have a nagging feeling that the core SDL library
is

becoming more and more bloated? Or am I part of a dying breed of
developers that think that size realy do matters?

… isn’t that what "./configure --without-foo-support"
is for? :slight_smile:

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Get free, personalized online radio with MSN Radio powered by Pandora. Try
it! http://radio.msn.com

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

27

Not everyone uses alot of stuff in the core SDL, what’s your point. I don’t
use sound in most of my uses of SDL, but I’m not crying about dll size.
Sound certainly bloats the dll many times more than clipboard functionality
would. Like I said, it can support being configured out of it for all I
care, default it to off if your really anal. We must have vastly different
definitions of bloat. A few k, or even a few tens of k to the dll is
insignificant. Bloat and carelessness would be adding dependencies that many
users may not use, as in external dependencies that developers would then be
required to build and link in just to use SDL. Invisible C&P functionality
that simply increases the size of the dll by some small amount is
insignificant compared to the utility of such functionality. SDL is itself a
utility library to facilitate cross platform development. I myself could
write a windows clipboard extension, but that wouldn’t be at all helpful on
linux or mac, neither of which I have the know-how or time to expand it to
support. This is what brings the requests to this list, to ask for such
functionality in the core, where it clearly makes the most sense as an
expected functionality in any windowing app, gui, and many games these days,
and where the SDL developers are clearly equipped to support it on platforms
that have the capability.

JOn 1/11/07, Jonathan Dearborn wrote:

Well, not everyone would use the cut & paste functionality if built into
the core. Many, many people use SDL just to load up a window, maybe
process some input, and for nothing else. To stick to them a functionality
that, in my opinion, would indeed bloat the core, would be pretty careless.
That’s not to mention the load you are asking of the nice people who write
the core and would have to work this in. A single nice person could make an
extension library that would be just as easy to install as SDL_Image instead
of making someone delve into the core and shove this functionality in.

-Jon

Date: Thu, 11 Jan 2007 07:42:57 -0800
From: @Jeremy
To: sdl at libsdl.org
Subject: Re: [SDL] Cut and Paste in SDL

Every game in existence pretty much has a GUI. Pretty much all of those
have some sort of textual input widgets. If you honestly think it’s not
useful to provide c&p functionality for these things then theres nothing
more that can be said to convince you otherwise, as you clearly don’t
understand the convenience of providing common functionality from within
your SDL application.

J

On 1/11/07, Paulo Pinto wrote:

Hi,

I personally don’t see the purpose of supporting
cut and paste in a multimedia library.

It seems that the only reason is for people using
SDL as a base for a windowing library, and for
that I would support an extra library.

After that is why we have so much SDL_* libraries.

Cheers,
Paulo

Quoting Bill Kendrick :

On Wed, Jan 10, 2007 at 11:31:44PM +0100, Mattias Karlsson wrote:

Why must it be part of the core libary and not a add-on, like say
SDL_net?

Well, as someone else said… then you may as well make keyboard, mouse,
video, etc.
all add-ons. (I might have a game for a touch screen device that has no

keyboard,
so why would I want keyboard support in my app?) :^)

If it IS a matter of "cut and paste functionality is too large to add to
the
core lib,"
then so be it, but it sounds like it’s relatively trivial.

In either case…

Am I the only one who have a nagging feeling that the core SDL library
is

becoming more and more bloated? Or am I part of a dying breed of
developers that think that size realy do matters?

… isn’t that what "./configure --without-foo-support"
is for? :slight_smile:

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

This message was sent using IMP, the Internet Messaging Program.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Get the Live.com Holiday Page for recipes, gift-giving ideas, and more. Check
it out! http://www.live.com/?addtemplate=holiday

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

28

I don’t know many games that allow you to do
copy-paste. In what context would you do copy
-paste in a game? The major goal of copy-paste
is to share data between applications.

Besides if the functionality is so important, just
implement it. Then if the library gets used by lots of
people maybe you can then ask Sam to include it in the
core.–
Paulo

Quoting Jeremy :

Every game in existence pretty much has a GUI. Pretty much all of those have
some sort of textual input widgets. If you honestly think it’s not useful to
provide c&p functionality for these things then theres nothing more that can
be said to convince you otherwise, as you clearly don’t understand the
convenience of providing common functionality from within your SDL
application.

J

This message was sent using IMP, the Internet Messaging Program.

29

I don’t know many games that allow you to do
copy-paste. In what context would you do copy
-paste in a game? The major goal of copy-paste

Say you’re trying to paste in an IP from a console window into the game
to connect to a friends game server. There’s nothing worse than having to
try to jot down the number (in the dark!), or flip between the desktop and
the full screen game several times (goldfish memory, here) just to get it
in there.

Besides if the functionality is so important, just

This alleged bloat that many mention, is it code size or API size or what
really is the fear here?On Thu, 11 Jan 2007 17:17:28 +0100, Paulo Pinto wrote:

30

Not really. The image format the windows clipboard uses is
CF_BITMAP, which SDL I believe can interpret by default(assumed due
to presence of saving bmp screenshot). I would imagine most
platforms copy their images to their clipboard in a standard format
like this to avoid knowledge about a ton of different formats.
There are only 2 clipboard formats that SDL could interpret,
CF_TEXT for ascii text, most important, and CF_BITMAP.

The problem is, what do we want?

I’m ok to have something like:

put(void *data, int length, int type);

get(void **data, int *length, int *type);

But that’s all, no interpretation at all or anything.

I think we should not put feature like:

putContentOfClipBoardOnSurface()

and have the bitmap be print on the surface in the core library.

Same with text. I work with 32 bit int UNICODE text, and would find a
clipboard where you can only return ascii quite useless.

I don’t know many games that allow you to do
copy-paste. In what context would you do copy
-paste in a game? The major goal of copy-paste
is to share data between applications.

Besides if the functionality is so important, just
implement it. Then if the library gets used by lots of
people maybe you can then ask Sam to include it in the
core.

In WoW, as you chat all the time, copy past would be cool, to show
url mostly.

Why can’t you look past your personal desire for SDL to do only
what YOU want and support the rather trivial functionality that
would not only benefit others but that you could also take
advantage of easily as well. Many games support c&p in their in-
game consoles now, which more SDL games could do if it was added to
the core. Sure it’s not NEEDED, but nor is it ever NEEDED. It’s a
very useful convenience functionality that makes the end users life
easier. Surely you can understand the value of users being able to
c&p into text fields in your game gui, the game console, maybe even
your chat input. Personally it annoys the hell out of me when games
don’t support such things for their text input.

I said I didn’t use C&P in my game as an example. We will have C&P in
our next game as it has a chat windows, but I thought we were
speaking of FULL copy past support in core library.

Like having interpretation of the data in the clipboard.

I think, as said earlier that basic copy past, JUST the wrapper
around the OS specifics function could be added.

But nothing fancy that interpret the data.

Best regardsOn Jan 11, 2007, at 4:55 PM, Jeremy wrote:

–
Kuon
Programmer and sysadmin.

“Computers should not stop working when the users’ brain does.”

31

Enemy Territory(& quake 3 engine), half-ilfe 2, most games that have a drop
down console support paste to the in-game console, and those games that
support selecting text in the console(such as half-life 2), also support
copying. This is all typically text only, which is all I personally would
like to take advantage of. Any decent GUI library would support c&p as well.
As the other reader mentioned as well, ip addresses, login names to games,
whatever. If the functionality were there and easily accessible, it would
get used, certainly more than as a separate library that one would have to
specifically think about using and then find it there on the internet, only
to find that my version only supports windows, which makes it rather useless
in the context of an otherwise cross platform SDL. That is why I don’t “just
implement it” and post it up for others. I don’t have a linux/mac/whatever
else box or the time to figure out how to do it in each to do justice to a
separate library by supporting the platforms that SDL itself supports. Cross
platform developers aren’t happy with platform specific extensions.

JOn 1/11/07, Paulo Pinto wrote:

I don’t know many games that allow you to do
copy-paste. In what context would you do copy
-paste in a game? The major goal of copy-paste
is to share data between applications.

Besides if the functionality is so important, just
implement it. Then if the library gets used by lots of
people maybe you can then ask Sam to include it in the
core.

–
Paulo

Quoting Jeremy <@Jeremy>:

Every game in existence pretty much has a GUI. Pretty much all of those
have
some sort of textual input widgets. If you honestly think it’s not
useful to
provide c&p functionality for these things then theres nothing more that
can
be said to convince you otherwise, as you clearly don’t understand the
convenience of providing common functionality from within your SDL
application.

J

This message was sent using IMP, the Internet Messaging Program.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

32

I can’t speak for linux or mac support, but c&p functionality is
pretty easy on windows.

For mac it here:

http://developer.apple.com/documentation/Carbon/Conceptual/
Pasteboard_Prog_Guide/index.htmlOn Jan 11, 2007, at 4:40 PM, Jeremy wrote:

–
Kuon
Programmer and sysadmin.

“Computers should not stop working when the users’ brain does.”

33

“I think, as said earlier that basic copy past, JUST the wrapper
around the OS specifics function could be added.”

Certainly. And that is all I’d like to have.

34

“I think, as said earlier that basic copy past, JUST the wrapper
around the OS specifics function could be added.”

Certainly. And that is all I’d like to have.

Ok, I’m sorry I misunderstood, I thought it was question of full
interpretation support (read here, puting asci text in char *,
unicode text in a struct, bitmap is an image object…) with handling
for all datatypes.

So I’m also for it:)On Jan 11, 2007, at 5:50 PM, Jeremy wrote:

–
Kuon
Programmer and sysadmin.

“Computers should not stop working when the users’ brain does.”

35

Tux Paint, which is unquestionably a multimedia application,
would benefit from:

  • Paste text into the Text tool
  • Paste images from other applications
  • Cut/Copy image content for use in other applications
  • Cut/paste within itself

I can even imagine games where copy/paste would be useful.
Imagine a game which includes a chat client, and you’d like
to copy/paste some error message, or solution to a problem
from a web page and into the chat area of the game window…?

Computers have had easy-to-use copy/paste since 1984, and
there’s no reason to second-guess whether certain applications
(games or otherwise) would need (or at least benefit) from a
feature such as this. :^/

-bill!On Thu, Jan 11, 2007 at 03:38:17PM +0000, Paulo Pinto wrote:

Hi,

I personally don’t see the purpose of supporting
cut and paste in a multimedia library.

36

Some people open a window, display an image, and never require mouse
input, or make any sounds. Yet these features are supported in the core lib.

What I think we’re saying here is: your argument is invalid, since there IS
so much stuff in SDL that you cannot guarantee that everyone will need
all the time.

If a reasonable c&p API is way too much bloat (that’s for Sam, Ryan, et. al
to decide), then fine… let’s being working on SDL_clipboard lib.
Otherwise, let’s figure out a nice API and start dropping patches into
bugzilla. :wink:

-bill!On Thu, Jan 11, 2007 at 10:50:13AM -0500, Jonathan Dearborn wrote:

Well, not everyone would use the cut & paste functionality if built into the core. Many, many people use SDL just to load up a window, maybe process some input, and for nothing else. To stick to them a functionality that, in my opinion, would indeed bloat the core, would be pretty careless.

37

Copy/paste is very useful in DROD. Online account name/key, editor
hold/level descriptions, scrolls, speech subtitles, etc. If SDL had
copy/paste built in, we wouldn’t need the custom code we currently have to
handle this, making it more portable =)

I think it makes sense to have at least basic copy/paste support in the
main SDL library, since it depends on the display driver being used. For
example, DROD checks the display driver and does dynamic loading of X11 if
X11 is being used to enable clipboard, but since SDL already has loaded
X11 anyway it’d be better if it was handled there.

As for copy/paste of non-text/nontrivial formats, just giving the raw data
should be good enough (buffer, rwops ?).

~ GerryOn Thu, 11 Jan 2007 18:22:38 +0100, Bill Kendrick wrote:

I can even imagine games where copy/paste would be useful.