Separate RenderWindow from Graphics?

[xerzi]

I find i don't often need anything from the Graphics portion, except for the render window itself. Or possible create a derivative of RenderWindow that only creates the graphics context and such (no reliance on glew or opengl ; i don't think, just x11 on linux), it wouldn't need any other dependencies to put this type of window into the Window library.

[Ixrec]

What are you doing with the RenderWindow/OpenGL context that doesn't involve anything else in sfml-graphics?

[eXpl0it3r]

The sf::RenderWindow is part of the sfml-graphics module since you want to render SFML stuff to it.
There's the sf::Window which is part of the sfml-window module, but it still creates the OpenGL context(s) etc.

Edit: Maybe I understood you wrong, but SFML depends on OpenGL. If you want to render stuff it requires OpenGL. Maybe one day there will be other render back-ends as well, but for now we have more important things to do.

My question is, what do you want to do with just a window? If you use it to run your own OS specific code on it, then there's really no need for SFML in all of this. Creating a window is probably one of the easiest thing in OS code writing and since you use OS specific code afterwards anyways there's no reason not to run your own code for the window creation as well.

SFML tries to encourage cross-platform coding and having a plain window which you can't do anything expect run your third-part or OS specific code with, doesn't really encourage cross-platform development.

However if you can bring forth some legitimate applications, we'll certainly discuss it a further.

[xerzi]

OpenGL is crossplatform, i just don't like the dependencies the Graphics library uses, all i need is the window with a context to be created, which is not part of OpenGL and is not crossplatform. I didn't think sf::Window did that.

[eXpl0it3r]

Well then you've either expressed yourself wrongly or contradicted yourself:

(no reliance on glew or opengl ; i don't think, just x11 on linux)

sf::Window gives you a window and some OpenGL contexts, but no SFML drawing stuff - see the official tutorials.
sfml-window of course depends on OpenGL and since we use GLEW for loading the OpenGL symbols, it's also dependent on GLEW, at least for now, because soon we'll use glLoadGen.

[xerzi]

Indubitably, didn't think you needed to link to opengl to create a context, as it is very Operating System specific in terms of parameters and naming used.

[eXpl0it3r]

A context of what?

The thing you need to render stuff is an OpenGL context so it obviously needs OpenGL.

[xerzi]

You have that dependency incorrect, you don't need opengl to create an OpenGL context, you need an opengl context to render using opengl though. So no, since it is such an OS specific operation, i would not say it to be part of opengl.

You are telling me there is a wglCreateContext function in GL on linux? Cause uh i don't see it . It's by chance (eg not a requirement) windoz decided to put that function in the opengl32 library and not gdi or some such where the pixel format is created and what not.

[binary1248]

You have that dependency incorrect, you don't need opengl to create an OpenGL context, you need an opengl context to render using opengl though. So no, since it is such an OS specific operation, i would not say it to be part of opengl.

I guess you haven't ever tried to create a 3.0+ context yet, because if you had, you would know that you need a prior context to initialize the extensions that will yield the final context. And guess how you get those extensions... yes... through the same extension loading functions as you would any other OpenGL function. The fact that those functions don't have names beginning with gl doesn't make them less part of the API than all the other functions you know of.

You are telling me there is a wglCreateContext function in GL on linux? Cause uh i don't see it .

Yeah... I guess you also never heard of glXCreateContext either. That function doesn't exist on Windows, same story. They are both functions from official OpenGL specifications. While OpenGL is a platform agnostic specification, it has to specify such rudimentary interaction between itself and specific windowing systems in order to ensure a proper environment for the rest of the API to work in.

It's by chance (eg not a requirement) windoz decided to put that function in the opengl32 library and not gdi or some such where the pixel format is created and what not.

So... the library that a function lives in all of a sudden determines what API it is part of? Do you really think that it is just by chance that the functions ended up where they are on each operating system? Maybe I have to remind you that the X window system itself and the way Windows deals with its dynamic libraries and installable client drivers predates OpenGL by more than a decade. When OpenGL came along it had to fit into how the operating system already worked and not the other way around. There is a reason GLX is the OpenGL Extension to the X Window System. That makes it and all of its functions no less a part of OpenGL than WGL is, although it might not be in an "opengl" library on UNIX machines.

If what you say is true, then on UNIX machines, you can get a functioning OpenGL context without having to install any OpenGL related software right? Solely with X11 installed, since the glXCreateContext function isn't part of OpenGL...

I don't know where you got all this information from, but before trying to openly disprove what other people say, maybe do a bit more research on the topic at hand.