[Openmcl-devel] prompt-for-file (embarrassing question)

[Rainer Joswig]

> Am 31.03.2017 um 09:23 schrieb Jānis Džeriņš <lisp at jonis.lv>:
> 
> Paul Krueger <plkrueger at comcast.net> writes:
> 
>> The problem with any platform-agnostic GUI development API (CLIM,
>> TCL/TK, X11, Qt, etc.) is that they almost never support the latest
>> and greatest features of the major platforms. What you develop using
>> them just never looks or feels quite right to a native user.
> 
> The concept "native user" is not very important nowadays.  And with the
> onslaught of WebKit based UIs its importance is diminishing.

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). 

I also don't think that many of the web-technology based UIs are very useful on the Desktop.
For example, an Application UI like Lighttable was shiny, but shallow.

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.

> 
> People want to use applications.  Getting used to an unusual but
> empowering interface is no big deal.  Take Emacs (or Vi/Vim for that
> matter) as an example.

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. ;-)

> 
>> And since those platforms are constantly moving targets, keeping up
>> with the changes is a herculean task that nobody will maintain for
>> very long. You’d need a large, committed support community to have a
>> chance and to the best of my knowledge that just hasn't ever developed
>> in the any community, much less in the CL community.
> 
> Yes, vendors want their vendor lock-in.  Us developers want to stay away
> from it.  We're not the only ones struggling with this.  Here is a link
> to an article on this same topic:
> 
>  http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/ <http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/>

Thanks. Have to read that...

> 
> You might notice the interfaces of the mentioned applications do not
> exactly look "native".
> 
> Another high-profile professional application I know of that is
> cross-platform is Ableton Live.  And it uses QT (as far as I know), but
> instead of trying the interface to feel "native" it tries to make it
> feel "empowering".

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.

Applications like Ableton need very special/customized user interfaces.
No GUI toolkit will provide that out-of-the-box. Some will make it even impossible to implement that.
Apple has their own offering (Logic), which is quite a bit more native, though Apple has/had their own 'pro' look&feel for applications.
They ditched the Windows version years ago of Logic when they bought the company (emagic).

Generally it makes sense to think about what kind of GUI applications to build.
The toolkit/framework and the leading application(s) usually will be developed in sync.

Apple could not develop and move forward with Cocoa/InterfaceBuilder if they didn't have applications to develop, too.

> The bottom line I guess is that we should take the good parts of CLIM,
> forget about the "native" gadgets, and use low-level drawing APIs
> (e.g., OpenGL, Vulcan, Metal) to enable programmers to create GUIs that
> make sense for the problem at hand.
> 
> My 2 cents,
> -- 
> Jānis Džeriņš
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20170331/86a21bbe/attachment.htm>