FOX is a C++ based Toolkit for developing GUIs easily and effectively. It offers a wide, and growing, collection of Controls, and provides state of the art facilities such as drag and drop, selection, as well as OpenGL widgets for 3D graphical manipulation. FOX also implements icons, images, and user-convenience features such as status line help, and tooltips. Tooltips may even be used for 3D objects. FOX stands for Free Objects for X. It was first developed under Linux, but it has now been ported to many flavors of UNIX, plus WindowsNT/2k/XP/9x/ME. After 4 years of development, Jeroen van der Zijp released FOX Toolkit 1.0 just a few days ago. FOX Toolkit is the third big cross-platform open source C++ toolkit, after wxWindows and Qt. In related news, Imperial Software Technology announced that it is now shipping X-Designer 7: Enterprise Edition, a major new version of its GUI builder for Motif, Windows and Java.
FOX Toolkit 1.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Now the Unix/Windows world can share a common, shitty gui API. Mind you, the programs on the unix side will “run faster” but render slower than shit. The windows programs that are developed with this layout will end up never being used because mom and dad windows user won’t know how to install required libraries, nor will they care to do it. The linux knob gobblers will write/port a bunch of shit to this new API, and then it will get packaged in some ghey gadjookistan distro that nobody uses. This, my dear friends, is the perfect way to unify the linux/windows world.
>Now the Unix/Windows world can share a common, shitty gui API
So, you’ve used it, right?
>The windows programs that are developed with this layout will end up never being used because mom and dad windows user won’t know how to install required libraries
All Unix-oriented libraries for Windows are offering binaries with the libraries statically linked. This is the case for SDL games as well. Indeed the Windows people do not need to know how to install libraries, therefore, statistically linking is what happens. Not a problem AT ALL.
>This, my dear friends, is the perfect way to unify the linux/windows world.
You can troll as much as you want.
IMHO the greatest strength and weakness of the free unices is the (often) huge number of tools and libs that is available to accomplish one task.
There will never be more users of free os than commercial ones? – I don’t care as long as I’m happy about a good hack, a fine tweak or a new release of some tool I use when I go to bed in the evening.
Be sure to have my respect everybody coding something out of nothing and giving it away for free!
Now, I don’t like disparaging good programming work, but the FOX toolkit takes the wrong approach IMHO. The last thing this world needs is another toolkit, especially one that may not look like the native toolkit. We need toolkit unifying toolkits. wxWindows is one of these, since it layers a C++ API over each native windowing system’s widgets.
QT, FOX, WinForms, Swing, whatever are all wrong for the current GUI problem. The problem is that unified GUI is good, but developers must be free.
On Mac OS X there is Aqua support from Cocoa, Carbon, Java (Swing or direct to Cocoa) and now Apple Script. Like it or not *users* enjoy a consistant look and feel. This is only possible because Apple controlls the whole show. Also, independant developers will take a hint from what apple has done. So one would expect to see Python and Perl working with Aqua. This is great for Apple because they were able to start from scratch. Unix and Windows will require a very elegant solution. This solution should also support Aqua.
The solution that I am creating defines a GUI description framework. I will use the example of an MP3 player. Typically a MP3 play is skinned to acheive a custom GUI. This skinning maybe just bitmapping images. It may require a custom, but application specific API. My solution will use Interfacing rather than Skinning.
The example MP3 player will 1) play a file from the local filesystem 2) Provide play, pause and stop buttons 3) will provide volume control.
Rather than create any GUI I will first create Interfaces. Interfaces are non-graphical sockets that communicate with a GUI. The play button is not a play button, but a socket that says, “If you say this to me I will play”. It also says, “If I play, I will let you know that I am playing”. So, the Interface sockets are published through a choice of frameworks. XML-RPC, SOAP, IPC, RMI, etc. Then a GUI is created. For a KDE version, I wrap some QT event junk around the client-side version of the Interface Socket. The state of the play button is communicated through non-GUI methods and then represented graphically.
The result? Only one applaction is needed on the backend and everyone can create there own GUI on the frontend.
This effort sounds like they are taking a very similar approach to the one used by TrollTech with Qt. I would be interesting in hearing from someone knowledgable about both APIs what the similarities, differences, advantages, and disadvantages between the two are.
If toolkits shared a theme it would make toolkit differences much less obvious. It would become like CSS stripping pointless difference from the browser market – where although there are changes between browsers it’s more bearable for the user.
RMS has been talking about a unified theme kit for Linux (QT/GTK) and a default theme between them. I think it’s an excellent idea.
>The solution that I am creating defines a GUI description >framework. I will use the example of an MP3 player. >Typically a MP3 play is skinned to acheive a custom GUI. >This skinning maybe just bitmapping images. It may >require a custom, but application specific API. My >solution will use Interfacing rather than Skinning.
Although this make work for an application with trivial user interface requirements like a mp3 player it will all to often fail on more complex applications. What you should bear in mind when designing a good UI is the workflow of the user and that is different on different OS’s and above all different for different users. Complex applications rely on the design of the user interface for application operations and unfortunately in many cases application architecture. The approach of adding a extra level of indirection between application logic and user interface will only provide small benefit.
Check FOX screenshots!
FOX Open File panel is fully inspired on Windows’s one.
Which is really stupid.
Oh well.
At last they made it to the 1st release. How about the FOX desktop that look stagnent for quite a long time.
Can’t anybody in Linux/GNU world invent some GUI that really different from Window$ such as Linux or X itself? If Linux/GNU can do what M$ can’t why their GUI can’t do what Window$ (or OS X) can.
(As I other posting I myself are trying harder to know XFree86 very much. Currently I manage to get around 33MB for the GUI that I’m using to post this complete with fonts. The X server only around 350K but this is not the way I want since what I’m doing is like cheating to me but it does work faster than the standard distribution from RH or Mandrake on my office PIII 800MHz although this box is just AMD K6 400MHz)
I’ve been using Fox for a couple of months on Suse Linux 7.2 and I must say I’m very happy. I’ve used Qt, GTKmm and several other toolkits and this is the easiest C++ toolkit to use. Fox uses standard C++ no moc(meta object compiler)
required. Also it is built directly on Xlib and you can call Xlib functions if need be. I use it with Kdevelop and have had no problems. I would like to thank the developer of Fox for making what I believe is the best C++ toolkit around.
Richard
I develop cross-platform applications for Win32 and Linux… without a tool like FOX or Qt, the job of a programmer is increased 10 fold. Fox is a very clean design, and while there are a few things that annoy me about it, it is overall very good. I write my code in Linux first, and EVERY piece of the GUI works after compiling in win32, without a single change! If I were to do it the traditional way, I’d have to use MFC and Motif for each respective OS.. this is not only a bad way to accomplish a task, but extremely expensive (why create two when you can create 1)…
Also, if you’ve got such aproblem with what their dialog box’s look like you can take the code (which is FREE), change a widget to look like what you want it to look like, and you have your new pretty looking interface.
try doing cross-platform GUI development.. you will soon praise the likes of Qt and FOX (and FLTK, and wxWindows etc etc)…