On Fri, Jan 30, 2015 at 1:59 AM, Rutledge Shawn <[email protected]> wrote: > > On 29 Jan 2015, at 23:46, Olivier Goffart <[email protected]> wrote: > >> On Thursday 29 January 2015 23:24:51 Robin Burchell wrote: >>> tl;dr: I'd like to request a behavior break in QML's Text element. I >>> would like to change the default value of Text::textFormat from >>> Text.AutoText to Text.PlainText.
Actually, the default should be Text.StyledText. It contains the core features of RichText without the big performance hit. >> Personally, that's what I am doing in the QML project I am working on >> (We had to develop our own set of component (it was started before QtQuick >> controls), and the text component default to Test.PlainText) >> >> Given the security implication, I do believe PlainText should be the default. If you're using user-generated values you should certainly set PlainText (until we have remote references disabled), but it's not the common case for Text. It's the basic element used to put your UI text on the screen anywhere in the app. >> >> However, I think it's too much of a breaking change for anyone who has used >> html tags on purpose and did not explicitly set the format. >> >> Is it possible to do the change if we do >> import QtQuick 2.5 >> That is, the default of textFormat changes depending on the number in the >> import statement. > > +1 to that. If you update your import versions, you can expect some minor > changes; and if you are editing the QML anyway, it implies that you are ready > to take the time to re-test your application and make small fixes and > improvements. I agree in theory. The biggest concern of changing the default value is if the runtime updates underneath your application and breaks it (super bad!), so if we can tie the change to a new import version then we avoid that scenario while helping new applications quicker. It's not without drawbacks, as have been pointed out, but it's manageable. In practice, we don't do this anywhere (default value changes based on import version) and we don't have language support for doing it. By the time we get to instantiating a QQuickText element, we're past the stage with import information. So I would like to resolve it this way, but it's not feasible. And I do not want to risk breaking existing applications. So I recommend this change should wait until QtQuick 3.0. > > On 29 Jan 2015, at 23:24, Robin Burchell <[email protected]> wrote: >> Ideally, we could also provide tooling changes to help cover the >> migration, by warning in QQuickTextItem::setText if HTML was >> discovered and an explicit format had not been set, or perhaps in >> other custom tooling aids. This is something that we could add now, if you want to make AutoText warn on use (something like: "Text.AutoText determines this is plain text. Please set Text.PlainText as Text.AutoText may be removed in QtQuick 3.0"). The details of the message and its performance impact would be up for a separate discussion, but it helps guide users without breaking any existing applications. >> Seperately, we may want to look at a restriction on the loading of >> remote resources in Text. I can understand allowing remote URIs in >> Image, but Text seems like an unexpected behavior to me. > > If we do that, there needs to be a way to override the restriction, maybe by > adding a property to control whether loading of anything outside the QML is > allowed. It would IMO be OK to have this property false by default, since > the majority of use cases don’t need it. Or we can add the property now, but default it to true (no behavior break). Then we can change the default to false next major version, which I agree seems like a more sensible default. Restricting remote URIs in RichText and StyledText is my biggest concern about malicious user generated content in rich text (it could force a request for an arbitrary external resource). So disabling them and using StyledText would be the best defaults I think. Shame we have to wait. > I can imagine that loading remote resources is a useful feature which some > apps are relying on. In fact, a single Text element is practically a web > browser already, for certain limited purposes. It's kindof cool to forego > the need for a real web engine if you need only to display lightweight > mid-90’s HTML. Which is really useful while the WebView is in flux or unavailable. Before there was a WebView, we used Text to display HTML all the time. By the time we had a choice we were already used to it. But for tables and certain text/image layouts, HTML is still easier to use than QML (just try inline images, even now). I'm optimistic that by QtQuick 3.0 QML will be preferred for most mid-90's-HTML style content and there will be a mature and efficient WebView available as well, which will decrease use of the rich text features. > I also think we should add a source URL property like Image has. It’s > unfortunate to need to rely on ugly hacks like this one > http://rschroll.github.io/beru/2013/08/12/opening-a-file-in-qml.html just to > be able to read a file. And I/O should be more agnostic about local and > remote resources, as long as the fact that you are doing I/O is explicit > rather than unintended. > > Sometimes you want network access to be really easy. Other times you want to > avoid security problems that come from unintentional network or filesystem > access. So we need to make it easy to go either direction, and enforce it > consistently. On this point, I'm hoping that we can make QML more flexible. Depending on how your configure your QQmlEngine, it could be as locked down as HTML or as open as native C. Which I currently imagine to be implemented mainly by import restrictions and easy local file I/O would go in a separate QtQml.* import (like how creating new windows goes in a separate QtQuick.Window import). That's the goal, and makes it easy in both directions, but it does mean local I/O should be handled differently in order to be consistent down the line. Until then we need to maintain the current behavior where a custom QNetworkAccessManager can intelligently deny most requests, routing through QNAM is why I/O is remote focused right now. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
