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
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
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
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
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
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
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
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
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
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
+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
>
> 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
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
>>
>> 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
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
>>
>> 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
> 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
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
>> 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
>
> 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
> 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
>> 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
>>
>> 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
> 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
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
> 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
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
> 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
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
>> 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
>
> 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
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
> 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
> 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
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
> 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
>
> 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
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
>
> 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
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
>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
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
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
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
44 matches
Mail list logo
