www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can D be cute? (Qt)

reply Justin Johansson <no spam.com> writes:
A week or two ago I started a thread suggesting that JavaScript might be 
an interesting "VM" for D to target for web apps.  A thriving discussion 
ensured and it was a delight to read the opinions posted by many on this 
newsgroup.

The idea came out of a frustration I had with having to develop a rather 
complex application using browser-only technology, JavaScript being 
somewhat awkward to deal with the task at hand.  In the process of 
pondering the scalability of the programming task I looked to many 
different ways of circumventing programming plain old JavaScript and 
considered such things as Haxe, Cappuccino (Objective-J) and SproutCore. 
  Then it occurred to me everything I liked about D and had this fairy 
wish that D might be ideal for client side programming down to JS.

Since then, my client has gone completely off web apps for this 
particular Linux-embedded hand-held mobile device and has mandated that 
the apps will now be written as desktop apps in Qt.

Qt, as many of you will know, is a C++ GUI framework produced by 
formerly TrollTech and now acquired by Nokia for $xxx million (60 or 
160M I read somewhere).  So Nokia pays megabucks for a GUI framework 
that is C++ at its core.  Questions are, why is Qt worth so much to 
Nokia, why is Qt so damn popular on the Linux platform and what is the 
secret of Qt's success given that it is basically a C++ framework 
wrapped in some "meta-object compiler"?

Having now been exposed to Qt for a few weeks and beginning to 
understand its architecture of "signals and slots" and a pre-processor 
that compiles down to C++, I am now wondering whether D is powerful 
enough to achieve the same sorts of things that Qt seems to be doing.

If I understand correctly, Qt brings a degree of "reflection capability" 
to C++ amongst other things.  Qt does a tremendous job of circumventing 
the gaps in plain old C++ to achieve great goodness for GUI development 
by way of its meta-object compiler.

May I ask if others on this NG are across Qt and D might be capable of 
slotting into some of this market for cross-platform GUI development.

As always, discussions such as these can go anywhere and everywhere on 
DigitalMars D NG, and that's much of the joy in staying with this NG if 
only as a bystander at times.

Cheers and best regards to all,

Justin Johansson
May 08 2010
next sibling parent reply "Guillaume B." <guillaume.b.spam spam.ca> writes:
Justin Johansson wrote:


 
 May I ask if others on this NG are across Qt and D might be capable of
 slotting into some of this market for cross-platform GUI development.
 


 That would be QtD: http://www.dsource.org/projects/qtd

 Guillaume
May 08 2010
parent reply Justin Johansson <no spam.com> writes:
Guillaume B. wrote:

 Justin Johansson wrote:
 

 May I ask if others on this NG are across Qt and D might be capable of
 slotting into some of this market for cross-platform GUI development.


 
  That would be QtD: http://www.dsource.org/projects/qtd
 
  Guillaume


Hey thanks for the quick reply, Guillaume.

I understand from the project brief though that QtD is a "binding" to Qt.

"QtD is a D binding to the Qt application and UI framework."

Whilst QtD looks like a cool project, my question was really about 
whether D could achieve the same sorts of things that Qt does with its 
meta-object compiler.

In other words, and calling a spade a spade, Qt is a "hack" to make C++ 
more pleasant for GUI.  Would it be possible for D to achieve natively 
the same sorts that Qt does via preprocessing to C++.

Cheers

Justin Johansson
May 08 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson:

 Whilst QtD looks like a cool project, my question was really about 
 whether D could achieve the same sorts of things that Qt does with its 
 meta-object compiler.
 
 In other words, and calling a spade a spade, Qt is a "hack" to make C++ 
 more pleasant for GUI.  Would it be possible for D to achieve natively 
 the same sorts that Qt does via preprocessing to C++.


I suggest you to explain what such things are, and to give some examples too.

Bye,
bearophile
May 08 2010
parent reply Justin Johansson <no spam.com> writes:
bearophile wrote:

 Justin Johansson:

 Whilst QtD looks like a cool project, my question was really about 
 whether D could achieve the same sorts of things that Qt does with its 
 meta-object compiler.

 In other words, and calling a spade a spade, Qt is a "hack" to make C++ 
 more pleasant for GUI.  Would it be possible for D to achieve natively 
 the same sorts that Qt does via preprocessing to C++.


 
 I suggest you to explain what such things are, and to give some examples too.
 
 Bye,
 bearophile


Okay, perhaps not everybody here is across Qt.

Programming in Qt is almost C++ bu not exactly C++ as Qt uses a 
preprocessor to translate "enhanced C++" into "vanilla C++".

Here is an example that demonstrates that "Qt C++" is not "vanilla C++".

In Qt, one adorns class declarations with things that are not valid C++.

So in a class declaration you can say

class MyWidget
{
public:
	// regular C++ stuff, attributes and methods

public slots:
	// method declarations for intercepting event signals
};

You will observe that "public slots" is not valid C++.  Qt's meta-object 
compiler does a preprocessing of the MyWidget class so that methods 
declared under the "public slots:" scope are subject to some kind of 
reflection or introspection that enables events (signals) to be delegate 
to the respective methods.

In doing so, according to my naive understanding, the Qt MOC 
(meta-object compiler) compiles the MyWidget class retaining knowledge 
of compile time analysis of the MyWidget class methods which are 
designated as slots.

So this is some kind of black magic that the MOC does to Qt source code 
in order to make event routing easier.  The concepts of reflection come 
to mind here.  In a way the MOC processor must be keeping a lot of the 
static analysis of classes around in similar fashion that Java does.

Accordingly it is fair to ask why does Qt do this?  Obviously Qt 
designers do not feel that vanilla C++ is adequate for cutting GUI apps 
which is why they resort to a preprocessor.

Now I was thinking about why is C++ deficient for Qt to go to such 
resorts.  And if vanilla C++ is deficient for GUI programming, and given 
that D is viewed by many as a "better C++", then can D do natively what 
Qt has to do with a preprocessor?

I'm not an expert on Qt or its MOC (only 2 weeks into it).  Perhaps 
others on this NG might cotton on to what I'm trying to express and 
chime in.

Does the simple example above help explain what I'm on about?

Cheers

Justin Johanssom
May 08 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson:

 You will observe that "public slots" is not valid C++.  Qt's meta-object 
 compiler does a preprocessing of the MyWidget class so that methods 
 declared under the "public slots:" scope are subject to some kind of 
 reflection or introspection that enables events (signals) to be delegate 
 to the respective methods.


More info about QT signals and slots:
http://doc.trolltech.com/4.6/signalsandslots.html

But if you look for a solution integrated in the D2/D3 language, then JavaFX
bind and triggers seem nice (this stuff is useful for GUIs):
http://java.sun.com/javafx/1/tutorials/core/dataBinding/

Bye,
bearophile
May 08 2010
parent reply Justin Johansson <no spam.com> writes:
bearophile wrote:

 Justin Johansson:

 You will observe that "public slots" is not valid C++.  Qt's meta-object 
 compiler does a preprocessing of the MyWidget class so that methods 
 declared under the "public slots:" scope are subject to some kind of 
 reflection or introspection that enables events (signals) to be delegate 
 to the respective methods.


 
 More info about QT signals and slots:
 http://doc.trolltech.com/4.6/signalsandslots.html
 
 But if you look for a solution integrated in the D2/D3 language, then JavaFX
bind and triggers seem nice (this stuff is useful for GUIs):
 http://java.sun.com/javafx/1/tutorials/core/dataBinding/
 
 Bye,
 bearophile


Okay, I think we are on the same wavelength now.

So how far removed is a solution integrated into D2/D3?

JJ
May 08 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson:

 So how far removed is a solution integrated into D2/D3?


I don't think D2 will change for this. For D3 there is a bit more probability,
but as I have said those features are mostly for GUI programming, and so far D
doesn't look designed to help GUI creation.

If you care about GUIs in D then I suggest you to do what I have done with unit
testing: to use what the language offers you for some months (or some years, as
in my case), and to use other languages with better GUI integration/usage too
to learn from them, and then to distil what you have learnt in a list of what
you think is both important and harder to do with the standard D2 language,
trying to keep things as simple to implement as possible. After you have
discussed such list with other people you can then use it to write an
enhancement request :-) And that will be the starting point. Designing things
is a lot of work.

Bye,
bearophile
May 08 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
bearophile Wrote:


 Justin Johansson:

 So how far removed is a solution integrated into D2/D3?


 
 I don't think D2 will change for this. For D3 there is a bit more probability,
but as I have said those features are mostly for GUI programming, and so far D
doesn't look designed to help GUI creation.
 
 If you care about GUIs in D then I suggest you to do what I have done with
unit testing: to use what the language offers you for some months (or some
years, as in my case), and to use other languages with better GUI
integration/usage too to learn from them, and then to distil what you have
learnt in a list of what you think is both important and harder to do with the
standard D2 language, trying to keep things as simple to implement as possible.
After you have discussed such list with other people you can then use it to
write an enhancement request :-) And that will be the starting point. Designing
things is a lot of work.
 
 Bye,
 bearophile


I'm in the middle of reading the PyQt book, and I really appreciate how easy it
is to implement GUI design & behavior in Qt using Python. I have yet to try
mixing Python with D, but it should be possible. Personally, I would leave all
the GUI stuff to Python, and most of the data manipulation (where speed is
crucial) to C/D.

It's probably best to pick the best language for a particular job. Unless the
coder is stuck using only one language, for whatever reason it may be.
May 08 2010
parent "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:hs3rju$ac1$1 digitalmars.com...

 I'm in the middle of reading the PyQt book, and I really appreciate how 
 easy it is to implement GUI design & behavior in Qt using Python. I have 
 yet to try mixing Python with D, but it should be possible. Personally, I 
 would leave all the GUI stuff to Python, and most of the data manipulation 
 (where speed is crucial) to C/D.

 It's probably best to pick the best language for a particular job. Unless 
 the coder is stuck using only one language, for whatever reason it may be.


Years of web development has led me to the conclusion that there's 
significant, but frequently overlooked, benefit in sticking to as few 
languages as possible (preferably one that's as general-purpose as possible) 
as opposed to spreading an app across a variety of languages.

But then, of course, web development isn't so much a case of "choosing the 
best languages for the individual jobs" as it is "being forced into the 
worst languages for the individual jobs" ;)
May 08 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 5/8/10 14:01, Justin Johansson wrote:

 bearophile wrote:

 Justin Johansson:

 Whilst QtD looks like a cool project, my question was really about
 whether D could achieve the same sorts of things that Qt does with
 its meta-object compiler.

 In other words, and calling a spade a spade, Qt is a "hack" to make
 C++ more pleasant for GUI. Would it be possible for D to achieve
 natively the same sorts that Qt does via preprocessing to C++.


 I suggest you to explain what such things are, and to give some
 examples too.

 Bye,
 bearophile


 Okay, perhaps not everybody here is across Qt.

 Programming in Qt is almost C++ bu not exactly C++ as Qt uses a
 preprocessor to translate "enhanced C++" into "vanilla C++".

 Here is an example that demonstrates that "Qt C++" is not "vanilla C++".

 In Qt, one adorns class declarations with things that are not valid C++.

 So in a class declaration you can say

 class MyWidget
 {
 public:
 // regular C++ stuff, attributes and methods

 public slots:
 // method declarations for intercepting event signals
 };

 You will observe that "public slots" is not valid C++. Qt's meta-object
 compiler does a preprocessing of the MyWidget class so that methods
 declared under the "public slots:" scope are subject to some kind of
 reflection or introspection that enables events (signals) to be delegate
 to the respective methods.

 In doing so, according to my naive understanding, the Qt MOC
 (meta-object compiler) compiles the MyWidget class retaining knowledge
 of compile time analysis of the MyWidget class methods which are
 designated as slots.

 So this is some kind of black magic that the MOC does to Qt source code
 in order to make event routing easier. The concepts of reflection come
 to mind here. In a way the MOC processor must be keeping a lot of the
 static analysis of classes around in similar fashion that Java does.

 Accordingly it is fair to ask why does Qt do this? Obviously Qt
 designers do not feel that vanilla C++ is adequate for cutting GUI apps
 which is why they resort to a preprocessor.

 Now I was thinking about why is C++ deficient for Qt to go to such
 resorts. And if vanilla C++ is deficient for GUI programming, and given
 that D is viewed by many as a "better C++", then can D do natively what
 Qt has to do with a preprocessor?

 I'm not an expert on Qt or its MOC (only 2 weeks into it). Perhaps
 others on this NG might cotton on to what I'm trying to express and
 chime in.

 Does the simple example above help explain what I'm on about?

 Cheers

 Justin Johanssom


I've read the two links bearophile posted and I think that Qt signals 

using delegates. Basically create a new template type (a struct for 
example) called Event. Event contains a data structure (a linked list 
for example) of delegates. Then you have a function that adds new 
delegates to the data structure and finally a function that calls all 
the delegates in the data structure.

This code is basically the same thing as the Counter example on Qt site.

class Counter
{
	int value_;
	Event!(void, int) valueChanged;

	void value (int value)
	{
		if (value != value_)
		{
			value_ = value;
			valueChanged(value);
		}
	}

	int value ()
	{
		return value_;
	}
}

auto a = new Counter;
auto b = new Counter;

a.valueChanged += &b.value; // I'm hoping this will choose the right 
method based on the signature that is needed

a.value = 12;
b.value = 48;

Am I missing something? This seems pretty simple. If some additional 
support is needed there is always compile time reflection in the form of 
__traits: http://www.digitalmars.com/d/2.0/traits.html and runtime 
reflection in the form of flectioned: 
http://www.dsource.org/projects/flectioned

/Jacob Carlborg
May 08 2010
parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:hs3su9$c7k$1 digitalmars.com...

 I've read the two links bearophile posted and I think that Qt signals and 

 delegates. Basically create a new template type (a struct for example) 
 called Event. Event contains a data structure (a linked list for example) 
 of delegates. Then you have a function that adds new delegates to the data 
 structure and finally a function that calls all the delegates in the data 
 structure.


When I looked into Qt, that was my impression as well. Seemed like a 

reflection (or at least an improved version of D's reflection anyway) seems 
to cover all the bases. But then, I'm no Qt expert.
May 08 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Justin Johansson wrote:

...

 Qt, as many of you will know, is a C++ GUI framework produced by
 formerly TrollTech and now acquired by Nokia for $xxx million (60 or
 160M I read somewhere).  So Nokia pays megabucks for a GUI framework
 that is C++ at its core.  Questions are, why is Qt worth so much to
 Nokia, why is Qt so damn popular on the Linux platform and what is the
 secret of Qt's success given that it is basically a C++ framework
 wrapped in some "meta-object compiler"?


1: Nokia is going to use Qt for everything, most importantly Symbian and 
Meego. 

2: It's attractive not only because it is so huge, well designed and 
supported, but also because it performs, is cross-platform and looks good 
everywhere (as opposed to Java and gtk)

3: The C++ and meta-object compiler are not the core of it's success, but 
rather the combination of:
- well-designed
- HUGE coherent framework
- good cross-platform capability
- both open source and commercial
- used by KDE, sponsored by Nokia


 Having now been exposed to Qt for a few weeks and beginning to
 understand its architecture of "signals and slots" and a pre-processor
 that compiles down to C++, I am now wondering whether D is powerful
 enough to achieve the same sorts of things that Qt seems to be doing.
 
 If I understand correctly, Qt brings a degree of "reflection capability"
 to C++ amongst other things.  Qt does a tremendous job of circumventing
 the gaps in plain old C++ to achieve great goodness for GUI development
 by way of its meta-object compiler.


I think it is no problem, since basically it's a framework that uses runtime 
reflection coupled with an event system. This shouldn't be hard to achieve 
(or beat) in D.
 

 May I ask if others on this NG are across Qt and D might be capable of
 slotting into some of this market for cross-platform GUI development.


Languages wise: surely, why not? The thousands of man-years a hypothetical D 
toolkit is behind Qt plus starting from 0% marketshare poses a slightly 
bigger problem though :) Not to mention D doesn't even have compilers on all 
the platforms Qt runs on. 
 

 As always, discussions such as these can go anywhere and everywhere on
 DigitalMars D NG, and that's much of the joy in staying with this NG if
 only as a bystander at times.
 
 Cheers and best regards to all,
 
 Justin Johansson
May 08 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-08 09:24:55 -0400, Lutger <lutger.blijdestijn gmail.com> said:


 2: It's attractive not only because it is so huge, well designed and
 supported, but also because it performs, is cross-platform and looks good
 everywhere (as opposed to Java and gtk)


Everywhere? Saying Qt apps looks good and behave well on a Mac is kind 
of a stretch. I have yet to see one that is not sub-par compared from 
what I would expect from an equivalent Cocoa implementation.

It's the same for all cross-platform toolkits really: they were first 
meant to work on Windows or Linux, so they're designed as such and it 
shows. Here's a nice comment to read:
http://illogic-al.org/blog/look-before-you-leap#comment-74



 3: The C++ and meta-object compiler are not the core of it's success, but
 rather the combination of:
 - well-designed
 - HUGE coherent framework
 - good cross-platform capability
 - both open source and commercial
 - used by KDE, sponsored by Nokia


Very true. Qt is well designed and is huge, and is one of the very few 
sane C++ framework on Windows. I don't want my comment about the Mac 
look and feel above to diminish that. Qt is a platform that can stand 
by itself.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 08 2010
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Michel Fortin wrote:


 On 2010-05-08 09:24:55 -0400, Lutger <lutger.blijdestijn gmail.com> said:
 

 2: It's attractive not only because it is so huge, well designed and
 supported, but also because it performs, is cross-platform and looks good
 everywhere (as opposed to Java and gtk)


 
 Everywhere? Saying Qt apps looks good and behave well on a Mac is kind
 of a stretch. I have yet to see one that is not sub-par compared from
 what I would expect from an equivalent Cocoa implementation.
 
 It's the same for all cross-platform toolkits really: they were first
 meant to work on Windows or Linux, so they're designed as such and it
 shows. Here's a nice comment to read:
 http://illogic-al.org/blog/look-before-you-leap#comment-74
 
 


Ah sorry I didn't know it was so crappy. Qt used to look different on windows 
too, not crap but just not native. In this area Qt is rapidly improving, the 
comment you cited is posted a while ago. Qt 4.6 can use Cocao now, I found 
this link in the docs:

http://doc.qt.nokia.com/4.6/qtmac-as-native.html
May 08 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hs3uft$efc$1 digitalmars.com...

 On 2010-05-08 09:24:55 -0400, Lutger <lutger.blijdestijn gmail.com> said:


 2: It's attractive not only because it is so huge, well designed and
 supported, but also because it performs, is cross-platform and looks good
 everywhere (as opposed to Java and gtk)


 Everywhere? Saying Qt apps looks good and behave well on a Mac is kind of 
 a stretch. I have yet to see one that is not sub-par compared from what I 
 would expect from an equivalent Cocoa implementation.


This is first I've heard of that. I find it interesting though. Can you post 
comparison screenshots and explain some of the behavioral differences? I 
promise I'll try my best to refrain from another of my "Apple sucks" rants 
;) (I saw the screenshot that was linked to in the comment that you linked 
to, but I couldn't quite make heads or tails of what exactly it was 
demonstrating.)
May 08 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-08 16:15:58 -0400, "Nick Sabalausky" <a a.a> said:


 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:hs3uft$efc$1 digitalmars.com...

 On 2010-05-08 09:24:55 -0400, Lutger <lutger.blijdestijn gmail.com> said:
 

 2: It's attractive not only because it is so huge, well designed and
 supported, but also because it performs, is cross-platform and looks good
 everywhere (as opposed to Java and gtk)


 
 Everywhere? Saying Qt apps looks good and behave well on a Mac is kind of
 a stretch. I have yet to see one that is not sub-par compared from what I
 would expect from an equivalent Cocoa implementation.


 
 This is first I've heard of that. I find it interesting though. Can you post
 comparison screenshots and explain some of the behavioral differences? I
 promise I'll try my best to refrain from another of my "Apple sucks" rants
 ;) (I saw the screenshot that was linked to in the comment that you linked
 to, but I couldn't quite make heads or tails of what exactly it was
 demonstrating.)


It's not "crappy" (I never said that), it's just that there are so many 
things which are just "almost right" and a few things that you'd expect 
to work but don't that it's really easy to tell it's a cross-platform 
app.

Also, when the Qt guys say they're using Cocoa, they're only using 
Cocoa drawing routines (as far as I know), and not everywhere. Many of 
the differences are behavioral or different layout conventions or the 
non-use of Mac-specific controls, which are much more complicated to 
fix.

I'm looking at Opera 10.53 and just by opening the preference pane I 
can tell you this is wrong:

- The first and last tab at the top have too small margins on their 
external edge of the simulated segmented control.
- Clicking on a tab selects the tab immediately (as on Windows); it 
should select only on mouse-up.
- The spacing between controls is quite strange in the Advanced tab.
- Clicking on a non-text control puts the keyboard focus on it, even 
when the system-wide setting is set to not do that.
- Separator bars aren't drawn correctly (should not have a lighter line 
below the bar).
- Lists (not just in the preference panel) use the text selection color 
instead of the darker list selection color.
- Text in pop-up buttons is misaligned, and should use "..." when too 
long to fit.
- Text in text boxes has incorrect margins.
- Text in labels should be right-aligned when the associated control is 
on the right of the label.
- The focus ring around text boxes is smaller than it should be.
- List boxes lack a focus ring when focused.
- List boxes headers combined with the box border makes a two 
pixel-border, this shouldn't happen and does not with Cocoa controls.
- The check box and radio button size doesn't fit with the size for the 
rest of the UI (they took the "small" variant instead of the "normal" 
variant (speculation: perhaps when checked the checkmark would go too 
far outside of the box for Qt to be able to handle it, so they took the 
smaller one?).
- Disabled buttons: the text should be dimmed too, not just the button border.
- Preferences in OS X should not have OK/Cancel buttons, they should 
apply immediately as you change them. They should also be modeless (not 
blocking other windows).
- The help button should be a standard Help button (round, purple, and 
with a question mark).
- Selecting a file/folder by having a Choose button next to a text 
field with a path is very un-mac-like.
- Font selection buttons displaying the currently selected font should 
use a bezel style button or something similar, not the standard push 
button style which looks out of place.
- When another window in frontmost, controls when clicked with the 
command key pressed still bring the window to the foreground; they 
shouldn't.
- The color selector control has exactly the same bevel pixels as a 
Windows 95 button!
- More generally, the layout of dialog boxes doesn't follow what we 
generally see in Mac apps, specifically columns of "Add", "Edit", 
"Delete", "Rename" buttons should use icons and be located below the 
list field, or minimally they should use the smaller control style to 
match the text size in the list box.

Looking elsewhere in the app (but ignoring the custom chrome Opera uses 
for its browser window):

- Various dialogs that pop up should be sheets attached to the browser 
window or the preference window instead of being standalone windows.
- Right clicking a word in a text box should select the word if the 
click isn't already inside the selection.
- Can't access the Mac OS X's definition dictionary or make a Google or 
Spotlight search by right-clicking a term in a text field. And 
system-wide context-menu plugins and services don't show up either.
- Text fields can't use the built-in Mac OS X spellchecker either 
(there's a custom spell checker, not sure if it comes with Qt or Opera).
- "radio-groups" in menus should use the same checkmark as checkable 
items, not a diamond.
- A diamond should be used in the window menu to indicate minimized 
window, but of course that's not the case.
- The "Details >>" button looks like a Windows thing. There's a special 
square button style with a triangle in Mac OS X for this kind of button.
- "Next >" and "< Previous" should not have "<" or ">" on a Mac.
- Tooltips are not exactly of the standard shape, color and 
transparency. When they appear, there's a very short flicker until the 
text is drawn inside. They should also contain a description, not just 
a word ("Go to home page" instead of "Home").
- I haven't tested, but I'm pretty sure VoiceOver doesn't work anywhere 
in this UI.
- Apparently, it doesn't look Opera can use the Mac OS X keychain to 
store passwords. Perhaps Qt made that more difficult, but I don't know.
...
I guess that's enough for today.

Note that there are a many Mac apps that break one or another of these 
rules (iTunes preferences come to mind, many Carbon apps too), but only 
cross-platform toolkits breaks as many.

Some of these are more a failure of the application developer to adapt 
his application to be more mac-like, but most are problems or 
limitations within Qt itself. Also, even though it's possible, the 
complexity of using platform-specific controls in Qt generally pushes 
developers to limit themselves to controls available on all platforms. 
The end result is something usable, but nonetheless feels a little 
alien.

Perhaps looking at just Opera is not fair, but this seems like a pretty 
typical Qt app to me, and I believe they did some effort to make it 
better on a mac recently. But in comparison, Chrome is much better: 
they're using a real Cocoa GUI and it shows.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 08 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hs4njf$1mmr$1 digitalmars.com...

 On 2010-05-08 16:15:58 -0400, "Nick Sabalausky" <a a.a> said:


 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:hs3uft$efc$1 digitalmars.com...

 Everywhere? Saying Qt apps looks good and behave well on a Mac is kind 
 of
 a stretch. I have yet to see one that is not sub-par compared from what 
 I
 would expect from an equivalent Cocoa implementation.


 This is first I've heard of that. I find it interesting though. Can you 
 post
 comparison screenshots and explain some of the behavioral differences? I
 promise I'll try my best to refrain from another of my "Apple sucks" 
 rants
 ;) (I saw the screenshot that was linked to in the comment that you 
 linked
 to, but I couldn't quite make heads or tails of what exactly it was
 demonstrating.)


 It's not "crappy" (I never said that),


Didn't mean to imply that you did :)


 [big snip]


Ahh, interesting.

I don't use Opera, but I have tried it briefly and I seem to have a vague 
recollection that it wasn't quite native-look-and-feel on my Win machine 
either (but I might be remembering wrong).


 But in comparison, Chrome is much better: they're using a real Cocoa GUI 
 and it shows.


Now that I find really surprising. On Windows, Chrome is one of the biggest 
offenders of "To hell with native look & feel!" that I've ever seen.
May 08 2010
parent reply retard <re tard.com.invalid> writes:
Sat, 08 May 2010 18:22:37 -0400, Nick Sabalausky wrote:


 Now that I find really surprising. On Windows, Chrome is one of the
 biggest offenders of "To hell with native look & feel!" that I've ever
 seen.


Chrome, on the other hand, has consistent look & feel across all 
platforms. I guess the style comes from their own google web os system. 
It doesn't look bad in my opinion, e.g. compared to Java and Swing.
May 08 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-08 18:34:02 -0400, retard <re tard.com.invalid> said:


 Sat, 08 May 2010 18:22:37 -0400, Nick Sabalausky wrote:
 

 Now that I find really surprising. On Windows, Chrome is one of the
 biggest offenders of "To hell with native look & feel!" that I've ever
 seen.


 
 Chrome, on the other hand, has consistent look & feel across all
 platforms. I guess the style comes from their own google web os system.
 It doesn't look bad in my opinion, e.g. compared to Java and Swing.


I was mostly talking about the non-browser-window elements, such as the 
preferences and the about box or any other windows. I specifically 
ignored the browser window because I understand they include a lot of 
custom controls which doesn't necessarily represent Qt or Cocoa fairly.

Speaking of Chrome, I can tell the browser window is implemented with 
Cocoa, not just the other windows. But they managed to get a few things 
wrong too in their customization. For one thing, the close button of 
the window and the two others are a few pixels too low. Their tooltips 
are standard and host a descriptions, the only thing I'd say is wrong 
is the focus ring for the Omnibar. They've got 3 or 4 things misaligned 
scattered in a few places in the other windows, but it just reflects 
small human errors, not systemic problems. Heck, they even have a menu 
item "Reload this page" that changes to "Force reload this page" when 
you press the shift key when the menu is open. Easy with Cocoa, but now 
try to do that with a cross-platform toolkit!

I wonder, what is wrong with Chrome on Windows? I mean, what is wrong 
that is not by design but because of laziness or incompleteness?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 08 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hs4s7g$1tc4$1 digitalmars.com...

 On 2010-05-08 18:34:02 -0400, retard <re tard.com.invalid> said:


 Sat, 08 May 2010 18:22:37 -0400, Nick Sabalausky wrote:


 Now that I find really surprising. On Windows, Chrome is one of the
 biggest offenders of "To hell with native look & feel!" that I've ever
 seen.


 Chrome, on the other hand, has consistent look & feel across all
 platforms. I guess the style comes from their own google web os system.
 It doesn't look bad in my opinion, e.g. compared to Java and Swing.


 I was mostly talking about the non-browser-window elements, such as the 
 preferences and the about box or any other windows. I specifically ignored 
 the browser window because I understand they include a lot of custom 
 controls which doesn't necessarily represent Qt or Cocoa fairly.


Ahh, I was including the browser window. Regarding the dialog/preference 
windows:

The dialog *body* has a very native look & feel, and I think it probably 
uses the native controls.

The title/frame/border looks identical to non-accelerated Aero...but I'm on 
XP. One hell of a blatant gaffe. (And even if I were on Win7, I would 
definitely set the system to the "Classic" non-aero style anyway. There's a 
number of things I like better about it, aesthetics just being one reason).


 I wonder, what is wrong with Chrome on Windows? I mean, what is wrong that 
 is not by design but because of laziness or incompleteness?


The above. Other than that, most of my [long, long, long list of] issues 
with Chrome are by-design things. However, I don't normally distinguish 
between intentional bad designs and accidental bad designs. Bad design is 
bad design. If anything, accidental bad design is better because at least 
then there's a chance that the developer might be persuaded to fix it.
May 08 2010
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:


 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:hs4s7g$1tc4$1 digitalmars.com...

 On 2010-05-08 18:34:02 -0400, retard <re tard.com.invalid> said:


 Sat, 08 May 2010 18:22:37 -0400, Nick Sabalausky wrote:


 Now that I find really surprising. On Windows, Chrome is one of the
 biggest offenders of "To hell with native look & feel!" that I've ever
 seen.


 Chrome, on the other hand, has consistent look & feel across all
 platforms. I guess the style comes from their own google web os system.
 It doesn't look bad in my opinion, e.g. compared to Java and Swing.


 I was mostly talking about the non-browser-window elements, such as the
 preferences and the about box or any other windows. I specifically ignored
 the browser window because I understand they include a lot of custom
 controls which doesn't necessarily represent Qt or Cocoa fairly.


 
 Ahh, I was including the browser window. Regarding the dialog/preference
 windows:
 
 The dialog *body* has a very native look & feel, and I think it probably
 uses the native controls.
 
 The title/frame/border looks identical to non-accelerated Aero...but I'm on
 XP. One hell of a blatant gaffe. (And even if I were on Win7, I would
 definitely set the system to the "Classic" non-aero style anyway. There's a
 number of things I like better about it, aesthetics just being one reason).


you can right-click and select 'Use system title bar and borders'. Or are you 
referring to the looks only?  
I disagree about Chrome being badly designed though, the nice thing about 
Chrome tabs is that you can easily drag one loose, rearrange or merge 
existing windows. This way they also take much less precious vertical space. 
Chrome is not as cluttered as the other browsers are, it just gets out of 
your way and lets you browse the web. 

Anyway, 'native look and feel' is a joke on windows. The classical style is 
history now and windows forms will probably be obsoleted by WPF soon. The big 
MS apps like Word, msn, windows media player, visual studio 2010: they all 
have very different styles from each other and previous versions of 
themselves.  
 

 I wonder, what is wrong with Chrome on Windows? I mean, what is wrong that
 is not by design but because of laziness or incompleteness?


 
 The above. Other than that, most of my [long, long, long list of] issues
 with Chrome are by-design things. However, I don't normally distinguish
 between intentional bad designs and accidental bad designs. Bad design is
 bad design. If anything, accidental bad design is better because at least
 then there's a chance that the developer might be persuaded to fix it.
May 08 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:hs5n6h$5k4$1 digitalmars.com...

 Nick Sabalausky wrote:


 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:hs4s7g$1tc4$1 digitalmars.com...

 On 2010-05-08 18:34:02 -0400, retard <re tard.com.invalid> said:


 Sat, 08 May 2010 18:22:37 -0400, Nick Sabalausky wrote:


 Now that I find really surprising. On Windows, Chrome is one of the
 biggest offenders of "To hell with native look & feel!" that I've ever
 seen.


 Chrome, on the other hand, has consistent look & feel across all
 platforms. I guess the style comes from their own google web os system.
 It doesn't look bad in my opinion, e.g. compared to Java and Swing.


 I was mostly talking about the non-browser-window elements, such as the
 preferences and the about box or any other windows. I specifically 
 ignored
 the browser window because I understand they include a lot of custom
 controls which doesn't necessarily represent Qt or Cocoa fairly.


 Ahh, I was including the browser window. Regarding the dialog/preference
 windows:

 The dialog *body* has a very native look & feel, and I think it probably
 uses the native controls.

 The title/frame/border looks identical to non-accelerated Aero...but I'm 
 on
 XP. One hell of a blatant gaffe. (And even if I were on Win7, I would
 definitely set the system to the "Classic" non-aero style anyway. There's 
 a
 number of things I like better about it, aesthetics just being one 
 reason).


 you can right-click and select 'Use system title bar and borders'. Or are 
 you
 referring to the looks only?


That's not showing up for me.
May 09 2010
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:


 "Lutger" <lutger.blijdestijn gmail.com> wrote in message
 news:hs5n6h$5k4$1 digitalmars.com...

 Nick Sabalausky wrote:


 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:hs4s7g$1tc4$1 digitalmars.com...

 On 2010-05-08 18:34:02 -0400, retard <re tard.com.invalid> said:


 Sat, 08 May 2010 18:22:37 -0400, Nick Sabalausky wrote:


 Now that I find really surprising. On Windows, Chrome is one of the
 biggest offenders of "To hell with native look & feel!" that I've ever
 seen.


 Chrome, on the other hand, has consistent look & feel across all
 platforms. I guess the style comes from their own google web os system.
 It doesn't look bad in my opinion, e.g. compared to Java and Swing.


 I was mostly talking about the non-browser-window elements, such as the
 preferences and the about box or any other windows. I specifically
 ignored
 the browser window because I understand they include a lot of custom
 controls which doesn't necessarily represent Qt or Cocoa fairly.


 Ahh, I was including the browser window. Regarding the dialog/preference
 windows:

 The dialog *body* has a very native look & feel, and I think it probably
 uses the native controls.

 The title/frame/border looks identical to non-accelerated Aero...but I'm
 on
 XP. One hell of a blatant gaffe. (And even if I were on Win7, I would
 definitely set the system to the "Classic" non-aero style anyway. There's
 a
 number of things I like better about it, aesthetics just being one
 reason).


 you can right-click and select 'Use system title bar and borders'. Or are
 you
 referring to the looks only?


 
 That's not showing up for me.


Ok, looks like this is specific for the linux chrome version. You have to 
right-click in the chrome title bar btw, not just anywhere. 

I do agree though that apps should respect or at least enable title bar 
decoration and theming. (Note that microsoft apps like office 2007 do not do 
this!) Most, if not all, linux window managers can be configured to force 
system titlebar decorations, perhaps it is also possible under windows.
May 09 2010
parent "Nick Sabalausky" <a a.a> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:hs64bs$voj$1 digitalmars.com...

 Ok, looks like this is specific for the linux chrome version. You have to
 right-click in the chrome title bar btw, not just anywhere.

 I do agree though that apps should respect or at least enable title bar
 decoration and theming. (Note that microsoft apps like office 2007 do not 
 do
 this!) Most, if not all, linux window managers can be configured to force
 system titlebar decorations, perhaps it is also possible under windows.


One of the millions of projects I would be working on if I had time:

A cross-platform GUI system that allowed 100% native look & feel, but also 
had an easy-to-use config program that allows the user to make/save/install 
skins (including highly-configurable skins, such as the "classic" Windows 
style, where f***ing everything can be adjusted - something that is 
idiotically missing in all so-called "modern" themes like Aero and Aqua). 
The user can set these themes on both a system-wide level and on an 
app-by-app basis. Theme settings would also affect the system's native 
Aero/Aqua/WinClassic/Gnome/KDE/etc settings to whatever extent is actually 
possible (Naturally, this means it would work best, by far, on Linux, but 
without MS or Apple taking notice, that can't be helped.)

Also, it would provide automatic protection against the now-epidemic 
invisible-text-syndrome by having the API designed so that it's impossible 
for a programmer to accidentally set up foreground/background colors with 
one being system-default and the other being manually-specified (something 
that should *never* happen, but is done *constantly* in both applications 
and websites, hell, .NET's WinForms even has cases where you *can't* fix 
it).

IMO, there is *NO* excuse for any modern windowing system *not* to work this 
way. I mean, crap, ***Windows 3.x*** was already most of the way there. All 
it was missing was a way to set things on an app-by-app basis and support 
for alternate rendering (and the invisible-text protection, but IIRC, 
developers back then weren't in the habit of making that mistake quite like 
they are now). I can understand Win3 missing those things, but I find it 
nothing short of truly pathetic that in the *20* years since, not only have 
we not been able to make that *little* bit of advancement, but things have 
actually gone *backwards*.
May 09 2010
prev sibling parent Christian Kamm <kamm-incasoftware removethis.de> writes:
Michel Fortin wrote:

 I'm looking at Opera 10.53 and just by opening the preference pane I
 can tell you this is wrong:


As far as I know Opera uses Qt on Linux - but not for the user interface.
http://my.opera.com/kilsmo/blog/2008/01/29/opera-is-not-based-on-qt

Cheers,
Christian
May 09 2010
prev sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
On 08/05/10 14:24, Lutger wrote:

 3: The C++ and meta-object compiler are not the core of it's success, but
 rather the combination of:
 - well-designed
 - HUGE coherent framework
 - good cross-platform capability
 - both open source and commercial
 - used by KDE, sponsored by Nokia


Add to this:
- excellent documentation
- excellent tutorials for newcomers
- huge, well sorted set of examples and case studies for special tasks
May 09 2010
prev sibling next sibling parent reply Marianne Gagnon <auria.mg gmail.com> writes:
Hi Justin,

looking at QtD, it seems like it can be done :

In file http://www.dsource.org/projects/qtd/browser/demos/browser/browsermainwindow.d

        m_historyHome.triggered().connect(&this.slotHome);

        // ...

 	public:
	
 	    void slotHome()
 	    {
 	        // ...
	    }

I however believe that this kind of delegate-connection can also be performed
in C++ (with templates?). Maybe Qt developers simply continue using the MOC
because they don't want to break backwards compatibility.

-- Auria
May 08 2010
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Marianne Gagnon wrote:


 Hi Justin,
 
 looking at QtD, it seems like it can be done :
 
 In file
 


http://www.dsource.org/projects/qtd/browser/demos/browser/browsermainwindow.d

 
         m_historyHome.triggered().connect(&this.slotHome);
 
         // ...
 
  public:
 
  void slotHome()
  {
  // ...
 }
 
 I however believe that this kind of delegate-connection can also be
 performed in C++ (with templates?). Maybe Qt developers simply continue
 using the MOC because they don't want to break backwards compatibility.
 
 -- Auria


Yes, but there is another reason: the signal/slot design is part of the 
reflection system that MOC generates. The idea is that this makes it more  
flexible and dynamic. For example you hook signal / slots in their gui 
designer or expose them as a dbus api, provide easy scripting access, etc.
May 08 2010
prev sibling next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 05/08/2010 06:27 PM, Marianne Gagnon wrote:

 Hi Justin,

 looking at QtD, it seems like it can be done :

 In file http://www.dsource.org/projects/qtd/browser/demos/browser/browsermainwindow.d

          m_historyHome.triggered().connect(&this.slotHome);


The example is outdated. Now it's like

connect(m_historyHome, "triggered", this, "slotHome").


          // ...

   	public:
 	
   	    void slotHome()
   	    {
   	        // ...
 	    }

 I however believe that this kind of delegate-connection can also be performed
in C++ (with templates?). Maybe Qt developers simply continue using the MOC
because they don't want to break backwards compatibility.

 -- Auria


Here's why they are not using templates 
http://doc.trolltech.com/4.5/templates.html
May 08 2010
parent reply Marianne Gagnon <auria.mg gmail.com> writes:
 The example is outdated. Now it's like
 
 connect(m_historyHome, "triggered", this, "slotHome").


Interesting. Does QtD use some MOC-like to generate code like C++ Qt, or is
there some magic?
I was searching for examples of how it was done, but if they're outdated... ^^
May 08 2010
parent Max Samukha <spambox d-coding.com> writes:
On 05/08/2010 10:37 PM, Marianne Gagnon wrote:

 Interesting. Does QtD use some MOC-like to generate code like C++ Qt, or is
there some magic?


No magic. It generates Qt-compatible meta-objects using CTFE (a nearly 
direct port of the MOC compiler to D).
May 08 2010
prev sibling parent Justin Johansson <no spam.com> writes:
Marianne Gagnon wrote:

 Hi Justin,
 
 looking at QtD, it seems like it can be done :
 
 In file http://www.dsource.org/projects/qtd/browser/demos/browser/browsermainwindow.d
 
         m_historyHome.triggered().connect(&this.slotHome);
 
         // ...
 
  	public:
 	
  	    void slotHome()
  	    {
  	        // ...
 	    }
 
 I however believe that this kind of delegate-connection can also be performed
in C++ (with templates?). Maybe Qt developers simply continue using the MOC
because they don't want to break backwards compatibility.
 
 -- Auria


Maybe to a small degree but it seems to me that the Qt Meta-Object 
Compiler does more than just support signal and slot connections.  There 
are a number of "C++ extension" that can go in a class declaration like 
Q_OBJECT, Q_PROPERTY, Q_ENUMS, Q_CLASSINFO.

e.g. as below from from http://doc.trolltech.com/4.4/moc.html

The MOC mechanism makes it trivial to expose classes in Qt to scripting 
with QtScript (basically Qt version of JavaScript).

I haven't dug deep enough into QtD to know how it fares in the scripting 
arena though.

Cheers
Justin Johansson


<QtDocumentation>

In addition to the signals and slots shown above, moc also implements 
object properties as in the next example. The Q_PROPERTY() macro 
declares an object property, while Q_ENUMS() declares a list of 
enumeration types within the class to be usable inside the property system.

In the following example, we declare a property of the enumeration type 
Priority that is also called priority and has a get function priority() 
and a set function setPriority().

  class MyClass : public QObject
  {
      Q_OBJECT
      Q_PROPERTY(Priority priority READ priority WRITE setPriority)
      Q_ENUMS(Priority)

  public:
      enum Priority { High, Low, VeryHigh, VeryLow };

      MyClass(QObject *parent = 0);
      ~MyClass();

      void setPriority(Priority priority);
      Priority priority() const;
  };

The Q_FLAGS() macro declares enums that are to be used as flags, i.e. 
OR'd together. Another macro, Q_CLASSINFO(), allows you to attach 
additional name/value pairs to the class's meta-object:

  class MyClass : public QObject
  {
      Q_OBJECT
      Q_CLASSINFO("Author", "Oscar Peterson")
      Q_CLASSINFO("Status", "Active")

  public:
      MyClass(QObject *parent = 0);
      ~MyClass();
  };

</QtDocumentation>
May 08 2010
prev sibling parent reply Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
Justin Johansson wrote:

 A week or two ago I started a thread suggesting that JavaScript might be 
 an interesting "VM" for D to target for web apps.  A thriving discussion 
 ensured and it was a delight to read the opinions posted by many on this 
 newsgroup.
 
 The idea came out of a frustration I had with having to develop a rather 
 complex application using browser-only technology, JavaScript being 
 somewhat awkward to deal with the task at hand.  In the process of 
 pondering the scalability of the programming task I looked to many 
 different ways of circumventing programming plain old JavaScript and 
 considered such things as Haxe, Cappuccino (Objective-J) and SproutCore. 
  Then it occurred to me everything I liked about D and had this fairy 
 wish that D might be ideal for client side programming down to JS.
 
 Since then, my client has gone completely off web apps for this 
 particular Linux-embedded hand-held mobile device and has mandated that 
 the apps will now be written as desktop apps in Qt.
 
 Qt, as many of you will know, is a C++ GUI framework produced by 
 formerly TrollTech and now acquired by Nokia for $xxx million (60 or 
 160M I read somewhere).  So Nokia pays megabucks for a GUI framework 
 that is C++ at its core.  Questions are, why is Qt worth so much to 
 Nokia, why is Qt so damn popular on the Linux platform and what is the 
 secret of Qt's success given that it is basically a C++ framework 
 wrapped in some "meta-object compiler"?
 
 Having now been exposed to Qt for a few weeks and beginning to 
 understand its architecture of "signals and slots" and a pre-processor 
 that compiles down to C++, I am now wondering whether D is powerful 
 enough to achieve the same sorts of things that Qt seems to be doing.
 
 If I understand correctly, Qt brings a degree of "reflection capability" 
 to C++ amongst other things.  Qt does a tremendous job of circumventing 
 the gaps in plain old C++ to achieve great goodness for GUI development 
 by way of its meta-object compiler.
 
 May I ask if others on this NG are across Qt and D might be capable of 
 slotting into some of this market for cross-platform GUI development.
 
 As always, discussions such as these can go anywhere and everywhere on 
 DigitalMars D NG, and that's much of the joy in staying with this NG if 
 only as a bystander at times.
 
 Cheers and best regards to all,
 
 Justin Johansson



you might want to check out this. Its state of the art, but its for a 
games envir

http://hybrid.team0xf.com/

Nick
May 08 2010
next sibling parent reply Andrej M. <none none.none> writes:
Nick B <nick_NOSPAM_.barbalich gmail.com> Wrote:

 
 
 you might want to check out this. Its state of the art, but its for a 
 games envir
 
 http://hybrid.team0xf.com/
 
 Nick


Almost turned blind right there. Fuzzy image on that homepage. :)
May 08 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 09/05/10 02:26, Andrej M. wrote:

 Almost turned blind right there. Fuzzy image on that homepage. :)


Ever heard the phrase "Don't judge a book by its cover"? I think that 
applies here, it's actually a very good GUI.
May 08 2010
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Robert Clipsham Wrote:


 On 09/05/10 02:26, Andrej M. wrote:

 Almost turned blind right there. Fuzzy image on that homepage. :)


 
 Ever heard the phrase "Don't judge a book by its cover"? I think that 
 applies here, it's actually a very good GUI.


I know, I saw that library before, I quite like it actually.

But it was 3 AM, and my eyes were turning red. :)
May 09 2010
prev sibling parent Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
Nick B wrote:

 Justin Johansson wrote:

 A week or two ago I started a thread suggesting that JavaScript might 
 be an interesting "VM" for D to target for web apps.  A thriving 
 discussion ensured and it was a delight to read the opinions posted by 
 many on this newsgroup.

 The idea came out of a frustration I had with having to develop a 
 rather complex application using browser-only technology, JavaScript 
 being somewhat awkward to deal with the task at hand.  In the process 
 of pondering the scalability of the programming task I looked to many 
 different ways of circumventing programming plain old JavaScript and 
 considered such things as Haxe, Cappuccino (Objective-J) and 
 SproutCore.  Then it occurred to me everything I liked about D and had 
 this fairy wish that D might be ideal for client side programming down 
 to JS.

 Since then, my client has gone completely off web apps for this 
 particular Linux-embedded hand-held mobile device and has mandated 
 that the apps will now be written as desktop apps in Qt.





 
 
 you might want to check out this. Its state of the art, but its for a 
 games environment.
 
 http://hybrid.team0xf.com/
 
 Nick


here is the short FAQ for Hybrid.
FAQ

     * Q: Does Hybrid support arbitrarily-shaped widgets?
     * A: Any widgets in Hybrid may use a custom shape. As long as it 	 
   plays well with the layout and rendering system, it should be OK.

     * Q: Does Hybrid support wobbly windows?
     * A: It's on the TODO list.

     * Q: Can I create a layout handler that treats widgets as physical 
objects in a dynamics simulation?
     * A: Yes, although widget rotations are not currently supported.

     * Q: Is Hybrid some SDL GUI?
     * A: No, but it's possible to create a SDL backend.

     * Q: What platforms does it run on?
     * A: In theory, all OpenGL and D-capable platforms that support 
Xlib or WinApi with Unicode should run the OpenGL backend. It has been 
tested on Windows XP, Vista, a few Linux distributions and FreeBSD.

     * Q: What's with the corn? :)
     * A: Hybrid food. Logo maker's idea :P

cheers
Nick
May 08 2010