> Hi Eric: > > My opinion is your point about size is weak because IUP normally depends on > a big suite of graphical libraries in the GTK+ case or a big set of > system libraries such as GDI/GDI+/Uniscribe or Direct2D/DirectWrite in > the Windows case. >
On systems the provide first class native GUIs, I would disagree with this point because the system libraries are typically already loaded by everything. Furthermore, even non-native frameworks like Qt need to link into the native frameworks even though they may not be using much from it. So you take a double hit because you get both the system frameworks and the non-native implementation. This is very apparent on Mac, where everything links to Foundation and AppKit as a baseline. I do cede that GTK is not small. However, almost all the distros I see today ship at least GTK2, with a lot of forks UI forks in protest of GTK3 and Gnome, and intentionally kept GTK2 alive because it was much smaller than GTK3. So there is probably something already on your system using it. But if you really need something smaller, Motif is always an option. (Also, somebody is experimenting with my Cocoa backend and has a prototype working in GNUStep on Linux though I wouldn't necessarily consider that small either and few systems install it.) > <off topic> > Thanks to your post the possibility now exists that I or one of my > PLplot colleagues will develop an IUP-based device driver in the > intermediate future. So if that occurs I would plan to download and > build IUP for myself on Linux. And that would put me in a position to > do the above simple test myself. But that is in the speculative > future and only for the GTK+ backend case. So your test results now > on this unicode and CTL question for as many of the IUP backends as > possible would be much appreciated. > </off topic> I'll be honest, string encodings are not my strong suit. What I can say is that IUP is developed in Brazil where they speak Portuguese. So I know being able to at least support their language is important to them, so I hope that means they got a lot of the string encoding stuff right. For the Cocoa implementation, IUP has a mode called UTF8 mode and I am basically enforcing that it is on for Mac. For every C string I have to bridge, I hand it to the native Cocoa UTF8 APIs that convert back and forth between C strings and NSStrings (native Cocoa string type). I did have some fellow Cocoa devs review my code and run a few tests, and they believed it was correct. Though it was not exhaustive. If the implementation is wrong, I would like to correct it. -Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
