Messages

1

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: August 26, 2015, 12:27:57 am »

I'm eager to see how ye are going to implement this with no hidden window && no hidden thread.

2

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: August 25, 2015, 02:30:52 pm »

Earlier in the discussion, a global list of user windows (as it already exists on Linux) was mentioned... The clipboard might also make use of that.

Would the window be picked arbitrarily?
What if it gets destroyed suddenly?
Would you still have a dedicated thread (or would you just hope that the window's events are handled regularly)?
Would the thread interfere with the normal use of the window? (Can it be avoided?)

3

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: August 24, 2015, 03:23:16 pm »

The reason for hiding the window is to make the API simpler and cleaner. I'd prefer an extra window argument to all the clutter that you add to the Clipboard class

I don't know what you mean by clutter

Why? You could create that on first use. Problem solved

Creating and destroying the hidden stuff in accordance to the need helps a lot, but the hidden stuff still is just what virtually all user applications would have anyway, and therefore redundant. But the only way to get rid of that redundance is to allow the user point a window to use.

4

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: August 21, 2015, 12:47:14 am »

@Nexus I think the main argument against a hidden window (& thread on x11) is that it makes everybody pay for a feature almost nobody really needs.
But never mind, I think it is possible to have a hidden window AND let user provide his own.
Here's a semi-pseudocode sketch of what I'm thinking:

struct ClipboardManager
{       explicit ClipboardManager(bool useDefaultBroker=true)
        {       if true // false-> a broker window must be manually set before use
                {       if usersOfHidden==0 startHidden();
                        ++usersOfHidden;
                        usingHidden=true;
                } else usingHidden=false;
        }
        explicit ClipboardManager( Window& broker);
        void setBroker( Window& );//<^User provided window
        void setDefaultBroker();// Does same as default constructor
        string getStr();
        void setStr(string);

        static bool needsWindow();// Would be nice to know (for user-provided window users)

        ~ClipboardManager(){ if usingHidden && --usersOfHidden==0 quitHidden();}
};
 

I don't think a global window is necessary. The ClipboardManager objects should create hidden stuff on demand and destroy it when it isn't used anymore.

5

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: August 16, 2015, 11:50:21 am »

I'd prefer a solution that doesn't incur unnecessary overhead (eg. a superfluous hidden window). Other than that, I'm ok with any interface or implementation. I'm just looking forward to getting clipboard support to SFML.

6

SFML development / Re: API deprecation model

« on: April 08, 2015, 01:38:48 am »

I think a serious commercial project should at least check the changelog. If it starts with something like

!!!ATTENTION!!! The following features have been **deprecated** in version x.y:

they should notice.

7

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: February 09, 2015, 12:51:35 am »

Setters and getters probably have to forward the job to some private sf::Window functions, and the clipboard requests could be handled among other events in processEvent.

Are there more implementation details to decide about?

8

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 20, 2014, 11:49:10 pm »

The current API (member function) is fine with me. Concerning Laurent's concern of possibly giving a false impression that each window would store its own clipboard data, I think it could be solved by just calling the member functions more appropriately: seizeClipboard(sf::String) and String readClipboard(), to reflect that the clipboard isn't a sf::Window field.
But if there are good reasons for a non-member approach, then what Laurent suggested is also fine with me:

class Clipboard
{
    static data get(window?);
    static void set(data, window);
}
 

9

General / Re: SFML tests and examples crash with "Process returned -1073741819 (0xC0000005)"

« on: October 13, 2014, 01:33:07 am »

Binaries compiled with an older GCC may be incompatible with the newer one.

I've been testing exclusively with the SFML-2.1 MinGW download version for a while, so recent GitHub changes shouldn't be an issue.

SFML binaries are compiled with GCC 4.7, and the one you're using is GCC 4.9.1.

10

General / Re: SFML tests and examples crash with "Process returned -1073741819 (0xC0000005)"

« on: October 13, 2014, 12:32:19 am »

Could this be the problem?
http://en.sfml-dev.org/forums/index.php?topic=16494.msg118295#msg118295

The MinGw that comes with Code::Blocks is actually TDM-GCC, and TDM-GCC links libgcc and libstdc++ statically by default, but SFML links them dynamically, and this causes problems when memory is allocated in one module and freed in another.

So if you're using TDM-GCC you have to either compile SFML with SFML_USE_STATIC_STD_LIBS or order TDM-GCC to do dynamic linking with "-shared-libgcc" and "-shared-libstdc++"

11

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 12, 2014, 11:40:53 pm »

If SetClipboardData succeeds, the system owns the object identified by the hMem parameter.

12

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 10, 2014, 11:25:51 pm »

And the API does not make sense from a semantic standpoint, users not being familiar with X11 won't expect the clipboard to be associated with a window. Other than Juhani, I don't think we should prematurely exclude applications that access the clipboard but not the window. Why is a console application not allowed to use a clipboard?

What use cases could a console application have for the clipboard? I can't think of any. I still claim that an app needs no clipboard access if the user isn't copy/pasting, and the user can't copy/paste if there isn't a window. How would the user control the clipboard from a console app, anyway? Type in a command?

Additionally, clipboard-related functionality is not gathered in one place if we add functions to the window. What if we decide to extend the clipboard API in the future, e.g. by supporting more MIME types? We would then have to further bloat sf::Window.

This brings to my mind Guru of the Week #84, where Herb Sutter states that the most OO way to write methods in C++ is making non-member non-friend functions.
So, if we were to follow his advice we would make the clipboard interface exactly identical to GLFW, even a global function taking a window as a parameter.

13

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 10, 2014, 05:35:37 pm »

I also favour the member function.

14

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 09, 2014, 10:05:36 pm »

Aside from possible performance issues and simpler implementation, I know nothing that would favour the member function, but I don't believe that it would cause any problems either.

I claim that there is a window if the application needs clipboard access. Here's my rationale:

1. An application doesn't need clipboard access if the user isn't copy/pasting something.
2. The user can't copy/paste if there isn't a window to copy/paste from/to.
----------------------------------------------------------------------------------------------------------
Therefore, the application doesn't need clipboard access if there isn't a window.
Which is to say, applying transposition, that there is a window if the application needs clipboard access.
If you disagree with this, then which is the premise you disagree with?

As for the case with multiple windows, the window would be decided by the user when calling the member function, even

*this

.

15

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 09, 2014, 01:32:29 pm »

A member function would be OK to me. After all, if you don't have a window, then where would the user paste the clipboard contents? or whence would he copy to clipboard?