<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 31.03.2017 um 09:23 schrieb Jānis Džeriņš <<a href="mailto:lisp@jonis.lv" class="">lisp@jonis.lv</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="">Paul Krueger <<a href="mailto:plkrueger@comcast.net" class="">plkrueger@comcast.net</a>> writes:<br class=""><br class=""><blockquote type="cite" class="">The problem with any platform-agnostic GUI development API (CLIM,<br class="">TCL/TK, X11, Qt, etc.) is that they almost never support the latest<br class="">and greatest features of the major platforms. What you develop using<br class="">them just never looks or feels quite right to a native user.<br class=""></blockquote><br class="">The concept "native user" is not very important nowadays. And with the<br class="">onslaught of WebKit based UIs its importance is diminishing.<br class=""></div></div></blockquote><div><br class=""></div><div>I don't think it 'not very important'. It's just very fragmented. If you look at iOS or Mac apps, the native best looking apps are definitely more attractive (not just looks). </div><div><br class=""></div><div>I also don't think that many of the web-technology based UIs are very useful on the Desktop.</div><div>For example, an Application UI like Lighttable was shiny, but shallow.</div><div><br class=""></div><div>The big Java IDEs (IntelliJ, Eclipse, Netbeans) have cross platform interfaces. There is still some alien and clunky feel to them, no matter how much polishing they got.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class="">People want to use applications. Getting used to an unusual but<br class="">empowering interface is no big deal. Take Emacs (or Vi/Vim for that<br class="">matter) as an example.<br class=""></div></div></blockquote><div><br class=""></div><div>Emacs/vim is cited as a big hurdle by many. As much as I like SLIME/ GNU Emacs and even can use it without problems, the UI of GNU Emacs is horrible - in many ways. Don't get me started. ;-)</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">And since those platforms are constantly moving targets, keeping up<br class="">with the changes is a herculean task that nobody will maintain for<br class="">very long. You’d need a large, committed support community to have a<br class="">chance and to the best of my knowledge that just hasn't ever developed<br class="">in the any community, much less in the CL community.<br class=""></blockquote><br class="">Yes, vendors want their vendor lock-in. Us developers want to stay away<br class="">from it. We're not the only ones struggling with this. Here is a link<br class="">to an article on this same topic:<br class=""><br class=""> <a href="http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/" class="">http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/</a><br class=""></div></div></blockquote><div><br class=""></div><div>Thanks. Have to read that...</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">You might notice the interfaces of the mentioned applications do not<br class="">exactly look "native".<br class=""><br class="">Another high-profile professional application I know of that is<br class="">cross-platform is Ableton Live. And it uses QT (as far as I know), but<br class="">instead of trying the interface to feel "native" it tries to make it<br class="">feel "empowering".<br class=""></div></div></blockquote><div><br class=""></div><div>I think they don't use QT for Ableton live. QT is used for Ableton Push, though. But that's a different type of product.</div><div><br class=""></div><div>Applications like Ableton need very special/customized user interfaces.</div><div>No GUI toolkit will provide that out-of-the-box. Some will make it even impossible to implement that.</div><div>Apple has their own offering (Logic), which is quite a bit more native, though Apple has/had their own 'pro' look&feel for applications.</div><div>They ditched the Windows version years ago of Logic when they bought the company (emagic).</div><div><br class=""></div><div>Generally it makes sense to think about what kind of GUI applications to build.</div><div>The toolkit/framework and the leading application(s) usually will be developed in sync.</div><div><br class=""></div><div>Apple could not develop and move forward with Cocoa/InterfaceBuilder if they didn't have applications to develop, too.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">The bottom line I guess is that we should take the good parts of CLIM,<br class="">forget about the "native" gadgets, and use low-level drawing APIs<br class="">(e.g., OpenGL, Vulcan, Metal) to enable programmers to create GUIs that<br class="">make sense for the problem at hand.<br class=""><br class="">My 2 cents,<br class="">-- <br class="">Jānis Džeriņš<br class="">_______________________________________________<br class="">Openmcl-devel mailing list<br class=""><a href="mailto:Openmcl-devel@clozure.com" class="">Openmcl-devel@clozure.com</a><br class="">https://lists.clozure.com/mailman/listinfo/openmcl-devel<br class=""></div></div></blockquote></div><br class=""></body></html>