OpenGL Widget Set Recommendations? 154
"GLUI provides a flexible windowing system and a rich selection of widgets (buttons, checkboxes, radio button sets, spinners, text boxes, arcballs, dividers, packing panels, packing columns, etc.). GLUI's design is very straightforward, and the docs and examples are extremely well done. GLUI is highly portable, since it depends only on OpenGL and Glut.
GLOW is 'a cross-platform object-oriented framework for building interactive applications using OpenGL or similar APIs such as Mesa.' GLOW is basically an elegant C++ wrapper around Glut, providing push buttons, check boxes, radio buttons, scroll bars, sliders, text fields, menus, etc. This is a really nice description of GLOW, including comparisons to GLUI and MUI.
Speaking of MUI, Steve Baker's advice is basically 'just don't.' Instead, Steve recommends PUI, which he wrote. :) Actually, he speaks very highly of GLUI, and does a nice job of pointing out the subtle differences between GLUI and PUI.
PUI is part of PLIB, a rich and vibrant set of libraries for cross-platform game development. This is a wonderful intro to PUI. Go read it right now. Really. PUI itself does all the sorts of stuff I'm looking for, and perhaps more. It looks to be very stable and mature, too.
LibUFO is a C++ widget set for OpenGL, currently in alpha. Features include pluggable look and feel, theme support, and layout manager support. LibUFO can be used with GLUT, SDL or any native GL context, so it is highly portable, too. Except for the fact that this is only alpha code at this point, it looks quite nice.
FOX is a C++ toolkit for developing cross-platform GUI apps. It seems like a fairly standard C++ framework, with built-in OpenGL widgets, too. By all accounts, FOX is quite mature and stable, with a fairly active developer base. FOX supports many OSes, but not, unfortunately, the Mac. And yes, I could easily hack out Mac support myself, but I don't want to do that-- I want to write my app.
FLTK is another cross-platform C++ GUI toolkit with OpenGL support. The advantage of FLTK over FOX is that FLTK supports MacOS X (not 9.x and earlier-- too bad).
DirectFB is a library built on top of a framebuffer device such as the Linux framebuffer or SDL. There seems to be some 3D support in there via DirectFBGL, though the docs say that there is no hardware acceleration support (i.e. Mesa vs OpenGL). The thing that makes DirectFB particularly attractive is the fact that Gtk/Gdk has been ported to it.
SDL and ParaGUI are also an attractive option. SDL is insanely portable, and ParaGUI is a wonderful GUI/widget toolkit that runs on top of SDL. You really need to see the ParaGUI demos running to appreciate how slick it is. The screenshots are nice and all, but they don't do it justice. As well, ParaGUI is really slick in its support for themes, XML, and Python.
PicoGUI was a recent SlashDotting victim. As mentioned at that time, PicoGUI is actually a sophisticated client-server framework, capable of running in a wide variety of environments, including on top of OpenGL. There is plenty of info at the PicoGUI FAQ, including a few comments that suggest it would be a perfectly reasonable choice for what I'm looking at doing. Given the scope of what PicoGUI is trying to achieve, I'm a little nervous that it might be overkill for what I want to do.
Fresco is another client-server framework which some may have previously known as Berlin. Fresco seems very cool, but again, I suspect it is overkill for what I'm doing.
The GUI Toolkit/Framework Page is also an excellent resource for cross-platform development of all stripes.
And the OpenGL Toolkit FAQ is also an excellent resource with special emphasis on OpenGL."
WxWindows (Score:2, Informative)
"Excellent, stable and intuitive API. Very straightforward to learn and easy to port Java, X11 and Win32 code to."
"Thanks heaps for the best piece of software I've ever come across."
"wxWindows 2 has been an absolute dream."
"I've never had an easier porting experience."
"I never thought that cross-platform development could be so easy and simply cool."
"I have used wxWindows in the past very successfully on multiple projects, and think it's the bee's knees. Thanks for everything!"
"wxWindows is jaw dropping amazing. Community support from the mailing list is extraordinary. Are you sure this is free?"
"wxWindows is one of the most magnificent development projects in existence.."
Re:WxWindows (Score:4, Informative)
Also worry about memory leaks. I am not sure If the code I wrote was leaking it or whether it was wxWindows, but hte programs did leak gallons of memory.
Not that I am an authority on wxWindows, or that it is a bad library, just a warning. Maybe some other readers have had experiences?
Re:memory leaks in WxWindows (Score:1)
If you think you've found a memory leak in wxWindows, please do let us know about it (comp.soft-sys.wxwindows). Remember that if our users don't report the bugs to us, we have much harder time fixing them.
Of course, in my experience, memory leaks in wxWindows are more often than not leaks (or bugs) in the user code but if you're sure your code is ok, please try to report the problem. Posting a bug report won't take much longer than posting to Slashdot (although arguably it's not as much fun).
VZ
Re:memory leaks in WxWindows (Score:2)
As an avid wx user (and casual contributor) for three years, let me say that wx is remarkably bug-free for a library that size. I use wx daily, both at work (designing GUIs for scientists at JPL) and on the side (Audacity [sf.net]) and I haven't seen a wx memory leak in a year. Nor have I seen a crash: the worst problems I've seen recently are occasional cosmetic errors that are easy to work around (i.e. a window redraws itself unnecessarily when you modify a certain attribute).
Re:WxWindows (Score:1)
wxWindows (Score:2, Informative)
Additional requirement - Widgets on textures! (Score:4, Interesting)
It'd be nice if a cross-platform widget/GUI library existed that would allow me to place the GUI's into the environment, by rendering to textures or virtual GUI planes, instead of just as yet another 2d desktop library. Its not TOO much additional work if done from the beginning...
Think of the fun you could have w/ full GUI support in the environment. A 3d embeddable Gecko control, anyone?
Re:Additional requirement - Widgets on textures! (Score:1)
A 3d embeddable Gecko control, anyone? :) (Wish that code was cleaner...)
You mean like something taken out of a David Cronenberg film?
Coin3D offers 3D widgets (Score:2, Informative)
Good luck.
Portability (Score:4, Informative)
For your GUI, take a look at GNUstep [gnustep.org]. It supports Linux, the BSDs, Solaris and Windows and is (pretty much) compatible with Cocoa.
For your 3D graphic stuff, take a look at the GNU 3DKit [gnu.org].
Re:Portability (Score:2)
Better change the name of whatever you want to code to "GNU/$ORIGINAL_NAME" lest you want to wake up one night with RMS next to you with a hockey mask and GNU/chainsaw.
Funny (Score:1)
wxWindows, FLTK (Score:4, Interesting)
I would recommend against using widget sets with OpenGL as a graphics layer unless you really need it: OpenGL is less than ideal for that purpose.
Re:wxWindows, FLTK (Score:1)
Just curious: why do you say that?
Re: (Score:3, Insightful)
Re:wxWindows, FLTK (Score:1)
Re:wxWindows, FLTK (Score:2)
Re:wxWindows, FLTK (Score:4, Interesting)
I'm not sure if any of the others do the same as I have never used them.
FLTK (Score:2)
Defanetley SDL (Score:2, Insightful)
Re:Defanetley SDL (Score:1)
There are some books about SDL, but the really good stuff can be found in the online documentation off of the web site. SDL also has really good community support. I have had nothing but good experiences with SDL and I would recommend it to everyone.
Re:Defanetley SDL (Score:2)
Use SDL if you want to create a cross-platform game, or movie player. For everything else that has a GUI, use wxWindows or one of the toolkits mentioned above.
Actually (Score:2, Insightful)
Mozilla XUL (Score:1)
PUI (Score:2)
SDL is OK (Score:2, Informative)
SDL doesn't have a GUI actually, but there are several GUIs made FOR SDL by other people.
Good luck!
Re:SDL is OK (Score:1)
Qt (Score:3, Informative)
You definitely forgot Qt [troll.no]. The only downside is that it's commercial on Win32 (unless you're running MSVC6), apart from that it does its job very well, and has a very reasonable OpenGL widget.
As for wxWindows (which others have suggested), I tried it some time ago and I think it truly sucked. Hopefully it has improved since then :-)
/* Steinar */
Re:Qt (Score:1)
In that case, several of his own suggestions seem to be wrong in exactly the same aspect. :-)
/* Steinar */
Re:Qt (Score:1)
Re:Qt (Score:3, Informative)
How long ago did you try wxWindows? If it was before 2.0, I can forgive you, but especially since version 2.2, wxWindows completely rocks.
wxWindows provides native widgets on more platforms than any other toolkit (Windows, Mac OS 9, Mac OS X, Unix/GTK, plus wxUniversal which gives you themable widgets based on extremely low-level interfaces such as pure X11 or a PDA's framebuffer).
It's closely modeled after the most widely-used GUI toolkit in existence (MFC) yet it deviates from the MFC model when necessary to make it more consistent, more flexible, or easier to use. What this means is that it's reasonably easy for anyone to pick up, but doubly easy for anyone who's used another modern C++ GUI toolkit like MFC, PowerPlant, or Qt.
wxWindows has more utility classes than just about any other toolkit I've seen, too: check out their list of classes [york.ac.uk]. One thing I love about wxWindows is that it goes beyond the least common denominator, and in fact makes it easy to take advantage of platform-specific features when you want to: for example setting the X Display of a window you pop up in X11, changing the Taskbar icon of a window in Windows, or setting the type/creator of a file on the Mac. Oh yes, and it has a perfectly decent OpenGL widget, too.
wxWindows is also not limited to C++ - it works well from Python, too...
Finally, the wxWindows developer and user communities are very helpful.
Re:Qt (Score:2)
Yes, it was before 2.0. (Everything was horribly painful to use, dialogs were a pain to set up, there was no real documentation except "whee, it's great!", etc. In general it didn't like me, and I didn't like it. :-) ) But no, I don't like MFC either ;-) I'll probably give it a new shot sooner or later, though.
/* Steinar */
GTK? (Score:2, Informative)
Comment removed (Score:5, Interesting)
Re:Cross platform widgets are BAD (Score:4, Informative)
It does exactly what you describe. It provides a single API, that, when linked with the appropriate platform's libs, creates the GUI using that platforms GUI.
Re:Cross platform widgets are BAD (Score:2, Informative)
If you absolutely need your widgets to be a part of the 3D environment... you're going to have to keep looking.
Good luck!
Re:Cross platform widgets are BAD(Yeah right!!!) (Score:2, Informative)
Don't tell me you don't know Qt [trolltech.com] !!! it's the best, totally cross platform, and definitely preserving the look and feel of the host O/S. And it is not only a GUI toolkit, it has everything:
native look and feel
database support
OpenGL support
XML through SAX and DOM implementations
true componentatization through the signal-and-slot mechanism
theme support
app settings and DLL transparent handling
lots of container templates which are easy to use
full visual environment intergrated nicely with various IDEs
source code 100% compatibility from platform to platform
multithreading and synchronization abstraction using the native O/S
networking abstraction using the native O/S
regular expression handling
HTML support
internationalization support with the easiest handling of UTF-8, ASCII and UNICODE formats
some of the best widget sets with full geometry management
follows C++ logic, unlike other toolkits like MFC or wxWindows
Its only downside is that you have to pay for it, but it is definitely worth it, because it is simply the best toolkit out there!!!
Re:Cross platform widgets are BAD (Score:2)
Re:Cross platform widgets are BAD (Score:1)
I'd agree with you in the case of a simple utility, say a sound recording program.
However once the application we're talking about is huge and the user is going to use only this program for hours and days, I don't think it's such a big deal. An example might a sound mixing, processing, on-the-fly editing program.
I use JBuilder quite a lot and I think it's no big deal that it behaves nothing like my KDE desktop. I mean yes CPW that mimic the behaviour of the platfrom are nice, but they just are too much hassle and in the end a decision must be made about what is feasable.
As for the Adobe example, they are not trying to support UNIX/Linux deskotp. Being consistent and pleasing everyone is almost impossible. What "native" behavior should it emulate? KDE? GNOME? Motif? WindowMaker? Just try running Acrobat Reader on Linux and see how out of place it looks.
As for standart behaviour for each platform, that can be coded right into the application, e.g. any program can support the basic GNU/Emacs shortcuts (JBuilder does :-) ).
Re:Cross platform widgets are BAD (Score:1)
JFMulder hit the nail right on the head, though. When developers decide to use their own widgets instead of those provided by the platform (usually so they can offer a choice of l33t "skins",) they're very unlikely to make them complete, especially when it comes to behaviors that are fairly obscure. Sure, it's not fair to expect a programmer to know all the subtleties of every environment in which his program might run -- that's what abstraction is for. Is it really worth it to throw away that advantage, just so your program can have a 3d-accelerated GUI?
Having just built and deployed a SDL app (Score:2)
Re:Having just built and deployed a SDL app (Score:1)
I second that, with caveats (Score:2, Insightful)
That said, since I developed my own 2D sprite library in C++ on top of OpenGL I'm writing my own set of widgets that will leverage the sprite engine. Basically this comes down to building my own "responder" chain, keeping track of which item has the focus, testing clicks inside my widgets (which are sprites in most cases), etc.
There are obvious advantages to building your own widgets, such as the aforementioned leveraging of your graphics engine to create a distinctive interface. And there are obvious disadvantages, such as the added development time required to put the whole thing together. Either way you will learn a lot about how (not) to implement a GUI.
For most games you can get away with a very minimal GUI, basically testing for clicks inside rectangles, but if you need to do more, such as building a level editor, it's nice to have all the standard items like menus, checkboxes, and file dialogs.
Think why Not what. (Score:2)
They basically want to enter textual (single or multi-line text, numbers, dates, currency [specie and quantity]) or spacial (2D or 3D coordinate system point[s]) data
or
to navigate relationships between objects. Think 0|1:0|1|N relationships (select from a list which may be a simple or a compound presentation of text, graphical or mixed views of objects.
Radio Buttons, push butons and other 'screen candy' should be switchable without the developer being involved. This has been available in Smalltalk (Widgets) since '91. Extend don't re-invent.
Let the user theme the presentations. Let the coder concentrate on the objects and the relationships, what's important.
And set up your API's on data streams so that you NEVER waste a cycle pumping data one pixel beyond what's visible. (There is NOTHING as disgusting as waiting on a GUI to fill a window that only shows a few Ks of data with a the complete contents of a multi-megabyte file.)
Duh!!! (Score:2, Funny)
FastGraph (Score:1)
There used to be a graphics library called FastGraph by infamous Ted gruber Software, and surprisingly it is still around [fastgraph.com](It actually predates borlands BGI driver, if people still remember that one). I used it 10 years ago to take my first feeble steps in graphics in c++, and designed my own widgets and basicly invented my own buttons/frames/menus system all by myself, and to this day the framework of that code is still usuable. Anyway, it's not a recommendation or anything, I would never used it at this time.
BGI? nooooooo! (Score:2)
prototyping is important (Score:2, Interesting)
Prototyping tools are different from production tools. It's okay (even preferable) to prototype in one environment, and write the deliverable in another. 3-D design is not cut-and dried, so you will spend a lot of time messing with how things look. This is much easier in an interpreted world than in one that requires compiling and linking of big C++ executables every time you decide that the red cube is a little too big.
Re:prototyping is important (Score:1)
Check out ClanLib (Score:2)
OGRE is another option (Score:1)
Re:OGRE is another option (Score:1)
It's not "coding by celebrity," but "coding by generally accepted good programming practices." (And, um, not in the sense of Arthur Anderson's interpretation of "generally accepted good accounting practices".) The names associated with seminal books on these practices are just eponymous -- again, they're just used as references by the experienced.
SWT (Score:1)
Re:SWT (Score:1)
[redhat.com]
ftp://sources.redhat.com/pub/rhug/swt-gcj-green
and just configure/make to get lib-org-eclipse-swt.so with gcj.
Re:SWT (Score:2)
Check out how Blender3d does it (Score:1)
GLUI Rocks! (Score:1)
The fact that GLUI is built on top of glut means that it is as cross platform as glut itself. I have not used any of the other toolkits but I would definitely use this toolkit again.
If you are intrested in what i used it for I have a short description of my dissertation (with screenshots) at :
http://www.hamza.legend.org.uk/diss.html [legend.org.uk]
Hope this helps.
Since you actually ARE reinventing the wheel... (Score:2)
Bottom line: Use fresco or join the Blender project - they've got their own kit fitted extra for the programm and therefore it runs on more or less everything that runs on electricity.
Re:Since you actually ARE reinventing the wheel... (Score:1)
Blender otoh is a waste of time imo. I hope something useful comes out of the whole open-source thing they hyped the community with, but until they sort out their code and make it usable for other developers i for one am not going to look at it again.
GLUI (Score:1)
On the other hand, it's only really made for simple, toy-ish programs. You couldn't really use it for a complicated or professional program interface.
Also I don't know how much Paul Rademacher (the author) is doing as far as updating/maintaining the code these days. Don't ask him about sliders! (There ain't none)
SDL and PyGame (Score:1)
Check out the Python wrapping of SDL PyGame
Check out the VGL (Score:2)
Obviously if you're not coding in Delphi/Kylix, then it's not much use.
Togl (also check out ayam3d) (Score:3, Interesting)
You might want to take a look at Togl [sourceforge.net]
It's a Tcl/Tk widget, it's pretty friendly and cross platform. There are a couple of 3D modellers using Togl. One of them is called Ayam3d [ayam3d.org] (it's kind of like Maya but not, it's also open source). AC3D [ac3d.org] is the other modeller I know using Togl, and it's shareware.
GTK+ with gtkglarea (Score:1, Informative)
It works perfectly OK on any Unix System and also in Win32.
I wrote several CAD/CAM applications for Linux [inocam.com] using this combination and the port to Windows took only two afternoons.
It was just a question of downloading all the stuff for win32 and I only had to correct some syntax problemas and change some header files in VC++ (some IFDEFs).
I also had one more problem with transient windows, because sometimes the dialog windows would move to the back of the main window and get invisible, but I solved that with a IFDEF _WIN32 and a call to a native WIN32 API function
Even the internationalization stuff works in WIN32.
In this process I always try to use only GTK+ widgets and avoid using Gnome stuff.
On the other hand, the user interface builder glade generates perfectly portable code.
I'm confused. (Score:3, Insightful)
U the same dude? (Score:1)
Use FLTK (Score:2)
The main reason for this is that it sounds like your project will consist more or less of a UI wrapped around a rendering engine. It is really, really easy to use FLTK to create quick GUIs to work with an existing codebase. As an example, all of the skeleton code we've developed and distributed while teaching graphics courses to undergraduates uses this package; its easy for the students to build on, lots of documentation exists, it has a lot of prebuilt functionality, and its pretty flexible. Since the focus is on *graphics* instead of the *applications*, FLTK fit perfectly for what we needed windowing-wise. And yeah, those who want to work on their projects under linux or OS X can do so without a whole lot of fuss.
Just $.02 from someone who's administered projects that are along the lines of what you're doing (on a much smaller scale). Good luck, looking forward to seeing your work!
TK/TCL, Visual TCL (Score:2)
Ayam3d and AC3D are both fast and light. they run well even on older hardware(i've tested this time and time again.
Also, someone else pointed out Coin3D. i've always hoped that someone would do something with it. it's just too cool.
QT? (Score:1, Redundant)
Use GTK+ 2.x (Score:3, Informative)
GTK+ does not support OpenGL out of the box, so to speak, but you can get a package called gtkglarea which adds an OpenGL widget.
If you use GTK+ v1.2, then gtkglarea v1.2.x packages are easy to find and come with many distros (e.g. Redhat).
However, I would recommend that you use GTK+ 2.x, since you are coding a new application, and GTK+ 2.x is much improved. There is no *official* version of gtkglarea for GTK+ 2.0 though. HOWEVER, you can get gtkglarea v1.99.0. Look on developer.gnome.org. I think.
Links:
Gnome ftp site [gnome.org]
Gnome ftp mirror [linux.org.uk]
GTK+'s main advantages are its maturity, its solid design, and its comprehensive selection of widgets. If your application is going to reach an appreciable size, then you will want a good widget set like GTK+.
As a C++ programmer, I find GTK+'s reliance on vanilla C to be a little irritating, however, you can gtk GTK-- which is a C++ wrapper for it. I prefer to use GTK+ directly though, so I interface my C++ code with GTK+ by using static member functions for callbacks.
Hope that helps
Mr. Meanie
I use Qt and the QGLWidget (Score:3, Informative)
Who needs widgets? (Score:2)
If you really want to be innovative, you will do away with widgets entirely. Oh, wait, it's already been done [quelsolaar.com].
Experience with OpenGL widget sets (Score:2)
GLOW is a nicely designed widget set, built on top of OpenGL. Written at Caltech. It uses GLUT, which has some problems with multiple windows.
GLUI has some nice widgets, but is badly designed internally - you can't add new widgets without modifying existing code.
GLUT is a big problem. It's widely used, but it's SGI abandonware, with a wierd license that doesn't let you distribute modified versions. So you're stuck with some annoying bugs. To get around this, some people wrote FreeGLUT, put it on SourceForge, and it's in good shape and maintained.
Another vote for wxWindows (Score:1)
I've written a small Basic interpreter [sourceforge.net] that uses the wxWindows (unfortunately, too slow to do any real 3D stuff with) and found that it was dead easy to get OpenGL to work with wxWindows.
Basically, you just have to declare a wxGLCanvas and you've got a nice canvas for drawing on. It's nicely integrated into the wx scheme of things - it generates and responds to the same events that a normal wxWindow does.
As people pointed out, you end up with native widgets (use wxSizers to make the layout portable), and wxWindows supports just about every compiler under the sun, which is nice for those of us without infinite budgets.
Plus, there's an excellent group of people on the mailing lists if you get stuck.
Modularity (Score:1)
FLTK (Score:2)
Although FLTK's default widget appearance looks dated, it resembles the SGI inteface that people have come to associate with high-end graphics programs. (virtually no high-end graphics software uses the native widgets on any platform, perhaps because native widgets tend not to offer the kinds of things you need - like good color pickers, configurable slider bars, etc)
Just about the only drawback to FLTK is that the API is C++-only, and it's tied strongly into a C++ "one owner" memory management model, which makes it difficult to use from any other language. (however FLTK is simple and well-designed C++, not like the haphazard hodgepodge of classes and poor event systems in many lesser C++ APIs)...
Java AWT or Swing and Java 3D. (Score:3, Interesting)
No no no no no no no... (Score:1)
DO NOT use a cross platform GUI toolkit, they all end up looking like crap, and pissing users of all the platforms off because the look and feel is all wrong.
"Oh but that's so much work, all my code is platform specific" you say? Well, guess what, someone tought you do code GUIs the wrong way. When someone hits a button you dont put the code in the button call, you call your do_XYZ() function, and you're done.
In fact, Windows, OSX, and a few of the UNIX toolkits will even generate all the code for you when you're done drag/droping the GUI elements on screen! All you have to do is put in the function calls, and you're done.
In fact in the time you've spent working up the post for
OpenGL is not for widgets, that's what the windowing system is for.
Re:No no no no no no no... (Score:2)
LOL.
You've obviously never used wxWindows. It has the native look and feel of each platform. Period. wxWindows rocks. I highly recommend you go check it out before you comment further on GUI toolkits.
Eiffel For Cross-Platform (Score:1)
Portable widgets (Score:1)
Before reinventing the wheel... (Score:1)
http://www.equinox3d.com
Java3D (Score:1)
Furthermore, it has the possibility to use loaders, i.e. a kind of import filters. IIRC, blender is supported as a loader.
Choosing a toolkit (Score:2)
FLTK had what seemed to be a bug in its scrolling - it could have been my code, of course, but I couldn't track it down. They have a mailing list but don't seem to have a helpful community.
FOX had some major inconsistencies between its documentation and its functionality. Nothing one couldn't figure out
Finally I settled on wxWindows. So far, it works as advertised. The documentation is quite good.
I drew the following lessons from my experience
1 - For a development tool, good documentation is a must. And it has to describe the way the tool is, not the way it was or the way it might be.
2 - A tool with more users tends to be better debugged than a tool with fewer users. This isn't a general rule (if it were, Microsoft products would be terrific) but within the open-source community I've found it a useful guide.
3 - Features, OO-purity, etc are much less important than (1) and (2) if you have a task to accomplish and limited time.
wxWindows is a "fatter" toolkit than I'd consider ideal, but I could get the job done with it. It has an MFC-like "Application Framework" but you don't have to use it if it's not appropriate for you application.
YMMV. I hope my comments help you.
they're all junk. do it from scratch or not at all (Score:1)
Re:they're all junk. do it from scratch or not at (Score:2)
It would be more appropriate to say each of them has their advantages and disadvantages.
if u wanna do it at all then do it properly.. and not be stuck in the sort of jam that wings3d for xample is right now.. www wings.com it's used some really totally garbage ericssons ERLANG language..
Erlang is quite cool. However it is a high level language, and thus the programmer has to grasp some advanced concepts before he can reap the benefits.
and tho it may be easy to port.. and use.. its SLOW AND CRAPPY
Then improve it. I remember this being the work a few individuals only.
and WHO in their right minds thinks its OK to having to install 50mb (4000+ files) of Erlang Runtime libraries to use a 800kb application?
It is possible to create compact stand alone binaries form Erlang code. Besides the virtual machine, there is a native compiler (HIPE) which might improve speed.
C++/C ASM.. something like that.. thats what you need!
Each tool has its uses. Manual ASM coding should only be done for a few hot spots which can't be done in C or C++. From Erlangs's perspective, C and C++ are low level languages. :) So one should do the complex stuff as much as possible in Erlang.
Regards,
Marc
Re-inventing the wheel.. (Score:1)
The one issue with it is that for the first release it will not be cross platform (because it was basically a lot quicker for the guy to do it Windows-specific than cross platform), but I'm quite sure that will be fixed soon after its release by someone else. Perhaps it's something you could even do as you have been doing this research into cross-platform GUI's.
-Nutter
Re:Re-inventing the wheel.. (Score:2)
From the plug in section, it seems to imply that it uses MFC. The Win platform needs another modeler like Gates needs another hole in his head. Hopefully, if it's worth a darn, it will be available of Linux and other Unix PDQ. I'm not holding my breath as it never seems to happen. Go figure....
Why reinvent the wheel? (Score:2)
There have been several 3D apps that have come and gone, and right now there are three or so real solid apps that can probably use some help to continue their development:
Blender is a mature, relatively stable app, albeit with a rather funky inplementation of its UI. Implementation notwithstanding, the UI is based entirely on OpenGL. Blender not only supports the modeling, but has a game creation and runtime facilities built right in.
K3D is a very innovative modeling app that has just experienced a resurgence of interest on the part of its original developer, and others. I can't remember if the engine and UI have already been separated to a degree that will allow you to develop your own UI with a K3D engine, but you might want to check that out.
Wingz3d, a modeling app based on Nendo, is very capable, and its current UI is very clean. It's based on erlang, a runtime environment (like java), that seems well-suited to handle a 3D app.
Re:Why reinvent the wheel? (Score:2)
> capable, and its current UI is very clean.
> It's based on erlang, a runtime environment (like
> java), that seems well-suited to handle a 3D app.
Comparing Java and Erlang/OTP [erlang.org]?
Both names are used to reference a programming language, a large library and a run-time system that is based on a virtual machine.
Java is (depending on your view and mode) either a dumbed down version of C++ or a version of C++ adapted for use with a virtual machine.
Erlang however is not an imperative language (where you state the control flow explictly) but a functional language (where the focus is on function evaluation) and a concurrent one too (which means the language system makes it easy for you to work with parallel processes on different CPU nodes).
Both systems come with large libraries. However Erlangs focus is rather concurrency and high availibility while client side Java provides much GUI support.
It is not unusual to do the high level programming in Erlang while interfacing to Java GUI code or to C++ performance intensive stuff.
Regards,
Marc
Re:People won't use your program because its porta (Score:1)
Of course, you make it work on one platform and then start testing elsewhere. That is simple 1st year CS. But you must design from the begining to be cross platform.
Personally, I would love to hear his secret, evil scheme is to write a better Blender front end. The renderer is so damn sweet and fast.