PureBasic or Q7Basic?

[Fred]

No upset. May be that's why PB doesn't use it directly, from Wikipedia:

Code: Select all

Xlib does not provide support for buttons, menus, scrollbar, etc. Such widgets are provided by other libraries, which in turn use Xlib. There are two kinds of such libraries:

libraries built atop of the Intrinsics library (Xt), which provides support for widgets but does not provide any particular widget; specific widgets are provided by widget set libraries that use Xt, such as Xaw and Motif; libraries that provide widget sets using Xlib directly, without the Xt library, such as the X versions of GTK+, Qt, FLTK and fpGUI.

Applications using any of these widget libraries typically specify the content of the window before entering the main loop and do not need to explicitly handle Expose events and redraw the window content.

The XCB library is an alternative to Xlib. Its two main aims are: reduction in library size and direct access to the X11 protocol. A modification of Xlib has been produced to use XCB as a low-level layer.

We certainly won't redo a full widget toolkit like GTK or QT, it's crazy.

[Polo]

It was just to show Polo, that his statement wasn't fully correct. It is correct for windows and mac, but not for Linux, as it could be even more native.

As I don't care much about Linux, I must say I only had Mac and Windows in mind.
For the little time I tested Purebasic on Linux it did look quite "native" anyway. It's not Fred & Freak's fault if Linux is a mess

[Fred]

It does use GTK+, like any other native application on Ubuntu and other Gnome based environment application. Using something else is just wrong and not 'native'.

[fsw]

On Ubuntu the X Window System and Xlib will be soon replaced by Wayland and other distros will follow suit.
AFAIK QT and GTK+ already run on Wayland - so Xlib will become obsolete.

The X Window System and Xlib only make sense on servers with dumb clients (computers not users) anyhow.

[xorc1zt]

Qt can be also considered as "native". Since ubuntu 11.10, the binaries are included by default and unity2d is made with Qml.

[DarkDragon]

On Ubuntu the X Window System and Xlib will be soon replaced by Wayland and other distros will follow suit.

Yes, but Wayland provides X compatibility: http://wayland.freedesktop.org/xserver.html. It doesn't matter for me what PureBasic uses, but the statement that it is on the lowest system level with it's GUI is wrong for linux.

[fsw]

It seems KBasic and Basic for QT (Q7Basic) and Objective-Basic are all done by the same dude.
KBasic and Basic for QT (Q7Basic) use a byte-code VM.
Objective-Basic compiles to Objective-C and it looks unfinished to me.

One reason why the above mentioned languages don't take off could be QT-Quick and QML (from QT).
Granted both use C-style syntax but still, QT development was never that easy...

[fsw]

... but the statement that it is on the lowest system level with it's GUI is wrong for linux.

If you talk about Xlib: I concur.

[ts-soft]

After reading this, i have download the trial-version of Basic for QT.
I open a example with only a msgbox and compile it. i am still waiting, waiting and waiting.
I have never seen a slowly compiler like this

I think, it is only the first compiling so slow, i test again and i am still waiting, waiting and waiting

[Zach]

To speak to the Virtual Instruments side of this.
I think it is worth noting, we haven't (that I know of) ever seen someone attempt to do this with Purebasic. I don't know of anyone who has created a VST/VSTi

But I entirely believe it should be possible, IF you know what is required to do it, and know what you are doing..
I would gather C++ or some such is the language most people develop VST's with, so keeping that in mind, if there are common libraries that are used often, they may (or may not?) need to be wrapped for use in PB.

Since no one really knows what is required, even at minimal, to create these kinds of DLL's, I really don't think we'll be able to give you a straight answer. We just need someone to attempt to do it

But in terms of, loading other DLL's, or using the Windows API, or using a library or some such, as long as they are all standard CDECL stuff, you'd likely be able to access it, and wrap it if needed. I know in some cases you can even load DLL's and call their commands directly, as long as you have documentation and know what the commands are, and how to get/pass those values between your program and the DLL, using the proper data types.

I really don't know much about this side of things, but that's my contribution to your question. I think it IS possible, you just have to figure out what you need to do to make it happen, and how much work it will be.

I would advise to play with the demo as much as you can, and also consult the documentation on stuff related to DLL compilation, and also loading external libraries, Import statements, defining Interfaces, etc.

[karmacomposer]

To speak to the Virtual Instruments side of this.
I think it is worth noting, we haven't (that I know of) ever seen someone attempt to do this with Purebasic. I don't know of anyone who has created a VST/VSTi

But I entirely believe it should be possible, IF you know what is required to do it, and know what you are doing..
I would gather C++ or some such is the language most people develop VST's with, so keeping that in mind, if there are common libraries that are used often, they may (or may not?) need to be wrapped for use in PB.

Since no one really knows what is required, even at minimal, to create these kinds of DLL's, I really don't think we'll be able to give you a straight answer. We just need someone to attempt to do it

But in terms of, loading other DLL's, or using the Windows API, or using a library or some such, as long as they are all standard CDECL stuff, you'd likely be able to access it, and wrap it if needed. I know in some cases you can even load DLL's and call their commands directly, as long as you have documentation and know what the commands are, and how to get/pass those values between your program and the DLL, using the proper data types.

I really don't know much about this side of things, but that's my contribution to your question. I think it IS possible, you just have to figure out what you need to do to make it happen, and how much work it will be.

I would advise to play with the demo as much as you can, and also consult the documentation on stuff related to DLL compilation, and also loading external libraries, Import statements, defining Interfaces, etc.

There are TONS of resources for Delphi and C++ on how to create VSTi's/VST's. I downloaded most of it. So, if someone can advise me how to create a wrapper in PureBasic perhaps we can create the first ever PureBasic VST. You have NO IDEA how many people would buy PureBasic if this was could be accomplished. Tens of thousands of hopeful coders all over the world would descend upon PureBasic since a easy language to create Virtual Instruments is pretty much most developer's holy grail.

Mike

[Tenaja]

Mike,
I use and like PB--especially the compile speed. I mostly chose it for its cross-platform output, and its string handling, and for the most part I find it a very capable little compiler. I am being productive with it--but here are some areas where I find it weak.

1. Cross platform, as has been previously stated, is pretty shallow. It can do all of the rudimentary things, but advanced tasks require os api calls. For a simple text editor, I have at least 3, maybe 4 places where I test for windows...and I haven't even tried to port it to mac or linux yet. I am not saying it is not suitable for cross platform work, just study the gadgets very carefully if you want a cross-platform gui. For instance, the Windows TaskBar requires API calls to get the height of it--and that could be critical with resizing a window--which I did because I had to hand-code a "snap to window height" feature that supposedly "comes with" win7. (At least now, having written it, the feature will work on all platforms, assuming, of course, I can figure out how to get the taskbar height in Linux & Mac.)

2. Speaking of OS-specific tasks, printing on windows is ABYSMAL, HORRID, SEVERLY LACKING, and add any other non-flattering word in here that you can imagine; there is little printer support. In windows, we get a dialog box (PrintRequester), but no access to any of the options chosen in that box; rudimentary options like page range & number of copies must be found using hard-to-find api calls. Someone wrote a very large printer library for windows, but it is OS specific--so I avoided it. I am dreading the Mac port...

3. The "PB-libraries" are written in C. Take that as a hint as to the efficiency of PB's output...it does simple one-pass compiling that includes inline "abbreviations," but no real "optimizations." (Maybe Fred can find an open source optimizer to throw in some day?) In some areas, output is actually de-optimized, to make things "easier" for beginners with (and encouraging) bad habits; it may even punish good habits. It is not consistent with these types of "helpers"; some can be disabled, some can not. This makes things easier on beginners, but more difficult to produce (relatively) fast output that was coded with good practices if you plan ahead with the option to port it to another language later. This is moot with most GUI stuff, but it may become an issue with CPU intensive tasks--games, heavy memory manipulation, etc.

4. Yes, it has 3d support...but threads indicate most gamers choose a different engine. (I have no interest, so this is just an observation of the forum.)

5. PB uses numerous open source libraries, and the licenses for those is buried in the Help file, so you have to search them out to see if you have to include them in your program. Fred may someday make a "license generator" based on your command usage...but I am not holding my breath.

6. Speaking of the help file, it is pretty good; better than some, not as good as others, but far from great, and as the years have gone by, it is due for some updates.

7. Some "advanced" data structures require a hokey Structure wrapper--such as a map of maps. This is obviously not huge, but it is a limitation.

I think if you are aware of these limitations up front, and you can live with them, then you can't go wrong with PB.

[Tenaja]

One thing I forgot to mention, PB has a great debugger that is invaluable, and the one-click installation gets you up and going immediately. With all of the libraries turned into "basic commands", it is about as easy as it gets.

[auser]

PureBasic has an Orge implementation so 3D games are possible.

Forget PBs current 3D implemention. I started with Blitz3D and did stuff (that just worked) many years ago. It worked like a charm ... on windows. But I found linux more and more usefull in the past as well and it seemed BlitzMax did not support 3D under linux while PB already did. So I thought PB would be similar to Blitz3D with linux-support (hurray?). I was wrong. While you should find screenshots of hundreds of projects done using Blitz3D on the Blitzbasic site you would most likely find just thousands of entries regarding on "how to workaround that PB-3D-implemention with an alternative 3D lib wrapper (like for Irrlicht3D or others)" here. So think of it: Why would so many search for an alternative if the "native" implemention just works like it should? On the other side: PB did not reinvent the wheel and used an already existing 3D-engine (where - as far I know - the B3D-creator did a bit more) so in theory there should be way more time to already polish that wheel where the creator of B3D had still to fiddle around and create from scratch himself. That said: Where is the showcase of all that shiny 3D projects done in PB (because 3D is not that new in PB anymore - so lot of time to implement the wheel that others already invented previously)? In my opinion PBs 3D implemention is (still) in an almost unusable state. And it's in that state already since it was implemented (means many years ago). There was features added but it's way, way too less compared to what you already got somewhere else many years ago (and 3D part did not sleep in meanwhile on PC). I would prefer that the current 3D would be dropped from PB. It would destroy the wrong illusion and probably make time free to fix some other important stuff at parts where PB is more usefull at all. I don't hate PB (I still like it) but I hate the 3D implemention (even more if it's going to linux).

I would not use PBs 3D because:
*) It's legal status is unclear to me. There is a font included for that 3D-GUI that seems not that free at all (I'm pretty sure I reported it already here in the past - even regarding license updated for newer Ogre. Who cares?). Just choose another font? That could be a problem because:
*) It's lacking on features. Some stuff that should be basic is just not there.
*) It most likely did never work on linux like it should many years ago. I guess almost nobody here expects a solution in one day but if you don't get a serious lifesign for that long time it feels dead. If I just open the example it have to work (way more if the stuff below is just using a wheel reinvented by others so major part of the work was done by others). If my crazy examples don't work then it might be ok (it's probably just my fault) and I have to fiddle around a bit longer but if already the stuff that is shipped with PB don't work what should I do with that afterwards? I've tried on different distros over years again and again and .... again ... and it did not what it should out of the box. Sometimes it already crashed at the first functions (so you might ask yourself did somebody ever test this at least once?). I don't care that much if it works currently anymore. It was just a pain and even if I look into 2D programming I'm not that happy. Some might think: 3D did not work? Ok I'm still motivated to do something on linux - let's try some 2D stuff as workaround. Linux implemention is not windows implemention. You have (or at least had) to choose between OpenGL and SDL and if you choosed one or the other then one or other stuff did not work anymore. Something like pixel-collision-detection is probably something you might just need in windows... who cares regarding linux? Yes, yes you could do yourself workaround and/or loose that multiplatform part even if you create some windows and so on... but if I create that myself (or yet again don't reinvent the wheel but use something already done by others) why should I use PB anymore (especially on linux) while so many stuff is C(++) releated anyway (including the communities depending on that)?


As linux-user I feel like a Forever-PB-beta-user that did not get gdb and standard linux-tools but some alien. I could not speak regarding MacOS-implemention. Probably fred or freak got and like a Mac and so polish a bit more there but nobody should seriously tell me that fred or freak ever tried to create a 3D-game in linux using PB. I'm even pretty sure they never tried to create one in windows as well... And I'm even sure they don't use linux on their main PC at home.

SDL is free and opensourced. Ogre is free and opensourced. Even stuff like GTK is free and open sourced. GCC is free and opensourced (VIM, QTCreator, Eclipse and others as well) - and they are used by lots. The major part that still keeps me using PB is: You could create alone fast some slim windows apps (for windows) without shipping some huge annoying runtime with it and you still get easy access to WinAPI. But even there not everything is just a perfect world and while reporting bugs you might get noob-tips coz nobody believes you and finally you might miss some response.

[Primoz128]

It's legal status is unclear to me ... DUDE it's Ogre.

I think you got mental issues...