PureBasic Forums - English

Have you tried my example ?
Well, later I'll still try to do it with a PB Windows, it's perhaps possible

Polo: that's just insane, if you don't have GTK on linux your a console user, just about 99% of all linux installs will have GTK installed by default, without it GNOME would not exist, GIMP wouldn't have a line of code to it's name, XChat would be just that 'X' as in history, basically without GTK linux as a desktop is nothing useless, of course there are others like QT,KDE etc. etc. but GTK is considered the standard, more or less the same as you can't run windows without it's gui.

Maybe... But why do we need to install GTK to use Purebasic then ? If GTK is the standard Linux API ?
On Windows, we don't need to install the API

On linux, it is normal for an application to have dependancies.
Why should purebasic be any different?

I don't know... Purebasic could have been an exception
BTW, freak, could you tell me what exactly return WindowID() ? Is it a pointer to GtkWidget, GdkWidget, GtkWindow, ... ???
I'm getting lost
PB's Linux documentation is sometime too much copied from the Pb"s Windows documentation : "ID which identifie the current window in the operating system" doesn't mean anything on Linux, especially in this case, because we don't know exactly what identification it is

Polo, I agree GTK is kind of a standard for windowing in linux... I think fred made a fine choice there. However I would appreciate if fred would show us how we can setup a rendering context with PB so we can use OpenGL commands with PB.

I start to doubt it's possible... Since there is libraries that add an opengl widget to gtk...
I'm still searching, in fact, i've done nearly everything within PB, the only problem : the window is grey, without opengl on it :roll:

BTW, for the WindowID() return, I'm guessing it's a GtkWidget pointer... But it should be documented !

Polo : yes it is one of the draw backs on linux dependancy dep.dep--> tree 44 sub deps deep, and maybe you'll get an error compiling making all that dep fixing a waste of time, that said linux is all about choice, choice of gnome/kde/enlightenment and so on, choice of QT/GTK etc. funny though that's no longer a choice it's more or less manadotory.

Never the less, PB's documentation on linux leaves a lot to be desired, in the effort to cross compile with out or very little modification, the manual has been some what side lined, due to the fact that it requires major modifications to make it apply to the linux envorment, it's not all that bad, but it could be much better, be thankful you've not HAD to use a GTK1/2 function that isn't in the libs yet!.

The way I would implyment GL in pb might be to build my own lib, with simplified functions.

OpenGL is really easy to call and is not the problem unfortunately
The big problem is to create a gl rendering context on a Purebasic window
I'll follow trying, but it doesn't sound like it's possible...

it's possiable just don't have PB create the window in the first place

I think the problem with that was as he stated before, you can't get the events for keys, etc...

uhmm well the salution to that is get the keys else where and do not depending anything PB at all just the language itself, but then what would be the point may as well just use C/C++ at that rate.

Inner wrote:it's possiable just don't have PB create the window in the first place

But as I said, I've managed to do it, when PB doesn't create the window, so with az simple XWindow. Unfortunately the problem is I want PB to create the window, just to be able to handle the event easily with PB
It's of course possible to get the event with Linux API, but I don't want to use that way

but of course no one, wants to use the 'hardcore' way but that's just the way it is, we can't expect Fred to do all these things for us that is asking way to much, however! we can say.. make an easier path and stanadard methods to accessing infomation, like for example; opening a window if the standard API call to open that window without PB basically wrapper, then that is EXACTALLY what is returned from the PB command wrapper not some mangled pointer to some custom thing, which is useless. ( can you tell I've been down this simular road before? )