As I understand it, that is not going to happen if you want Google's bless (i.e. their applications and Google Play Services, which are critical for some applications to work). Read Google’s iron grip on Android, especially page 3.

Since the Kindle OS counts as an incompatible version of Android, no major OEM is allowed to produce the Kindle Fire for Amazon. So when Amazon goes shopping for a manufacturer for its next tablet, it has to immediately cross Acer, Asus, Dell, Foxconn, Fujitsu, HTC, Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, Sony, Toshiba, and ZTE off the list. Currently, Amazon contracts Kindle manufacturing out to Quanta Computer, a company primarily known for making laptops. Amazon probably doesn't have many other choices.

Seems like a terrible move against market freedom. Even worse for consumer freedom.

OK, I give up. The fact that you still think that using a string as a vector of bytes is comparable with a class that is capable of understanding the text it stores, with some encoding conversion capabilities, and more, should be a clear enough indication that we don't have the same expectations on what is a class for human text. And the fact that you still try to put words in my mouth signals that it isn't worth wasting time with you.

Luckily enough that people admit that you should use a Unicode library, because even C++11 supports Unicode terribly, and there is work underway to improve it. Meanwhile, I'm happy to have QString. And I'll be happier if with Qt6 there is a type that can replace it.

Read again the thread. You said that MOC is a precompiler (wrong, is a code generator), and that it transforms the input text in ways impossible with C macros (even more wrong).

I said "Is the classic C preprocessor" in response to "these keywords are pre-processed by a special compilation step into C++ code" which is absolutely right.

And you still fail to explain how you can use std::string for text instead of for low level manipulation of the string bytes.

Next time you write about something, use it first, please. MOC is not a precompiler nor "transforms" input text. It generates code. Like a bazillion other tools that generate perfectly standard C++ code.

Execellent. That's why everyone is using std::string in i18n-ed text, and why C++11 didn't introduce new string types.

But yes, call people stupid as long as you want. Now you are probably right.

Thanks for the hint, but I've found the Wikipedia page on it (and the first results on the web) not very exciting. However, Software for Infrastructure from Stroustrup has a really cool example on how to do it very pretty. It uses user-defined literals to create expressions such as "Speed s = 10m/2s".

My C++ compiler doesn't compile "#include" either. Because it doesn't have to. You need to run the file through a preprocessor. That's part of the standard, and is unavoidable at this time.

If don't like the use of the C preprocessor, fine. But don't lie saying that is not "standard". It might not be the part of the standard that you like the most, but is standard. And using a tool for generating code is perfectly normal. Or is protobuf no longer a "standard C++" tool?

There is a proof of concept clang plugin that would provide the QObject features without MOC. That doesn't make it better in all use cases, since that would be tied to a compiler.

No, seriosly, one might not like one solution to a problem. But having no solution is worse. If one day there is a better solution, the Qt project will adopt it. But right now there isn't one that fills all the features provided by Qt with the current implementation.

You've made me ruin my moderation in this thread, but I can't let such wrong statements unreplied.

Wrong. Is not a special compilation step. Is the classic C preprocessor, which is as standard C++ as any other feature of the language. Does this mean that udev is not standard C because it defines a foreach with a macro?

Qt has its own notion of string, because till C++11 there was no string type that allowed Unicode. Likewise for threads. Besides, QThread has features to integrate with an event loop, notion that the standard library doesn't have.

How the hell were programs written with WxWidgets using threads? Relying on Windows POSIX capabilities? Seriously.

And don't even try again the "but Qt duplicates all the containers". Qt's containers use a very different implementation (e.g. with implicit sharing), and so have pros and cons against STL containers. And Qt's containers have compatibility APIs with the STL ones as well. And you are not forced to use them at all. If some part of the API exposes a Qt container, you can convert to and from STL, since such functions are provided.

The C++ standard library is now much better than it used to be, but Qt started in an age where the STL wasn't even an acceptable option in all the environments where it had to run.

Certainly not. People is migrating from VxWidgets (e.g. VLC) to Qt, and not the other way around. Why it might be? Maybe is because is such a good application framework that is convenient to use, even for non-graphical applications.

The problem wasn't if Nokia should have killed Symbian, the problem is how.

They told the world all their flagship products sucked, and they would replace them... eventually. They were only ready to deliver a first device almost a year after, and they killed Symbian for good much time afterwards. They should have lied, and tell that they were only adding Windows Phone to their portfolio, and then time will tell.

Or better: they should have done an embrace and extend to the whole Android ecosystem. Elop was selling that this was a "war of ecosystems", so Nokia should have said "The operating sytem is irrelevant. Just use Qt to target Symbian, MeeGo, Android, and next year iOS".

They could have taken several paths, and they took the worst, in the worst possible way.

Thank you for insulting the other companies and the individuals that work hard on Qt. Digia maybe owns the trademark and the right/obligation to relicense, but is not the owner of Qt, and certainly not the only contributor. See the statistics about Qt created by Thiago Macieira.

The Android port started as a community only project, by the way.

I am perfectly aware that for some people (most people?) playing the video embedded in the browser might be the most straightforward way of playing it. For some it might be somewhat challenging finding the "save as" option in the context menu, and deciding a path that later they have to find again, but...

Embedded video players are the worst video player ever. Ever. There, I said it.

I'm following a class in Coursera, and the first thing I do is save the videos as local files and play them with VLC. When I press the spacebar to jot down something, sometimes the video pauses, sometimes an invisible blank character is written in a text field of the page, or some link that has the focus is accidentally clicked.

If the embedded player in the browser can't get right something as simple as toggling the playback, don't get me started on the convenient shortcuts that a video player has to play faster and slower, or going some seconds/minutes/hours forward and backward.

Browsers are nice, and some cool fancy webpages can be done combinating transitions, text, images, and yes, video, but attempting that a browser is going to be a good video player is never going to happen.

This is as stupid as saying that you are going to complain in all stories about Foo that is not Bar. I've seen long term X11 developers move from XFree86 to XOrg, and now to Wayland (I have a bad memory, but for example, Keith Packard and Daniel Stone). I've read them claiming that Wayland will probably have even better performance over the network because it will have less roundtrips. And still we have to accept that people complain on what others are doing? Even though they know better? That's trolling.

Wrong. The problem are not the 3800 gadgets. After all, when you run a program through ssh+x11, is just the application. The problem is that normally the application, if is something meaningful, requires to interoperate with other tools, and normally such tools, frameworks or services don't comunicate properly through ssh+x11.

I've tried to achive such allegedly cool network transparency on my local network several times, and has always been useless because real world applications use things like D-BUS.

Some pearls from the original conversation. Alan Pope:

We're agile enough that we can migrate our desktop to QML if that's the decision that gets made. Unity has existed on four toolkits already, what's a fifth between friends ;)

Daniel Stone on wether Ubuntu Phone uses Wayland or not:

No idea, no-one from the project will respond even to direct questions. They've said in the past that they're writing their own window system, which is pretty tragicomic.

And the best one, the only thing that Mark Shuttleworth had to say:

As Kipling put it:

If you can bear to hear the truth you've spoken
Twisted by knaves to make a trap for fools

The rest of the poem is pretty apt, too. My kingdom for a link.
Mark

I wish success to Ubuntu Phone, really, but it hurts me a little bit that it receives the same or more attention from the community than Plasma Active, when the later delivered the same or more (specially if you value open governance and source code from day 1), with way less resources.

I doubt Aaron has many complaints with the technology used in Ubuntu Phone, because that's Qt Quick using QML, the same is used in Plasma. The thing is, Plasma was conceived as a very flexible way to create the primary user interface (that is, the visible thing that is not the applications). At that time, that was the "desktop shell" (Plasma Desktop), and nowadays is also a touch-device user interface and others (Plasma Active, Plasma Media Center, etc.).

The vision the KDE guys had was right, and with few resources have created a great framework. Instead, Canonical had to write Unity several times. The "normal" Unity I don't even remember in what's written (GTK+, Clutter, Nux... can't follow it), but I remember that there is the Qt-based Unity-2D (dead, AFAIK) and the new Ubuntu Phone version, which uses Qt again.

They could have saved tons of resources by choosing the technology and sticking a bit to it, helping to develop it. And now they claim they provide a seamless user experience across devices. Well, that could be true, but not using the same technologies, so the user experience is not going to be consistent with different bugs, different features, because the code bases are totally different.

There could be many reasons to that. One might be becase Vim has a limited interface to writing plugins. There are plugins that use the Python interface to create different processes, or one that uses Vim's libcall() to run a task asynchronously, but are just nice hacks that work acceptably, but not great.

I've been quite impressed by Shougo's plugins, becase, for example, Unite.vim, loads files from the disk in a background task that doesn't make Vim unresponsive, but is still limited in that it seems Vim can not have some kind of timer that polls the background job to update the UI (even less a fully asynchronous interface). The solution is probably resort to using Vim with the client-server interface, but I don't think is the common case of most Vim users.

On the other hand, lately I've been suffering frequent blocks and even full crashes of Vim when using the clang_complete plugin, because uses Python in some unsafe way.

In short, a new Vim implementation that doesn't suffer from such limitations would be welcome. I doubt that making that implementation on top of Emacs is the right way, but who knows. Ideally it should be native, but Vim's development is a bit slow. I can't find the relevant links now, but I remember a conversation on IRC that pointed out to a patch that a YankAdded (or something like that) autocommand. The patch was simple, and it would make plugins like yankring and yankstack almost trivial, since instead of doing map tricks, they could plug into such autocommand and work comfortably. But the patch is about 18 months old, and still has not been applied. Bram Molenaar's response is that bug fixes have priority over features (which makes all the sense of the world), but gives a bad impression over the scalability of Vim's development. Last time I checked the version control, Bram was the only one committing.