Messages

1

Window / Gtk+

« on: August 15, 2007, 07:21:54 am »

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

2

Window / Gtk+

« on: August 14, 2007, 11:54:47 am »

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

3

Window / Gtk+

« on: August 14, 2007, 11:01:40 am »

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

4

General / Building on Ubuntu

« on: August 14, 2007, 10:15:15 am »

Ah ok, i'll give that a shot, but by the way, it seems the problem was that it wants GL/glew.h from my system (probably a good policy since it will probably be up to date for the system) but that was the only build error, i'm going to try placing my glew.h in my /usr/include and see what happens

cheers
-Dan

5

Window / Gtk+

« on: August 14, 2007, 10:05:58 am »

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

6

General / Building on Ubuntu

« on: August 14, 2007, 10:03:54 am »

I've been trying to build sfml on ubuntu linux 7.04.  CMake fails with this error:
The end of a CMakeLists file was reached with an IF statement that was not closed properly.
Within the directory: /home/dan/Projects/sfml/src/SFML/System
The arguments are: UNIX
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dan/Projects/sfml/src

Which in turn causes a whole mess of problems in Clock.cpp

I changed line 34 from
ENDIF(WIN32)
to
ENDIF(UNIX)
and cmake succeeded (however I'm still getting build errors but I'll give you an update on that.

cheers
-Dan

7

Window / Gtk+

« on: August 14, 2007, 09:38:45 am »

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

8

Window / Gtk+

« on: August 14, 2007, 09:00:23 am »

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