On 24 Apr 2014, at 00:57, Alex Montgomery
apmontgom...@gmail.commailto: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
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
On Sep 24, 2013, at 1:06 PM, Nils Jeisecke njeise...@saltation.de 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
On May 16, 2013, at 3:24 PM, Tomasz Olszak olszak.tom...@gmail.com 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 May 12, 2013, at 11:35 PM, Thiago Macieira thiago.macie...@intel.com 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
On Mar 13, 2013, at 10:07 PM, Jake Thomas Petroules
jake.petrou...@petroules.commailto:jake.petrou...@petroules.com
wrote:
On Mar 13, 2013, at 1:43 PM, Bache-Wiig Jens
jens.bache-w...@digia.commailto:jens.bache-w...@digia.com wrote:
Exactly. Being able to do pixel perfect layouts within
On Mar 13, 2013, at 5:07 PM, joao morgado
joaodeusmorg...@yahoo.commailto: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 :)
On Mar 11, 2013, at 12:41 PM, Jake Thomas Petroules
jake.petrou...@petroules.com 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
On Feb 7, 2013, at 1:52 PM, Andreas Aardal Hanssen
andr...@hanssen.namemailto:andr...@hanssen.name wrote:
2013/2/7 Eirik Aavitsland
eirik.aavitsl...@digia.commailto:eirik.aavitsl...@digia.com
+1 of course
Also a bit surprised to hear that he's not already an approver. :)A
distinguished
+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
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 way to
On Jan 15, 2013, at 1:39 PM, Mohamed Fawzi fawzi.moha...@digia.com 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
On Jan 15, 2013, at 6:38 PM, Attila Csipa q...@csipa.in.rs 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?
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
On Jan 10, 2013, at 5:46 PM, Alberto Mardegan ma...@users.sourceforge.net
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
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 Ministro.
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 shared
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
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 have
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?
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 written in QML
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 you
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
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
for
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 application will
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
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
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 treated
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
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
honest
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
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
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
35 matches
Mail list logo
