PB for Windows binding to GTK?

[BasicGuy]

Now that PB has a GTK binding for Linux, will the same be available for Windows? It would seem logical to leverage the GTK API so that PB apps could be ported between platforms with a minimum of fuss and bother.
There is a GTK port to OS X as well...

Any thoughts?

[Num3]

I've asked for this API a long time ago, Windows, Unux, Mac, PalmOs....

http://www.wxwindows.org/

[GedB]

I don't think that switching to GTK would be popular with use Windows users because we would lose the dependancy free executables.

Still, it would be useful as long as it was optional.

[Inner]

I agree wxWidgets should be in PureBasic, however having said that; just look at the tour of available gadgets it would be a nightmare to intergrate into PureBasic, it's not like someone can just throw the lib in and away it goes; at least I don't think it works that way.

Might have a look at what it would take to do this later in 2005 maybe, current project take a higher priority.

[Num3]

Why a nightmare!?

I guess it would be much easier than writting for 3 specific API's, and with a bonus, you can use the same API calls on all OS's, instead of windows API code / GTK API code.

[Karbon]

You don't see some problems ripping out all the support for the native Windows controls to replace them with this library? C'mon!

Never mind the above troubles, these control look like crap to boot! Check out their screen shots - those applications look like they were written for Windows 3.1!

I've said it before and I'll say it again - Linux isn't worth this amount of trouble. Linux has a fraction of the market share that Apple does, and Apple is barely on the board. Windows is not giving up it's iron-clad grip on the desktop OS market any time soon (if ever).

Before anyone starts talking to me about how great Linux is keep in mind that I started using Linux in 1994 and still use it, just not for a desktop OS.

Personally I really liked OSX as a desktop OS but the hardware is just out of control expensive. I sold my TI Powerbook 800 recently (3 years old) and bought *two* modern PCs. You just can't compete with that!

[Num3]

I did not say it was easy

But then, you could do this... on any os:

Personally I really liked OSX as a desktop OS but the hardware is just out of control expensive. I sold my TI Powerbook 800 recently (3 years old) and bought *two* modern PCs. You just can't compete with that!

Gzzzz.... Get an Amiga, at least it has 2 mouse buttons

[BasicGuy]

"I don't think that switching to GTK would be popular with use Windows users because we would lose the dependancy free executables."

I would think it would be *very* popular with Windows users as it would free them from dependancy. It all depends on your needs. I write apps for multiple platforms for a living and right now Java and REALBasic are my tools for RAD. I suspect that many PB users fall into the "hobbyist" category so their needs are different. Sure, there's always C/C++ for cross-platforming but until you've had to deal with different OS quirks, it's not suitable, and it' certainly *not* RAD. Java's not perfect, but it's *much* easier to port... (just my opinion)

"You don't see some problems ripping out all the support for the native Windows controls to replace them with this library? C'mon!"

Hmm, I guess if one could bind to say, the OpenGL API, then it should be reasonable to assume that it can be done to GTK... Isn't PB for M$ making calls to the Windows API for it's displays?

"I've said it before and I'll say it again - Linux isn't worth this amount of trouble."

I beg to differ. REALBasic is covering the "Big 3" and doing quite well. It's a capable RAD tool which I use frequently. True, RB uses whatever native graphics API is present on the platform it's being compiled for but the approach is not without it's difficulties. I think it would be very advantageous to bind to an API that *already*, by dint of it's integration with the OS, takes care of those inconsistencies and doesn't require coding "gymnastics". Compile once, run anywhere.

"Before anyone starts talking to me about how great Linux is keep in mind that I started using Linux in 1994 and still use it, just not for a desktop OS."

Perhaps if users had access to better tools, the desktop market would increase. It certainly has improved with the advent of the KDE and Gnome. I've used the Linux since the kernel was 0.99 and mwm was the windowing enviroment.

[Karbon]

I did not say it was easy

But then, you could do this... on any os:

From an academic standpoint, great. From a usable or even commercial standpoint, bleck. You still have to develop specific versions for the different OSes.

Gzzzz.... Get an Amiga, at least it has 2 mouse buttons

I have a 5 button mouse and it worked just fine with OSX

That single button mouse this is a Mac myth. MacOS has been supporting multiple mouse buttons for a very long time now!

[BasicGuy]

"From a usable or even commercial standpoint, bleck. You still have to develop specific versions for the different OSes. "

I'm not trying to spark an argument but I don't quite understand you here. REALBasic handles OS differences by using different compilation flags or directives. When I compile an app for OS X on an XP machine, I simply set some flags and add a small amount (less than 1% of the total application code) to handle the OS X differences. The point is, I'm invoking *one compiler* and porting to three platforms with a minimum of modification to my source. I don't need three versions of the same source. or three different compilers.
I'm sure that PB must be doing some of the same so as to re-use existing core code. I doubt seriously that LINUX PB or OS X PB are "ground up" rewrites.

[fsw]

I agree wxWidgets should be in PureBasic, however having said that; just look at the tour of available gadgets it would be a nightmare to intergrate into PureBasic, it's not like someone can just throw the lib in and away it goes; at least I don't think it works that way.

Might have a look at what it would take to do this later in 2005 maybe, current project take a higher priority.

There is a wx DLL in the wx.NET package called wx-c.dll.
This dll is a clean c dll and doesn't use any net stuff, but has (I think so...) all wx stuff build in. And because it's c and not c++ it should be fairly easy to talk to it with pure.
The only negative thing is: there is no doc for it, because it's not intended to be used outside wx.net (I think they use it to create wx-NET application that uses the Win32API instead of the NET framework). But I've seen somewhere a project in c that worked with it as a normal gui dll.

[fsw]

You still have to develop specific versions for the different OSes.

I second that.

Even if you use the Purebasic gui toolkit - if you need certain gadget functions or gadget fonts you have to use Win32API.
Example: try to code a input box and use the same font, for the text and buttons, as a messagebox would use (for consistency reasons...).
Without Win32API you can't do it!
BTW: the PB InputRequester has still no cancel button, and because of that it's unusable - but we all know it since the day it came out...)

And with that, if you want to code cross-platform apps, you have to look on the other gui apis and search for the Win32API replacement yourself.

[fsw]

Never mind the above troubles, these control look like crap to boot! Check out their screen shots - those applications look like they were written for Windows 3.1!

But it doesn't have to be.
AFAIK wx uses on all platforms the native os gui as a basis.

[fsw]

I agree wxWidgets should be in PureBasic, however having said that; just look at the tour of available gadgets it would be a nightmare to intergrate into PureBasic, it's not like someone can just throw the lib in and away it goes; at least I don't think it works that way.

Might have a look at what it would take to do this later in 2005 maybe, current project take a higher priority.

There is a wx DLL in the wx.NET package called wx-c.dll.
This dll is a clean c dll and doesn't use any net stuff, but has (I think so...) all wx stuff build in. And because it's c and not c++ it should be fairly easy to talk to it with pure.
The only negative thing is: there is no doc for it, because it's not intended to be used outside wx.net (I think they use it to create wx-NET application that uses the Win32API instead of the NET framework). But I've seen somewhere a project in c that worked with it as a normal gui dll.

Forgot to mention:
under Linux the library's name is libwx-c.so

[Inner]

That single button mouse this is a Mac myth. MacOS has been supporting multiple mouse buttons for a very long time now!

It's not myth, but it is history. Macs at one point did only have 1 mouse button.

There is a wx DLL in the wx.NET package called wx-c.dll.
This dll is a clean c dll and doesn't use any net stuff, but has (I think so...) all wx stuff build in. And because it's c and not c++ it should be fairly easy to talk to it with pure.
The only negative thing is: there is no doc for it, because it's not intended to be used outside wx.net (I think they use it to create wx-NET application that uses the Win32API instead of the NET framework). But I've seen somewhere a project in c that worked with it as a normal gui dll.

Very nice, but it is not the way to approach it the way to approach it is to take the static libs and compile them into PureBasic libraries and make them native to the command set of PureBasic, by using a dll you have to write additional [purebasic] code to access the functions, which has to be an include, which is from my point of view messy, the way I use dll is to learn how the api of the said dll works, so that you are better prepared to use the lib to make a proper purebasic library from from know how.

fsw : I disagree with you, I am currently coding an application that is cross platform over 4 operating systems, thus far I have not had to touch a single api command directly except for some real low level stuff but that isn't anything to do with gui anyway.

Okay well we've been mention 3 of the Operating System, PB supports, we've missed one the Amiga which afaik wx doesn't support.