Java > Scala -> new thread: GUI for D

[Nick Sabalausky]

"Marco Leise" <Marco.Leise at gmx.de> wrote in message 
news:op.v5vk4ov69y6py2 at marco-leise.homedns.org...
> Am 02.12.2011, 19:15 Uhr, schrieb Nick Sabalausky <a at a.a>:
>
>> "Adam Wilson" <flyboynw at gmail.com> wrote in message
>> news:op.v5vibnca707hn8 at invictus.skynet.com...
>>> On Fri, 02 Dec 2011 04:33:48 -0800, a <a at a.com> wrote:
>>>
>>>> QML looks like it is (currently ?) targeted at the kind of GUI
>>>> programming when you make your own custom widgets for everything. It
>>>> only provides the most basic components such as rectangles, text, and
>>>> images. There isn't, say, a button components - you have to make one
>>>> using a Rectangle and a MouseArea. One consequence of this is that
>>>> typical GUI programming is much slower. Another consequence is that you
>>>> can't build GUIs that look native on multiple platforms. QML is 
>>>> probably
>>>> great for some things, but it is not a replacement for GUI  toolkits
>>>> such as Qt.
>>>
>>> This is similar in concept to how XAML in WPF/Silverlight is used to
>>> construct screens, and it's not bad idea. And the fact that the UX can 
>>> be
>>> skinned to look nothing like the default OSUI is actually probably one 
>>> of
>>> the most useful things about WPF and Silverlight. Yes, it doesn't look
>>> true to the OS, but you'll find that in the UI Design world, that is of
>>> surprisingly little importance.
>>
>> That's without a doubt my #1 complaint about desktop apps over the last
>> decade: Narcissistic designers with nothing but contempt for a user's
>> control over their own system.
>>
>>> The most important thing to a UI designer  is that the UI looks and 
>>> works
>>> the same across *ALL* OS's.
>>
>> That's just terrible.
>>
>>> Facebook looks and works the  same regardless of whether I pull it up in
>>> Chrome or Firefox, Mac or Linux.
>>
>> The hell with mobile, eh? Making things look and act the same on 
>> everything
>> is *terrible* UI design. Making things look and act *appropriate* for the
>> given platform has alwas been and will always be the proper thing to do
>> regardless of what the majority of designers decide is the trend du jour
>> (ok, so that's redundant, so sue me ;) ).
>
> I disagree with you on Java, but I agree with you here. I really don't 
> want to use MacOS X and find that application X's UI looks like WindowsXP 
> or vice versa. I hope QML will continue to try to support native looks, if 
> it becomes standard with Qt applications.
> If someone writes a new custom control, that needs a new look of course 
> that didn't exist on any OS before, ok.

Right. I agree. If you really do need a control that doesn't already exist 
in a standard form, then you gotta do what  you gotta do.

> But file open dialogs, buttons,  toolbars etc should really not try to 
> jump out of the pattern unless the  application itself is entirely 
> skinned, like WinAmp.

Actually, I absolutely hate WinAmp (and all programs that are entirely 
skinned). And WinAmp in particular is super butt-ugly. *And* the UI overall, 
esp. the library, is screwy (read: buggy and poorly architected) as all 
hell. iTunes is irritatinnly all-skinned, too (on Windows, anyway), but at 
least it actually looks half-way decent as far as skinned apps go (and it's 
not so buggy). The only benefits WinAmp has over iTunes is that it's not so 
absurdly bloated, doesn't infect you with useless always-resident processes, 
and it actually handles Ogg Vorbis worth a damn.

Unfortunately, I've been using WinAmp as my primary player despite my hatred 
for it because the iTunes lack of Ogg Vorbis support is a deal-breaker for 
me, and I still haven't found any other music manager that's any better. 
Foobar 2000 came pretty damn close, but as I recall, it had some sort of 
deal-breaker limitations (don't remember what), and the fact that it's a 
freeware program that's *not* open-source makes me very uneasy about relying 
on it.

> The closer you get to  entertainment, the more fancy the UI becomes I 
> think :D

It makes sense in a videogame or a TV-connected media center PC. But those 
are exceptions for valid reasons: They themselves essentially *are* separate 
environments. Seeing system dialogs in a videogame is just too jarring, in 
both aesthetics and interface, especially since such system UI's aren't 
designed for games[1]. And connecting a PC to a TV for media purposes 
effectively amounts to a different platform that has fundamentally different 
UI requirements.

[1] The Wii/PS3's system UIs (and XBox1 Live, IIRC), by contrast, actually 
work out very well since they're designed specifically for set-top 
videogaming (Probably 360's too, but I'm less familiar with that, especially 
the newer 360 UI). 'Course in the Wii's case, I suspect it's more a std lib 
they make the game developers use rather than a true system UI like the 
PS3/360 seem to be, but the effect is much the same...