www.digitalmars.com         C & C++   DMDScript  

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

reply Joshua Niehus <jm.niehus gmail.com> writes:
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 :)
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 "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
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.



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



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



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



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



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



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



 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 parent reply Gour <gour atmarama.net> writes:
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
next sibling 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:



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

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:



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

 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
next sibling parent reply "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:



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

 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
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 next sibling parent Gour <gour atmarama.net> writes:
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 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:



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

 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 next sibling parent Gour <gour atmarama.net> writes:
On Sat, 3 Dec 2011 13:16:14 -0500
"Nick Sabalausky" <a a.a> wrote:


 My ranking would be:
=20


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


Thank you...I'm also moving towards wx.


 .

 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 reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-12-03 at 13:16 -0500, Nick Sabalausky wrote:
[...]

A few thoughts based mainly from Python use perspective.





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.





ng=20

 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.

[...]




ng,=20

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


me.

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.





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.



 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?


[...]


 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 next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sun, 2011-12-04 at 12:00 -0500, Nick Sabalausky wrote:
[...]


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


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


=20

 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=


=20

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





 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.



 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 parent a <a a.com> writes:

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



 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 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 parent reply 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.


No, there are widgets with native look and feel for QML: 
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
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.


 No, there are widgets with native look and feel for QML:
 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 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.
 


What about Lua ?
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.


 What about Lua ?
 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.


 What about Lua ?
 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.


 What about Lua ?
 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.


 What about Lua ?
 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 "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=


age-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:

 =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=


er_1  =


 < 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
next 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


-- 
/Jacob Carlborg
Dec 05 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Jacob Carlborg Wrote:

 for e in arr



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



 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


Which compiles to:

for (k in obj) {
   v = obj[k];
}

-- 
/Jacob Carlborg
Dec 05 2011
prev sibling 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:



-- 
/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++

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++

 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++

 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++

 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