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

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/

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

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.

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>

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/

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

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

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

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.