Messages

1

SFML projects / Re: [GUI] SFML backend for ImGui

« on: June 28, 2015, 09:46:42 am »

I've updated the repository and main post.
The usage has slightly changed, but everything works now.

Sorry for my absence and lack of response, thanks for your patience.

2

SFML projects / Re: [GUI] SFML backend for ImGui

« on: March 16, 2015, 11:47:27 am »

Would be nice to have that pushed into the main repo.

Sorry for my lack of response. I've been extremely busy lately, but I should have the repo updated with much more than this by Sunday (March 22nd). Rendering and event backends will be completely separate, allowing them to be used interchangeably with different libraries.

Not sure if I'll have time, but GLFW and SDL support should also be there soon enough, and I'll try to come up with a clever method for replacing glScissor without using OpenGL directly in the SFML rendering backend.

3

Window / Re: [Linux]window.setPosition()

« on: February 04, 2015, 10:44:28 pm »

You can easily test the known bug I mentioned in a previous post, by calling setPosition(x, y) and checking if getPosition() returns {x, y}.

This is fixed in the XCB patch. test code:

(click to show/hide)

#include <iostream>
#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow window(sf::VideoMode(800, 600), "CustomBorders", sf::Style::None);

        while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.setPosition(sf::Vector2i(100, 100));//window.getPosition()+sf::Vector2i(10, 10));

        std::cout<<window.getPosition().x<<" "<<window.getPosition().y<<std::endl;

        sf::sleep(sf::seconds(5));

        window.clear();
        window.display();
    }
}

This isn't the same bug, I think.

4

Window / Re: [Linux]window.setPosition()

« on: February 04, 2015, 10:39:34 pm »

sf::Window::getPosition() does not update when sf::Window::setPosition(...) is called. I just tested this with:

(click to show/hide)

#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow window(sf::VideoMode(800, 600), "CustomBorders", sf::Style::None);

        while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.setPosition(window.getPosition()+sf::Vector2i(10, 10));

        sf::sleep(sf::seconds(5));

        window.clear();
        window.display();
    }
}
 

This is probably a child/parent/root window issue in the xcb code.

5

SFML projects / [GUI] SFML backend for ImGui

« on: January 05, 2015, 07:51:23 pm »

Hello.

I've written an SFML backend for ImGui: https://github.com/Mischa-Alff/imgui-backends

ImGui is a bloat-free graphical user interface library for C++. It outputs vertex buffers that you can render in your 3D-pipeline enabled application. It is portable, renderer agnostic and carries minimal amount of dependencies. It is based on an "immediate" graphical user interface paradigm which allows you to build user interfaces with ease.

ImGui is designed to enable fast iteration and allow programmers to create "content creation" or "debug" tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal, and thus lacks certain features normally found in more high-level libraries.

ImGui is particularly suited to integration in 3D applications, fullscreen applications, embedded applications, games, or any applications on consoles platforms where operating system features are non-standard.

The backend uses SFML's vertex arrays (and GL_TRIANGLES) for rendering, so this should work on every platform SFML supports.

Usage is explained in the repository's SFML/README.md, or here: https://github.com/Mischa-Alff/imgui-backends/blob/master/SFML/README.md

What isn't implemented:

• Stencils. If the horizontal ImGui window size is too small, you'll still see transparent rectangles, as SFML does not provide support for clipping, and I haven't gotten around to working on a solution.

Cheers

6

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

« on: December 29, 2014, 11:35:51 pm »

It seems that the API people want is sf::Clipboard::set(string, window). How should this be implemented in a way that the X11 window can properly respond to selection related events?

7

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

« on: October 23, 2014, 11:24:38 pm »

Okay.

To whoever wanted to be able to get raw clipboard data:
Here is the list of target formats on Linux: http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
Take a very good look at it and tell me if you see "RAW" anywhere, because I don't. Perhaps I'm wrong, and that's great!

To whoever wants to support 26 different selection formats:
Here is the list of target formats on Linux: http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
Take a very good look at it and tell me if you see more than 3 that are interesting to you. I can find three interesting formats:

• Text/String/UTF-8
• Images
• Timestamps?

Of all of those, timestamps are the most necessary! (That was irony, by the way)

To those who have an irrational fear of API clutter:
This means that we'd get at most two get/set clipboard functions in the sf::Window class for text and.. timestamps, and one in the sf::RenderWindow class for images. That's not API clutter.
As zsbzsb and I said:
Realistically, we'd have one function in sf::Window for text, and an overload, for images, in sf::RenderWindow.

To those who want to compare to Qt:
Stop. Qt is a huge, high-level library. If I remember correctly, some people enjoy calling SFML a low-level library. So why are you comparing both?

To those who want to compare to SDL:
This isn't C, this is C++. We have OOP and all these wonderful things. Also SDL is much bigger than SFML and nobody cares if it has "bad" hacks.

To those who think a clipboard class is a better idea:
On Windows and Linux, you're getting the clipboard from the window. No point in hiding that from the user. You must also assume the user isn't a complete moron. Seriously. I don't mind making things "user friendly", but the user has to know what a clipboard is, and how to use it. It's not the window's clipboard, but you are giving the clipboard contents to the window, and you are getting the clipboard contents from the window.

To those who want a getAvailableFormats function:
I actually agree. This is a good idea, and it can be implemented whenever someone decides to add an sf::Image overload.

Regarding the allWindows vector:
It's a horrible, horrible hack. I don't care who wrote it. There's a much better way of doing this (almost identical procedure to how it's done on Windows), and a little Googling and reading some documentation and headers would prove very useful.

That's pretty much all I can think of.

And don't worry, it won't get lost just because it is not merged

Yes it will.

8

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

« on: October 23, 2014, 07:18:48 pm »

"fixing the API" = breaking the API => Can only be done for every major version.
If everything was just merged without thinking about the API, SFML wouldn't be where it is today. So it won't be merged for the sake of having it merged, but it will be merged once it's done, meaning the API has been decided, it has been tested enough and has been reviewed.

I understand.

9

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

« on: October 23, 2014, 06:52:27 pm »

Maybe we should focus on the functionality instead of the API right now.
With this kerfuffle, only two people other than me have tested my PR and given me results.
Can people test, give me results, etc?

For the sake of not having this lost in "PRs we couldn't agree on", perhaps this should get merged, and an issue should be created on GitHub for fixing the API?
The arguments could be listed there, and anybody who wants to fix the API and/or contribute to the discussion can do so.

10

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

« on: October 21, 2014, 12:35:51 pm »

EDIT: We can ask for a list of available formats on Linux, not sure about Windows.

That should definitely be investigated. If we know the format, it allows for a simpler and more flexible implementation.

Seems like it is possible on Windows too.

Then yes, it's possible.

Unrelated to what you just compared to Qt, but we really should stop comparing to Qt. It's a huge, high-level library that serves a completely different purpose. They don't care if the API is bloated, or if the code is slow, and they probably didn't have a single person implementing it.

11

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

« on: October 21, 2014, 12:07:08 pm »

I don't think we should waste our time with an implement which doesn't have the window argument.

So, assuming the other systems don't need a window, you would still require that parameter but just ignore it in the function? On mobile systems, does the user always have a window at hand?

Very few people write console applications with SFML.
Nobody writes windowless applications with SFML on Android.

And we should start with a neutral implementation that deals with raw data (vector<char> instead of sf::String), and implement conversions to unicode text, image, whatever on top of it.

But we should definitely provide a string-based high-level function pair. Do we want to provide all MIME types from the beginning? I'd probably start with text-only clipboards and such a high level function, it's still possible to add a generic interface for further types later.

As I've said: supporting "as many MIME types as possible" isn't an issue. Other (similar) libraries only support a text clipboard (UTF-8), and nobody is complaining.
While planning ahead for potential additional MIME types is a good idea. We'll probably never get any, and if we do, it'll be in a somewhat distant future.

This is not what I was suggesting. In the end we would do all the conversion job, the user will still be able to call getText, getImage, etc. directly.

What I'm suggesting is to split our implementation into two layers: the part that gets raw data + format from the OS, and another part that provides higher-level access functions, internally doing conversions from/to raw data based on the format. This would improve flexibility, not require stupid dependencies between modules (the text handler can be written in sfml-window, the image handler in sfml-graphics, etc.), and leave space for user conversions of formats that we don't support out of the box. Don't forget that sf::String is not raw data, it already performs a conversion based on a character encoding, so this must not be the "base" type for clipboard access, only one of the high-level conversion that we provide.

So:

class Clipboard
{
    // these functions are directly plugged on the OS-specific implementation
    static Format getFormat();
    static vector<char> getData(Window& window);
    static void setData(vector<char> data, Format format, Window& window);

    // these functions use the above functions
    static String getText(Window& window); // --> if (format() == Text) return sf::String(getData() ...);
    static void setText(String string, Window& window); // --> setData(string, Text, window);
};

Is this not overcomplicating something that should just be two simple functions?
What does getData return if we request formatted text? An image? A sound clip?
Plus, we can't get the "format" of the clipboard. We can only ask if conversion to a specific format is possible.

EDIT: We can ask for a list of available formats on Linux, not sure about Windows. The point is: there isn't a single available format, even just for text there are a bunch.

12

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

« on: October 21, 2014, 11:39:07 am »

And we should start with a neutral implementation that deals with raw data (vector<char> instead of sf::String), and implement conversions to unicode text, image, whatever on top of it.

Why?
We already know the type of said data, why would we store it in a vector<char> of all things? I don't think asking the user to decode everything is a good idea. A lot of people would get confused.

13

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

« on: October 20, 2014, 08:43:36 pm »

How would the implementation look on other systems -- OS X, iOS, Android?

Nor OSX, nor Android require a window handle to use the clipboard as far as I know.
No clue for iOS.

Does the use of XCB instead of raw X11 change anything?

No.

14

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

« on: October 20, 2014, 06:42:15 pm »

So.. no conclusion?
Now that we've been through the internals, is the current API suitable?

15

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

« on: October 13, 2014, 09:26:05 am »

Yeah, EmptyClipboard would fail if you called it without being the owner. Not the first time that the WinAPI is confusing.

EmptyClipboard sets the owner. As Juhani said, the contents of the clipboard are owned by the system, not the window, when SetClipboardData is called, which is why you don't delete them during cleanup.