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 and slots look similar to C# events. This can easily be implemented 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 
 slots look similar to C# events. This can easily be implemented 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.

When I looked into Qt, that was my impression as well. Seemed like a slightly more clumbsy/awkward version of C#'s events. That plus D's 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 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 next sibling parent 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
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
 

 
         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