Java > Scala -> new thread: GUI for D
>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 :)
Re: Java > Scala -> new thread: GUI for D
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.
Re: Java > Scala -> new thread: GUI for D
"Joshua Niehus" wrote in message news:mailman.1243.1322814889.24802.digitalmar...@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 :) >
Re: Java > Scala -> new thread: GUI for D
On Fri, 02 Dec 2011 04:33:48 -0800, 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. 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/
Re: Java > Scala -> new thread: GUI for D
On Fri, Dec 02, 2011 at 09:46:25AM -0800, Adam Wilson wrote: > 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. Actually, html and css are supposed to adapt to the user's environment. html describes the data and css has cascading defaults and provisions for users to override styles. But nobody uses it that way in practice, indeed.
Re: Java > Scala -> new thread: GUI for D
"Adam Wilson" wrote in message news:op.v5vibnca707...@invictus.skynet.com... > On Fri, 02 Dec 2011 04:33:48 -0800, 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. > > This is similar in concept to how XAML in WPF/Silverlight is used to > construct screens, and it's not bad idea. And the fact that the UX can be > skinned to look nothing like the default OSUI is actually probably one of > the most useful things about WPF and Silverlight. Yes, it doesn't look > true to the OS, but you'll find that in the UI Design world, that is of > surprisingly little importance. That's without a doubt my #1 complaint about desktop apps over the last decade: Narcissistic designers with nothing but contempt for a user's control over their own system. >The most important thing to a UI designer is that the UI looks and works >the same across *ALL* OS's. That's just terrible. >Facebook looks and works the same regardless of whether I pull it up in >Chrome or Firefox, Mac or Linux. The hell with mobile, eh? Making things look and act the same on everything is *terrible* UI design. Making things look and act *appropriate* for the given platform has alwas been and will always be the proper thing to do regardless of what the majority of designers decide is the trend du jour (ok, so that's redundant, so sue me ;) ).
Re: Java > Scala -> new thread: GUI for D
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.
Re: Java > Scala -> new thread: GUI for D
Am 02.12.2011, 19:15 Uhr, schrieb Nick Sabalausky : "Adam Wilson" wrote in message news:op.v5vibnca707...@invictus.skynet.com... On Fri, 02 Dec 2011 04:33:48 -0800, 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. This is similar in concept to how XAML in WPF/Silverlight is used to construct screens, and it's not bad idea. And the fact that the UX can be skinned to look nothing like the default OSUI is actually probably one of the most useful things about WPF and Silverlight. Yes, it doesn't look true to the OS, but you'll find that in the UI Design world, that is of surprisingly little importance. That's without a doubt my #1 complaint about desktop apps over the last decade: Narcissistic designers with nothing but contempt for a user's control over their own system. The most important thing to a UI designer is that the UI looks and works the same across *ALL* OS's. That's just terrible. Facebook looks and works the same regardless of whether I pull it up in Chrome or Firefox, Mac or Linux. The hell with mobile, eh? Making things look and act the same on everything is *terrible* UI design. Making things look and act *appropriate* for the given platform has alwas been and will always be the proper thing to do regardless of what the majority of designers decide is the trend du jour (ok, so that's redundant, so sue me ;) ). I disagree with you on Java, but I agree with you here. I really don't want to use MacOS X and find that application X's UI looks like WindowsXP or vice versa. I hope QML will continue to try to support native looks, if it becomes standard with Qt applications. If someone writes a new custom control, that needs a new look of course that didn't exist on any OS before, ok. But file open dialogs, buttons, toolbars etc should really not try to jump out of the pattern unless the application itself is entirely skinned, like WinAmp. The closer you get to entertainment, the more fancy the UI becomes I think :D
Re: Java > Scala -> new thread: GUI for D
"Marco Leise" wrote in message news:op.v5vk4ov69y6...@marco-leise.homedns.org... > Am 02.12.2011, 19:15 Uhr, schrieb Nick Sabalausky : > >> "Adam Wilson" wrote in message >> news:op.v5vibnca707...@invictus.skynet.com... >>> On Fri, 02 Dec 2011 04:33:48 -0800, 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. >>> >>> This is similar in concept to how XAML in WPF/Silverlight is used to >>> construct screens, and it's not bad idea. And the fact that the UX can >>> be >>> skinned to look nothing like the default OSUI is actually probably one >>> of >>> the most useful things about WPF and Silverlight. Yes, it doesn't look >>> true to the OS, but you'll find that in the UI Design world, that is of >>> surprisingly little importance. >> >> That's without a doubt my #1 complaint about desktop apps over the last >> decade: Narcissistic designers with nothing but contempt for a user's >> control over their own system. >> >>> The most important thing to a UI designer is that the UI looks and >>> works >>> the same across *ALL* OS's. >> >> That's just terrible. >> >>> Facebook looks and works the same regardless of whether I pull it up in >>> Chrome or Firefox, Mac or Linux. >> >> The hell with mobile, eh? Making things look and act the same on >> everything >> is *terrible* UI design. Making things look and act *appropriate* for the >> given platform has alwas been and will always be the proper thing to do >> regardless of what the majority of designers decide is the trend du jour >> (ok, so that's redundant, so sue me ;) ). > > I disagree with you on Java, but I agree with you here. I really don't > want to use MacOS X and find that application X's UI looks like WindowsXP > or vice versa. I hope QML will continue to try to support native looks, if > it becomes standard with Qt applications. > If someone writes a new custom control, that needs a new look of course > that didn't exist on any OS before, ok. Right. I agree. If you really do need a control that doesn't already exist in a standard form, then you gotta do what you gotta do. > But file open dialogs, buttons, toolbars etc should really not try to > jump out of the pattern unless the application itself is entirely > skinned, like WinAmp. Actually, I absolutely hate WinAmp (and all programs that are entirely skinned). And WinAmp in particular is super butt-ugly. *And* the UI overall, esp. the library, is screwy (read: buggy and poorly architected) as all hell. iTunes is irritatinnly all-skinned, too (on Windows, anyway), but at least it actually looks half-way decent as far as skinned apps go (and it's not so buggy). The only benefits WinAmp has over iTunes is that it's not so absurdly bloated, doesn't infect you with useless always-resident processes, and it actually handles Ogg Vorbis worth a damn. Unfortunately, I've been using WinAmp as my primary player despite my hatred for it because the iTunes lack of Ogg Vorbis support is a deal-breaker for me, and I still haven't found any other music manager that's any better. Foobar 2000 came pretty damn close, but as I recall, it had some sort of deal-breaker limitations (don't remember what), and the fact that it's a freeware program that's *not* open-source makes me very uneasy about relying on it. > The closer you get to entertainment, the more fancy the UI becomes I > think :D It makes sense in a videogame or a TV-connected media center PC. But those are exceptions for valid reasons: They themselves essentially *are* separate environments. Seeing system dialogs in a videogame is just too jarring, in both aesthetics and interface, especially since such system UI's aren't designed for games[1]. And connecting a PC to a TV for media purposes effectively amounts to a different platform that has fundamentally different UI requirements. [1] The Wii/PS3's system UIs (and XBox1 Live, IIRC), by contrast, actually work out very well since they're designed specifically for set-top videogaming (Probably 360's too, but I'm less familiar with that, especially the newer 360 UI). 'Course in the Wii's case, I suspect it's more a std lib they make the game developers use rather than a true system UI like the PS3/360 seem to be, but the effect is much the same...
Re: Java > Scala -> new thread: GUI for D
"Marco Leise" wrote in message news:op.v5vk4ov69y6...@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!
Re: Java > Scala -> new thread: GUI for D
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.
Re: Java > Scala -> new thread: GUI for D
"David Gileadi" 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.
Re: Java > Scala -> new thread: GUI for D
On Fri, 02 Dec 2011 10:15:12 -0800, Nick Sabalausky wrote: "Adam Wilson" wrote in message news:op.v5vibnca707...@invictus.skynet.com... On Fri, 02 Dec 2011 04:33:48 -0800, 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. This is similar in concept to how XAML in WPF/Silverlight is used to construct screens, and it's not bad idea. And the fact that the UX can be skinned to look nothing like the default OSUI is actually probably one of the most useful things about WPF and Silverlight. Yes, it doesn't look true to the OS, but you'll find that in the UI Design world, that is of surprisingly little importance. That's without a doubt my #1 complaint about desktop apps over the last decade: Narcissistic designers with nothing but contempt for a user's control over their own system. So the push for multi-platform UI consistency via the internet and HTML/CSS is wrong? I don't mind calling the use of HTML/CSS the wrong method to achieve multi-platform UI consistency, it's a document markup language after all and was never originally intended to construct complex UI's, but what you are saying is that the entire idea of how the internet displays data is wrong. It certainly has it's pitfalls, but I have trouble believing that the collective conclusion of billions of people that it is the right idea can realistically be considered 'wrong'. Users in general LOVE the cross-platform UI consistency of the internet. Amazon, Facebook, the list goes on, the most widely-used and successful interfaces in the world are built on the concept of cross-platform UI consistency. It just so happens that it is achieved with HTML/JS/CSS. The implementation might be lacking, but I don't see any point in arguing with the collective will of billions of people. The most important thing to a UI designer is that the UI looks and works the same across *ALL* OS's. That's just terrible. Why? Isn't that pretty much the definition of the internet? Facebook looks and works the same regardless of whether I pull it up in Chrome or Firefox, Mac or Linux. The hell with mobile, eh? Making things look and act the same on everything is *terrible* UI design. Making things look and act *appropriate* for the given platform has alwas been and will always be the proper thing to do regardless of what the majority of designers decide is the trend du jour (ok, so that's redundant, so sue me ;) ). Mobile has form factor issues, namely that it's too small to display a desktop style UI. But UI design isn't a technical thing, it's a right-brain thing. As long as the interaction and display models are similar (i.e. it works and looks similar) the physical layout changes that the mobile form-factor demands won't seem nearly as jarring to the user, because they already have a mental model for how to interact with the interface for that piece of software. Now, all that said, the default style of WPF is Windows Aero (aka the default look of Vista/7). And there is no reason not to have the UI framework default to the OS default style. But the true power of WPF is that if you need to, you can change everything. It's like Andrei once said, "The right way should be easy, but the wrong way should be possible." The implication there is that 'wrong' isn't always wrong. That's what WPF does and that's what I want to build for D. I have no problem defaulting to the OS default look, and in fact that would be the default of any GUI project I'd be interested in undertaking. But I don't want to be limited to just the OS look. Those types of arbitrary limitations fly in the face of the D way, at least as I understand it. -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Java > Scala -> new thread: GUI for D
Am 02.12.2011, 21:19 Uhr, schrieb Adam Wilson : On Fri, 02 Dec 2011 10:15:12 -0800, Nick Sabalausky wrote: "Adam Wilson" wrote in message news:op.v5vibnca707...@invictus.skynet.com... On Fri, 02 Dec 2011 04:33:48 -0800, 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. This is similar in concept to how XAML in WPF/Silverlight is used to construct screens, and it's not bad idea. And the fact that the UX can be skinned to look nothing like the default OSUI is actually probably one of the most useful things about WPF and Silverlight. Yes, it doesn't look true to the OS, but you'll find that in the UI Design world, that is of surprisingly little importance. That's without a doubt my #1 complaint about desktop apps over the last decade: Narcissistic designers with nothing but contempt for a user's control over their own system. So the push for multi-platform UI consistency via the internet and HTML/CSS is wrong? I don't mind calling the use of HTML/CSS the wrong method to achieve multi-platform UI consistency, it's a document markup language after all and was never originally intended to construct complex UI's, but what you are saying is that the entire idea of how the internet displays data is wrong. It certainly has it's pitfalls, but I have trouble believing that the collective conclusion of billions of people that it is the right idea can realistically be considered 'wrong'. Users in general LOVE the cross-platform UI consistency of the internet. Amazon, Facebook, the list goes on, the most widely-used and successful interfaces in the world are built on the concept of cross-platform UI consistency. It just so happens that it is achieved with HTML/JS/CSS. The implementation might be lacking, but I don't see any point in arguing with the collective will of billions of people. The most important thing to a UI designer is that the UI looks and works the same across *ALL* OS's. That's just terrible. Why? Isn't that pretty much the definition of the internet? Facebook looks and works the same regardless of whether I pull it up in Chrome or Firefox, Mac or Linux. The hell with mobile, eh? Making things look and act the same on everything is *terrible* UI design. Making things look and act *appropriate* for the given platform has alwas been and will always be the proper thing to do regardless of what the majority of designers decide is the trend du jour (ok, so that's redundant, so sue me ;) ). Mobile has form factor issues, namely that it's too small to display a desktop style UI. But UI design isn't a technical thing, it's a right-brain thing. As long as the interaction and display models are similar (i.e. it works and looks similar) the physical layout changes that the mobile form-factor demands won't seem nearly as jarring to the user, because they already have a mental model for how to interact with the interface for that piece of software. Now, all that said, the default style of WPF is Windows Aero (aka the default look of Vista/7). And there is no reason not to have the UI framework default to the OS default style. But the true power of WPF is that if you need to, you can change everything. It's like Andrei once said, "The right way should be easy, but the wrong way should be possible." The implication there is that 'wrong' isn't always wrong. That's what WPF does and that's what I want to build for D. I have no problem defaulting to the OS default look, and in fact that would be the default of any GUI project I'd be interested in undertaking. But I don't want to be limited to just the OS look. Those types of arbitrary limitations fly in the face of the D way, at least as I understand it. The OS default look is provided by the OS widgets. Skinned interfaces are created by not using them. I don't think the limitations are arbitrary here. Swing tried to provide native look without native widgets and my experience was, that it felt neither native nor nice. Perhaps the common ground is to provide two implementations of a 'button'. One using OS widgets and one that just renders into a bitmap, but provides the same event hooks.
Re: Java > Scala -> new thread: GUI for D
"Adam Wilson" wrote in message
news:op.v5vpeyg4707...@invictus.skynet.com...
> On Fri, 02 Dec 2011 10:15:12 -0800, Nick Sabalausky wrote:
>
>> "Adam Wilson" wrote in message
>> news:op.v5vibnca707...@invictus.skynet.com...
>>> On Fri, 02 Dec 2011 04:33:48 -0800, 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.
>>>
>>> This is similar in concept to how XAML in WPF/Silverlight is used to
>>> construct screens, and it's not bad idea. And the fact that the UX can
>>> be
>>> skinned to look nothing like the default OSUI is actually probably one
>>> of
>>> the most useful things about WPF and Silverlight. Yes, it doesn't look
>>> true to the OS, but you'll find that in the UI Design world, that is of
>>> surprisingly little importance.
>>
>> That's without a doubt my #1 complaint about desktop apps over the last
>> decade: Narcissistic designers with nothing but contempt for a user's
>> control over their own system.
>>
>
> So the push for multi-platform UI consistency via the internet and
> HTML/CSS is wrong?
It's unrelated and irrelevent. HTML/CSS is for documents and presentation
(though it could stand to be much better at presentation). Cramming apps
into a web browser is moronic any way you look at it. Even if your goal
actually is "Fuck your OS and your settings, I'm forcing *MY* design on
you!" like most asshole designers these days, doing it via a web browser is
*still* an unnecessary and grossly inferior way to go about it.
> The implementation might be lacking, but I don't see any point in arguing
> with the collective will of billions of people.
>
The collective will of thousands of **designers**. The majority of sheeple
just gobble up whetever's tossed onto their plate. Feed them "web apps" and
tell them it's the great new thing, and they believe it. Feed them "mobile
apps" and tell them it's the great new thing, and they believe it. Feed them
"desktop apps" and tell them it's the great new thing, and they believe it.
It doesn't make a damn bit of difference what it is. The billions of people
HAVE NO COLLECTIVE WILL. The majority of the time, their only will is to
swallow anything they're given, and right now, with the exception of mobile,
what they're being fed just happens to be web apps, therefore they assume
web apps are a great and wonderous thing (They're not. They're a perversion
of technology).
So a designer following the "collective will of billions of people" is
nothing but an idiocy feedback loop with nobody at the helm. As designers,
we have a resposibility to give people *quality*, not whatever randam
garbage the trend-whore designers have decided to cram down all their loyal
subject's throats.
>>> The most important thing to a UI designer is that the UI looks and
>>> works
>>> the same across *ALL* OS's.
>>
>> That's just terrible.
>>
>
> Why? Isn't that pretty much the definition of the internet?
>
No, of course not.
>
> Mobile has form factor issues, namely that it's too small to display a
> desktop style UI. But UI design isn't a technical thing, it's a
> right-brain thing. As long as the interaction and display models are
> similar (i.e. it works and looks similar) the physical layout changes that
> the mobile form-factor demands won't seem nearly as jarring to the user,
> because they already have a mental model for how to interact with the
> interface for that piece of software.
Right, and that all boils down to: You make it right for the given platform
instead of trying to force the same look & feel onto everything. Forcing the
same look & feel on all platforms only works if all platforms are the same.
And then anytime some platform is different, that thinking just leads people
to bitch and moan about the device being "wrong" ("The screen's too small
for my pristine one-size-fits-all design! It's the devices fault! Wah!").
>
> I have no problem defaulting to the OS default look, and in fact that
> would be the default of any GUI project I'd be interested in undertaking.
> But I don't want to be limited to just the OS look. Those types of
> arbitrary limitations fly in the face of the D way, at least as I
> understand it.
>
I agree the look of apps should be user-configurable, but that belongs at
the OS/Window-Manager level. 'Course, I'll grant that's never going to
happen on MS or Apple platforms, in which case, yea, using a lib that makes
"system" the
Re: Java > Scala -> new thread: GUI for D
On Fri, 02 Dec 2011 13:03:57 -0800, Nick Sabalausky wrote:
"Adam Wilson" wrote in message
news:op.v5vpeyg4707...@invictus.skynet.com...
On Fri, 02 Dec 2011 10:15:12 -0800, Nick Sabalausky wrote:
"Adam Wilson" wrote in message
news:op.v5vibnca707...@invictus.skynet.com...
On Fri, 02 Dec 2011 04:33:48 -0800, 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.
This is similar in concept to how XAML in WPF/Silverlight is used to
construct screens, and it's not bad idea. And the fact that the UX can
be
skinned to look nothing like the default OSUI is actually probably one
of
the most useful things about WPF and Silverlight. Yes, it doesn't look
true to the OS, but you'll find that in the UI Design world, that is
of
surprisingly little importance.
That's without a doubt my #1 complaint about desktop apps over the last
decade: Narcissistic designers with nothing but contempt for a user's
control over their own system.
So the push for multi-platform UI consistency via the internet and
HTML/CSS is wrong?
It's unrelated and irrelevent. HTML/CSS is for documents and presentation
(though it could stand to be much better at presentation). Cramming apps
into a web browser is moronic any way you look at it. Even if your goal
actually is "Fuck your OS and your settings, I'm forcing *MY* design on
you!" like most asshole designers these days, doing it via a web browser
is
*still* an unnecessary and grossly inferior way to go about it.
The implementation might be lacking, but I don't see any point in
arguing
with the collective will of billions of people.
The collective will of thousands of **designers**. The majority of
sheeple
just gobble up whetever's tossed onto their plate. Feed them "web apps"
and
tell them it's the great new thing, and they believe it. Feed them
"mobile
apps" and tell them it's the great new thing, and they believe it. Feed
them
"desktop apps" and tell them it's the great new thing, and they believe
it.
It doesn't make a damn bit of difference what it is. The billions of
people
HAVE NO COLLECTIVE WILL. The majority of the time, their only will is to
swallow anything they're given, and right now, with the exception of
mobile,
what they're being fed just happens to be web apps, therefore they assume
web apps are a great and wonderous thing (They're not. They're a
perversion
of technology).
So a designer following the "collective will of billions of people" is
nothing but an idiocy feedback loop with nobody at the helm. As
designers,
we have a resposibility to give people *quality*, not whatever randam
garbage the trend-whore designers have decided to cram down all their
loyal
subject's throats.
The most important thing to a UI designer is that the UI looks and
works
the same across *ALL* OS's.
That's just terrible.
Why? Isn't that pretty much the definition of the internet?
No, of course not.
Mobile has form factor issues, namely that it's too small to display a
desktop style UI. But UI design isn't a technical thing, it's a
right-brain thing. As long as the interaction and display models are
similar (i.e. it works and looks similar) the physical layout changes
that
the mobile form-factor demands won't seem nearly as jarring to the user,
because they already have a mental model for how to interact with the
interface for that piece of software.
Right, and that all boils down to: You make it right for the given
platform
instead of trying to force the same look & feel onto everything. Forcing
the
same look & feel on all platforms only works if all platforms are the
same.
And then anytime some platform is different, that thinking just leads
people
to bitch and moan about the device being "wrong" ("The screen's too small
for my pristine one-size-fits-all design! It's the devices fault! Wah!").
I have no problem defaulting to the OS default look, and in fact that
would be the default of any GUI project I'd be interested in
undertaking.
But I don't want to be limited to just the OS look. Those types of
arbitrary limitations fly in the face of the D way, at least as I
understand it.
I agree the look of apps should be user-configurable, but that belongs at
the OS/Window-Manager level. 'Course, I'll grant that's never going to
happen on MS or Apple platforms, in which case, yea, using a lib that
makes
"system" the default and "user-configured" an option is the next best
thing.
I think at th
Re: Java > Scala -> new thread: GUI for D
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.
Re: Java > Scala -> new thread: GUI for D
On Fri, 2 Dec 2011 16:03:57 -0500 "Nick Sabalausky" 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 -- But a person free from all attachment and aversion and able to control his senses through regulative principles of freedom can obtain the complete mercy of the Lord. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Java > Scala -> new thread: GUI for D
Am 03.12.2011, 07:14 Uhr, schrieb Alexey Prokhin : 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.
Re: Java > Scala -> new thread: GUI for D
"Gour" wrote in message news:20111203075455.6d9d1...@atmarama.noip.me... >"Nick Sabalausky" wrote: > >> I agree the look of apps should be user-configurable, but that >> belongs at the OS/Window-Manager level. 'Course, I'll grant that's >> never going to happen on MS or Apple platforms, in which case, yea, >> using a lib that makes "system" the default and "user-configured" an >> option is the next best thing. > >I fully agree with things which you said above...not liking this >mobile/web hype pushed to us at the moment. > >Just, curious what would be your choise for multi-platform GU app: gtk, >qt or wx? > My ranking would be: #1: wx: Because it uses native controls on pretty much all platforms. #2: qt: Because for a non-native UI, it at least does a good job of getting the look & feel right. And I've heard that the API is nice. . . . #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome.
Re: Java > Scala -> new thread: GUI for D
"Nick Sabalausky" wrote in message news:jbdp5t$2j0k$1...@digitalmars.com... > "Gour" wrote in message > news:20111203075455.6d9d1...@atmarama.noip.me... >>"Nick Sabalausky" wrote: >> >>> I agree the look of apps should be user-configurable, but that >>> belongs at the OS/Window-Manager level. 'Course, I'll grant that's >>> never going to happen on MS or Apple platforms, in which case, yea, >>> using a lib that makes "system" the default and "user-configured" an >>> option is the next best thing. >> >>I fully agree with things which you said above...not liking this >>mobile/web hype pushed to us at the moment. >> >>Just, curious what would be your choise for multi-platform GU app: gtk, >>qt or wx? >> > > My ranking would be: > > #1: wx: Because it uses native controls on pretty much all platforms. > #2: qt: Because for a non-native UI, it at least does a good job of > getting the look & feel right. And I've heard that the API is nice. > . > . > . > #84,259,254: gtk: Because it doesn't give a rat's ass about native > anything, plus it's just plain ugly (read: big-n-chunky) on all platforms, > even Gnome. > FWIW, SWT would probably be somewhere in the top 3, definitely above qt (because I *think* SWT is true native...?), but not sure how I'd rank it compared to wx b/c I'd have to actually try them both out.
Re: Java > Scala -> new thread: GUI for D
Am 03.12.2011, 19:20 Uhr, schrieb Nick Sabalausky : "Nick Sabalausky" wrote in message news:jbdp5t$2j0k$1...@digitalmars.com... "Gour" wrote in message news:20111203075455.6d9d1...@atmarama.noip.me... "Nick Sabalausky" wrote: I agree the look of apps should be user-configurable, but that belongs at the OS/Window-Manager level. 'Course, I'll grant that's never going to happen on MS or Apple platforms, in which case, yea, using a lib that makes "system" the default and "user-configured" an option is the next best thing. I fully agree with things which you said above...not liking this mobile/web hype pushed to us at the moment. Just, curious what would be your choise for multi-platform GU app: gtk, qt or wx? My ranking would be: #1: wx: Because it uses native controls on pretty much all platforms. #2: qt: Because for a non-native UI, it at least does a good job of getting the look & feel right. And I've heard that the API is nice. . . . #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome. FWIW, SWT would probably be somewhere in the top 3, definitely above qt (because I *think* SWT is true native...?), but not sure how I'd rank it compared to wx b/c I'd have to actually try them both out. As far as I understood it SWT was written for Eclipse. It may fall behind the other toolkits in terms of features and it is written in Java, so using it means a true D reimplementation of the API unless someone already did a C port. I think the small and native aspect made it a good candidate for inclusion into Phobos in the past. The much other toolkits are just too big. We may all have good eyes and such, but maybe the accessibility aspect should also be considered in this discussion.
Re: Java > Scala -> new thread: GUI for D
On Sat, 3 Dec 2011 13:20:49 -0500 "Nick Sabalausky" 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 -- The senses are so strong and impetuous, O Arjuna, that they forcibly carry away the mind even of a man of discrimination who is endeavoring to control them. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Java > Scala -> new thread: GUI for D
On Sat, 3 Dec 2011 13:16:14 -0500 "Nick Sabalausky" wrote: > My ranking would be: > > #1: wx: Because it uses native controls on pretty much all platforms. > #2: qt: Because for a non-native UI, it at least does a good job of > getting the look & feel right. And I've heard that the API is nice. Thank you...I'm also moving towards wx. > . > #84,259,254: gtk: Because it doesn't give a rat's ass about native > anything, plus it's just plain ugly (read: big-n-chunky) on all > platforms, even Gnome. From where did you find that long int? :-) Sincerely, Gour -- Never was there a time when I did not exist, nor you, nor all these kings; nor in the future shall any of us cease to be. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Java > Scala -> new thread: GUI for D
On Sat, 2011-12-03 at 13:16 -0500, Nick Sabalausky wrote: [...] A few thoughts based mainly from Python use perspective. > #1: wx: Because it uses native controls on pretty much all platforms. wxWidgets appears to have the need in the C++ API for the programmer to number each widget individually in order to access it, and the parameter passing gets messy. The wxPython API get around a lot of this by being able to do lots of dynamic binding and parameter passing tricks. wxWidgets and wxPython have licences amenable to being used for proprietary software without cost. > #2: qt: Because for a non-native UI, it at least does a good job of 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. C++ API is awkward compared to the PySide API, again because of dynamic binding and parameter tricks. PyQt has an unfriendly licence for anyone wishing to make proprietary systems. [...] > #84,259,254: gtk: Because it doesn't give a rat's ass about native 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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java > Scala -> new thread: GUI for D
> #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, > plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome. Using XFCE right now, looks fine to me.
Re: Java > Scala -> new thread: GUI for D
On 2011-12-02 17:38, Nick Sabalausky wrote: "Joshua Niehus" wrote in message news:mailman.1243.1322814889.24802.digitalmar...@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
Re: Java > Scala -> new thread: GUI for D
On 2011-12-02 19:15, Nick Sabalausky wrote: "Adam Wilson" wrote in message news:op.v5vibnca707...@invictus.skynet.com... On Fri, 02 Dec 2011 04:33:48 -0800, 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. This is similar in concept to how XAML in WPF/Silverlight is used to construct screens, and it's not bad idea. And the fact that the UX can be skinned to look nothing like the default OSUI is actually probably one of the most useful things about WPF and Silverlight. Yes, it doesn't look true to the OS, but you'll find that in the UI Design world, that is of surprisingly little importance. That's without a doubt my #1 complaint about desktop apps over the last decade: Narcissistic designers with nothing but contempt for a user's control over their own system. The most important thing to a UI designer is that the UI looks and works the same across *ALL* OS's. That's just terrible. Facebook looks and works the same regardless of whether I pull it up in Chrome or Firefox, Mac or Linux. The hell with mobile, eh? Making things look and act the same on everything is *terrible* UI design. Making things look and act *appropriate* for the given platform has alwas been and will always be the proper thing to do regardless of what the majority of designers decide is the trend du jour (ok, so that's redundant, so sue me ;) ). I agree. I hate that applications invent their own GUI widgets when there already exist perfectly usable widgets. These new widgets never work or look as good as the native ones. -- /Jacob Carlborg
Re: Java > Scala -> new thread: GUI for D
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
Re: Java > Scala -> new thread: GUI for D
On 2011-12-03 19:20, Nick Sabalausky wrote: "Nick Sabalausky" wrote in message news:jbdp5t$2j0k$1...@digitalmars.com... "Gour" wrote in message news:20111203075455.6d9d1...@atmarama.noip.me... "Nick Sabalausky" wrote: I agree the look of apps should be user-configurable, but that belongs at the OS/Window-Manager level. 'Course, I'll grant that's never going to happen on MS or Apple platforms, in which case, yea, using a lib that makes "system" the default and "user-configured" an option is the next best thing. I fully agree with things which you said above...not liking this mobile/web hype pushed to us at the moment. Just, curious what would be your choise for multi-platform GU app: gtk, qt or wx? My ranking would be: #1: wx: Because it uses native controls on pretty much all platforms. #2: qt: Because for a non-native UI, it at least does a good job of getting the look& feel right. And I've heard that the API is nice. . . . #84,259,254: gtk: Because it doesn't give a rat's ass about native anything, plus it's just plain ugly (read: big-n-chunky) on all platforms, even Gnome. FWIW, SWT would probably be somewhere in the top 3, definitely above qt (because I *think* SWT is true native...?), but not sure how I'd rank it compared to wx b/c I'd have to actually try them both out. SWT uses native widgets where available and emulates them otherwise. -- /Jacob Carlborg
Re: Java > Scala -> new thread: GUI for D
On 2011-12-03 19:34, Marco Leise wrote: Am 03.12.2011, 19:20 Uhr, schrieb Nick Sabalausky : 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
Re: Java > Scala -> new thread: GUI for D
"Russel Winder" wrote in message news:mailman.1300.1322991626.24802.digitalmar...@puremagic.com... On Sat, 2011-12-03 at 13:16 -0500, Nick Sabalausky wrote: >[...] > >A few thoughts based mainly from Python use perspective. > >> #1: wx: Because it uses native controls on pretty much all platforms. > >wxWidgets appears to have the need in the C++ API for the programmer to >number each widget individually in order to access it, and the parameter >passing gets messy. The wxPython API get around a lot of this by being >able to do lots of dynamic binding and parameter passing tricks. >wxWidgets and wxPython have licences amenable to being used for >proprietary software without cost. I hven't looked at the wxWidgets API, I would think that could easily be hidden by a good wrapper even without any fancy tricks (maybe wxD already does that? I don't know. I haven't gotten around to trying any GUI in D yet). I'm thinking basic bindings in deimos, and then paper over the rough spots in a separate package that wraps it with a revamped API. >> #2: qt: Because for a non-native UI, it at least does a good job of >> getting >> the look & feel right. And I've heard that the API is nice. > >Qt4 and PySide appear to have good cross-platform capabilities, but >clearly look like Qt applications on all platforms. I'm not doubting you, but it's strange that I of all people (ie, Mr. Native-or-Die ;) ) haven't noticed. My copy of Arora on Windows (v0.11.0) looks indistinguishable from native to me, and it reports using Qt 4.7.1. Do you have specific examples of differences? Hmm, well, I admit the scroll bars in Arora fail to use my system color theme, but I always assumed that was just Arora trying to emulate IE's questionable "web-page-specified scroll bar colors" feature, with an incorrect default setting. The scroll bars in the "Show All Bookmarks" window look right. >PyQt has an unfriendly licence for anyone wishing to >make proprietary systems. I didn't know that. Do you know if that's specific to PyQt, or inhereted from Qt? >[...] >> #84,259,254: gtk: Because it doesn't give a rat's ass about native >> anything, >> plus it's just plain ugly (read: big-n-chunky) on all platforms, even >> Gnome. > >GTKmm is not that bad. PyGTK makes it very much nicer. On Gnome GTK >stuff looks fine. Doesn't port well to OS X and Windows though, which >is why most people plump for Qt. What I meant about Gnome is just that, IMO, everthing on Gnome looks all big-n-chunky with way too much padding. YMMV.
Re: Java > Scala -> new thread: GUI for D
"Jacob Carlborg" 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."
Re: Java > Scala -> new thread: GUI for D
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
Re: Java > Scala -> new thread: GUI for D
"Jacob Carlborg" wrote in message news:jbfmq4$rkc$2...@digitalmars.com... > On 2011-12-02 17:38, Nick Sabalausky wrote: >> "Joshua Niehus" wrote in message >> news:mailman.1243.1322814889.24802.digitalmar...@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.
Re: Java > Scala -> new thread: GUI for D
On Sun, 2011-12-04 at 12:00 -0500, Nick Sabalausky wrote: [...] > >PyQt has an unfriendly licence for anyone wishing to > >make proprietary systems. > > I didn't know that. Do you know if that's specific to PyQt, or inhereted > from Qt? As David pointed out, PyQt stayed GPL and commercial licence when Qt went to LGPL and commercial licence. People with money can just pay for the commercial licences of course, but the fact that PyQt didn't switch to LGPL when Qt did annoyed a lot of people. Sifficient to start teh PySide project. [...] > What I meant about Gnome is just that, IMO, everthing on Gnome looks all > big-n-chunky with way too much padding. YMMV. It depends on the engine you use. For Gnome 2 I used thinice which gets rid of all the chunkyness. For Gnome 3 I am using Adwaita which is a bit chunkier but not too much so -- and I am a person who thinks that chunkyness is anathema not just a bad thing. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java > Scala -> new thread: GUI for D
"Russel Winder" wrote in message news:mailman.1305.1323019362.24802.digitalmar...@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.
Re: Java > Scala -> new thread: GUI for D
On 2011-12-04 18:00, Nick Sabalausky wrote: "Russel Winder" wrote in message news:mailman.1300.1322991626.24802.digitalmar...@puremagic.com... On Sat, 2011-12-03 at 13:16 -0500, Nick Sabalausky wrote: [...] A few thoughts based mainly from Python use perspective. #1: wx: Because it uses native controls on pretty much all platforms. wxWidgets appears to have the need in the C++ API for the programmer to number each widget individually in order to access it, and the parameter passing gets messy. The wxPython API get around a lot of this by being able to do lots of dynamic binding and parameter passing tricks. wxWidgets and wxPython have licences amenable to being used for proprietary software without cost. I hven't looked at the wxWidgets API, I would think that could easily be hidden by a good wrapper even without any fancy tricks (maybe wxD already does that? I don't know. I haven't gotten around to trying any GUI in D yet). I'm thinking basic bindings in deimos, and then paper over the rough spots in a separate package that wraps it with a revamped API. #2: qt: Because for a non-native UI, it at least does a good job of getting the look& feel right. And I've heard that the API is nice. Qt4 and PySide appear to have good cross-platform capabilities, but clearly look like Qt applications on all platforms. I'm not doubting you, but it's strange that I of all people (ie, Mr. Native-or-Die ;) ) haven't noticed. My copy of Arora on Windows (v0.11.0) looks indistinguishable from native to me, and it reports using Qt 4.7.1. Do you have specific examples of differences? Hmm, well, I admit the scroll bars in Arora fail to use my system color theme, but I always assumed that was just Arora trying to emulate IE's questionable "web-page-specified scroll bar colors" feature, with an incorrect default setting. The scroll bars in the "Show All Bookmarks" window look right. PyQt has an unfriendly licence for anyone wishing to make proprietary systems. I didn't know that. Do you know if that's specific to PyQt, or inhereted from Qt? Qt is licensed under GPL, LGPL and a commercial license. -- /Jacob Carlborg
Re: Java > Scala -> new thread: GUI for D
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
Re: Java > Scala -> new thread: GUI for D
"Jacob Carlborg" 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.
Re: Java > Scala -> new thread: GUI for D
On 2011-12-04 21:13, Nick Sabalausky wrote: "Jacob Carlborg" 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
Re: Java > Scala -> new thread: GUI for D
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).
Re: Java > Scala -> new thread: GUI for D
Am 04.12.2011 12:50, schrieb Jacob Carlborg: > On 2011-12-02 17:38, Nick Sabalausky wrote: >> "Joshua Niehus" wrote in message >> news:mailman.1243.1322814889.24802.digitalmar...@puremagic.com... On 12/1/11 2:59 AM, Walter Bright wrote: > On 12/1/2011 2:42 AM, Gour wrote: > I'd like to help with GUI bindings if D community would come more > close > together here with some people ready to lead the herd... Why not you lead the effort? >>> >>> I just went to the Qt DevDays 2011 and it looks like a lot of >>> work is >>> being done to get QML ready for desktop applications. Its Qt's next >>> gen UI >>> framework and its JavaScript based (it looks pretty good). >> >> Ewww, why are so many organiations trying to put JS on the desktop? >> There's >> that, Win8, Flex, etc. It's such an abomination. Completely backwards. >> What's needed is for proper desktop technologies to take over the web, >> not >> the other way around. I can't beleve the spawn of what had long been >> dubbed >> "Nutscrape" has become, and is still becoming, so prolific. > > I completely agree, JavaScript is quite a horrible language. > Yes it is - but did you ever tried haXe ? IMO it is the best cross platform language around - you target JavaScript, Flash, PHP, NEKO, C++ and soon Java and C# with one language. Typesafe with type inference, compiled and code completion support from the compiler.
Re: Java > Scala -> new thread: GUI for D
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
Re: Java > Scala -> new thread: GUI for D
On 2011-12-05 08:17, Adrian wrote: Yes it is - but did you ever tried haXe ? IMO it is the best cross platform language around - you target JavaScript, Flash, PHP, NEKO, C++ and soon Java and C# with one language. Typesafe with type inference, compiled and code completion support from the compiler. I have looked at haxe but to me it just basically looks like Java. I think CoffeeScript is better, has a less verbose syntax. Although static typing would be nice to have sometimes. -- /Jacob Carlborg
Re: Java > Scala -> new thread: GUI for D
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
Re: Java > Scala -> new thread: GUI for D
Am 05.12.2011 09:17, schrieb Jacob Carlborg: > On 2011-12-05 08:17, Adrian wrote: >> Yes it is - but did you ever tried haXe ? IMO it is the best cross >> platform language around - you target JavaScript, Flash, PHP, NEKO, C++ >> and soon Java and C# with one language. Typesafe with type inference, >> compiled and code completion support from the compiler. > > I have looked at haxe but to me it just basically looks like Java. I > think CoffeeScript is better, has a less verbose syntax. Although static > typing would be nice to have sometimes. > I wouldn't compare it to Java and I wouldn't say its verbose either, its expressiveness is close to D . It is a full dynamic language with all the benefit and safety of static typing through type inference. You can use it object oriented or functional. It has a fantastic remoting framework with type checking at compile time! cross platform - no other language has this to offer. CoffeeScript is just a JavaScript alternative without a real benefit. HaXe is a complete framework.
Re: Java > Scala -> new thread: GUI for D
On 2011-12-05 10:24, Adrian wrote: Am 05.12.2011 09:17, schrieb Jacob Carlborg: On 2011-12-05 08:17, Adrian wrote: Yes it is - but did you ever tried haXe ? IMO it is the best cross platform language around - you target JavaScript, Flash, PHP, NEKO, C++ and soon Java and C# with one language. Typesafe with type inference, compiled and code completion support from the compiler. I have looked at haxe but to me it just basically looks like Java. I think CoffeeScript is better, has a less verbose syntax. Although static typing would be nice to have sometimes. I wouldn't compare it to Java and I wouldn't say its verbose either, its expressiveness is close to D . It is a full dynamic language with all the benefit and safety of static typing through type inference. You can use it object oriented or functional. It has a fantastic remoting framework with type checking at compile time! cross platform - no other language has this to offer. CoffeeScript is just a JavaScript alternative without a real benefit. HaXe is a complete framework. I think the benefit is that CoffeeScript has a better syntax and better features (compared to JavaScript). Well, CoffeeScript isn't supposed to have any runtime or similar. It's compiled into standard JavaScript without needing any extra runtime methods. -- /Jacob Carlborg
Re: Java > Scala -> new thread: GUI for D
"Somedude" 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.
Re: Java > Scala -> new thread: GUI for D
On 2011-12-05 18:05, Nick Sabalausky wrote: "Somedude" 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
Re: Java > Scala -> new thread: GUI for D
"Jacob Carlborg" wrote in message news:jbj0lo$mec$1...@digitalmars.com... > On 2011-12-05 18:05, Nick Sabalausky wrote: >> "Somedude" 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.
Re: Java > Scala -> new thread: GUI for D
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...
Haxe (From: Java > Scala -> new thread: GUI for D)
"Adrian" wrote in message news:jbhr5j$1n9t$1...@digitalmars.com... > > Yes it is - but did you ever tried haXe ? IMO it is the best cross > platform language around - you target JavaScript, Flash, PHP, NEKO, C++ > and soon Java and C# with one language. Typesafe with type inference, > compiled and code completion support from the compiler. Haxe is great. The documentation isn't always so good, the language itself could admittedly be better (it absolutely pales in comparison to D, but then, so do most languages), but it's better than JavaScript, and it absolutely beats the SHIT of out of AS2 and PHP (as much as I hate JS, my hatred towards PHP, FlashIDE and AS2 is at least 10x that). The main "real world work" project I've been working on for awhile has had requirements of Flash, and shared web hosting (which generally implies PHP). The Flash requirement is due to things that JS just can't handle well even now, and definitely couldn't have handled back at the project's start. Very early on, I switched development from PHP/AS2 to Haxe and have never looked back. In that project, Haxe's ability to compile the same code, in the same language, down to both server-side (PHP) and client-side (Flash8) has been an *enormous* benefit. Just that one ability alone, even without the fact that Haxe beats the snot of out both AS2 and PHP. I also use a slightly-hacked version of the HaxeIgniter framework (could be better, but it's not bad and it gets the job done). That said, I have been chomping at the bit to switch to D (and Adam's clever web framework) for my server-side code. I've pretty much managed to convince my client to eventually let us switch to a host that allows native-compiled CGI. The only problem now is that that would rule out the possibility of sharing code between both server and client - Which is *NOT* something I want to give up... : So to that end, you mentioned Java and C# targets are coming to Haxe? Well, so is D... :) HaxeD: http://www.dsource.org/projects/haxed It's not at a usable point just yet, but the basics are in place, and at this point it's mostly just a matter of continuing to translate each of the different types of statements, expressions, declarations, etc. Details of the current status are on that homepage. (Haxe's macro system is a low priority for me right now though, unless someone else wants to work on that). Why did I write the whole thing from scratch in D as a separate tool, instead of just adding D support to the official Haxe codebase? Ehh, possibly-questionable reasons: 1. Because I looked at Haxe's source and decided I didn't feel like figuring out OCaml before getting started :/ 2. I already have a parsing framework in D ( http://www.semitwist.com/goldie/ ) and figured dogfooding would be a good idea.
javascript (was Re: Java > Scala -> new thread: GUI for D)
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-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";
}
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.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
> In that project, Haxe's ability to compile the same code, in the same > language, down to both server-side (PHP) and client-side (Flash8) has been > an *enormous* benefit. That's what Google Web Toolkit makes possible for Java. It's like SWT for WEB plus easy connections to server.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Nick Sabalausky Wrote: > The only problem now is that that would rule out the possibility of > sharing code between both server and client - Which is *NOT* something I > want to give up... What kind of code is it? The main reason for the javascript api thing in my web.d is to help minimize the pain of duplication, by keeping it all on the server, but still having easy client side interface. Then basically your js is just event glue to various server side functions. Of course, it keeps the JS down to size... but doesn't actually let you run code on the client written in D.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Adam Ruppe Wrote: > Of course, it keeps the JS down to size... but doesn't actually let you > run code on the client written in D. Unless your client is a real application, of course :P I did a Qt app using the modules from a work web app earlier in the year. I interfaced with Qt via a message passing layer which converted signals and slots into C calls - which were implemented in D. So, new widgets would be written in C++ (QtD was close but not quite good enough for me to use), but the core was still D.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
"Adam Ruppe" wrote in message news:jbj23n$p68$1...@digitalmars.com... > Nick Sabalausky Wrote: >> The only problem now is that that would rule out the possibility of >> sharing code between both server and client - Which is *NOT* something I >> want to give up... > > What kind of code is it? Flash. A demo of it is here: www.attentionworkout.com (Pardon the voiceovers, that's a requirement that's outside of my control.) Basically, there's a series of "activities" that are (by necessity) Flash SWFs (but written in Haxe). These activities collect as much performance information as possible (including various timings, and in the case of the Radio, a log with enough info to "play back" the performance and re-interpret it however desired.) The whole thing was designed to be used in clinical trials on the elderly (which it's currently going through), so data collection/analysis, correctness/reliability, and compatibility were important concerns. (And naturally, flashiness and polish were lower priorities, which is why it...umm...doesn't exactly compete with PopCap in those regards.) For the most part, the shared PHP-server/Flash-client code is things like: - Data structures for all the results data. - Various utility functions (Such as a lerp function. And a string->int function that actually works consistently on server/client and doesn't have the other weirdness of Haxe's built-in string->int. And other such util funcs that's aren't in Haxe's std lib). - Identifiers for and URL-building for various URLs involved in the program. Even the flash apps need to refer to specific URLs now and then. - Much of the code in the custom error-notification system (which automatically logs and emails us about things like unhandled exceptions in both the server and client-side code). This includes the Exception classes. The client version will notify the server instead of recording to log/DB/email directly, but other than that it's mostly the same code on both sides. - The code which takes a log of exactly what happened (and when) during the Radio activity, and gives it an accuracy ranking between 0% - 100%. This, of course, needs to be consistent in both PHP and Flash. We could just simply record the 0% - 100% result the flash app shows to the user, but then we'd lose the ability to re-analyze the old performace data if we decide we want to change the algorithm (well, we *could*, but we'd be forced to do it in flash). Basically the shared code, aside from reducing duplication (which has well-known problems), helps to keep simple things simple, helps with consistentcy, and helps us keep our options open (hell, at some point I could probably even make it work on an iOS browser without rewriting all the client code). > The main reason for the javascript > api thing in my web.d is to help minimize the pain of duplication, > by keeping it all on the server, but still having easy client side > interface. > > Then basically your js is just event glue to various server side > functions. > > > Of course, it keeps the JS down to size... but doesn't actually let you > run code on the client written in D. Yea, actually, I don't use Haxe for JS at all. Like you, I prefer keep my JS usage minimal and hand-tuned, and don't want to pull in a ton of JS libs just to do simple DHTML tricks. (Of course, once JS/HTML5 advance to a point where they can be used as an alternative to Flash, then I'd be more likely to use Haxe->JS for those purposes.)
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Am 05.12.2011 18:56, schrieb Nick Sabalausky: > In that project, Haxe's ability to compile the same code, in the same > language, down to both server-side (PHP) and client-side (Flash8) has been > an *enormous* benefit. Just that one ability alone, even without the fact > that Haxe beats the snot of out both AS2 and PHP. I also use a > slightly-hacked version of the HaxeIgniter framework (could be better, but > it's not bad and it gets the job done). > > That said, I have been chomping at the bit to switch to D (and Adam's clever > web framework) for my server-side code. I've pretty much managed to convince > my client to eventually let us switch to a host that allows native-compiled > CGI. The only problem now is that that would rule out the possibility of > sharing code between both server and client - Which is *NOT* something I > want to give up... > That is exactly my point. HaXe' s ability to share the same code on client and server side is one of it's killer features. Together with a increasing number of target languages it fits almost everywhere. Currently I use the following setup for my development: - a web and database server written in pascal (Delphi) - all server modules written in haXe/neko - client - server communication via haXe - GUI client modules written either in Delphi with a small neko layer for the communication, or in haXe/Javascript in an embedded browser. > : > > So to that end, you mentioned Java and C# targets are coming to Haxe? Well, > so is D... :) > > HaxeD: http://www.dsource.org/projects/haxed > interesting - the last time I looked, I thought the project is abandoned. > It's not at a usable point just yet, but the basics are in place, and at > this point it's mostly just a matter of continuing to translate each of the > different types of statements, expressions, declarations, etc. Details of > the current status are on that homepage. (Haxe's macro system is a low > priority for me right now though, unless someone else wants to work on > that). > > Why did I write the whole thing from scratch in D as a separate tool, > instead of just adding D support to the official Haxe codebase? Ehh, > possibly-questionable reasons: > > 1. Because I looked at Haxe's source and decided I didn't feel like figuring > out OCaml before getting started :/ > yes OCaml is another beast. My idea was to take the source of Hugh Sandersons C++ target and adopt it to D. For me, D is a much more logical target for haXe, because many of the language features fit better together. The problem I see with your solution is, that haXe evolves very fast and a D target written in OCaml would benefit from this, whereas a target written in D is always behind. The last few months I am looking at D as a replacement for Delphi at least at the server side (which would be a major task rewriting the database server), but I am twisted at the moment, because I am not sure if D is mature enough ( and/or me good enough to master if not).
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
"Adrian" wrote in message news:jbkkpf$cut$1...@digitalmars.com... > Am 05.12.2011 18:56, schrieb Nick Sabalausky: > >> In that project, Haxe's ability to compile the same code, in the same >> language, down to both server-side (PHP) and client-side (Flash8) has >> been >> an *enormous* benefit. Just that one ability alone, even without the fact >> that Haxe beats the snot of out both AS2 and PHP. I also use a >> slightly-hacked version of the HaxeIgniter framework (could be better, >> but >> it's not bad and it gets the job done). >> >> That said, I have been chomping at the bit to switch to D (and Adam's >> clever >> web framework) for my server-side code. I've pretty much managed to >> convince >> my client to eventually let us switch to a host that allows >> native-compiled >> CGI. The only problem now is that that would rule out the possibility of >> sharing code between both server and client - Which is *NOT* something I >> want to give up... >> > > That is exactly my point. HaXe' s ability to share the same code on > client and server side is one of it's killer features. Absolutely! >> : >> >> So to that end, you mentioned Java and C# targets are coming to Haxe? >> Well, >> so is D... :) >> >> HaxeD: http://www.dsource.org/projects/haxed >> > > interesting - the last time I looked, I thought the project is abandoned. > Nah, I'm pretty hell-bent on getting this working[1]. It's just that sometimes real-world gets in the way. But I plan to use this for my main real-world project, so that's helping keep the priority up. [1] ...Unless I could get Dax (ie, D -> Haxe) working before finishing HaxeD, which I would have preferred, but that's definitely not going to happen: I've decided to put Dax on indefinite hold b/c it's a *much* more difficult problem: partly because D's features are more-or-less a superset of Haxe's, and partly b/c Dax is currently based on DDMD which has proven to be an unsustainable approach to accessing DMD from D. >> >> Why did I write the whole thing from scratch in D as a separate tool, >> instead of just adding D support to the official Haxe codebase? Ehh, >> possibly-questionable reasons: >> >> 1. Because I looked at Haxe's source and decided I didn't feel like >> figuring >> out OCaml before getting started :/ >> > > yes OCaml is another beast. My idea was to take the source of Hugh > Sandersons C++ target and adopt it to D. For me, D is a much more > logical target for haXe, because many of the language features fit > better together. The problem I see with your solution is, that haXe > evolves very fast and a D target written in OCaml would benefit from > this, whereas a target written in D is always behind. > Yea, that is definitely the downside of my approach. OTOH, Haxe still doesn't evolve as fast as, say, D. And I'm optimistic that once I have it 100% working, updates shouldn't be too difficult. Most of the changes in each Haxe release are either in the std lib, neko-related, or bug-fixes, none of which would be applicable to HaxeD (as far as the std lib, HaxeD will have a copy of the std lib that may add some "#if d" directives where applicable, and those would need to get merged wih each Haxe release, but that shouldn't be too hard). > The last few months I am looking at D as a replacement for Delphi at > least at the server side (which would be a major task rewriting the > database server), but I am twisted at the moment, because I am not sure > if D is mature enough ( and/or me good enough to master if not). > Personally, I think it is. FWIW.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
"Nick Sabalausky" wrote in message
news:jblhn8$1vis$1...@digitalmars.com...
> "Adrian" wrote in message
> news:jbkkpf$cut$1...@digitalmars.com...
>> Am 05.12.2011 18:56, schrieb Nick Sabalausky:
>>>
>>> Why did I write the whole thing from scratch in D as a separate tool,
>>> instead of just adding D support to the official Haxe codebase? Ehh,
>>> possibly-questionable reasons:
>>>
>>> 1. Because I looked at Haxe's source and decided I didn't feel like
>>> figuring
>>> out OCaml before getting started :/
>>>
>>
>> yes OCaml is another beast. My idea was to take the source of Hugh
>> Sandersons C++ target and adopt it to D. For me, D is a much more
>> logical target for haXe, because many of the language features fit
>> better together. The problem I see with your solution is, that haXe
>> evolves very fast and a D target written in OCaml would benefit from
>> this, whereas a target written in D is always behind.
>>
>
> Yea, that is definitely the downside of my approach. OTOH, Haxe still
> doesn't evolve as fast as, say, D. And I'm optimistic that once I have it
> 100% working, updates shouldn't be too difficult. Most of the changes in
> each Haxe release are either in the std lib, neko-related, or bug-fixes,
> none of which would be applicable to HaxeD (as far as the std lib, HaxeD
> will have a copy of the std lib that may add some "#if d" directives where
> applicable, and those would need to get merged wih each Haxe release, but
> that shouldn't be too hard).
>
There is another upside to my approach, though: It gives me the ability to
add optional features without Cannasse's approval. Sometimes he can
be...(how can I say this diplomatically?)...a bit stubborn in refusing to
even consider or discuss reasonable requests. He seems to like his "Denied
Because I Said So" stamp ;). Couple off the top of my head examples:
http://code.google.com/p/haxe/issues/detail?id=106 Forum thread links have
JS that screws up "open link in new tab/window"
http://code.google.com/p/haxe/issues/detail?id=105 Assigning from a Dynamic
silently subverts type system and corrupts var.
Note that first one, #106, is NOT my usual "X requires JS" complaint. This
is something that breaks standard browser behavior *with* JS on, and is a
trivial fix with no downside (at least none that he was willing to actually
share). Of course, that's just unrelated website stuff, but...
That #105 in particular is pretty nasty. Haxe supports static typing and
also has a Dynamic type. But take a look at this:
var dyn:Dynamic = "foo";
var i:Int; // Statically-typed **INTEGER**!!
i = dyn;
Guess what? Not only does the compiler accept that, but there is no
runtime-check either. My *statically-typed integer* now contains a *string*
("foo")!! Yes, seriously. And with *no* explicit casts or "unsafe" or
anything. Of course, the fun doesn't stop there:
dyn = "5";
i = dyn;
i += 10; // Looks like integer addition
trace(i); // Wheee!!! Output: 510
Granted, one could argue that you should be able to this without any
run-time baggage if you chose to (for instance, if you *know* that dyn is
really an Int). But Haxe ALREADY has "Unsafe Cast" which DOES EXACTLY THAT!:
// From the official docs on Unsafe Cast:
// "...the cast call will not result in any runtime check,
// but will allow you to "loose" one type."
i = cast dyn;
After I explained all of that to commenters #1 and #3, Cannasse pulled out
his "Denied" stamp along with a message that clearly misunderstood much of
the issue.
So anyway, with my own Haxe implementation, I can just add an optional
"-sane" switch to enable either a runtime or compile-time check...And nobody
can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA!@!!!
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Am 06.12.2011 18:00, schrieb Nick Sabalausky: > "Adrian" wrote in message > news:jbkkpf$cut$1...@digitalmars.com... >> Am 05.12.2011 18:56, schrieb Nick Sabalausky: >> >>> CGI. The only problem now is that that would rule out the possibility of >>> sharing code between both server and client - Which is *NOT* something I >>> want to give up... >>> >> >> That is exactly my point. HaXe' s ability to share the same code on >> client and server side is one of it's killer features. > > Absolutely! > >>> : >>> >>> So to that end, you mentioned Java and C# targets are coming to Haxe? >>> Well, >>> so is D... :) >>> >>> HaxeD: http://www.dsource.org/projects/haxed >>> >> >> interesting - the last time I looked, I thought the project is abandoned. >> > > Nah, I'm pretty hell-bent on getting this working[1]. It's just that > sometimes real-world gets in the way. But I plan to use this for my main > real-world project, so that's helping keep the priority up. > > [1] ...Unless I could get Dax (ie, D -> Haxe) working before finishing > HaxeD, which I would have preferred, but that's definitely not going to > happen: I've decided to put Dax on indefinite hold b/c it's a *much* more > difficult problem: partly because D's features are more-or-less a superset > of Haxe's, and partly b/c Dax is currently based on DDMD which has proven to > be an unsustainable approach to accessing DMD from D. > > IMHO haXe->D is more interesting than D->haXe. [OT] As a side point from a not yet D developer, but someone who looks at the language with great interest, but also someone with a commercial responsibility: I am missing big projects developed in D and the most logic project would be the compiler itself! I know this has been discussed a million times before, but... >>> >>> Why did I write the whole thing from scratch in D as a separate tool, >>> instead of just adding D support to the official Haxe codebase? Ehh, >>> possibly-questionable reasons: >>> >>> 1. Because I looked at Haxe's source and decided I didn't feel like >>> figuring >>> out OCaml before getting started :/ >>> >> >> yes OCaml is another beast. My idea was to take the source of Hugh >> Sandersons C++ target and adopt it to D. For me, D is a much more >> logical target for haXe, because many of the language features fit >> better together. The problem I see with your solution is, that haXe >> evolves very fast and a D target written in OCaml would benefit from >> this, whereas a target written in D is always behind. >> > > Yea, that is definitely the downside of my approach. OTOH, Haxe still > doesn't evolve as fast as, say, D. And I'm optimistic that once I have it > 100% working, updates shouldn't be too difficult. Most of the changes in > each Haxe release are either in the std lib, neko-related, or bug-fixes, > none of which would be applicable to HaxeD (as far as the std lib, HaxeD > will have a copy of the std lib that may add some "#if d" directives where > applicable, and those would need to get merged wih each Haxe release, but > that shouldn't be too hard). > The pro of this approach would be, that there is a second haXe implementation, even if it is bound only to D. The downside would be, that there is the risk of incompatibilities of the compilers, leading to 2 different dialects, which would force the users of both, only to use the subset of the languages. I have this situation on the object pascal side with freepascal and Delphi, which are very the same but still different. If you code for both, you can't use new language features (and "new" means sometimes many years) Reading your second post, I feel that the risk for the haXe language is real: > There is another upside to my approach, though: It gives me the ability to > add optional features without Cannasse's approval. Sometimes he can > be...(how can I say this diplomatically?)...a bit stubborn in refusing to > even consider or discuss reasonable requests. He seems to like his "Denied > Because I Said So" stamp . Couple off the top of my head examples: Yes it is sometimes frustrating when the leaders of certain development (like the Canasses, Brights, Alexandrescus etc.) seem to be stubborn in some cases. But I think otherwise we wouldn't have such nice developments like D or haXe and many others - they have to be! But the decision for a second haXe compiler shouldn't be driven by such feelings, even if I agree that: > var dyn:Dynamic = "foo"; > var i:Int; // Statically-typed **INTEGER**!! > i = dyn; should be compiled as: i = cast(dyn, Int); but it could be handled like that by the runtime as well. Dynamic languages like JS don't do it, but a D target could - even if implemented in OCaml. IMHO a way to avoid dynamics at all (at least reduce the need), would be much better! And here is haXe going in the right way with its macros. Most of the need for dynamics comes from accessing data from foreign sources like databases. If the structure of these
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Adrian Wrote: > [OT] As a side point from a not yet D developer, but someone who looks > at the language with great interest, but also someone with a commercial > responsibility: I am missing big projects developed in D and the most > logic project would be the compiler itself! I know this has been > discussed a million times before, but... How big is big? My app is up to about 75,000 lines of D2 (including my D libs), which isn't gigantic but it does a lot of things and needs to be ready for use and changes almost every day.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
"Adrian" wrote in message news:jbnmoo$2seg$1...@digitalmars.com... > > The downside would be, that there is the risk of incompatibilities of > the compilers, leading to 2 different dialects, which would force the > users of both, only to use the subset of the languages. I have this > situation on the object pascal side with freepascal and Delphi, which > are very the same but still different. If you code for both, you can't > use new language features (and "new" means sometimes many years) > That's true, but FWIW, I do intend to place a very strong emphasis on compatablity with the official Haxe. (It even accepts Haxe's command line params to the extent possible, and I plan to support .hxml files.) As far as any deliberate deviations (such as #105), such things will be purely optional. Anything else is to be considered a bug in HaxeD.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Am 07.12.2011 15:16, schrieb Adam Ruppe: > Adrian Wrote: >> [OT] As a side point from a not yet D developer, but someone who looks >> at the language with great interest, but also someone with a commercial >> responsibility: I am missing big projects developed in D and the most >> logic project would be the compiler itself! I know this has been >> discussed a million times before, but... > > How big is big? My app is up to about 75,000 lines of D2 (including my D > libs), > which isn't gigantic but it does a lot of things and needs to be ready > for use and changes almost every day. I meant a community driven project of course. And the only projects, which are useful for every D user and therefor have lot of contributers are the compiler itself and maybe an IDE with debugger.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Nick Sabalausky wrote: So anyway, with my own Haxe implementation, I can just add an optional "-sane" switch to enable either a runtime or compile-time check...And nobody can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA!@!!! HAHhahahaAHHAAHA - As a long time haXe user I appreciate this! :D But, have you looked at the new haXe macro output feature?: http://haxe.org/api/haxe/macro/jsgenapi You could write a D generator macro which acts as a JS target. Probably alot less work too. I find it unfortunate D -> haXe is so complex, as I'd much rather write my code in D. If only D was as multiplatform as haXe... :-(
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
"Danny Wilson" wrote in message news:jbrjp6$n54$1...@digitalmars.com... > Nick Sabalausky wrote: > >> So anyway, with my own Haxe implementation, I can just add an optional >> "-sane" switch to enable either a runtime or compile-time check...And >> nobody >> can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA!@!!! >> > > HAHhahahaAHHAAHA - As a long time haXe user I appreciate this! :D > Heh :) > But, have you looked at the new haXe macro output feature?: > http://haxe.org/api/haxe/macro/jsgenapi > > You could write a D generator macro which acts as a JS target. Probably > alot less work too. > I'm happy with the progress I'm making so far on with my approach, but that is an interesting idea. > I find it unfortunate D -> haXe is so complex, as I'd much rather write my > code in D. If only D was as multiplatform as haXe... :-( Yes, me too. Definitely. I would still like to get around to that sometime. This Haxe->D will probably help give me some good language converstion experience, though.
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
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-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";
}
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
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
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.
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
"Jacob Carlborg" 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.
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
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
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
On 2011-12-05 07:59, Nick Sabalausky wrote: "Jacob Carlborg" 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
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
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
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
Am 04.12.2011, 21:17 Uhr, schrieb Adam D. Ruppe
:
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.
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
On 2011-12-05 10:10, Marco Leise wrote:
Am 04.12.2011, 21:17 Uhr, schrieb Adam D. Ruppe
:
Jacob Carlborg Wrote:
If you like the idea there, but want something a lot more conservative,
in my html.d (in here:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
)
there's now a JavascriptMacroExpander class which pre-processes
javascript.
The only build in function it provides right now is foreach() (just
because I find
it's lack to be the easiest thing to take care of...) but the macro
system might
be useful too for certain things.
Again, it's just a preprocessor, so you drop stuff like this into the
middle of
regular js code:
¤foreach(element; document.querySelectorAll("p")) {
element.style.color = "red";
}
converts to
var arsd_foreach_loop_temporary_2 = document.querySelectorAll("p");
for(var arsd_foreach_loop_counter_1 = 0; arsd_foreach_loop_counter_1 <
arsd_foreach_loop_temporary_2.length; arsd_foreach_loop_counter_1++) {
var element = arsd_foreach_loop_temporary_2[arsd_foreach_loop_counter_1];
element.style.color = "red";
}
There is also this macro in the JavaScript plugin for Eclipse:
for (var ${index} = 0; ${index} < ${array}.length; ${index}++) {
var ${array_element} = ${array}[${index}];
${cursor}
}
This is really one of the largest shortcomings of the language that can
not be explained with a simple design choice.
CoffeeScript makes it a correct for-each loop:
for e in arr
# do something with the element "e"
--
/Jacob Carlborg
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
Jacob Carlborg Wrote: > for e in arr > # do something with the element "e" Heh, I used to think that would work in regular Javascript, since it does have a for(blah in something) form... But in regular javascript, that only works on objects!
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
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.
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
On 2011-12-05 16:47, Adam Ruppe wrote:
Jacob Carlborg Wrote:
for e in arr
# do something with the element "e"
Heh, I used to think that would work in regular Javascript,
since it does have a for(blah in something) form...
But in regular javascript, that only works on objects!
Yeah, it's very annoying. CoffeeScript also has the following iteration
syntax:
for key, value of obj
# do something with key and value
Which compiles to:
for (k in obj) {
v = obj[k];
}
--
/Jacob Carlborg
Re: javascript (was Re: Java > Scala -> new thread: GUI for D)
On 2011-12-05 16:53, Adam Ruppe wrote:
Marco Leise Wrote:
This is really one of the largest shortcomings of the language that can
not be explained with a simple design choice.
Aye. One of the newer versions adds a forEach member to the
array prototype, that works like this:
[1, 2, 3].forEach(function(element) { use element here; });
but I don't like that style, personally. All those years of C
and friends have wired my brain to see it as being backward.
And, it doesn't work for everyone out of the box anyway.
That's the Ruby style, quite verbose in plain JavaScript. In
CoffeeScript it would look like:
[1, 2, 4].forEach (element) -> # use element here
--
/Jacob Carlborg
