Gtk+

[Ademan]

I think the promise of integrating SFML with widget toolkits such as Gtk+ (and others such as Qt and Win32.  However I personally have an interest in Gtk+) is one of the best things about SFML from what i've seen so far, and I would love to see it implemented. (I am totally willing to work on it myself at some point, although I definitely can't dedicate my full attention to it for quite a while)

I guess the purpose of this thread is mostly to see if anyone else has similar interest in this functionality.

cheers
-Dan

[Laurent]

Integration with other GUI toolkits is important ; if someone is interested in making a GTK+ SFML widget if would be nice. Then I can write a tutorial about it and include it in the samples.

[Ademan]

Well I'm certainly interested.  I'm checking out the source code now (though like I said I can't guarantee i'll actually accomplish anything), you mentioned making a Gtk+ widget.  I was thinking that the best way to go about this was to derive from sfWindow (maybe sfWindowImpl ?) and implement the needed features, right? The question remains though, how the GtkWidget * would make it back to the application.  I see several references to sfWindowHandle, however I don't (at least nowhere i can see) allow the user to obtain this handle.

Would it make sense to derive from both sfWindow and sfWindowImpl and provide a member function sfGtkWidget::GetWidget() ?  (which would return a GtkWidget *, or a gtkmm Gtk::Widget *)

This seems to be the sanest solution, however it IS your project and you know better than I what would be most consistent with the current API.

cheers
-Dan

[Laurent]

I don't know much GTK+, but with other GUI toolkits I can create SFML widgets quite easily by inheriting from both sfWindow and the widget base class provided by the toolkit (QWidget, wxControl, ...). No need to deal with sfWindowImpl or sfWindowHandle, which really are implementation details and should remain hidden.
Is it different with GTK+ ?

[Alp]

As GTK+ is C, it will be harder. But with gtkmm, there isn't any problem.

[Ademan]

Hrm ok, so just sfWindow?  That shouldn't be too tough.  I was thinking i'd just derive from sfWindow and encapsulate the Gtk+ functionality within the class (since gtkmm doesn't have openGL capabilities as far as I know)

cheers
-Dan

[Ademan]

Well I am struggling with the sfWindowHandle, the whole concept confuses me a bit.  If sfWindow is to include functionality for both windows and toolkit widgets it doesn't make sense to me to have it be either a HWND or an x11 window handle.  

I'm also a bit confused on how to derive from sfWindow, as none of its methods are virtual, which is how I would have gone about making my derived class useful.

EDIT: Sorry, i realize i may have come off as offensive, sorry if I did, i'm very excited about your library and I'm trying to be constructive.  There's also the possibility that I just need to understand the design decisions better by studying the source more, or then there's the possibility that i'm just flat out crazy and should be ignored :-).

cheers/sorry
-Dan

[Laurent]

Sorry, i realize i may have come off as offensive, sorry if I did, i'm very excited about your library and I'm trying to be constructive

No problem It's a good thing to start discussing about the class design.

sfWindow does not need to be derived to be usable, nor to be customized. I use public inheritance in this case because a SFML widget "is-a" SFML window, ie. it must provide the same public interface as sfWindow. But no behavior has to be cutomized through virtual functions. You could perfectly use private inheritance or have a sfWindow as a member of your custom widget, the only consequence is that you wouldn't propagate the public interface of sfWindow.

Does it make things clearer for you ?

[Ademan]

Well I was sort of thinking about the reverse, where sfGtkWidget (probably a bad name as well) "is-a" sfWindow, and "has-a" the appropriate Gtk+ information (such as a handle to the widget and any associated data)  In which case it (to me) seems important to be able to override things like UseVerticalSync(), SetCurrent(), and Display() because they could be vastly different (I think?) between different "backends" (at least thats how I was envisioning the setup)

http://picasaweb.google.com/ademan555/Misc/photo#5098490718798421314

This is sort of what I was envisioning as far as the usage goes.

Code: [Select]


sfWindow & Window = sfGetGtkWidget(sfVideoMode(640, 480, 32), "gtkWidget");

sfWindowImpl * Impl = dynamic_cast <sfGtkWidgetImpl> (Window.GetImpl());

if (Impl)
    gtk_widget_add(SomeOtherGtkWidget, Impl->GetGtkWidget()); //thereby adding the GtkWidget to SomeOtherGtkWidget


The factory would return sfWindows but the sfWindowImpl would depend on the function called, GetGtkWidget would obviously return a sfWindow with a sfGtkWidgetImpl which would internally handle all of the things needed by an application (such as initializing the surface, switching modes, flipping the front and back buffers).

And as far as my factory class, the more I think about it the sillier i think it is, there could be a CreateWindow() function (free of any class) which takes an implementation type enum(gtk, qt, whatever), or even just CreateGtkWidgetWindow() or something like that.

(I realized that deducing the correct sfWindowImpl based on the things required of it is sort of impossible considering the program needs to know whether it's a wxWidget or a GtkWidget that's being returned)

Anyways, its rather late and I need some sleep (probably evident in my deteriorating grammar) but I'll be back.

cheers
-Dan

[Laurent]

You don't need to provide a window implementation for every toolkit. SFML relies on the lowest possible level (Win32 under Window, XLib under Linux), so all you have to do is to get the low-level ID of your toolkit widget, pass it to SFML and watch things working automatically

The only thing to do then is to put the call to Display() at the right place (usually in the paint event), and a way to refresh the control at a framerate high enough (using the idle event, or a timer).

That's why I don't think we need such complicated things

[Ademan]

Hrm, well i see what you're saying now (i checked out the wxWidgets example, and reread what you were saying with a few more working brain cells).  I suppose they're just 2 different solutions to the same problem, i'll probably be pondering for a while...
cheers
-Dan