Re: [Development] Using semicolons in JS (QML)
FWIW, in unity8 (reasonably big QML application) we agreed to not use
semicolons for declarative code unless you really want to write some
things into a single line and need them, but always use semicolons for
imperative code.
This has served us very well over the past years, seems consistent and
everyone in the team agrees this makes sense. Of course, your opinion
may differ but I thought I'd share nevertheless...
example:
Button {
anchors { left: parent.left; right: parent.right }
height: 100
text: "foobar"
onClicked: {
doSomething();
soSomeMoreStuff();
}
onReleased: doSomethingElse();
}
Br,
Michael
On 30.09.2016 14:19, Kai Koehne wrote:
> Hi,
>
>
>
> It’s Friday, so time for some bikeshedding ;)
>
>
>
>
>
> As you might know, the semicolon as a statement separator in JavaScript
> is optional. That is, most of the time you can just separate commands
>
> by newlines. There are a few pathological cases [1] though where a
> semicolon is needed. It seems the JavaScript world is divided on the topic
>
> whether to use semicolons by default though.
>
>
>
> Now I do not care that much about JavaScript as a language, but I do
> care about consistency in the Qt documentation and examples. Unfortunately
>
> we didn’t seem to have made a call so far what to prefer. Even our
> minimal “QML coding conventions” at
> http://doc.qt.io/qt-5/qml-codingconventions.html
>
> feature a semicolon in places, and in others no semicolon.
>
>
>
> To make a proposal: Let’s use semicolons in imperative JS parts of QML
> in our examples and documentation.
>
> Apart from being on the safe side regarding some pathological cases, it
> also makes the difference between declarative QML bindings and
>
> imperative JS code more explicit.
>
>
>
> Now I do realize that the right side of QML bindings is actually
> JavaScript. But no, I do not want to propose that now every binding ends
> with a ‘;’.
>
> A good rule of thumb might be that semicolons should be used inside
> either function X() {} or OnSignalHandler: {} blocks, or in .js files.
>
>
>
> Thoughts?
>
>
>
> Kai
>
>
>
> [1]: See e.g.
> http://benalman.com/news/2013/01/advice-javascript-semicolon-haters/
>
>
>
>
>
>
>
> --
>
>
>
> Kai Köhne, Senior Manager R&D | The Qt Company
>
>
>
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
>
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
> 144331 B
>
>
>
> Qt World Summit 2016 | Pier 27, San Francisco, CA
>
> Experience Exponential Potential on October 18-20
>
> www.qtworldsummit.com
>
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
On 20.07.2016 11:12, Edward Welbourne wrote: > Prav said: >> Another problem will be with icons. They will scale bad. We are used >> to make icons with versions like _x2, _x3 ... and what we going to do >> if scale factor will be fractional? ... have icons versions like _1.1 >> _1.2 _1.3? Probably we need to rethink why in the world we make so >> many copies of one icon in compile time if we can make one SVG icon >> which can be scaled to any size without loss of crispness in >> runtime. Especially material design makes this easier because we >> mostly see only contours in material design icons. So the next step >> for Qt can be supporting of SVG-icons as main and preferable way for >> setting icons. In this case icons can be scaled clearly. > > I am baffled that anyone does the _x2, etc., approach to icons any more, > when most icons are indeed well-suited to SVG - in most cases, a tiny > SVG, smaller (in file-size) than any one of the many icons it makes > redundant, can do an excellent job of presenting the clear visual that > the icon is supposed to provide. Making many larger files seems to > serve no purpose - other than letting web-or-UI designers bill their > clients for large amounts of pointless make-work. Well, in smaller icons you can have less details than in bigger icons, so having multiple icons does make sense. Also rendering svg icons is slower than bitmaps so in some cases that won't work out either. What we do in ubuntu is to find the closes available icon that's larger than the current ui scale and then scale it down. In case no larger one is available we fall back to the closest available smaller one and scale it up. And as I said before, we also use icon_x2.svg and icon_x3.svg for different levels of details in the image. > > Then again, our SVG support is embarrassingly poor, > > Eddy. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
On 22.06.2016 14:46, Morten Sorvig wrote: > >> On 22 Jun 2016, at 10:30, Michael Zanetti >> wrote: >> >> >> >> On 20.06.2016 15:00, Morten Sorvig wrote: >>> >>> Another reason to not spend time on it would be that integer is, or is going >>> to be, the dominating use case. Wayland and Apple is integer, so are most of >>> the Android device categories. For Windows and desktop in general there are >>> currently lots of fractional hardware and configurations. >> >> I don't think this is true. From all the devices (phones/tablets) we >> support Ubuntu on, none is a full integer multiplier. I really don't see >> how it is going to fly if only full integers are supported. After all, >> all the Ubuntu Devices are actually based on Android hardware, so surely >> there the same issue would happen, no? >> > > What I have for Android devices are tables like this: (there are various > sources, see below) > > 0.75 - ldpi > 1.0 - dpi > 1.5 - hdpi > 2.0 - xhdpi > 3.0 - xxhdpi > 4.0 - xxxhdpi > > The factor here is DisplayMetrics.density. This suggests integer factors, or > at least a convergence towards integer factors if we allow that new Android > devices are xhdpi or better. > > It think what is happening is that the hardware may be non-integer, but then > Android maps that to a device class with a fixed scale factor. We can use that > scale factor in Qt - any error introduced by it (if the hardware is some > fraction > between classes) will be matched by the native UI. > > If Qt applications are going to see fractional factors on Ubuntu then that’s > a point in favor of making Qt work better in that configuration. Hmm, I see... So what we are using is this: Nexus 4: 2.25 Nexus 7: 2.25 Nexus 10: 2.5 bq E4.5: 1.625 Meizu Pro 5: 2.625 Because of this we're currently not using the devicePixelRatio() API. Instead, that one is set to 1 and we add an additional layer in our toolkit on top. So we'd use units.gu(1) on the application level to express 8 pixels on a scale factor of 1. That method then returns device pixels based on the scale factor, rounding it to full integers after the scaling. Those values are calculated in a way that we'd get as close as possible to a consistent look and feel of the platform. For example, for a 4 to 5 inch screen we try to have 40 grid units (units.gu(40)) in width. 5 to 6 inch devices would have 50 grid units in width and so on. This gives a rather consistent look and feel of the platform across different sizes and pixel densities. Using this method in our toolkit on top of Qt is obviously not ideal for a (rather big) number of reasons and we *really* would like to drop this in favor of the in-Qt high dpi mechanism. For that however, it would need to match a number of requirements: * floating point scaling * different scale factor per window * dynamically changing scale factor * some sort of language that allows developers to use virtual sizes, ideally we'd be able to register our grid unit stuff as that's what all our design has evolved around. I really think that in the mid to long run, all of those requirements will become natural on all platforms. Now that people start connecting external displays to their phones, or now that desktop monitors come with different pixel densities, dragging a window from one screen to another with a different pixel density will become something we encounter more and more often. Some more details on this can be found in an earlier mail on this topic: http://lists.qt-project.org/pipermail/development/2016-February/024954.html Best regards, Michael signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
On 20.06.2016 15:00, Morten Sorvig wrote: > >> On 17 Jun 2016, at 14:54, Frank Hemer wrote: >> >> Can you give a hint on what causes these glitches and how to avoid them? >> I'm not talking about general usage of fractional methods for painting here. >> >> For example when drawing to a pixmap (sized for the 'real' screen >> resolution) >> and then updating just a sub-rectangle of this pixmap, for some (and really >> only some) fractional scale factor values there are glitches around that sub- >> rectangle where the background color of the window shines through. >> What is causing this? > > I have not analyzed these in detail, but my guess would be rounding errors > due to fractional coordinates. So you could look at the update code (in > QPainter > or the paint engine) and make sure coordinates are rounded to _include_ > partially covered pixels. > >> >> What is the reason for not aiming towards supporting fractional scale >> factors >> on the long run? What is the real challenge here? >> > > Good question! > > If you ask me I think the Qt project should move towards supporting this > (taking > care to avoid maintenance traps such as the native styles). One of the > challenges > is simply available time and resources for doing the work. But even today Qt > Creator > at QT_SCALE_FACTOR=1.3 is a usable application. > > Another reason to not spend time on it would be that integer is, or is going > to be, the dominating use case. Wayland and Apple is integer, so are most of > the Android device categories. For Windows and desktop in general there are > currently lots of fractional hardware and configurations. I don't think this is true. From all the devices (phones/tablets) we support Ubuntu on, none is a full integer multiplier. I really don't see how it is going to fly if only full integers are supported. After all, all the Ubuntu Devices are actually based on Android hardware, so surely there the same issue would happen, no? signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Testability Driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 28.05.2015 16:36, Friedemann Kleint wrote: > Hi, > >> adly we're not using it in Canonical any more. TDriver did a good >> job > with Qt4 apps. But it was desired to have a single tool to test > multiple toolkits (Qt & GTK & Html5) using python, so > >we ended > up building our own: AutoPilot [1]. IMO TDriver is more powerful > though. > > Does this mean the code introduced by > https://codereview.qt-project.org/#/c/66513/ can be removed ? - No > need to keep dead code? No, we'd still need that. The "autopilot" driver uses the same mechanism to be loaded. Br, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlVnLYAACgkQXJwWsxE5x7hyUACdF5mRG/PgPA7p9j1RJzDy+O7m 7MEAoIsW/ow10TKwdu9/tqKr1EqnIfHC =wOf8 -END PGP SIGNATURE- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rich Text Editor using QML
Hi, I've been working on that last week for an Evernote client for Ubuntu Phone. Seems to work reasonably well. Here's the diff of just the edit mode: https://code.launchpad.net/~mzanetti/reminders-app/new-edit-mode/+merge/241226 Here's the complete app code: http://bazaar.launchpad.net/~reminders-app-dev/reminders-app/trunk/files Note that the edit mode in here is not 100% complete yet (doesn't support complex formatting yet - you'll understand what that is while working on it or reading the review comments) but I'm confident it can be achieved nicely this way. Here's a screenshot of what it can do so far: http://i.imgur.com/dejnDU7.png Long story, short, yes, you are in the right direction, at least I solved it the same way. Hope this helps, Michael On 14.11.2014 10:06, Yann Levreau wrote: Hi everybody! I am starting a new project and I am looking for some advice about what kind of Qt/QML controls I should use. The purpose is to develop an rich text editor using QML. Basically I am going to develop IDE features. Until now I have tried the TextArea QML Control. Using this control I get a QQuickTextDocumentandQTextDocumenton the C++ side. Am I in the right direction ? Is there any limitations using this control that I should know ? Or maybe there is better way to implement this (using QWebView or a simple QTextEdit, ... ). Thanks a lot ! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ListView.positionViewAtIndex() seems to be unreliable during object initialization
Hi,
I think this is related to a similar issue I've been running into. We
identified it to be related to the snapping of the ListView which makes it snap
to somewhere else then one would expect for the initial positioning.
In your example there seems to be an issue that you set snapMode to
ListView.SnapPosition which doesn't seem to be a valid value for that (its
defined for positionViewAtIndex only) so I'm not sure which snap mode is
enabled in your case. In any case, you might want to dig into that direction.
We came up with a patch that would get around it. However, due to some other
ramifications that patch never landed.
Here's the according bug report and patch:
https://bugreports.qt-project.org/browse/QTBUG-32251
https://codereview.qt-project.org/#change,60535
The related code can be found here:
http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/qml/Launcher/LauncherPanel.qml
Hope this helps,
Michael
On Saturday 31 May 2014 23:19:44 Baldo Davide wrote:
> Hello,
>
> I'm having in issue with ListView.positionViewAtIndex(), i'm changing the
> index with the last selection of the user in Component.onCompleted(),
> but positionViewAtIndex() seems to behave randomly: sometime the listview
> is moved correctly, sometime is off by 1 or 2 items.
> I've been having this issue since 5.0 and i can still reproduce it on 5.3,
> i spent several hours trying to debug it but without luck, in the end i
> added a workaround:
>
> Timer {
>
> interval: 100
>
> repeat: false
>
> running: true
>
> onTriggered: {
>
> main.alignIndex()
>
> }
>
> }.
> but it's really a bad solution, and it's even visible.
>
> Is it wrong to call positionViewAtIndex() inside Component.onCompleted()?
> If so, when should i call it?
>
> The component is a simple digit selector.
>
> --- CODE ---
>
> import QtQuick 2.0
>
>
> Rectangle {
>
> id: main
>
> width: 60
>
> height: 180
>
> color: "transparent"
>
> border.color: "black"
>
> border.width: 3
>
> radius: 3
>
> clip: true
>
>
> property int initialDigit: 0;
>
> property int digit: 0;
>
> property string textColor: "violet";
>
>
> function alignIndex()
>
> {
>
> var newIndex = main.digit + 50
>
> listView.positionViewAtIndex(newIndex,ListView.Center);
>
> }
>
>
> /** workaround, force refresh after initialization **/
>
> Timer {
>
> interval: 100
>
> repeat: false
>
> running: true
>
> onTriggered: {
>
> main.alignIndex()
>
> }
>
> }
>
>
> onDigitChanged: {
>
> if( main.digit >= 10 ) {
>
> main.digit = main.digit % 10
>
> }
>
> main.alignIndex()
>
> }
>
>
> Component.onCompleted: {
>
> for( var i = 0; i < 10; i +=1 )
>
> {
>
> for( var n = 0; n < 10; n += 1 )
>
> {
>
> listModel.append({
>
> digit: n
>
> })
>
> }
>
> }
>
>
> //console.log("initial digit: "+initialDigit)
>
> digit = initialDigit
>
> alignIndex();
>
> }
>
>
> Timer {
>
> running: true
>
> repeat: false
>
> interval: 1
>
> onTriggered: {
>
> main.alignIndex()
>
> }
>
> }
>
>
> ListView {
>
> id: listView
>
> anchors.fill: parent
>
>
> snapMode: ListView.SnapPosition
>
>
> Rectangle {
>
> anchors.left: listView.left
>
> anchors.right: listView.right
>
> anchors.margins: 3
>
> height: 60 * 0.8
>
> y: main.height/2.0 - height/2.0 - 3
>
> color: "#37ff"
>
> }
>
>
> onMovementEnded: {
>
> main.digit = listView.indexAt(
>
> listView.contentX,
>
> listView.contentY + main.height/2.0
>
> ) % 10
>
> }
>
>
> model: ListModel {
>
> id: listModel
>
> }
>
>
> orientation: ListView.Vertical
>
>
> delegate: Component
>
> {
>
> id: digitDelegate;
>
> Item
>
> {
>
> height: 60
>
> width: main.width
>
> Text {
>
> id: digitText
>
> anchors.fill: parent
>
> text: digit
>
> font.pixelSize: parent.height * 0.8
>
> verticalAlignment: Text.Center
>
> horizontalAlignment: Text.Center
>
>
> Component.onCompleted: {
>
> digitText.color = main.textColor
>
> }
>
> }
>
> }
>
> }
>
> }
>
> }
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtLocation offline Navigation support
On Monday 28 October 2013 07:34:08 Thiago Macieira wrote: > On segunda-feira, 28 de outubro de 2013 12:53:53, John Layt wrote: > > Until QtLocation does offer offline maps and navigation, you may want > > to consider Marble (http://marble.kde.org) which besides being a cool > > mapping app also provides a pure-Qt library for online and offline > > mapping and navigation. It's currently only available for Qt4, but > > patches for Qt5 support are currently under review so should be > > available soon. > > We've been using Marble on Subsurface and its lack of support for Qt 5 is > what holding Subsurface back from Qt 5 too. I've spent some time to port Marble to Qt5 actually. Current state is that the QWidget version works fine with Qt5 (performs even better than the Qt4 one) but the plugin structure does still rely on QGraphicsItem which obviously doesn't play well with QtQuick >= 2.0. We hope to tackle that one soonish. Any help is welcome. > > Please note that MarbleWidgets does appear to have a few quirks when > installed outside of KDE. It seems to be tailored for being run as part of > Marble itself, so it behaves more as an application library than a > general-purpose library. I agree that there are some quirks, but if you don't need each and every feature I think there are good chances you'll be able to embed it in another application. Br, Michael ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
On Tuesday 01 October 2013 12:25:37 Kate Alhola wrote: > On Tue, Oct 1, 2013 at 11:23 AM, Michael Zanetti < > > michael.zane...@canonical.com> wrote: > > On Monday 30 September 2013 13:09:53 Thiago Macieira wrote: > > > On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote: > > > > >As far as I know from my colleague, it misses some necessary API -- > > > > >at > > > > >least the connection state changes notification and device > > > > disappearing > > > > > > >notification. > > > > >We could prepare some patches during the next week or two, though > > > > >QtBluetooth probably needs few more revisions and API > > > > changes/fixes...but > > > > > > >we can't do too much in case of API freeze, you know... > > > > > > > > A missing feature is for me not enough reason to delay the release of > > > > a > > > > module. There's always more features we could add to a module. It's > > > > also > > > > > > important to get something out and into the hands of people. > > > > > > > > Feature freeze doesn't imply a full API freeze. We have the alpha/beta > > > > period exactly for finding issues and fixing them. A missing signal is > > > > something we can fix if required. > > > > > > Right. > > > > > > However, if there are major defects in the API, they need to be voiced > > > > now. > > > > > Like Lars said before, this API isn't new, so people have had the time > > > to > > > look at it. > > > > > > If there are major problems, I expect that they are already known. > > > Therefore, post them. > > > > After having worked quite a bit with the Bluetooth API I wouldn't say it > > has > > major defects any more. > > How about getting list of Bound ( and known) Devices from > QBluetoothLocalDevice ( or from somewhere else) ? > Normal use case is that you use device discovery only when you are pairing > new device. After that > you only ask locally that is there device already paired and directly > connect to that one. > > I did not found any other practical way to do this that implement it using > Dbus for "normal" Linux > and JNI to Android. Shouldn't QBluetoothLocalDevice::allDevices() give that information? Br, Michael > > Kate > > > Br, > > Michael > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
On Monday 30 September 2013 13:09:53 Thiago Macieira wrote: > On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote: > > >As far as I know from my colleague, it misses some necessary API -- at > > >least the connection state changes notification and device disappearing > > >notification. > > >We could prepare some patches during the next week or two, though > > >QtBluetooth probably needs few more revisions and API changes/fixes...but > > >we can't do too much in case of API freeze, you know... > > > > A missing feature is for me not enough reason to delay the release of a > > module. There's always more features we could add to a module. It's also > > important to get something out and into the hands of people. > > > > Feature freeze doesn't imply a full API freeze. We have the alpha/beta > > period exactly for finding issues and fixing them. A missing signal is > > something we can fix if required. > > Right. > > However, if there are major defects in the API, they need to be voiced now. > Like Lars said before, this API isn't new, so people have had the time to > look at it. > > If there are major problems, I expect that they are already known. > Therefore, post them. After having worked quite a bit with the Bluetooth API I wouldn't say it has major defects any more. This wasn't the case with NFC last time I worked with. But afaik there were some change lately addressing the things I found troublesome. Br, Michael ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
