Linked by Eugenia Loli-Queru on Fri 13th Jul 2007 06:18 UTC, submitted by Sander Jansen
General Development Jeroen van der Zijp, the author of Fox Toolkit, has kindly given kerkythea.net an interview. The Fox Toolkit is a platform independent GUI that has matured over the last years to become one of the fastest and well structured APIs.
Thread beginning with comment 255201
To read all comments associated with this story, please click here.
I think you're right
by stodge on Fri 13th Jul 2007 11:53 UTC
stodge
Member since:
2005-09-08

rx182: I think you're right. I think Fox looks ugly, but I guess in some cases native look and feel isn't necessary.

RE: I think you're right
by rx182 on Fri 13th Jul 2007 12:53 in reply to "I think you're right"
rx182 Member since:
2005-07-08

I think inconsistent (with the rest of the OS) would be a better world ;) But not only that. Non-native widgets are always much slower than native ones.

Anyway, while I prefer other toolkits over FOX, I admire the amount of work the author has done. Keep it going!

Reply Parent Bookmark Score: 1

RE[2]: I think you're right
by navaraf on Fri 13th Jul 2007 13:10 in reply to "RE: I think you're right"
navaraf Member since:
2005-07-08

By looking at the sreenshots, it looks like the widgets are drawn by the toolkit. It doesn't seem to use native widgets (at least under Windows). Am I right? Am I wrong?


You are right. I looked at the source code and verified it.

Non-native widgets are always much slower than native ones.


And you got this info where? This is completely untrue. Under Windows the "native controls" are implemented in user mode (well, except some hacks, but they're not for improving performance) using the very same API that the makers of non-native controls use. Even though I have little experience with other operating systems I know that the common toolkits on Linux all use X11 APIs under the hood and so can do another toolkit. So why exactly would the non-native controls be slower when they can use the same underlying API?! (Of course, they might be poorly implemented, but you said "always".)

To me the disadvantage of non-native controls is that they usually don't fit with the rest of the environment. No matter how much you try to imitate the look and feel of the platform you're doomed to fail, because new version of the platform can be advanced somehow (themes, spell checking, IME or other such feature) and your custom controls won't reflect that.

Edited 2007-07-13 13:13

Reply Parent Bookmark Score: 5

RE[2]: I think you're right
by fretinator on Fri 13th Jul 2007 14:07 in reply to "RE: I think you're right"
fretinator Member since:
2005-07-06

Non-native widgets are always much slower than native ones.


I'd still rather have Swing that AWT!

Reply Parent Bookmark Score: 2

RE[2]: I think you're right
by Doc Pain on Fri 13th Jul 2007 14:42 in reply to "RE: I think you're right"
Doc Pain Member since:
2006-10-08

"I think inconsistent (with the rest of the OS) would be a better world ;) "

Don't confuse OS and GUI. :-)

Famous quotation: "I don't like the Linux file systems - the pictures are too big!" (The term "pictures" refers to icons.)

Inconsistency usually does not matter to the end user. While you may judge from an aesthetic point of view, look & feel usually is very user dependant. Look at Mac OS X, at all these "Windows", at the various Linux and UNIX GUIs and desktops. Users keep using them, even if some applications use others than the "standard" toolkits or violate the "standard" way of doing things withing a particular system.

"Anyway, while I prefer other toolkits over FOX, I admire the amount of work the author has done. Keep it going!"

Personally, I find FOX with its bindings interesting, but actually won't use it because I prefer Gtk + C, or GNUstep + ObjC. Surely, FOX may be a good solution for ressource limited systems. Especially the cross-platform sector is interesting if you don't want to use Java and do only consider UNIX/Linux and "Windows" (allthough Mac OS X variants are possible, too).

Reply Parent Bookmark Score: 3