www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Java > Scala -> new thread: GUI for D

reply Joshua Niehus <jm.niehus gmail.com> writes:
--000e0ce0f7023b1ebe04b315a9f4
Content-Type: text/plain; charset=ISO-8859-1

On 12/1/11 2:59 AM, Walter Bright wrote:
 On 12/1/2011 2:42 AM, Gour wrote:
 I'd like to help with GUI bindings if D community would come more close
 together here with some people ready to lead the herd...

Why not you lead the effort?

I just went to the Qt DevDays 2011 and it looks like a lot of work is being done to get QML ready for desktop applications. Its Qt's next gen UI framework and its JavaScript based (it looks pretty good). It might be worth while to investigate using QML as a UI "frontend" and use D code to do the "backend" heavy lifting as opposed to C++. I know there was a Qt port to D a while back, but it seems to have died out or was buggy. This might be much easier (im new to development so forgive my naivety :) --000e0ce0f7023b1ebe04b315a9f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-fami= ly: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 25= 5, 0.917969); ">&gt;On 12/1/11 2:59 AM, Walter Bright wrote:</span><br styl= e=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13p= x; background-color: rgba(255, 255, 255, 0.917969); "> <span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-fami= ly: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 25= 5, 0.917969); ">&gt;&gt; On 12/1/2011 2:42 AM, Gour wrote:</span><br style= =3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px= ; background-color: rgba(255, 255, 255, 0.917969); "> <span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-fami= ly: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 25= 5, 0.917969); ">&gt;&gt; I&#39;d like to help with=A0</span><span class=3D"= il" style=3D"background-image: initial; background-attachment: initial; bac= kground-origin: initial; background-clip: initial; background-color: rgba(2= 55, 255, 255, 0.917969); color: rgb(34, 34, 34); font-family: arial, sans-s= erif; font-size: 13px; ">GUI</span><span class=3D"Apple-style-span" style= =3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px= ; background-color: rgba(255, 255, 255, 0.917969); ">=A0bindings if D commu= nity would come more close</span><br style=3D"color: rgb(34, 34, 34); font-= family: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255= , 255, 0.917969); "> <span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-fami= ly: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 25= 5, 0.917969); ">&gt;&gt; together here with some people ready to=A0</span><= span class=3D"il" style=3D"background-image: initial; background-attachment= : initial; background-origin: initial; background-clip: initial; background= -color: rgba(255, 255, 255, 0.917969); color: rgb(34, 34, 34); font-family:= arial, sans-serif; font-size: 13px; ">lead</span><span class=3D"Apple-styl= e-span" style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; fo= nt-size: 13px; background-color: rgba(255, 255, 255, 0.917969); ">=A0the he= rd...</span><br style=3D"color: rgb(34, 34, 34); font-family: arial, sans-s= erif; font-size: 13px; background-color: rgba(255, 255, 255, 0.917969); "> <span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-fami= ly: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 25= 5, 0.917969); ">&gt;</span><br style=3D"color: rgb(34, 34, 34); font-family= : arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 255,= 0.917969); "> <span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-fami= ly: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 25= 5, 0.917969); ">&gt; Why not you=A0</span><span class=3D"il" style=3D"backg= round-image: initial; background-attachment: initial; background-origin: in= itial; background-clip: initial; background-color: rgba(255, 255, 255, 0.91= 7969); color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 1= 3px; ">lead</span><span class=3D"Apple-style-span" style=3D"color: rgb(34, = 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color:= rgba(255, 255, 255, 0.917969); ">=A0the effort?</span><font class=3D"Apple= -style-span" color=3D"#222222" face=3D"arial, sans-serif"><br> </font><div><span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34= ); font-family: arial, sans-serif; font-size: 13px; background-color: rgba(= 255, 255, 255, 0.917969); "><br></span></div><div><span class=3D"Apple-styl= e-span" style=3D"background-color: rgba(255, 255, 255, 0.917969); "><font c= lass=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans-serif">=A0 = =A0 I just went to the Qt DevDays 2011 and it looks like a lot of work is b= eing done to get QML ready for desktop applications. Its Qt&#39;s next gen = UI framework and its JavaScript based (it looks pretty good). =A0It might b= e worth while to investigate using QML as a UI &quot;frontend&quot; and use= D code to do the &quot;backend&quot; heavy lifting as opposed to C++.=A0</= font></span></div> <div><span class=3D"Apple-style-span" style=3D"background-color: rgba(255, = 255, 255, 0.917969); "><font class=3D"Apple-style-span" color=3D"#222222" f= ace=3D"arial, sans-serif">=A0 =A0 I know there was a Qt port to D a while b= ack, but it seems to have died out or was buggy. =A0This might be much easi= er (im new to development so forgive my naivety :)</font></span></div> --000e0ce0f7023b1ebe04b315a9f4--
Dec 01 2011
next sibling parent reply a <a a.com> writes:
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.
Dec 02 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam Wilson" <flyboynw gmail.com> wrote in message 
news:op.v5vibnca707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 04:33:48 -0800, a <a 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 ;) ).
Dec 02 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:op.v5vk4ov69y6py2 marco-leise.homedns.org...
 Am 02.12.2011, 19:15 Uhr, schrieb Nick Sabalausky <a a.a>:

 "Adam Wilson" <flyboynw gmail.com> wrote in message
 news:op.v5vibnca707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 04:33:48 -0800, a <a 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...
Dec 02 2011
next sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 12/2/11 12:54 PM, Nick Sabalausky wrote:
 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...

Did you ever try http://xiph.org/quicktime/? It solved the iTunes ogg problem for me.
Dec 02 2011
parent "Nick Sabalausky" <a a.a> writes:
"David Gileadi" <gileadis NSPMgmail.com> wrote in message 
news:jbbatc$1ksf$1 digitalmars.com...
 On 12/2/11 12:54 PM, Nick Sabalausky wrote:
 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...

Did you ever try http://xiph.org/quicktime/? It solved the iTunes ogg problem for me.

Yea, I had actually been using that for a long time because at least it adds *some* vorbis support to iTunes. Unfortunately, it only *barely* works. There's a ton of issues with it [1], apparently due mostly to problems in Quicktime and iTunes themselves (which will guaranteed never get fixed because Apple is perpetually uninterested in anything that isn't "glitz" or gimmick). Plus it seems to be abandoned (and with the Windows port still stuck a few versions behind). It was nice to have iTunes be able to at least *play* vorbis (although not very well [2]), and *kinda* have library support...sort of...ish..., but I got tired of it always being so screwy and limited. [1] http://xiph.org/quicktime/faq.html One additional thing that's not mentioned there is that it can't decode & burn vorbis files to audio CDs. [2] It would go mute whenever any other process got busy. Never happened with other formats, and never happens in WinAmp even with vorbis.
Dec 02 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-02 20:54, Nick Sabalausky wrote:
 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.

On Mac OS X iTunes looks mostly native. There are few widgets that doesn't have a native look, like the scroll bars and the column headers. But they look so good and fit in with the rest of the GUI, the iTunes look could just as well be the native look.
 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.

The problem with widgets in computer games is when they look like a specific widget but doesn't behave like one. For example, a scroll bar is a perfect example. On most platforms the native scroll bar has a bar, sitting on top of an other bar and two buttons with arrows. The behavior of the widget is: * You can drag the first bar to scroll * You can click on the second bar to scroll * You can click on the two buttons to scroll * You can use the mouse wheel to scroll There are very few games that have a scroll bar that have all the above listed behaviors
 [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...

-- /Jacob Carlborg
Dec 04 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:op.v5vk4ov69y6py2 marco-leise.homedns.org...
 I really don't  want to use MacOS X and find that application X's UI looks 
 like WindowsXP  or vice versa.

Interesting side-note regarding that: The dialog boxes in Chrome/Iron really do look *exactly* like Vista Starter Edition...when you run it on XP. Doh!
Dec 02 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam Wilson" <flyboynw gmail.com> wrote in message 
news:op.v5vpeyg4707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 10:15:12 -0800, Nick Sabalausky <a a.a> wrote:

 "Adam Wilson" <flyboynw gmail.com> wrote in message
 news:op.v5vibnca707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 04:33:48 -0800, a <a 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.

So the push for multi-platform UI consistency via the internet and HTML/CSS is wrong?

It's unrelated and irrelevent. HTML/CSS is for documents and presentation (though it could stand to be much better at presentation). Cramming apps into a web browser is moronic any way you look at it. Even if your goal actually is "Fuck your OS and your settings, I'm forcing *MY* design on you!" like most asshole designers these days, doing it via a web browser is *still* an unnecessary and grossly inferior way to go about it.
 The implementation might  be lacking, but I don't see any point in arguing 
 with the collective will  of billions of people.

The collective will of thousands of **designers**. The majority of sheeple just gobble up whetever's tossed onto their plate. Feed them "web apps" and tell them it's the great new thing, and they believe it. Feed them "mobile apps" and tell them it's the great new thing, and they believe it. Feed them "desktop apps" and tell them it's the great new thing, and they believe it. It doesn't make a damn bit of difference what it is. The billions of people HAVE NO COLLECTIVE WILL. The majority of the time, their only will is to swallow anything they're given, and right now, with the exception of mobile, what they're being fed just happens to be web apps, therefore they assume web apps are a great and wonderous thing (They're not. They're a perversion of technology). So a designer following the "collective will of billions of people" is nothing but an idiocy feedback loop with nobody at the helm. As designers, we have a resposibility to give people *quality*, not whatever randam garbage the trend-whore designers have decided to cram down all their loyal subject's throats.
 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.

Why? Isn't that pretty much the definition of the internet?

No, of course not.
 Mobile has form factor issues, namely that it's too small to display a 
 desktop style UI. But UI design isn't a technical thing, it's a 
 right-brain thing. As long as the interaction and display models are 
 similar (i.e. it works and looks similar) the physical layout changes that 
 the mobile form-factor demands won't seem nearly as jarring to the user, 
 because they already have a mental model for how to interact with the 
 interface for that piece of software.

Right, and that all boils down to: You make it right for the given platform instead of trying to force the same look & feel onto everything. Forcing the same look & feel on all platforms only works if all platforms are the same. And then anytime some platform is different, that thinking just leads people to bitch and moan about the device being "wrong" ("The screen's too small for my pristine one-size-fits-all design! It's the devices fault! Wah!").
 I have no problem defaulting to the OS default look, and in fact that 
 would be the default of any GUI project I'd be interested in undertaking. 
 But I don't want to be limited to just the OS look. Those types of 
 arbitrary limitations fly in the face of the D way, at least as I 
 understand it.

I agree the look of apps should be user-configurable, but that belongs at the OS/Window-Manager level. 'Course, I'll grant that's never going to happen on MS or Apple platforms, in which case, yea, using a lib that makes "system" the default and "user-configured" an option is the next best thing.
Dec 02 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-03 19:34, Marco Leise wrote:
 Am 03.12.2011, 19:20 Uhr, schrieb Nick Sabalausky <a a.a>:
 FWIW, SWT would probably be somewhere in the top 3, definitely above qt
 (because I *think* SWT is true native...?), but not sure how I'd rank it
 compared to wx b/c I'd have to actually try them both out.

As far as I understood it SWT was written for Eclipse. It may fall behind the other toolkits in terms of features and it is written in Java, so using it means a true D reimplementation of the API unless someone already did a C port. I think the small and native aspect made it a good candidate for inclusion into Phobos in the past. The much other toolkits are just too big. We may all have good eyes and such, but maybe the accessibility aspect should also be considered in this discussion.

DWT already exists and is a port of SWT to D. There's also a C++ port of SWT available, but only for Windows. I think SWT is at least as capable as wxWidgets. -- /Jacob Carlborg
Dec 04 2011
prev sibling parent Somedude <lovelydear mailmetrash.com> writes:
Le 03/12/2011 07:54, Gour a écrit :
 
 Just, curious what would be your choise for multi-platform GU app: gtk,
 qt or wx?
 
 
 Sincerely,
 Gour
 

1) By far wxWidgets because it's native and stable 2) FLTK because it's small, fast and supports OpenGL, allowing for custom interfaces. It's also probably the easiest to port/bind with. On the downsides, its look'n feel is quite ugly, and its development is slow. 3) Qt because it's very complete and looks ok, but it's (too) big and probably complex to port/bind with
Dec 05 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-02 19:15, Nick Sabalausky wrote:
 "Adam Wilson"<flyboynw gmail.com>  wrote in message
 news:op.v5vibnca707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 04:33:48 -0800, a<a 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 agree. I hate that applications invent their own GUI widgets when there already exist perfectly usable widgets. These new widgets never work or look as good as the native ones. -- /Jacob Carlborg
Dec 04 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jbfnbk$rkc$4 digitalmars.com...
 On 2011-12-02 19:15, Nick Sabalausky wrote:
 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 agree. I hate that applications invent their own GUI widgets when there already exist perfectly usable widgets. These new widgets never work or look as good as the native ones.

Yea. And even if they do actually mange to look nice (ex: Adobe's CS5 installers, and CS3/4, IIRC...at least on Windows anyway) they just don't *fit*. They stand out too much. Plus they carry an arrogant implication of "Fuck your settings. We think ours are better, so we're taking away your control over your computer."
Dec 04 2011
prev sibling parent Alexey Prokhin <alexey.prokhin yandex.ru> writes:
a 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.

http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/ . Right now it is a research project, but it most likely will be a part of the upcoming Qt5.
Dec 02 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Joshua Niehus" <jm.niehus gmail.com> wrote in message 
news:mailman.1243.1322814889.24802.digitalmars-d puremagic.com...
On 12/1/11 2:59 AM, Walter Bright wrote:
 On 12/1/2011 2:42 AM, Gour wrote:
 I'd like to help with GUI bindings if D community would come more close
 together here with some people ready to lead the herd...

Why not you lead the effort?

I just went to the Qt DevDays 2011 and it looks like a lot of work is being done to get QML ready for desktop applications. Its Qt's next gen UI framework and its JavaScript based (it looks pretty good).

Ewww, why are so many organiations trying to put JS on the desktop? There's that, Win8, Flex, etc. It's such an abomination. Completely backwards. What's needed is for proper desktop technologies to take over the web, not the other way around. I can't beleve the spawn of what had long been dubbed "Nutscrape" has become, and is still becoming, so prolific.
 It might be
 worth while to investigate using QML as a UI "frontend" and use D code to
 do the "backend" heavy lifting as opposed to C++.
    I know there was a Qt port to D a while back, but it seems to have died
 out or was buggy.  This might be much easier (im new to development so
 forgive my naivety :)
 

Dec 02 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-02 17:38, Nick Sabalausky wrote:
 "Joshua Niehus"<jm.niehus gmail.com>  wrote in message
 news:mailman.1243.1322814889.24802.digitalmars-d puremagic.com...
 On 12/1/11 2:59 AM, Walter Bright wrote:
 On 12/1/2011 2:42 AM, Gour wrote:
 I'd like to help with GUI bindings if D community would come more close
 together here with some people ready to lead the herd...

Why not you lead the effort?

I just went to the Qt DevDays 2011 and it looks like a lot of work is being done to get QML ready for desktop applications. Its Qt's next gen UI framework and its JavaScript based (it looks pretty good).

Ewww, why are so many organiations trying to put JS on the desktop? There's that, Win8, Flex, etc. It's such an abomination. Completely backwards. What's needed is for proper desktop technologies to take over the web, not the other way around. I can't beleve the spawn of what had long been dubbed "Nutscrape" has become, and is still becoming, so prolific.

I completely agree, JavaScript is quite a horrible language. -- /Jacob Carlborg
Dec 04 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jbfmq4$rkc$2 digitalmars.com...
 On 2011-12-02 17:38, Nick Sabalausky wrote:
 "Joshua Niehus"<jm.niehus gmail.com>  wrote in message
 news:mailman.1243.1322814889.24802.digitalmars-d puremagic.com...
 On 12/1/11 2:59 AM, Walter Bright wrote:
 On 12/1/2011 2:42 AM, Gour wrote:
 I'd like to help with GUI bindings if D community would come more 
 close
 together here with some people ready to lead the herd...

Why not you lead the effort?

I just went to the Qt DevDays 2011 and it looks like a lot of work is being done to get QML ready for desktop applications. Its Qt's next gen UI framework and its JavaScript based (it looks pretty good).

Ewww, why are so many organiations trying to put JS on the desktop? There's that, Win8, Flex, etc. It's such an abomination. Completely backwards. What's needed is for proper desktop technologies to take over the web, not the other way around. I can't beleve the spawn of what had long been dubbed "Nutscrape" has become, and is still becoming, so prolific.

I completely agree, JavaScript is quite a horrible language.

Yea. I do appreciate how it's able to do so much with such simplicity (if you ignore the bizarre semicolon rules), but only in the same sense that I appreciate Brainfuck for the same reason.
Dec 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-04 18:11, Nick Sabalausky wrote:
 Yea. I do appreciate how it's able to do so much with such simplicity (if
 you ignore the bizarre semicolon rules), but only in the same sense that I
 appreciate Brainfuck for the same reason.

I hide JavaScript behind CoffeeScript, makes it a bit more usable. http://jashkenas.github.com/coffee-script/ -- /Jacob Carlborg
Dec 04 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jbgj74$2jff$3 digitalmars.com...
 On 2011-12-04 18:11, Nick Sabalausky wrote:
 Yea. I do appreciate how it's able to do so much with such simplicity (if
 you ignore the bizarre semicolon rules), but only in the same sense that 
 I
 appreciate Brainfuck for the same reason.

I hide JavaScript behind CoffeeScript, makes it a bit more usable. http://jashkenas.github.com/coffee-script/

I've looked at CoffeeScript, but the implicit declarations and indent-syntax are deal-breakers for me. Besides, for the most part, the syntax isn't one of my bigger issues with JS. It's more the semantics, type system, implementation issues, and DHTML abuse.
Dec 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-04 21:13, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:jbgj74$2jff$3 digitalmars.com...
 On 2011-12-04 18:11, Nick Sabalausky wrote:
 Yea. I do appreciate how it's able to do so much with such simplicity (if
 you ignore the bizarre semicolon rules), but only in the same sense that
 I
 appreciate Brainfuck for the same reason.

I hide JavaScript behind CoffeeScript, makes it a bit more usable. http://jashkenas.github.com/coffee-script/

I've looked at CoffeeScript, but the implicit declarations and indent-syntax are deal-breakers for me. Besides, for the most part, the syntax isn't one of my bigger issues with JS. It's more the semantics, type system, implementation issues, and DHTML abuse.

I really like the syntax, specially since Ruby is my favorite language next to D, they both have a similar syntax (CS and Ruby). I really like that it adds a class based object model, the prototype based object model is just weird. Now all JS libraries have their own way of declaring classes, it seems like everyone actually wants a class based object model. But the problem remains, CoffeeScript compiles to JavaScript so you are still limited by JS. -- /Jacob Carlborg
Dec 04 2011
parent reply Somedude <lovelydear mailmetrash.com> writes:
Le 04/12/2011 21:24, Jacob Carlborg a écrit :
 
 But the problem remains, CoffeeScript compiles to JavaScript so you are
 still limited by JS.
 

I find it pretty powerful for such a small language. And I do think it makes sens to base a GUI on a scripting language. As for the choice of Javascript with Qt, the choice is obvious: the goal is to be able to write once and run anywhere (i.e on desktop, on mobile devices AND on the web).
Dec 04 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-05 08:13, Somedude wrote:
 Le 04/12/2011 21:24, Jacob Carlborg a écrit :
 But the problem remains, CoffeeScript compiles to JavaScript so you are
 still limited by JS.

I find it pretty powerful for such a small language. And I do think it makes sens to base a GUI on a scripting language. As for the choice of Javascript with Qt, the choice is obvious: the goal is to be able to write once and run anywhere (i.e on desktop, on mobile devices AND on the web).

I have no experience with Lua. -- /Jacob Carlborg
Dec 04 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Somedude" <lovelydear mailmetrash.com> wrote in message 
news:jbhquu$1mj2$1 digitalmars.com...
 Le 04/12/2011 21:24, Jacob Carlborg a écrit :
 But the problem remains, CoffeeScript compiles to JavaScript so you are
 still limited by JS.

I find it pretty powerful for such a small language. And I do think it makes sens to base a GUI on a scripting language.

I'm with John Carmack on this one (not that I always agree with him): Using scripting for parts of your program just encourages the team to have non-programmers writing production code, and that's never a good thing (hell, there's a lot of *actual* programmers who don't even know what they're doing). And if the only people writing code are real programmers, they may as well just use a real langauge.
 As for the choice of
 Javascript with Qt, the choice is obvious: the goal is to be able to
 write once and run anywhere (i.e on desktop, on mobile devices AND on
 the web).

That's a poor reason to aid in the proliferation of such a terrible language. It's also a poor reason to write one's own software in such a bad langauge. What's needed is for JS on the web to be replaced with a real langauge, or at least a sensible one (or better yet, for this "web as an applications platform" idiocy to finally end, but that's a separate matter). I don't see the goal as being "write once and run anywhere" anyway. The goal is to write software that doesn't suck. Granted, "write once and run anywhere" is a worthwhile goal, but it's only secondary. It's a total wash if the methods used to achieve it result in either development problems or just simply the software sucking, both of which are likely to happen when adopting JS as a production language.
Dec 05 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-05 18:05, Nick Sabalausky wrote:
 "Somedude"<lovelydear mailmetrash.com>  wrote in message
 news:jbhquu$1mj2$1 digitalmars.com...
 Le 04/12/2011 21:24, Jacob Carlborg a écrit :
 But the problem remains, CoffeeScript compiles to JavaScript so you are
 still limited by JS.

I find it pretty powerful for such a small language. And I do think it makes sens to base a GUI on a scripting language.

I'm with John Carmack on this one (not that I always agree with him): Using scripting for parts of your program just encourages the team to have non-programmers writing production code, and that's never a good thing (hell, there's a lot of *actual* programmers who don't even know what they're doing). And if the only people writing code are real programmers, they may as well just use a real langauge.
 As for the choice of
 Javascript with Qt, the choice is obvious: the goal is to be able to
 write once and run anywhere (i.e on desktop, on mobile devices AND on
 the web).

That's a poor reason to aid in the proliferation of such a terrible language. It's also a poor reason to write one's own software in such a bad langauge. What's needed is for JS on the web to be replaced with a real langauge, or at least a sensible one (or better yet, for this "web as an applications platform" idiocy to finally end, but that's a separate matter).

Do you have any opinion about Dart from Google? -- /Jacob Carlborg
Dec 05 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jbj0lo$mec$1 digitalmars.com...
 On 2011-12-05 18:05, Nick Sabalausky wrote:
 "Somedude"<lovelydear mailmetrash.com>  wrote in message
 news:jbhquu$1mj2$1 digitalmars.com...
 Le 04/12/2011 21:24, Jacob Carlborg a écrit :
 But the problem remains, CoffeeScript compiles to JavaScript so you are
 still limited by JS.

I find it pretty powerful for such a small language. And I do think it makes sens to base a GUI on a scripting language.

I'm with John Carmack on this one (not that I always agree with him): Using scripting for parts of your program just encourages the team to have non-programmers writing production code, and that's never a good thing (hell, there's a lot of *actual* programmers who don't even know what they're doing). And if the only people writing code are real programmers, they may as well just use a real langauge.
 As for the choice of
 Javascript with Qt, the choice is obvious: the goal is to be able to
 write once and run anywhere (i.e on desktop, on mobile devices AND on
 the web).

That's a poor reason to aid in the proliferation of such a terrible language. It's also a poor reason to write one's own software in such a bad langauge. What's needed is for JS on the web to be replaced with a real langauge, or at least a sensible one (or better yet, for this "web as an applications platform" idiocy to finally end, but that's a separate matter).

Do you have any opinion about Dart from Google?

No, since this is the first I've heard about it ;) I'll take a look.
Dec 05 2011
prev sibling parent Adam Ruppe <destructionator gmail.com> writes:
Jacob Carlborg Wrote:
 Do you have any opinion about Dart from Google?

Google's MO is generally to take something bad... and make it /worse/. It compiles to Javascript, but script that doesn't actually work everywhere...
Dec 05 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jacob Carlborg Wrote:
 I hide JavaScript behind CoffeeScript, makes it a bit more usable.

If you like the idea there, but want something a lot more conservative, in my html.d (in here: https://github.com/adamdruppe/misc-stuff-including-D-programmin -language-web-stuff ) there's now a JavascriptMacroExpander class which pre-processes javascript. The only build in function it provides right now is foreach() (just because I find it's lack to be the easiest thing to take care of...) but the macro system might be useful too for certain things. Again, it's just a preprocessor, so you drop stuff like this into the middle of regular js code: ¤foreach(element; document.querySelectorAll("p")) { element.style.color = "red"; } converts to var arsd_foreach_loop_temporary_2 = document.querySelectorAll("p"); for(var arsd_foreach_loop_counter_1 = 0; arsd_foreach_loop_counter_1 < arsd_foreach_loop_temporary_2.length; arsd_foreach_loop_counter_1++) { var element = arsd_foreach_loop_temporary_2[arsd_foreach_loop_counter_1]; element.style.color = "red"; } which I realize is an ugly mess but just because I used long names for the temporaries. It: a) puts the iterable in it's own var, b) does a for loop over it, c) sets up a local for the iterated thing inside the loop and d) pastes your code in there. (that symbol before foreach is the one I did to denote a macro. I put it on a hotkey in my editor... but I wanted something that I'd never use in normal code, to keep the preprocessor both dead simple and out of the way.) You can also define your own macros and variables in the JS code or as delegates in D. I actually wrote this macro system for css, but it works pretty well here too. (html.d also includes a CssMacroExpander, which runs this and a de-nesting function.) This is pretty new stuff, so I'll probably be adding more functions as I use it more.
Dec 04 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-04 21:17, Adam D. Ruppe wrote:
 Jacob Carlborg Wrote:
 I hide JavaScript behind CoffeeScript, makes it a bit more usable.

If you like the idea there, but want something a lot more conservative, in my html.d (in here: https://github.com/adamdruppe/misc-stuff-including-D-programmin -language-web-stuff ) there's now a JavascriptMacroExpander class which pre-processes javascript. The only build in function it provides right now is foreach() (just because I find it's lack to be the easiest thing to take care of...) but the macro system might be useful too for certain things. Again, it's just a preprocessor, so you drop stuff like this into the middle of regular js code: ¤foreach(element; document.querySelectorAll("p")) { element.style.color = "red"; } converts to var arsd_foreach_loop_temporary_2 = document.querySelectorAll("p"); for(var arsd_foreach_loop_counter_1 = 0; arsd_foreach_loop_counter_1< arsd_foreach_loop_temporary_2.length; arsd_foreach_loop_counter_1++) { var element = arsd_foreach_loop_temporary_2[arsd_foreach_loop_counter_1]; element.style.color = "red"; } which I realize is an ugly mess but just because I used long names for the temporaries. It: a) puts the iterable in it's own var, b) does a for loop over it, c) sets up a local for the iterated thing inside the loop and d) pastes your code in there. (that symbol before foreach is the one I did to denote a macro. I put it on a hotkey in my editor... but I wanted something that I'd never use in normal code, to keep the preprocessor both dead simple and out of the way.) You can also define your own macros and variables in the JS code or as delegates in D. I actually wrote this macro system for css, but it works pretty well here too. (html.d also includes a CssMacroExpander, which runs this and a de-nesting function.)

Maybe you should take a look at SASS, it has if-statements, for-loops, functions, mixins, variables and other useful features. Two syntaxes are available, one which is a superset of CSS (SCSS) and one which doesn't use semicolon and uses indentation for scopes (SASS). http://sass-lang.com/
 This is pretty new stuff, so I'll probably be adding more functions
 as I use it more.

I think CoffeeScript works really well, it's been around a while and it's the default way to handle JavaScript in Rails 3.1 and later versions (SASS is the default way of handling CSS). Rails is what I'm using for web development. -- /Jacob Carlborg
Dec 04 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jacob Carlborg Wrote:
 Maybe you should take a look at SASS, it has if-statements, for-loops, 

Yea, I've looked at it before (and like some of the ideas - their lighten, darken, etc. functions are nice and I intend to implement them myself as I find the time - see color.d in that github page.) But it went a little too far away from the css base for me, and I wanted something I could more easily customize and integrate with D anyway, so I did my own.
 Rails is what I'm using for web development.

Indeed. You've linked me to some stuff before, and I like some of it, so I'm stealing a few of their ideas :) That message was more aimed toward Nick or any other lurker who, like me, might find the Rails end to go a bit too far away from our comfort zone.
Dec 04 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-04 21:40, Adam D. Ruppe wrote:
 Jacob Carlborg Wrote:
 Maybe you should take a look at SASS, it has if-statements, for-loops,

Yea, I've looked at it before (and like some of the ideas - their lighten, darken, etc. functions are nice and I intend to implement them myself as I find the time - see color.d in that github page.) But it went a little too far away from the css base for me, and I wanted something I could more easily customize and integrate with D anyway, so I did my own.

If you use the SCSS syntax then you can basically choose what SASS specific features you want. For example, use regular CSS + variables. Or regular CSS + mixins. I mean, you're not forced to use any feature. But I can understand you want something integrated with D.
 Rails is what I'm using for web development.

Indeed. You've linked me to some stuff before, and I like some of it, so I'm stealing a few of their ideas :)

Yeah, I think it's a good framework and there's plenty of stuff to steal from it. I have looked at other frameworks, in other languages, PHP and Python for example. But these frameworks just look like bad implementations of Rails. They're not as good as Rails, or have syntax that look as good as Rails', usually because the languages are lacking in some way (or several ways).
 That message was more aimed toward Nick or any other lurker who,
 like me, might find the Rails end to go a bit too far away from our comfort
 zone.

Hehe, I see. -- /Jacob Carlborg
Dec 04 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jbglgs$2no2$1 digitalmars.com...
 I think CoffeeScript works really well, it's been around a while and it's 
 the default way to handle JavaScript in Rails 3.1 and later versions (SASS 
 is the default way of handling CSS).

That seems slightly strange to me since Ruby is not an indent-syntax langauge. I would have expected something like Django to be more likely to standardize on on SASS/CoffeeScript.
Dec 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-05 07:59, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:jbglgs$2no2$1 digitalmars.com...
 I think CoffeeScript works really well, it's been around a while and it's
 the default way to handle JavaScript in Rails 3.1 and later versions (SASS
 is the default way of handling CSS).

That seems slightly strange to me since Ruby is not an indent-syntax langauge. I would have expected something like Django to be more likely to standardize on on SASS/CoffeeScript.

I think they're good languages, regardless of the indent-syntax or not. CoffeeScript and Ruby share a couple of language features that I'm not sure if Python does: * Instance variables start with (shortcut for "this." in CS) * Functions can be called without parentheses (they have to take at least one argument in CS) * Braces around hashes are optional * No need to declare variables * Existential operator * Trailing if-statements On the other hand, CoffeeScript and Python shares a couple of features as well: * Indentations are used for scopes * Array comprehension I'm not very familiar with Python. BTW, SASS comes with two syntaxes, SCSS and SASS. SCSS is a superset of CSS and uses braces for scope and semicolons, just as CSS. SASS uses indentation and no semicolons. SCSS is the default in Rails 3.1. -- /Jacob Carlborg
Dec 04 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 I think they're good languages, regardless of the indent-syntax or not. 
 CoffeeScript and Ruby share a couple of language features that I'm not 
 sure if Python does:
 
 * Instance variables start with   (shortcut for "this." in CS)
 
 * Functions can be called without parentheses (they have to take at 
 least one argument in CS)

In Python instance variables start with "self.". And function call requires a (). There is a way to define properties that don't need the () but they can't take arguments. Bye, bearophile
Dec 05 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-05 10:10, Marco Leise wrote:
 Am 04.12.2011, 21:17 Uhr, schrieb Adam D. Ruppe
 <destructionator gmail.com>:

 Jacob Carlborg Wrote:
 If you like the idea there, but want something a lot more conservative,
 in my html.d (in here:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
 )
 there's now a JavascriptMacroExpander class which pre-processes
 javascript.

 The only build in function it provides right now is foreach() (just
 because I find
 it's lack to be the easiest thing to take care of...) but the macro
 system might
 be useful too for certain things.

 Again, it's just a preprocessor, so you drop stuff like this into the
 middle of
 regular js code:

 ¤foreach(element; document.querySelectorAll("p")) {
 element.style.color = "red";
 }

 converts to

 var arsd_foreach_loop_temporary_2 = document.querySelectorAll("p");
 for(var arsd_foreach_loop_counter_1 = 0; arsd_foreach_loop_counter_1 <
 arsd_foreach_loop_temporary_2.length; arsd_foreach_loop_counter_1++) {
 var element = arsd_foreach_loop_temporary_2[arsd_foreach_loop_counter_1];
 element.style.color = "red";
 }

There is also this macro in the JavaScript plugin for Eclipse: for (var ${index} = 0; ${index} < ${array}.length; ${index}++) { var ${array_element} = ${array}[${index}]; ${cursor} } This is really one of the largest shortcomings of the language that can not be explained with a simple design choice.

CoffeeScript makes it a correct for-each loop: for e in arr # do something with the element "e" -- /Jacob Carlborg
Dec 05 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Jacob Carlborg Wrote:
 for e in arr
      # do something with the element "e"

Heh, I used to think that would work in regular Javascript, since it does have a for(blah in something) form... But in regular javascript, that only works on objects!
Dec 05 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-05 16:47, Adam Ruppe wrote:
 Jacob Carlborg Wrote:
 for e in arr
       # do something with the element "e"

Heh, I used to think that would work in regular Javascript, since it does have a for(blah in something) form... But in regular javascript, that only works on objects!

Yeah, it's very annoying. CoffeeScript also has the following iteration syntax: for key, value of obj # do something with key and value Which compiles to: for (k in obj) { v = obj[k]; } -- /Jacob Carlborg
Dec 05 2011
prev sibling parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
Am 04.12.2011 12:50, schrieb Jacob Carlborg:
 On 2011-12-02 17:38, Nick Sabalausky wrote:
 "Joshua Niehus"<jm.niehus gmail.com>  wrote in message
 news:mailman.1243.1322814889.24802.digitalmars-d puremagic.com...
 On 12/1/11 2:59 AM, Walter Bright wrote:
 On 12/1/2011 2:42 AM, Gour wrote:
 I'd like to help with GUI bindings if D community would come more
 close
 together here with some people ready to lead the herd...

Why not you lead the effort?

I just went to the Qt DevDays 2011 and it looks like a lot of work is being done to get QML ready for desktop applications. Its Qt's next gen UI framework and its JavaScript based (it looks pretty good).

Ewww, why are so many organiations trying to put JS on the desktop? There's that, Win8, Flex, etc. It's such an abomination. Completely backwards. What's needed is for proper desktop technologies to take over the web, not the other way around. I can't beleve the spawn of what had long been dubbed "Nutscrape" has become, and is still becoming, so prolific.

I completely agree, JavaScript is quite a horrible language.

Yes it is - but did you ever tried haXe ? IMO it is the best cross platform language around - you target JavaScript, Flash, PHP, NEKO, C++ and soon Java and C# with one language. Typesafe with type inference, compiled and code completion support from the compiler.
Dec 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-05 08:17, Adrian wrote:
 Yes it is - but did you ever tried haXe ? IMO it is the best cross
 platform language around - you target JavaScript, Flash, PHP, NEKO, C++
 and soon Java and C# with one language. Typesafe with type inference,
 compiled and code completion support from the compiler.

I have looked at haxe but to me it just basically looks like Java. I think CoffeeScript is better, has a less verbose syntax. Although static typing would be nice to have sometimes. -- /Jacob Carlborg
Dec 05 2011
parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
Am 05.12.2011 09:17, schrieb Jacob Carlborg:
 On 2011-12-05 08:17, Adrian wrote:
 Yes it is - but did you ever tried haXe ? IMO it is the best cross
 platform language around - you target JavaScript, Flash, PHP, NEKO, C++
 and soon Java and C# with one language. Typesafe with type inference,
 compiled and code completion support from the compiler.

I have looked at haxe but to me it just basically looks like Java. I think CoffeeScript is better, has a less verbose syntax. Although static typing would be nice to have sometimes.

I wouldn't compare it to Java and I wouldn't say its verbose either, its expressiveness is close to D . It is a full dynamic language with all the benefit and safety of static typing through type inference. You can use it object oriented or functional. It has a fantastic remoting framework with type checking at compile time! cross platform - no other language has this to offer. CoffeeScript is just a JavaScript alternative without a real benefit. HaXe is a complete framework.
Dec 05 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-05 10:24, Adrian wrote:
 Am 05.12.2011 09:17, schrieb Jacob Carlborg:
 On 2011-12-05 08:17, Adrian wrote:
 Yes it is - but did you ever tried haXe ? IMO it is the best cross
 platform language around - you target JavaScript, Flash, PHP, NEKO, C++
 and soon Java and C# with one language. Typesafe with type inference,
 compiled and code completion support from the compiler.

I have looked at haxe but to me it just basically looks like Java. I think CoffeeScript is better, has a less verbose syntax. Although static typing would be nice to have sometimes.

I wouldn't compare it to Java and I wouldn't say its verbose either, its expressiveness is close to D . It is a full dynamic language with all the benefit and safety of static typing through type inference. You can use it object oriented or functional. It has a fantastic remoting framework with type checking at compile time! cross platform - no other language has this to offer. CoffeeScript is just a JavaScript alternative without a real benefit. HaXe is a complete framework.

I think the benefit is that CoffeeScript has a better syntax and better features (compared to JavaScript). Well, CoffeeScript isn't supposed to have any runtime or similar. It's compiled into standard JavaScript without needing any extra runtime methods. -- /Jacob Carlborg
Dec 05 2011
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Fri, 02 Dec 2011 04:33:48 -0800, a <a 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. The most important thing to a UI designer is that the UI looks and works the same across *ALL* OS's. That's kind of the point of HTML/CSS and the whole internet. Facebook looks and works the same regardless of whether I pull it up in Chrome or Firefox, Mac or Linux. Now, not having higher level constructs like Buttons, Textboxes, etc. will put QML at a huge disadvantage to tools like WPF that DO have those constructs. In WPF you apply a new look to an existing button, you don't build the button from scratch. The new look is usually made out of the primitives similar to those in QML, but all the code and functionality that makes it a Button is still there, and that's important, because the functionality is the hard part, I can skin a WPF button in under an hour, I dare say you couldn't write the code for a button in an hour. -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Dec 02 2011
parent Kagamin <spam here.lot> writes:
Adam Wilson Wrote:

 Facebook looks and works the  
 same regardless of whether I pull it up in Chrome or Firefox, Mac or Linux.

Tried to look at it and thought it's some fraudulent site: looks like entire facebook is in my adblock filters, lol.
Dec 02 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 02.12.2011, 19:15 Uhr, schrieb Nick Sabalausky <a a.a>:

 "Adam Wilson" <flyboynw gmail.com> wrote in message
 news:op.v5vibnca707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 04:33:48 -0800, a <a 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. 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. The closer you get to entertainment, the more fancy the UI becomes I think :D
Dec 02 2011
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Fri, 02 Dec 2011 10:15:12 -0800, Nick Sabalausky <a a.a> wrote:

 "Adam Wilson" <flyboynw gmail.com> wrote in message
 news:op.v5vibnca707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 04:33:48 -0800, a <a 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.

So the push for multi-platform UI consistency via the internet and HTML/CSS is wrong? I don't mind calling the use of HTML/CSS the wrong method to achieve multi-platform UI consistency, it's a document markup language after all and was never originally intended to construct complex UI's, but what you are saying is that the entire idea of how the internet displays data is wrong. It certainly has it's pitfalls, but I have trouble believing that the collective conclusion of billions of people that it is the right idea can realistically be considered 'wrong'. Users in general LOVE the cross-platform UI consistency of the internet. Amazon, Facebook, the list goes on, the most widely-used and successful interfaces in the world are built on the concept of cross-platform UI consistency. It just so happens that it is achieved with HTML/JS/CSS. The implementation might be lacking, but I don't see any point in arguing with the collective will of billions of people.
 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.

Why? Isn't that pretty much the definition of the internet?
 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 ;) ).

Mobile has form factor issues, namely that it's too small to display a desktop style UI. But UI design isn't a technical thing, it's a right-brain thing. As long as the interaction and display models are similar (i.e. it works and looks similar) the physical layout changes that the mobile form-factor demands won't seem nearly as jarring to the user, because they already have a mental model for how to interact with the interface for that piece of software. Now, all that said, the default style of WPF is Windows Aero (aka the default look of Vista/7). And there is no reason not to have the UI framework default to the OS default style. But the true power of WPF is that if you need to, you can change everything. It's like Andrei once said, "The right way should be easy, but the wrong way should be possible." The implication there is that 'wrong' isn't always wrong. That's what WPF does and that's what I want to build for D. I have no problem defaulting to the OS default look, and in fact that would be the default of any GUI project I'd be interested in undertaking. But I don't want to be limited to just the OS look. Those types of arbitrary limitations fly in the face of the D way, at least as I understand it. -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Dec 02 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 02.12.2011, 21:19 Uhr, schrieb Adam Wilson <flyboynw gmail.com>:

 On Fri, 02 Dec 2011 10:15:12 -0800, Nick Sabalausky <a a.a> wrote:

 "Adam Wilson" <flyboynw gmail.com> wrote in message
 news:op.v5vibnca707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 04:33:48 -0800, a <a 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.

So the push for multi-platform UI consistency via the internet and HTML/CSS is wrong? I don't mind calling the use of HTML/CSS the wrong method to achieve multi-platform UI consistency, it's a document markup language after all and was never originally intended to construct complex UI's, but what you are saying is that the entire idea of how the internet displays data is wrong. It certainly has it's pitfalls, but I have trouble believing that the collective conclusion of billions of people that it is the right idea can realistically be considered 'wrong'. Users in general LOVE the cross-platform UI consistency of the internet. Amazon, Facebook, the list goes on, the most widely-used and successful interfaces in the world are built on the concept of cross-platform UI consistency. It just so happens that it is achieved with HTML/JS/CSS. The implementation might be lacking, but I don't see any point in arguing with the collective will of billions of people.
 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.

Why? Isn't that pretty much the definition of the internet?
 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 ;) ).

Mobile has form factor issues, namely that it's too small to display a desktop style UI. But UI design isn't a technical thing, it's a right-brain thing. As long as the interaction and display models are similar (i.e. it works and looks similar) the physical layout changes that the mobile form-factor demands won't seem nearly as jarring to the user, because they already have a mental model for how to interact with the interface for that piece of software. Now, all that said, the default style of WPF is Windows Aero (aka the default look of Vista/7). And there is no reason not to have the UI framework default to the OS default style. But the true power of WPF is that if you need to, you can change everything. It's like Andrei once said, "The right way should be easy, but the wrong way should be possible." The implication there is that 'wrong' isn't always wrong. That's what WPF does and that's what I want to build for D. I have no problem defaulting to the OS default look, and in fact that would be the default of any GUI project I'd be interested in undertaking. But I don't want to be limited to just the OS look. Those types of arbitrary limitations fly in the face of the D way, at least as I understand it.

The OS default look is provided by the OS widgets. Skinned interfaces are created by not using them. I don't think the limitations are arbitrary here. Swing tried to provide native look without native widgets and my experience was, that it felt neither native nor nice. Perhaps the common ground is to provide two implementations of a 'button'. One using OS widgets and one that just renders into a bitmap, but provides the same event hooks.
Dec 02 2011
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Fri, 02 Dec 2011 13:03:57 -0800, Nick Sabalausky <a a.a> wrote:

 "Adam Wilson" <flyboynw gmail.com> wrote in message
 news:op.v5vpeyg4707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 10:15:12 -0800, Nick Sabalausky <a a.a> wrote:

 "Adam Wilson" <flyboynw gmail.com> wrote in message
 news:op.v5vibnca707hn8 invictus.skynet.com...
 On Fri, 02 Dec 2011 04:33:48 -0800, a <a 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.

So the push for multi-platform UI consistency via the internet and HTML/CSS is wrong?

It's unrelated and irrelevent. HTML/CSS is for documents and presentation (though it could stand to be much better at presentation). Cramming apps into a web browser is moronic any way you look at it. Even if your goal actually is "Fuck your OS and your settings, I'm forcing *MY* design on you!" like most asshole designers these days, doing it via a web browser is *still* an unnecessary and grossly inferior way to go about it.
 The implementation might  be lacking, but I don't see any point in  
 arguing
 with the collective will  of billions of people.

The collective will of thousands of **designers**. The majority of sheeple just gobble up whetever's tossed onto their plate. Feed them "web apps" and tell them it's the great new thing, and they believe it. Feed them "mobile apps" and tell them it's the great new thing, and they believe it. Feed them "desktop apps" and tell them it's the great new thing, and they believe it. It doesn't make a damn bit of difference what it is. The billions of people HAVE NO COLLECTIVE WILL. The majority of the time, their only will is to swallow anything they're given, and right now, with the exception of mobile, what they're being fed just happens to be web apps, therefore they assume web apps are a great and wonderous thing (They're not. They're a perversion of technology). So a designer following the "collective will of billions of people" is nothing but an idiocy feedback loop with nobody at the helm. As designers, we have a resposibility to give people *quality*, not whatever randam garbage the trend-whore designers have decided to cram down all their loyal subject's throats.
 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.

Why? Isn't that pretty much the definition of the internet?

No, of course not.
 Mobile has form factor issues, namely that it's too small to display a
 desktop style UI. But UI design isn't a technical thing, it's a
 right-brain thing. As long as the interaction and display models are
 similar (i.e. it works and looks similar) the physical layout changes  
 that
 the mobile form-factor demands won't seem nearly as jarring to the user,
 because they already have a mental model for how to interact with the
 interface for that piece of software.

Right, and that all boils down to: You make it right for the given platform instead of trying to force the same look & feel onto everything. Forcing the same look & feel on all platforms only works if all platforms are the same. And then anytime some platform is different, that thinking just leads people to bitch and moan about the device being "wrong" ("The screen's too small for my pristine one-size-fits-all design! It's the devices fault! Wah!").
 I have no problem defaulting to the OS default look, and in fact that
 would be the default of any GUI project I'd be interested in  
 undertaking.
 But I don't want to be limited to just the OS look. Those types of
 arbitrary limitations fly in the face of the D way, at least as I
 understand it.

I agree the look of apps should be user-configurable, but that belongs at the OS/Window-Manager level. 'Course, I'll grant that's never going to happen on MS or Apple platforms, in which case, yea, using a lib that makes "system" the default and "user-configured" an option is the next best thing.

I think at this point we'll just have to agree to disagree. Fortunately, being the open project this is, there is room for both methods and we let the coders decide which one they want to use and everyone wins. I won't get in your way if you won't get in mine. Deal? :-) -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Dec 02 2011
prev sibling next sibling parent reply Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 2 Dec 2011 16:03:57 -0500
"Nick Sabalausky" <a a.a> wrote:

 I agree the look of apps should be user-configurable, but that
 belongs at the OS/Window-Manager level. 'Course, I'll grant that's
 never going to happen on MS or Apple platforms, in which case, yea,
 using a lib that makes "system" the default and "user-configured" an
 option is the next best thing.

I fully agree with things which you said above...not liking this mobile/web hype pushed to us at the moment. Just, curious what would be your choise for multi-platform GU app: gtk, qt or wx? Sincerely, Gour --=20 But a person free from all attachment and aversion and able=20 to control his senses through regulative principles of=20 freedom can obtain the complete mercy of the Lord. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 02 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Gour" <gour atmarama.net> wrote in message 
news:20111203075455.6d9d1321 atmarama.noip.me...
"Nick Sabalausky" <a a.a> wrote:

 I agree the look of apps should be user-configurable, but that
 belongs at the OS/Window-Manager level. 'Course, I'll grant that's
 never going to happen on MS or Apple platforms, in which case, yea,
 using a lib that makes "system" the default and "user-configured" an
 option is the next best thing.

I fully agree with things which you said above...not liking this mobile/web hype pushed to us at the moment. Just, curious what would be your choise for multi-platform GU app: gtk, qt or wx?

My ranking would be: #1: wx: Because it uses native controls on pretty much all platforms. #2: qt: Because for a non-native UI, it at least does a good job of getting the look & feel right. And I've heard that the API is nice. . . . #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome.
Dec 03 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jbdp5t$2j0k$1 digitalmars.com...
 "Gour" <gour atmarama.net> wrote in message 
 news:20111203075455.6d9d1321 atmarama.noip.me...
"Nick Sabalausky" <a a.a> wrote:

 I agree the look of apps should be user-configurable, but that
 belongs at the OS/Window-Manager level. 'Course, I'll grant that's
 never going to happen on MS or Apple platforms, in which case, yea,
 using a lib that makes "system" the default and "user-configured" an
 option is the next best thing.

I fully agree with things which you said above...not liking this mobile/web hype pushed to us at the moment. Just, curious what would be your choise for multi-platform GU app: gtk, qt or wx?

My ranking would be: #1: wx: Because it uses native controls on pretty much all platforms. #2: qt: Because for a non-native UI, it at least does a good job of getting the look & feel right. And I've heard that the API is nice. . . . #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome.

FWIW, SWT would probably be somewhere in the top 3, definitely above qt (because I *think* SWT is true native...?), but not sure how I'd rank it compared to wx b/c I'd have to actually try them both out.
Dec 03 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-03 19:20, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:jbdp5t$2j0k$1 digitalmars.com...
 "Gour"<gour atmarama.net>  wrote in message
 news:20111203075455.6d9d1321 atmarama.noip.me...
 "Nick Sabalausky"<a a.a>  wrote:

 I agree the look of apps should be user-configurable, but that
 belongs at the OS/Window-Manager level. 'Course, I'll grant that's
 never going to happen on MS or Apple platforms, in which case, yea,
 using a lib that makes "system" the default and "user-configured" an
 option is the next best thing.

I fully agree with things which you said above...not liking this mobile/web hype pushed to us at the moment. Just, curious what would be your choise for multi-platform GU app: gtk, qt or wx?

My ranking would be: #1: wx: Because it uses native controls on pretty much all platforms. #2: qt: Because for a non-native UI, it at least does a good job of getting the look& feel right. And I've heard that the API is nice. . . . #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome.

FWIW, SWT would probably be somewhere in the top 3, definitely above qt (because I *think* SWT is true native...?), but not sure how I'd rank it compared to wx b/c I'd have to actually try them both out.

SWT uses native widgets where available and emulates them otherwise. -- /Jacob Carlborg
Dec 04 2011
prev sibling parent a <a a.com> writes:
 #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, 
 plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome.

Using XFCE right now, looks fine to me.
Dec 04 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 03.12.2011, 07:14 Uhr, schrieb Alexey Prokhin  
<alexey.prokhin yandex.ru>:

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

http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/ . Right now it is a research project, but it most likely will be a part of the upcoming Qt5.

That stuff looks convincingly native on Gnome and Windows.
Dec 03 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 03.12.2011, 19:20 Uhr, schrieb Nick Sabalausky <a a.a>:

 "Nick Sabalausky" <a a.a> wrote in message
 news:jbdp5t$2j0k$1 digitalmars.com...
 "Gour" <gour atmarama.net> wrote in message
 news:20111203075455.6d9d1321 atmarama.noip.me...
 "Nick Sabalausky" <a a.a> wrote:

 I agree the look of apps should be user-configurable, but that
 belongs at the OS/Window-Manager level. 'Course, I'll grant that's
 never going to happen on MS or Apple platforms, in which case, yea,
 using a lib that makes "system" the default and "user-configured" an
 option is the next best thing.

I fully agree with things which you said above...not liking this mobile/web hype pushed to us at the moment. Just, curious what would be your choise for multi-platform GU app: gtk, qt or wx?

My ranking would be: #1: wx: Because it uses native controls on pretty much all platforms. #2: qt: Because for a non-native UI, it at least does a good job of getting the look & feel right. And I've heard that the API is nice. . . . #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome.

FWIW, SWT would probably be somewhere in the top 3, definitely above qt (because I *think* SWT is true native...?), but not sure how I'd rank it compared to wx b/c I'd have to actually try them both out.

As far as I understood it SWT was written for Eclipse. It may fall behind the other toolkits in terms of features and it is written in Java, so using it means a true D reimplementation of the API unless someone already did a C port. I think the small and native aspect made it a good candidate for inclusion into Phobos in the past. The much other toolkits are just too big. We may all have good eyes and such, but maybe the accessibility aspect should also be considered in this discussion.
Dec 03 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 3 Dec 2011 13:16:14 -0500
"Nick Sabalausky" <a a.a> wrote:

 My ranking would be:
=20
 #1: wx: Because it uses native controls on pretty much all platforms.
 #2: qt: Because for a non-native UI, it at least does a good job of
 getting the look & feel right. And I've heard that the API is nice.

Thank you...I'm also moving towards wx.
 .
 #84,259,254: gtk: Because it doesn't give a rat's ass about native
 anything, plus it's just plain ugly (read: big-n-chunky) on all
 platforms, even Gnome.

=46rom where did you find that long int? :-) Sincerely, Gour --=20 Never was there a time when I did not exist,=20 nor you, nor all these kings; nor in the future=20 shall any of us cease to be. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 03 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 3 Dec 2011 13:20:49 -0500
"Nick Sabalausky" <a a.a> wrote:

 FWIW, SWT would probably be somewhere in the top 3, definitely above
 qt (because I *think* SWT is true native...?), but not sure how I'd
 rank it compared to wx b/c I'd have to actually try them both out.

Thank you for your input. I've tried to build DWT, but no luck and I'm not so thrilled about DWT's inheritage from the Java-world. Sincerely, Gour --=20 The senses are so strong and impetuous, O Arjuna,=20 that they forcibly carry away the mind even of a man=20 of discrimination who is endeavoring to control them. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 03 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-12-03 at 13:16 -0500, Nick Sabalausky wrote:
[...]

A few thoughts based mainly from Python use perspective.

 #1: wx: Because it uses native controls on pretty much all platforms.

wxWidgets appears to have the need in the C++ API for the programmer to number each widget individually in order to access it, and the parameter passing gets messy. The wxPython API get around a lot of this by being able to do lots of dynamic binding and parameter passing tricks. wxWidgets and wxPython have licences amenable to being used for proprietary software without cost.
 #2: qt: Because for a non-native UI, it at least does a good job of getti=

 the look & feel right. And I've heard that the API is nice.

Qt4 and PySide appear to have good cross-platform capabilities, but clearly look like Qt applications on all platforms. C++ API is awkward compared to the PySide API, again because of dynamic binding and parameter tricks. PyQt has an unfriendly licence for anyone wishing to make proprietary systems. [...]
 #84,259,254: gtk: Because it doesn't give a rat's ass about native anythi=

 plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gno=

GTKmm is not that bad. PyGTK makes it very much nicer. On Gnome GTK stuff looks fine. Doesn't port well to OS X and Windows though, which is why most people plump for Qt. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Dec 04 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.1300.1322991626.24802.digitalmars-d puremagic.com...
On Sat, 2011-12-03 at 13:16 -0500, Nick Sabalausky wrote:
[...]

A few thoughts based mainly from Python use perspective.

 #1: wx: Because it uses native controls on pretty much all platforms.

wxWidgets appears to have the need in the C++ API for the programmer to number each widget individually in order to access it, and the parameter passing gets messy. The wxPython API get around a lot of this by being able to do lots of dynamic binding and parameter passing tricks. wxWidgets and wxPython have licences amenable to being used for proprietary software without cost.

I hven't looked at the wxWidgets API, I would think that could easily be hidden by a good wrapper even without any fancy tricks (maybe wxD already does that? I don't know. I haven't gotten around to trying any GUI in D yet). I'm thinking basic bindings in deimos, and then paper over the rough spots in a separate package that wraps it with a revamped API.
 #2: qt: Because for a non-native UI, it at least does a good job of 
 getting
 the look & feel right. And I've heard that the API is nice.

Qt4 and PySide appear to have good cross-platform capabilities, but clearly look like Qt applications on all platforms.

I'm not doubting you, but it's strange that I of all people (ie, Mr. Native-or-Die ;) ) haven't noticed. My copy of Arora on Windows (v0.11.0) looks indistinguishable from native to me, and it reports using Qt 4.7.1. Do you have specific examples of differences? Hmm, well, I admit the scroll bars in Arora fail to use my system color theme, but I always assumed that was just Arora trying to emulate IE's questionable "web-page-specified scroll bar colors" feature, with an incorrect default setting. The scroll bars in the "Show All Bookmarks" window look right.
PyQt has an unfriendly licence for anyone wishing to
make proprietary systems.

I didn't know that. Do you know if that's specific to PyQt, or inhereted from Qt?
[...]
 #84,259,254: gtk: Because it doesn't give a rat's ass about native 
 anything,
 plus it's just plain ugly (read: big-n-chunky) on all platforms, even 
 Gnome.

GTKmm is not that bad. PyGTK makes it very much nicer. On Gnome GTK stuff looks fine. Doesn't port well to OS X and Windows though, which is why most people plump for Qt.

What I meant about Gnome is just that, IMO, everthing on Gnome looks all big-n-chunky with way too much padding. YMMV.
Dec 04 2011
next sibling parent David Nadlinger <see klickverbot.at> writes:
On 12/4/11 6:00 PM, Nick Sabalausky wrote:
 PyQt has an unfriendly licence for anyone wishing to
 make proprietary systems.

I didn't know that. Do you know if that's specific to PyQt, or inhereted from Qt?

This is specific to PyQt, they stayed at GPL when Qt changed its open source license to LGPL. PySide was conceived as a LGPL-licensed alternative to it. David
Dec 04 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-04 18:00, Nick Sabalausky wrote:
 "Russel Winder"<russel russel.org.uk>  wrote in message
 news:mailman.1300.1322991626.24802.digitalmars-d puremagic.com...
 On Sat, 2011-12-03 at 13:16 -0500, Nick Sabalausky wrote:
 [...]

 A few thoughts based mainly from Python use perspective.

 #1: wx: Because it uses native controls on pretty much all platforms.

wxWidgets appears to have the need in the C++ API for the programmer to number each widget individually in order to access it, and the parameter passing gets messy. The wxPython API get around a lot of this by being able to do lots of dynamic binding and parameter passing tricks. wxWidgets and wxPython have licences amenable to being used for proprietary software without cost.

I hven't looked at the wxWidgets API, I would think that could easily be hidden by a good wrapper even without any fancy tricks (maybe wxD already does that? I don't know. I haven't gotten around to trying any GUI in D yet). I'm thinking basic bindings in deimos, and then paper over the rough spots in a separate package that wraps it with a revamped API.
 #2: qt: Because for a non-native UI, it at least does a good job of
 getting
 the look&  feel right. And I've heard that the API is nice.

Qt4 and PySide appear to have good cross-platform capabilities, but clearly look like Qt applications on all platforms.

I'm not doubting you, but it's strange that I of all people (ie, Mr. Native-or-Die ;) ) haven't noticed. My copy of Arora on Windows (v0.11.0) looks indistinguishable from native to me, and it reports using Qt 4.7.1. Do you have specific examples of differences? Hmm, well, I admit the scroll bars in Arora fail to use my system color theme, but I always assumed that was just Arora trying to emulate IE's questionable "web-page-specified scroll bar colors" feature, with an incorrect default setting. The scroll bars in the "Show All Bookmarks" window look right.
 PyQt has an unfriendly licence for anyone wishing to
 make proprietary systems.

I didn't know that. Do you know if that's specific to PyQt, or inhereted from Qt?

Qt is licensed under GPL, LGPL and a commercial license. -- /Jacob Carlborg
Dec 04 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2011-12-04 at 12:00 -0500, Nick Sabalausky wrote:
[...]

PyQt has an unfriendly licence for anyone wishing to
make proprietary systems.

I didn't know that. Do you know if that's specific to PyQt, or inhereted=

 from Qt?

As David pointed out, PyQt stayed GPL and commercial licence when Qt went to LGPL and commercial licence. People with money can just pay for the commercial licences of course, but the fact that PyQt didn't switch to LGPL when Qt did annoyed a lot of people. Sifficient to start teh PySide project. [...]
 What I meant about Gnome is just that, IMO, everthing on Gnome looks all=

 big-n-chunky with way too much padding. YMMV.

It depends on the engine you use. For Gnome 2 I used thinice which gets rid of all the chunkyness. For Gnome 3 I am using Adwaita which is a bit chunkier but not too much so -- and I am a person who thinks that chunkyness is anathema not just a bad thing. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Dec 04 2011
parent "Nick Sabalausky" <a a.a> writes:
"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.1305.1323019362.24802.digitalmars-d puremagic.com...
On Sun, 2011-12-04 at 12:00 -0500, Nick Sabalausky wrote:
[...]

PyQt has an unfriendly licence for anyone wishing to
make proprietary systems.

I didn't know that. Do you know if that's specific to PyQt, or inhereted from Qt?

As David pointed out, PyQt stayed GPL and commercial licence when Qt went to LGPL and commercial licence. People with money can just pay for the commercial licences of course, but the fact that PyQt didn't switch to LGPL when Qt did annoyed a lot of people. Sifficient to start teh PySide project.

I see. Thanks.
[...]
 What I meant about Gnome is just that, IMO, everthing on Gnome looks all
 big-n-chunky with way too much padding. YMMV.

It depends on the engine you use. For Gnome 2 I used thinice which gets rid of all the chunkyness. For Gnome 3 I am using Adwaita which is a bit chunkier but not too much so -- and I am a person who thinks that chunkyness is anathema not just a bad thing.

I had no idea. I'll have to try those next time I'm on Gnome.
Dec 04 2011
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 04.12.2011, 21:17 Uhr, schrieb Adam D. Ruppe  =

<destructionator gmail.com>:

 Jacob Carlborg Wrote:
 If you like the idea there, but want something a lot more conservative=

 in my html.d (in here:  =

 https://github.com/adamdruppe/misc-stuff-including-D-programming-langu=

 )
 there's now a JavascriptMacroExpander class which pre-processes  =

 javascript.

 The only build in function it provides right now is foreach() (just  =

 because I find
 it's lack to be the easiest thing to take care of...) but the macro  =

 system might
 be useful too for certain things.

 Again, it's just a preprocessor, so you drop stuff like this into the =

 middle of
 regular js code:

 =C2=A4foreach(element; document.querySelectorAll("p")) {
      element.style.color =3D "red";
 }

 converts to

     var arsd_foreach_loop_temporary_2 =3D document.querySelectorAll("p=

     for(var arsd_foreach_loop_counter_1 =3D 0; arsd_foreach_loop_count=

 < arsd_foreach_loop_temporary_2.length; arsd_foreach_loop_counter_1++)=

              var element =3D  =

 arsd_foreach_loop_temporary_2[arsd_foreach_loop_counter_1];
              element.style.color =3D "red";
     }

There is also this macro in the JavaScript plugin for Eclipse: for (var ${index} =3D 0; ${index} < ${array}.length; ${index}++) { var ${array_element} =3D ${array}[${index}]; ${cursor} } This is really one of the largest shortcomings of the language that can = = not be explained with a simple design choice.
Dec 05 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Marco Leise Wrote:
 This is really one of the largest shortcomings of the language that can  
 not be explained with a simple design choice.

Aye. One of the newer versions adds a forEach member to the array prototype, that works like this: [1, 2, 3].forEach(function(element) { use element here; }); but I don't like that style, personally. All those years of C and friends have wired my brain to see it as being backward. And, it doesn't work for everyone out of the box anyway.
Dec 05 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-05 16:53, Adam Ruppe wrote:
 Marco Leise Wrote:
 This is really one of the largest shortcomings of the language that can
 not be explained with a simple design choice.

Aye. One of the newer versions adds a forEach member to the array prototype, that works like this: [1, 2, 3].forEach(function(element) { use element here; }); but I don't like that style, personally. All those years of C and friends have wired my brain to see it as being backward. And, it doesn't work for everyone out of the box anyway.

That's the Ruby style, quite verbose in plain JavaScript. In CoffeeScript it would look like: [1, 2, 4].forEach (element) -> # use element here -- /Jacob Carlborg
Dec 05 2011