16
General discussions / Re: Clipboard support on Linux: A few hiccups.
« on: October 08, 2014, 10:43:30 pm »
The problem is that SFML must also send the clipboard contents to other applications when they request it.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: 1 [2]
17
General discussions / Re: Clipboard support on Linux: A few hiccups.
« on: October 08, 2014, 10:13:04 pm »
I think spawning a new thread for handling the clipboard window is the lesser evil of these two. Clipboard ownership probably won't be requested until the user tries to copy something in another program, so a blocking setter would cause the program hang until the user gives up and starts doing something else. Requiring the user to copy something in another application to make the program responsive again is bad.
With a blocking setter, the programmer would have to create a new thread anyway just for calling the setter in order to keep the app responsive.
With a blocking setter, the programmer would have to create a new thread anyway just for calling the setter in order to keep the app responsive.
18
SFML development / Re: SFML Context Management
« on: October 07, 2014, 02:52:58 pm »
Ok so I voted it, but for a clarification, it doesn't mean that I would like to keep the current system where SFML creates extraneous contexts even for a simple single-threaded app, just to pamper multithreaders, wherefore I also said that I don't care how painful context management becomes to them. SFML shouldn't create more contexts than what is needed in a single-threaded app, and multithreaders can handle contexts manually.
19
SFML development / Re: SFML Context Management
« on: October 07, 2014, 01:48:24 pm »
Personally I don't care how chaotic context management gets with threads, for multithreading isn't for beginners anyway. IMHO context management should be simplest for a single thread.
With these opinions, which option should I vote?
With these opinions, which option should I vote?
20
General discussions / Re: Clipboard support on Linux: A few hiccups.
« on: October 06, 2014, 07:34:06 pm »
Typically the clipboard is accessed when the computer user wants to copy/paste text from 1 program to another. A ~0.5 sec busy wait would be hardly noticeable.
21
General discussions / Re: Clipboard support on Linux: A few hiccups.
« on: October 05, 2014, 07:46:59 am »
Yea, I think I read somewhere that on Linux no data is actually copied to the clipboard, so I imagine that when data is requested, a pointer is provided to it in the Mighty Clipboard Data Holder's memory.
So, to provide identical behavior on all platforms, SFML must itself keep a copy of the clipboard contents when it's owned by SFML on Linux.
So, to provide identical behavior on all platforms, SFML must itself keep a copy of the clipboard contents when it's owned by SFML on Linux.
22
Feature requests / Re: ability to use rotated images with setTextureRect
« on: August 14, 2014, 03:09:36 pm »probably with having, let say, top/left being the top right corner and a negative width and let SFML do the work (for a 90 CW rotation) but probably too much hassle.
IMHO this is a good idea.
Edit:
Just realized that this would cause mirroring but not rotating. 
How about taking as arguments the top left and bottom right corner? If bottom right is more left than top left the texture is rotated 90 degrees, if higher it is -90 degrees, and if bottom right is both above and left of top left 180 degrees.
23
Feature requests / Re: Clipboard and open with default application support
« on: June 09, 2014, 12:39:14 pm »
Using the CLIPBOARD would also allow adding support for PRIMARY later without changing the clipboard interface.
Concerning the suggested paste Event, it occurred to me that the user might want to bind the middle-mouse or ctrl+v to something else in a context where clipboard isn't needed (such as in a FPS game). Then SFML would be reading the clipboard needlessly to produce the paste Event (which would be ignored).
Concerning the suggested paste Event, it occurred to me that the user might want to bind the middle-mouse or ctrl+v to something else in a context where clipboard isn't needed (such as in a FPS game). Then SFML would be reading the clipboard needlessly to produce the paste Event (which would be ignored).
24
Feature requests / Re: Clipboard and open with default application support
« on: June 09, 2014, 12:26:01 am »That sounds reasonable to me (the paste event thing).
But what if the user wants to stuff something into the clipboard? Stuff it into PRIMARY? CLIPBOARD? Both? Should the user be able to choose?
The best service for the user would be letting him choose which clipboard to overwrite, which would normally be determined by key bindings: ctrl+c for CLIPBOARD and selection for PRIMARY. Always overwriting both clipboards would be an annoyance to the user, especially if he doesn't expect it.
25
Feature requests / Re: Clipboard and open with default application support
« on: June 08, 2014, 04:42:06 pm »
Using PRIMARY would make sense, because in normal use it would be overwritten anyway when highlighting text for the CLIPBOARD (unless the application provides an eccentric manner of selecting text for the CLIPBOARD). The middle-mouse paste may be unknown to users migrating from Windows, but the application should anyway define which clipboard it uses and that could be mentioned there (for ensample: "This editor by the way uses the middle-mouse paste clipboard on Linux."). Actually, I think you'll be more likely understood if you call it 'the middle-mouse paste' rather than 'PRIMARY':
"This editor uses PRIMARY on Linux">
<What...?
If both clipboards were supported, one of them would need its own interface. In that case, it would make sense to group the CLIPBOARD with Windows clipboard, because they're accessed similarly, and give PRIMARY its own interface, including a function to check whether it exists at all. It could be called mouseSelection, or just 'selection'.
"This editor uses PRIMARY on Linux">
<What...?If both clipboards were supported, one of them would need its own interface. In that case, it would make sense to group the CLIPBOARD with Windows clipboard, because they're accessed similarly, and give PRIMARY its own interface, including a function to check whether it exists at all. It could be called mouseSelection, or just 'selection'.
26
Feature requests / Re: Clipboard and open with default application support
« on: June 03, 2014, 10:54:04 pm »Clipboard support is trickier than it seems.
Keep in mind that, in addition to mime type handling, some systems (like Linux/X) have multiple clipboards - so when you get/set clipboard contents, which one are you referring to?
You tell me. I don't know much anything of Linux clipboards - that's why I'm requesting a platform independent interface. If I knew those systems I could make my own implementation of it. I don't know how many clipboards there are on Linux, how they differ from one another, which one most people would prefer, or whether they vary depending on the distribution. Of Macintoshes I know even less than of Linux.
The trickiness of the clipboard is the very reason why SFML should provide an interface to it.
27
Feature requests / Re: Clipboard and open with default application support
« on: June 03, 2014, 03:28:13 am »
Add me to the list of those looking for clipboard support (for text at least). It is within the scope of a multimedia library and used a lot, so I'm slightly surprised that it isn't supported yet.
API could be like:
API could be like:
namespace sf
{ namespace clipboard
{ bool isAvailable(); // Check whether the operating system has a clipboard and it is supported.
std::string text(); // Return text on the clipboard, "" if empty.
bool text(std::string); // Try to set clipboard text and tell is it fails.
}
}
{ namespace clipboard
{ bool isAvailable(); // Check whether the operating system has a clipboard and it is supported.
std::string text(); // Return text on the clipboard, "" if empty.
bool text(std::string); // Try to set clipboard text and tell is it fails.
}
}
28
General discussions / Re: SFML 3 - What is your vision?
« on: June 01, 2014, 05:57:49 pm »As promised we as the new team, would like to be more open towards the community especially regarding the current development. We're currently discussing on how to approach things after SFML 2.2 and as such, we need to figure out what SFML 3.0 should actually be about.
Keep in mind this shouldn't really be about simple feature requests, for that we have dedicated forum, this should be more about what SFML 3 should offer besides a few new feature. For example: How the graphics API should be changed/opened/advanced, or whether C++11 should be non-optional, or should we change the way window states are handled, or etc...
We won't make any decisions here, we simply want to hear the ideas from all community members.
What is your vision of SFML 3?
Basically all computer programs receive information and send information; just the source/destination varies. The source may be user input (not just mouse+keyboard, but microphone and webcam), any mass storage, the clipboard or something else. The destination may be the monitor, speakers, printer, any writable storage, the clipboard, or something else.
SFML's job is to provide a simple & fast multiplatform interface to receive that information, and send it. That's what I call a multimedia library.
I don't see a reason to avoid C++11 if that is useful.
Pages: 1 [2]