Re: [Development] Changelogs for 5.3.0

2014-04-24 Thread Bache-Wiig Jens
I edited and updated the controls related change log here: https://codereview.qt-project.org/#change,84066 On a somewhat related note, I would suggest that for future updates we standardize on putting the bug-id after each item entry rather than in front as that would make the document a bit more

Re: [Development] Styling Qt Quick Items

2014-04-24 Thread Bache-Wiig Jens
On 24 Apr 2014, at 00:57, Alex Montgomery mailto:apmontgom...@gmail.com>> wrote: Hello, While trying to style a ComboBox such that its text didn't elide and it didn't have inexplicably large margins, I was surprised to learn that these two items would be displayed entirely differently: Combo

Re: [Development] Qt5.2 application palette

2013-12-05 Thread Bache-Wiig Jens
On 05 Dec 2013, at 15:31, Martin Koller wrote: > I'm at ec03058fa5b84b4570a2158bf2179f7ba4d83b99 and I see something I can not > explain: > > QApplication app(argc, argv); > > cerr << "style:" << qPrintable(QApplication::style()->objectName()) << > std::endl; > > QPalette pal = QApplicat

Re: [Development] QtQuick Control ComboBox localization

2013-09-24 Thread Bache-Wiig Jens
On Sep 24, 2013, at 1:06 PM, Nils Jeisecke wrote: > Hi list, > > What is the correct way to localize strings in a ListModel that is > used for populating a ComboBox? > > The localization documentation says it's the views responsibility to > use use qsTr. However, concluding from a quick code c

Re: [Development] Problem with QtQuick.Controls, style.panel <-> custom Control children stack order

2013-05-16 Thread Bache-Wiig Jens
On May 16, 2013, at 3:24 PM, Tomasz Olszak wrote: > I have encountered some problem related to Control.qml/AbstractCheckable.qml > internals. > Example case: > CheckBoxStyle has indicator which can interact with user (has mouse area). Note this discussion probably belongs on the qt-components

Re: [Development] Qt for Tizen repos

2013-05-12 Thread Bache-Wiig Jens
On May 12, 2013, at 11:35 PM, Thiago Macieira wrote: > On quinta-feira, 9 de maio de 2013 00.39.03, Jaroslaw Staniek wrote: >> Hello, >> Given that a new port was born[1] I'd like to ask for possibility of >> creating wip/tizen branches in the main Qt 5 repos. > > I support that request. +1 fr

Re: [Development] Qt for iOS - iOSStyle

2013-03-14 Thread Bache-Wiig Jens
On Mar 13, 2013, at 10:07 PM, Jake Thomas Petroules mailto:jake.petrou...@petroules.com>> wrote: On Mar 13, 2013, at 1:43 PM, Bache-Wiig Jens mailto:jens.bache-w...@digia.com>> wrote: Exactly. Being able to do pixel perfect layouts within the Qt Quick designer is one of t

Re: [Development] Qt for iOS - iOSStyle

2013-03-13 Thread Bache-Wiig Jens
On Mar 13, 2013, at 5:07 PM, joao morgado mailto:joaodeusmorg...@yahoo.com>> wrote: To Richard: What your saying makes perfect sense to me, and whatever solution your team comes up with, for iOS style, I'm sure it will be handsome, (it's Qt we're talking after all :) ). Just some toughts f

Re: [Development] Qt for iOS - iOSStyle

2013-03-12 Thread Bache-Wiig Jens
On Mar 11, 2013, at 12:41 PM, Jake Thomas Petroules wrote: > By the way, I don't know if you saw my comments on your "Qt for iOS Preview" > blog post, but... > > You stated that because there is no HITheme-like API on iOS, that creating > QiOSStyle would be "not possible". > > However, we c

Re: [Development] Nominating Andreas Hanssen as Approver

2013-02-07 Thread Bache-Wiig Jens
On Feb 7, 2013, at 1:52 PM, Andreas Aardal Hanssen mailto:andr...@hanssen.name>> wrote: 2013/2/7 Eirik Aavitsland mailto:eirik.aavitsl...@digia.com>> >> +1 of course >> Also a bit surprised to hear that he's not already an approver. :)A >> distinguished developer like Andreas does not deserve

Re: [Development] Nominating Alan Alpert as QtDeclarative maintainer

2013-02-05 Thread Bache-Wiig Jens
+1 from me as well. Alan has an excellent overview on everything going on in this module and is still actively following every aspect of its development. I also agree with Lars that we eventually will need to break this beast into smaller more manageable parts as its scope will only continue to

Re: [Development] Missing documentation makes QML ListView unusable

2013-01-29 Thread Bache-Wiig Jens
> > No. ListView is designed to support many interaction methods, not a > specific interaction method with others being "custom things". Aside > from the case where you want more than click-to-select in your > MouseArea (which is probably the most common case, and would require > overriding any de

Re: [Development] Runtime Platform Content Selection

2013-01-16 Thread Bache-Wiig Jens
On Jan 15, 2013, at 1:39 PM, Mohamed Fawzi wrote: > In the Platform Content Selection thread some saw runtime selection as not > needed. > I disagree, as I think it could be very useful in some occasions > (high_res/low_res, different orientation,…). > I do not believe that having a separate b

Re: [Development] Proposal: expose the OS/platform in QML

2013-01-16 Thread Bache-Wiig Jens
>> >> Second, it would be useful to know if I am on a "phone", "tablet" or >> "desktop" platform. ( can already guess by the resolution but perhaps it >> would be convenient to abstract it a bit. > > These days you can't really tell from the resolution :) But I don't > think Qt currently has a

Re: [Development] Proposal: expose the OS/platform in QML

2013-01-15 Thread Bache-Wiig Jens
On Jan 15, 2013, at 6:38 PM, Attila Csipa wrote: > On 15/01/13 18:27, Nurmi J-P wrote: >> What do you think about exposing the underlying operating system and/or >> platform name in QML? >> ... >> Which one of these proposals do you like the most, or are you against the >> whole idea? > > In

[Development] The future of the "Ministro" brand on Android (was: Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android)

2013-01-12 Thread Bache-Wiig Jens
>> >> Hi, >> >> As part of the Android-port of Qt 5 being contributed to the Qt >> Project by BogDan, he also contributed the code for a general-purpose >> Android app which is used for getting libraries and plugins on demand >> when a Qt app is deployed to an Android device. This tool is call

Re: [Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android

2013-01-11 Thread Bache-Wiig Jens
> Hi, > > As part of the Android-port of Qt 5 being contributed to the Qt Project > by BogDan, he also contributed the code for a general-purpose Android > app which is used for getting libraries and plugins on demand when a Qt > app is deployed to an Android device. This tool is called "Minis

Re: [Development] QML and QAbstractListModel

2013-01-11 Thread Bache-Wiig Jens
On Jan 10, 2013, at 5:46 PM, Alberto Mardegan wrote: > Hi all! > I'd like to make C++ models more usable from QML; in the net there > are several blog posts illustrating how to achieve that, but IMHO it > would be better if at least some of these handy features were in > QAbstractListModel

Re: [Development] QAction-like API for QML

2012-12-20 Thread Bache-Wiig Jens
>> I find the idea of adding a new QCoreAction base class that is shared >> between QML Action and QAction and only carries a small subset of properties >> an unnecessary layer of abstraction. The idea of QAction is to have the >> convenience of icons, text and shortcuts predefined for you in a

Re: [Development] QAction-like API for QML

2012-12-18 Thread Bache-Wiig Jens
> > Right, but referring to a file (bundled or in the resources) is still > referring to the icon by name, no? One of them is a logical icon-name the other one is a file-name. The logical name refers to an icon outside of the application, the file name refers to a file bundled inside the appli

Re: [Development] QAction-like API for QML

2012-12-18 Thread Bache-Wiig Jens
> Now, you've most likely seen way more Qt apps than I have, but all I have > seen > were shipping icons, most of them as part of their resources, some as files. I am pretty sure this is a misunderstanding. We do not bundle the icons inside the Qt libraries. People bundle it with their applica

Re: [Development] QAction-like API for QML

2012-12-16 Thread Bache-Wiig Jens
>> How about having ToolBar.addAction() for convenience? It is exactly what we >> do for widgets. > > Widgets is a toolkit for an imperative language. Looping over lists > and adding things individually is acceptable there. In a declarative > language it is really not the right way to go. Even if

Re: [Development] QAction-like API for QML

2012-12-16 Thread Bache-Wiig Jens
>> >> What is so terrible about it? QtWidgetEnables would be private API, only >> used by components internally and we would not need to load the module on >> embedded, or am I missing something? > > I don't see how you'd avoid loading the module on embedded. Because > the components are writte

Re: [Development] QAction-like API for QML

2012-12-16 Thread Bache-Wiig Jens
> But if you are writing a 100% declarative UI you'd probably wish to > avoid linking against widgets. So I guess you're saying regular old > QActions should be exposed just for putting a declarative UI onto > legacy apps, and also there should be a new QQuick action, which is an > unrelated class

Re: [Development] QAction-like API for QML

2012-12-16 Thread Bache-Wiig Jens
On Dec 16, 2012, at 4:55 PM, Shawn Rutledge wrote: > On 16 December 2012 15:32, Bache-Wiig Jens wrote: >> I did not say the idea was not useful. My point was that it is not required >> since we already have access to everything the common base class would give >> you. Ac

Re: [Development] QAction-like API for QML

2012-12-16 Thread Bache-Wiig Jens
> Having a common base class was something I thought of last summer or > so. I still think maybe it can work. But we won't get the benefit of > it unless we change the QWidget menu system to take the base class > pointers, and deal with them polymorphically; or deprecate the old > QAction and hav

Re: [Development] [Qt-creator] gerrit-speak

2012-12-14 Thread Bache-Wiig Jens
Oh well, if you already feel offended by this phrasing, I guess you should get a thicker skin ... we've people from very different cultures and with varying English language skills in the community, so you should just take things with a pinch of salt in general. Anyway, the sentence is from the

Re: [Development] [Qt-creator] gerrit-speak

2012-12-14 Thread Bache-Wiig Jens
> Oh well, if you already feel offended by this phrasing, I guess you should > get a thicker skin ... we've people from very different cultures and with > varying English language skills in the community, so you should just take > things with a pinch of salt in general. > > Anyway, the sentence

Re: [Development] QAction-like API for QML

2012-12-13 Thread Bache-Wiig Jens
I have been lurking in the discussion a bit but I guess it is time for me to pitch in. It is hard to keep up with 10 different threads at once. :) I find the idea of adding a new QCoreAction base class that is shared between QML Action and QAction and only carries a small subset of properties an

Re: [Development] Settings API for QML

2012-12-11 Thread Bache-Wiig Jens
>> I would also consider an even simpler API. How about we introduce a new >> keyword for persistent properties and make it part of the language. >> >> Rectangle { >> id: root >> persistent property width: 400 >> persistent property height: 300 >> } >> >> What this means is that the

Re: [Development] Settings API for QML

2012-12-11 Thread Bache-Wiig Jens
> > To get the discussion going, here's my suggestion for that API: > PersistentSettings > { >property bool loadOnStartup: true >property bool saveOnExit: true >function load() >function save() > } I would also consider an even simpler API. How about we introduce a new keyword fo

Re: [Development] HEADS UP: Changes in QStyle subclasses

2012-11-26 Thread Bache-Wiig Jens
For the desktop components we will use QStyle by default so they look and behave as regular widgets. This means that applications with custom styles will also get QML component styling for free, avoiding the need to duplicate any styling code. I recently also made it possible to style the compon

Re: [Development] New high-dpi QPen proposal (Was Re: Proposal: Make QPen non-cosmetic by default)

2012-10-18 Thread Bache-Wiig Jens
> Maybe as a best effort we could introduce a different render hint, > asking QPainter to treat cosmetic pens as geometric, would be a better > solution for Morten's high-dpi use case. Then it would be opt-in instead > of opt-out, and no existing applications would be affected. Turning on > hig

Re: [Development] Replacing Cleanlooks and Plastique

2012-10-15 Thread Bache-Wiig Jens
> Those are not obsolete. They still ship with KDE 4, it just uses Oxygen by > default. So I wouldn't call then "non-native", just "less common". Should we also call Motif and Windows also native KDE styles because they happen to ship with the Qt4 libraries? I think many KDE developers would di

[Development] Replacing Cleanlooks and Plastique

2012-10-15 Thread Bache-Wiig Jens
The main focus of Qt on the desktop is to provide a native look and feel on all platforms. Until now, Qt has come bundled with a few extra styles that were not used intentionally anywhere. Historically plastique was designed to blend with KDE 3.0 and cleanlooks in early Gnome environments. They

Re: [Development] Proposal: Make QPen non-cosmetic by default

2012-10-12 Thread Bache-Wiig Jens
> Basically it is about if you want to have a pen width in model or paint > device coordinates. Both use cases exist and IMHO none of them is more > important than the other. Agree on the importance on both but the inconsistency applies in both use cases. >> Most likely no more than setRenderH

Re: [Development] Proposal: Make QPen non-cosmetic by default

2012-10-12 Thread Bache-Wiig Jens
> > Think about a scatter plot with many points displayed as crosses. On a > large zoom level you only see a cloud but when zooming in you can see > each cross and its position in detail. True. There are certainly plenty of valid use cases out there and some of those would require a minor chan

[Development] Proposal: Make QPen non-cosmetic by default

2012-10-11 Thread Bache-Wiig Jens
This issue came up while preparing some code to be High-dpi aware but it is really a completely separate issue. While I previously supported the idea that cosmetic pens should be two pixels wide by default on HDPI screens, I think we should take it one step further as the real issue is caused by

Re: [Development] High-dpi Qt best practices

2012-10-11 Thread Bache-Wiig Jens
> > The only thing is about QPen. should we draw lines twice as large? that is > bascically what QPen::isCosmetic is for Absolutely. The problem is that for some reason we have cosmetic as the default. In practice people hardly use cosmetic pens for what it was designed for, it is imply treate

Re: [Development] Qt desktop components project

2012-10-08 Thread Bache-Wiig Jens
Anyway, a theming question. How can the QML Desktop Components currently be themed? Only by means of QStyle? Would there be a way to use kde's plasma themes in the QML Desktop Components? And do the desktop components depend on QWidgets only because of QStyle. Yes we have already been researching

Re: [Development] Qt desktop components project

2012-10-04 Thread Bache-Wiig Jens
>Anyway, what is the plan right now? Don't do anything for the desktop >components till Qt 5 is released then developing the desktop >components further till they are perfect and ready to be released with >Qt 5.1? That is a reasonable proposal. Perhaps they could be an addon to Qt 5.0. To be hon

Re: [Development] Qt desktop components project

2012-10-03 Thread Bache-Wiig Jens
No worries. Development is still going strong. It just happens that the people that are involved in component development are the very same people trying to push a Qt 5.0 release out of the door right now. This obviously means a bit less focus on new feature development while the release is ongo

Re: [Development] Removal of Motif and CDE styles in Qt5

2012-09-19 Thread Bache-Wiig Jens
Exactly. Just like with KDE, those projects are probably better served by maintaining their own platform plugin rather than depend on upstream changes that might block their releases. I would of course welcome anyone to step up and maintain those styles as an addon, but I would prefer that we fo

[Development] Removal of Motif and CDE styles in Qt5

2012-09-19 Thread Bache-Wiig Jens
As we are cleaning up some QStyle related things for Qt5, we are planning on removing the now ancient motif and cde styles from qtbase. These were designed for platforms and desktops that are no longer supported in Qt5 and there is not much value in including them in all of our Qt 5 source packa