Live data from Hacker News

Ask HN: Time to give up on Qt?

news.ycombinator.com

61–70 of 72 posts

Re: Ask HN: Time to give up on Qt?

#61
post #33

Earlier quoted context omitted.

@Jarred. Thanks for sharing about the CEF project. I need to build a cross-platform GUI in Python if possible and wanted to use wxWidgets with the python binding. Now CEF seems really great: The possibility to make an HTML5-Javascript App and having also the opportunity to deploy it on a web-server is really exiting. I will have to evaluate it, seems really cool. Can you access files on the file system as a normal na…

Adobe Bracket( https://github.com/adobe/brackets/ ) are using it and they are editing files from the disk. From looking at the source of their implementation I think that this is how you access system functionality https://github.com/adobe/brackets-app/blob/master/src/win/ce...

Those two flags only enable local file access via XHR, you still have to know the exact path to the file and you can't write anything. It would be less tricky and more secure to just handle file i/o with native code.

Re: Ask HN: Time to give up on Qt?

#62
post #35

> Something else? GTK+ still doesn't look very native on Windows or OS X, so for many cross-platform apps it's not a viable option. GTK+ can look just like Windows XP, Windows 7, Mac OS X. It has themeing capability.

You can skin GTK widgets, but it's like putting lipstick on a pig. For truly native look you would have to reimplement most widgets so that they follow OSX HIG.

Re: Ask HN: Time to give up on Qt?

#63
I did a lot of work on the Win32 backend for GTK+ a few years ago, but then when I started at Canonical I stopped working on that. Nobody else really picked it up either. Tor Lillqvist was the original developer of this, and I think he's basically stopped working on it as well.

It's been awhile since I used wxWidgets, but I had an absolutely awful time with it. Honestly if Qt wasn't around, I would choose to contribute to GTK+ to get it back into shape rather than be forced to use fucking wxWidgets.

If I were in the situation of needing to work on a cross-platform GUI app again, having the experience I already have with GTK+ and its Win32 backend, I would choose to go back to contributing to the Win32 backend and write my app using GTK+ (or probably Gtk# with .NET and Mono). But if I were in your position and did not already have both the experience with the Gdk backend and the predisposition to use GTK+, I would absolutely use Qt.

Re: Ask HN: Time to give up on Qt?

#64
post #34

Earlier quoted context omitted.

The difference is that each environment for non-Web apps - Mac, Windows, KDE etc - has each own somewhat well defined look and feel, that applications should follow in order to feel native. That's not true for Web apps in different Web browsers - they are supposed to look the same. Qt compromises that native experience by letting you target multiple platforms. For Web toolkits, at worst you'll end up with an app that…

I don't know if you've used Qt or not, but one of the things that always impressed me about it was how good it was at defining the abstraction just right at the level so that out of box each platform's app did in fact look right on that platform and fit in with the same look and feel. Obviously that doesn't catch everything, but the areas where Qt apps didn't fit perfectly into the platform's native look and feel by…

I've used Qt a lot. In fact, I'm still a big fan and wasn't trying to sound negative about it in any way. I absolutely agree that Qt does a tremendous job at abstracting away the differences but still, it's the little details that matter and no toolkit could address them all. Things like ribbons on Windows. Multi touch support, cover flow and proper OS X-like multiple window management on Mac. Not to mention mobile. For big applications, these glitches add up and in no time you find yourself resorting to way too many native workarounds.

But my main point was to that cross-browser Web toolkits and cross-platform GUI toolkits are apples and oranges. On the Web there are no UI guidelines. It's essentially free for all. The chrome of the Web browser constitutes a clear separation point between the native experience and the Web experience, which makes it possible for things like Gmail not to feel hostile on Mac, Linux, Windows and any other Web-enabled environment. Whether or not that's good for UX is irrelevant, the fact remains is that Web apps have never tried to integrate seamlessly with the look and feel of the host environment and the users have grown accustomed to that.

Re: Ask HN: Time to give up on Qt?

#65
post #3

Qt -- particularly the desktop version -- is still being supported and maintained by Digia (and the Qt community). Digia have been fairly aggressive in insisting that Qt isn't going anywhere and touting the features of upcoming Qt 5. There really is no better cross-platform GUI library at this time. To jump ship from Qt now, I think, is a fool's move that will create hassle later on down the line.

The guys doing new stuff are/were working for Nokia though, the commercial support part was split off from Nokia and sold to Digia. Judging from Digia's front page, Qt isn't a big part of the company. Are they interested, rich and capable enough to ramp up staff, expertise and community support to take over Qt development? I haven't paid close attention but how visible have they been in the open Qt development scene?

Re: Ask HN: Time to give up on Qt?

#66
post #4

Earlier quoted context omitted.

stuff that runs in chrome ? that's not really a desktop app.

And Windows 8.

Windows 8 HTML5 apps are designed completely differently from on-the-Web HTML5 apps and Native Client apps.

the carryover is significant but you don't get a Windows 8 port for free.

Re: Ask HN: Time to give up on Qt?

#67
post #66

Earlier quoted context omitted.

And Windows 8.

Windows 8 HTML5 apps are designed completely differently from on-the-Web HTML5 apps and Native Client apps. the carryover is significant but you don't get a Windows 8 port for free.

Well, event for web apps you have to make sure all the browser work as expected...

Re: Ask HN: Time to give up on Qt?

#68

Earlier quoted context omitted.

Adobe Bracket( https://github.com/adobe/brackets/ ) are using it and they are editing files from the disk. From looking at the source of their implementation I think that this is how you access system functionality https://github.com/adobe/brackets-app/blob/master/src/win/ce...

Those two flags only enable local file access via XHR, you still have to know the exact path to the file and you can't write anything. It would be less tricky and more secure to just handle file i/o with native code.

@feronull @jarek-foksa. Ok thanks for the info. I agree with jarek-foksa it is still a bit tricksy and I would prefer to access the file i/o with native code. What does it means ? Do I need to build my own "file i/o" lib in c to interface with it ? Does it exist somewhere ? Would you have an example ? Many thanks
Post reply on HN