Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defragmenting Qt and Uniting Our Ecosystem

blog.qt.digia.com

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Defragmenting Qt and Uniting Our Ecosystem

#81

Post by zura »

comex wrote: post #80
zura wrote: post #79

Earlier quoted context omitted.

When I hear "GUI" and "native", wxWidgets immediately pops up in my head, which is a decent framework and wraps native controls. I wish it had more publicity.

After trying to maintain a wxWidgets project about a year ago, I'm afraid I must disagree. It wraps native controls, but it is a horrible broken framework. Among other things, - It uses macros instead of C++ templates in order to support ancient compilers. - To handle events, you're supposed to make an enum for your controls and go through these EVENT_TABLE macros - it works, but generally it's a mess compared to nic…

Well, it has its drawbacks, but if native controls are a requirement, what alternative cross-platform good enough frameworks do we have?

Agree about your points, except you can Connect (dynamically) event handlers as in Qt's connect. From wx 3.0 you can actually Bind any function (i.e. it is not necessary to derive from wxEvtHandler). I always preferred this to Qt's blind, non-cpp, runtime evaluated connect's. At least you get a compiler error when it is not possible to connect.

Re: Defragmenting Qt and Uniting Our Ecosystem

#82

Post by mwfunk »

comex wrote: post #80
zura wrote: post #79

Earlier quoted context omitted.

When I hear "GUI" and "native", wxWidgets immediately pops up in my head, which is a decent framework and wraps native controls. I wish it had more publicity.

After trying to maintain a wxWidgets project about a year ago, I'm afraid I must disagree. It wraps native controls, but it is a horrible broken framework. Among other things, - It uses macros instead of C++ templates in order to support ancient compilers. - To handle events, you're supposed to make an enum for your controls and go through these EVENT_TABLE macros - it works, but generally it's a mess compared to nic…

wxWidgets looks like a reimplementation of MFC almost. This might be good for some people or bad for others. MFC is/was the Microsoft Foundation Classes, an OO framework for doing GUI development on Windows that dates back to 1992.

I'm guessing that when wxWidgets was originally written (also 1992!), the author(s) thought it would ease the transition from writing Windows-only apps to cross-platform apps. wxWidgets has a very similar class hierarchy and uses the same preprocessor techniques.

Not that knowing any of that background makes it any more pleasant to work with.

Re: Defragmenting Qt and Uniting Our Ecosystem

#83

Post by __david__ »

pavlov wrote: post #56
jordigh wrote: post #52

Earlier quoted context omitted.

I don't get it, why would anyone buy an LGPL exception? They want to keep their own private Qt fork and keep the modifications to Qt locked up? Is the cost of maintaining a private fork really that profitable and much lower than the cost of buying an LGPL exception? I'm just surprised that's a good business model too. I don't quite understand it. Maybe there's something I could read instead of asking the lazyweb?

LGPL allows only dynamic linking, i.e. the Qt libraries must remain separately loaded binaries and cannot be included into another project in object form. I could see some reasons why a company would want to statically link Qt libraries into a larger binary. For that they'll need the commercial license.

That's not precisely correct. You can statically link proprietary code with LGPL code and even distribute it, but you must also distribute the object code such that the user can re-link against newer/changed versions of the library to create a new static binary.

Re: Defragmenting Qt and Uniting Our Ecosystem

#84

Post by regularfry »

geraldcombs wrote: post #43
zanny wrote: post #31

Earlier quoted context omitted.

> it wanted MySQL as a dependency! For me, if you cannot build a well focused tool with a GUI toolkit it's not worth using. How is Wireshark not well focused? It probably uses a mysql database for its activity history (note: I didn't look, its just a common design pattern). I mean, it seems like a program like Wireshark would be better suited by a simpler sqlite database, but its really up to the project lead on thes…

Wireshark doesn't use MySQL or any other SQL backend. I'm not sure what sort of dependency chain would trigger the installation of MySQL but it's unusual to say the least.

Looking at the exherbo package list, it seems that the qt4 package has an optional (or opportunistic) dependency on mysql. And on sqlite. So it ought to be possible to do the equivalent of an `apt-get install --no-install-recommends` to get it without mysql.

Re: Defragmenting Qt and Uniting Our Ecosystem

#85

Post by regularfry »

codehero wrote: post #29

One thing you do not see fragmenting are command-line tools, because people tend to agree on their function(1). However, QT is huge; its scope goes far beyond GUI functionality, into string classes, SQL databases, networking, etc. And moc, its C++ code generator. More scope equals more possible disagreements, which necessarily entails fragmentation. I tried installing the Qt version of wireshark using exherbo (one of…

The mysql dependency is an exherbo packaging quirk. Hardly the fault of the the toolkit.

Re: Defragmenting Qt and Uniting Our Ecosystem

#86

Post by walterbell »

joezydeco wrote: post #55
milliams wrote: post #34

Earlier quoted context omitted.

I'm not sure it's going to affect it at all. What makes you think it will? All they're doing is spinning off a subsidiary to do what the Qt division is already doing.

And does that have a completely zero cost to accomplish? As I see it, leaving Qt entirely at the mercy of it's licensing revenue stream and not supplemented by Digia's consulting revenue stream means 1) Qt needs to sell more licenses going ahead or 2) Qt needs to charge more per license. The cost of doing business or paying developers will not be going down any time soon. It can only be flat or, more likely, up. And…

Are there other options to improve the financial health of the Qt ecosystem?

Re: Defragmenting Qt and Uniting Our Ecosystem

#87

Post by roel_v »

wolfgke wrote: post #67
zokier wrote: post #62

Earlier quoted context omitted.

There barely are any "native" controls on Windows either.

Then what is the function CreateWindow in User32.dll for (for all non-Windows developers: this is the WinAPI function to create a control on Windows; it returns a handle to it)? > http://msdn.microsoft.com/en-us/library/windows/desktop/ms63... The lpClassName parameter specifies the type of control to create.

The vast majority of controls on any Windows screen in 2014 is created with CreateWindow calls with that parameter set to some value that was added on by RegisterWindowClass though.

I still agree with you that it's silly to say that Windows hardly has 'native' controls.

Re: Defragmenting Qt and Uniting Our Ecosystem

#88

Post by onli »

e15ctr0n wrote: post #73
Groxx wrote: post #58

Earlier quoted context omitted.

Various *nix flavors, MySQL, Asterisk...

Also, see Wordpress[0][2] and Vanilla Forums[1][3]. They both offer an open source version that you can download and self-host, and a commercial offering which they host and you can customize through a limited set of themes and plugins. Open source, community edition: [0] http://wordpress.org/ [1] http://vanillaforums.org/ Hosted version with customization via themes and plugins: [2] https://wordpress.com/ [3] http:/…

I would have counted wordpress as a counter example: they offer both, but on different sites (wordpress.com vs wordpress.org).

Re: Defragmenting Qt and Uniting Our Ecosystem

#90

Post by joezydeco »

walterbell wrote: post #86
joezydeco wrote: post #55

Earlier quoted context omitted.

And does that have a completely zero cost to accomplish? As I see it, leaving Qt entirely at the mercy of it's licensing revenue stream and not supplemented by Digia's consulting revenue stream means 1) Qt needs to sell more licenses going ahead or 2) Qt needs to charge more per license. The cost of doing business or paying developers will not be going down any time soon. It can only be flat or, more likely, up. And…

Are there other options to improve the financial health of the Qt ecosystem?

Sadly, no. And it's distressing. Especially as I finish work on a UI system that's using it.
Post reply on HN