Hi Kevin, > The main reason I'm so keen on wxWindows is that other toolkits > commonly have the problem that they were *written* specifically for > one platform, then ported to another. (Often using 'themes' to mimic > look - ugh.) Portability wasn't necessarily an initial goal, but > people started saying "Oh, can I run this on platform Y too?". Thus > even though they run on other platforms, there are a lot of internal > assumptions in the code which make it not really portable. *nix apps > tend to follow Windows conventions to some extent so the change isn't > so dramatic, but when porting a *nix toolkit to Mac or vice versa, it > is bound to at least feel strange on the other platform. wxWindows is > by far the closest thing I know of to something that "does the right > thing". well, I must admit I haven't tried to use it yet, but the terminology and documentation I browsed so far feels rather Windows-ish. For example, "window" is encompassing controls and views as well as "real" windows (which are called "frames" in wxWindows). Other examples are SDI/MDI, per-window (pardon, per-frame) menus, right moues button, key names etc. That gives me (still) the impression of a "ported" toolkit and lets me wonder whether it would be possible to develop wxWindows apps using the Mac as main development platform. Thus I believe one would often have to think "backwards" to realize a particular feature - translating from Mac into (wx)Windows concepts and terminology, and hoping that wxWindows will translate this into the desired Mac look & behaviour. ciao Martina
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4