Re: [Development] [Releasing] Qt 5.0 RC 2 released
ok, thanks. https://bugreports.qt-project.org/browse/QTIFW-190 2012/12/18 Kalinowski Maurice maurice.kalinow...@digia.com Hm, then it sounds like a bug in the Installer Framework. ** ** Please create a new report against https://bugreports.qt-project.org/browse/QTIFW ** ** Thx. Maurice ** ** *From:* techabc [mailto:tech...@gmail.com] *Sent:* Tuesday, December 18, 2012 8:38 AM *To:* Kalinowski Maurice *Cc:* development; releas...@qt-project.org *Subject:* Re: [Releasing] [Development] Qt 5.0 RC 2 released ** ** thanks for Maurice. I su to root and things ok. but, I still know it as a bug, because the installer have already request me a root's password during install as normal user. ** ** 2012/12/18 Kalinowski Maurice maurice.kalinow...@digia.com The installers have built the extraction items statically in the binary, so there is no dependency on having packages installed on your system. So the question is rather, why this fails in your case. Things I could think of right now are not enough disk space (the installer should check for this, but there are configurations where this check fails) or installing into a read-only section. Does it install anything before or does is this the first package it tries to install? Maurice *From:* releasing-bounces+maurice.kalinowski=digia@qt-project.org[mailto: releasing-bounces+maurice.kalinowski=digia@qt-project.org] *On Behalf Of *techabc *Sent:* Monday, December 17, 2012 5:56 PM *To:* development; releas...@qt-project.org *Subject:* Re: [Releasing] [Development] Qt 5.0 RC 2 released I run the testing package qt-linux-opensource-5.0.0-x86_64-offline-2012-12-17-386.run on OpenSuse 12.3 m2 , but errors below: Error during installation process (qt.500.src.essentials): Error while extracting installer://qt.500.src.essentials/5.0.0qtbase-src.7z: Extraction failed..* *** I have already installed p7zip tools, and get the result in http://superuser.com/questions/406915/extract-7z-files-with-standard-linux-tools Q: I know that you can extract .7z files with 7-zip. Is there another standard linux program that can do this? Maybe one of these tar bzip2 xz gzip A: No. 7-Zip archives use LZMA and LZMA2, which are not supported by standard tools (they also use bzip2, but you still need to decode the header). The standard way to work with 7-Zip archives on Unix is to use P7ZIPhttp://p7zip.sourceforge.net/. But since the 7-Zip format was designed primarily for Windows, you shouldn't really expect P7ZIP to come installed on Linux distributions by default. If you want the benefit of LZMA compression on Unix, prefer XZ Utilshttp://tukaani.org/xz/ . 2012/12/17 Thiago Macieira thiago.macie...@intel.com On segunda-feira, 17 de dezembro de 2012 10.00.15, haithem rahmani wrote: But after updating my repository, I've noticed that the submodules, qtwebkit, qtrepotools and qtqa were not providing the tag v5.0.0-rc2 not even the v5.0.0-rc1 are there plans to update those submodule too? The qtwebkit repository has the tag. If you don't see it, you've got the wrong repo. Check that you have git://gitorious.org/qt/qtwebkit.git. The other two aren't part of the release itself, so they aren't tagged. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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] How I'm using qtchooser
Did you forget to push / integrate qtchooser by chance? The repo is empty for
me :)
Simon
From: development-bounces+simon.hausmann=digia@qt-project.org
[development-bounces+simon.hausmann=digia@qt-project.org] on behalf of
Thiago Macieira [thiago.macie...@intel.com]
Sent: Tuesday, December 18, 2012 8:33 AM
To: development@qt-project.org
Subject: [Development] How I'm using qtchooser
Clone https://codereview.qt-project.org/p/qt/qtchooser
Run:
make bindir=$HOME/bin install
Packagers, please install as:
make INSTALL_ROOT=insert-install-root-variable-here install
For example, on my Mac:
$ qt
Not using Qt.
$ ls .config/qtchooser
5-frameworks.conf 5-no-frameworks.conf
$ qt press TAB
5-frameworks 5-no-frameworks none
$ qt 5-frameworks
Using Qt 5-frameworks
$ echo $QT_SELECT
5-frameworks
$ echo $QTLIBDIR
/Users/tjmaciei/obj/qt/qt5-frameworks/qtbase/lib
$ echo $QTOBJDIR
/Users/tjmaciei/obj/qt/qt5-frameworks/qtbase
$ echo $QTSRCDIR
/Users/tjmaciei/src/qt/qt5-frameworks/qtbase
$ ls -l `which qmake`
lrwxr-xr-x 1 tjmaciei staff 9 Dec 17 22:47 /Users/tjmaciei/bin/qmake -
qtchooser
$ qmake -v
QMake version 3.0
Using Qt version 5.0.0 in /Users/tjmaciei/obj/qt/qt5-frameworks/qtbase/lib
$ moc -v
Qt Meta Object Compiler version 69 (Qt 5.0.0)
$ uic3 -v
uic3: could not exec '/Users/tjmaciei/obj/qt/qt5/qtbase/bin/uic3': No such file
or directory
My qt function is:
function qt()
{
# Get or set the Qt version
if [ $# -eq 0 ]; then
# Get the Qt version
if [ -z $QT_SELECT ]; then
echo Not using Qt.
else
echo Using Qt $QT_SELECT
fi
else
# Set the working Qt version
unset QT_SELECT
local QTTOOLDIR
test x$1 = xnone || eval $(qtchooser -qt=$1 -print-env) || return $?
# Remove old
removefrom LD_LIBRARY_PATH $QTLIBDIR
removefrom PKG_CONFIG_PATH $QTLIBDIR/pkgconfig
# Add new
if [ x$1 != xnone ]; then
{ pushd $QTLIBDIR/.. QTOBJDIR=$PWD
updatedirs QTSRCDIR=$srcdir popd; } /dev/null
2/dev/null
QTSRCDIR=${QTSRCDIR-$QTOBJDIR}
addto LD_LIBRARY_PATH $QTLIBDIR
addto PKG_CONFIG_PATH $QTLIBDIR/pkgconfig
echo Using Qt $1
export LD_LIBRARY_PATH PKG_CONFIG_PATH
export QTOBJDIR QTSRCDIR QTLIBDIR QT_SELECT
else
unset QTOBJDIR QTSRCDIR QTLIBDIR
echo Not using Qt
fi
fi
}
The removefrom and addto functions are trivial and left as an exercise for the
reader. The updatedirs function is part of my shadow build manipulation and it
updates $objdir and $srcdir indicating where the sources and binaries are. You
may skip that line or update to whatever you currently use.
The zsh completion function is:
function _qt() {
_wanted arguments expl 'Disable Qt' compadd none
qtchooser -list-versions | while read ver; do
_wanted arguments expl Qt version $ver compadd $ver
done
return 1
}
compdef _qt qt
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Sunday, 2012-12-16, Bache-Wiig Jens wrote: Sure. But we don't actually have support for logical icon names on Windows, Mac or Embedded since we don't have pixmaps for those. I'm not sure what you mean. This is really sidetracking the discussion but Windows and Mac do not have default action icons built-in and we do not ship those icons with Qt. There are practical and legal reasons for that. Most apps probably don't want to carry the extra data. When I first read that I didn't see how this could be true. It seemed you were saying that applications on Windows and Mac were creating icon pixmaps at runtime (because they can't get native pixmap from the OS and they wouldn't ship icon data). 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. Both mechanisms which by design load icon data by name, so at least from my empirical data I am quite puzzled to learn that iconName would be sufficient for specifying icons. Drawing icons on demand sounds very cumbersome to me. Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
Sounds reasonable. Laszlo Folks, how can we conclude on this? There were two votes Sounds reasonable, one comment with doubts from Tuukka and one more natural from Sergio. How do we proceed now? More comments? Some details for the expressed doubts? Some actions? Thanks! -- Vladimir - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Tuesday, 2012-12-18, Bache-Wiig Jens wrote: 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 application executables. I.e they put their edit-copy.png file inside their application resources, just like we do in our examples. Ah, that makes sense. I was misled by Most apps probably don't want to carry the extra data. assuming that was referring to shipping icon files with the application. Both mechanisms which by design load icon data by name, so at least from my empirical data I am quite puzzled to learn that iconName would be sufficient for specifying icons. On Linux and related open source platforms there is an established icon naming standard. The linux distributions are free to ship their own icon themes as long as they follow the naming convention. This makes it possible to use icons by logical names like edit-copy instead of referring to explicit png files bundled within your application resources. It saves time, space and makes applications more consistent since they can use the same icons across different applications. Right, but referring to a file (bundled or in the resources) is still referring to the icon by name, no? Taking your example of edit-copy, does it make any difference if edit- copy.png is stored in some system wide shared locations, relative to the application executable or in the application's resources? In the end the result is QIcon( filename ) being used, right? It is a nice concept but my only point was that we cannot rely on it alone since it makes the app useless on Windows and Mac. It would be neat to include icons in Qt but that would essentially be like bundling all of the Oxygen icons in every single KDE application and beats the purpose of it. I am not sure I can follow here. Where is the connection of Windows and Mac not valuing visual consistency and not providing some kind of central icon repository and Qt applications continuing to load icons from files? Drawing icons on demand sounds very cumbersome to me. That was certainly not what I was trying to suggest. I hope that clarifies things. :) It does :) It was just that drawing was the only way I could quickly come up with that would create an icon without having to load data from a file. What other form of creating an icon did I miss? Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Tuesday 18 December 2012 10:00:25 Vladimir Minenko wrote: Sounds reasonable. Laszlo Folks, how can we conclude on this? There were two votes Sounds reasonable, one comment with doubts from Tuukka and one more natural from Sergio. How do we proceed now? More comments? Some details for the expressed doubts? Some actions? I vote for yes, create a vendor branch, but then I suggested it to Peter in the first place on irc. It keeps the work flow the same, the legal process is unchanged, has precedent, and allows the work to still be done in the open without causing unnecessary delays. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
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 application. Taking your example of edit-copy, does it make any difference if edit- copy.png is stored in some system wide shared locations, relative to the application executable or in the application's resources? You can bundle an icon theme and include only the icons you are using in your application. That way icon names would work even on windows and mac. In the end the result is QIcon( filename ) being used, right? Yes eventually. But the application doesn't have to care know which one. Feel free to look up QIcon::fromThemeName. It should explain the relevant details. Regards, Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 18.12.2012 12.25, Sean Harmer sean.har...@kdab.com wrote: On Tuesday 18 December 2012 10:00:25 Vladimir Minenko wrote: Sounds reasonable. Laszlo Folks, how can we conclude on this? There were two votes Sounds reasonable, one comment with doubts from Tuukka and one more natural from Sergio. How do we proceed now? More comments? Some details for the expressed doubts? Some actions? I vote for yes, create a vendor branch, but then I suggested it to Peter in the first place on irc. It keeps the work flow the same, the legal process is unchanged, has precedent, and allows the work to still be done in the open without causing unnecessary delays. In case we decide to proceed with creation of a vendor branch, is it planned to be a temporary solution or something permanent? Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Tuesday 18 December 2012 11:00:56 Turunen Tuukka wrote: On 18.12.2012 12.25, Sean Harmer sean.har...@kdab.com wrote: On Tuesday 18 December 2012 10:00:25 Vladimir Minenko wrote: Sounds reasonable. Laszlo Folks, how can we conclude on this? There were two votes Sounds reasonable, one comment with doubts from Tuukka and one more natural from Sergio. How do we proceed now? More comments? Some details for the expressed doubts? Some actions? I vote for yes, create a vendor branch, but then I suggested it to Peter in the first place on irc. It keeps the work flow the same, the legal process is unchanged, has precedent, and allows the work to still be done in the open without causing unnecessary delays. In case we decide to proceed with creation of a vendor branch, is it planned to be a temporary solution or something permanent? I suppose that entirely depends upon what gets committed there. The general idea is to keep this branch as the minimum set of patches needed for this platform that cannot be merged into the Qt mainline. Peter already mentioned one such patch. The case of expediting patches in this branch is to allow this to happen in the open in the spirit of the Qt project. Wherever possible the idea is to upstream the patches into the Qt mainline so that the vendor branch remains as close as possible to the official Qt Project version. Vladimir and Peter may have more to add of course. All the best, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Tue, Dec 18, 2012 at 10:00:25AM +, Vladimir Minenko wrote: How do we proceed now? More comments? Some details for the expressed doubts? Some actions? i created the branch 4.8.4-bb10 (which is also the version number you should announce your release as). members of the group Blackberry10 Branch Owners (which you and peter are the admins of) may direct-push and submit changes into it (adjustments possible at any time). for the next release you'll obviously need the next vendor-release branch. provided you actually use it to start from scratch (by rebasing on top of the latest official release), this is cleaner than a permanent vendor branch where you only merge from upstream (and get yourself a fine mess of already upstreamed and still proprietary patches). if the number of patches which are not supposed to be upstreamed is is too big, going for the permanent vendor branch would be more reasonable, though. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Thursday, December 13, 2012 13:18:35 you wrote:
On Thu, Dec 13, 2012 at 8:18 AM, Stephen Kelly stephen.ke...@kdab.com
wrote:
The reason for the split is not clear to me. Do you suggest that UIAction
would be a QML element, not a creatable C++ class? Do you suggest that
CoreAction would be a creatable C++ class? Why does it not have a text?
The split is because there is a need for a usable element in two
separate worlds, widget-land and QML-topia.
I know you like QML, but this kind of thing is just distracting. It reads as
if you don't care at all about getting the API right for people who don't
create QML only applications. I know you don't think that as you have said so,
but that's how it reads.
The details of the split
was just following Andre's suggestion. text/secondaryText might fit
into CoreAction, icon will not.
Why not? Because QML doesn't do QIcons? The reason for that is not clear
either to me.
There is a concrete need for an Action like class which you can
create, manage and use in QML to implement your QML menus and toolbars
for desktop, mobile and cross-platform UIs.
There is a need to use them certainly. I'm not certain what you mean by
manage. I think creating them in QML is useful enough to be done, but as any
useful QML application has a c++ part where they can also be created, it's not
as big a need as the need to use them.
There is an existing need
for a QAction because it's used in QWidget UIs. These cannot be the
same class for already explained reasons.
The reasons already explained are quite fuzzy. To be specific, the reason is
that QAction has these APIs, right? :
- QListQGraphicsWidget * associatedGraphicsWidgets () const
- QListQWidget * associatedWidgets () const
- QMenu * menu () const
- QWidget * parentWidget () const
- void setMenu ( QMenu * menu )
- bool showStatusText ( QWidget * widget = 0 )
Those are not necessarily 'always used, primary' APIs required for 'an Action
API which can be used from both C++ and QML'.
There is no concrete need
for the CoreAction type, we're just considering it now because it
might prove a useful abstraction to bridge the gap. If it is a useful
abstraction to bridge gaps, then it makes sense to make it a usable
C++ class so that other separate worlds can also interact easily.
Interact and have a common codebase etc, yes.
The QML Action class would be a QML type, and not exposed C++ API.
This is to add flexibility, in case we need to add or remove a
QGuiAction subclass later.
If we get it right, we won't need to add other classes in the inheritance
heirarchy later. Most of Qt is written in C++ where that need is present, so
we have a lot of experience with getting it right.
I don't think this is a good reason to make the API QML only.
If you'll accept this, then we could
actually focus on the QML API now and deal with the C++/QAction
integration later (although perhaps it will still help to think about
it now).
Yes, I think it still helps to think about it now.
CoreAction may not even need a QML API. QML users either implicitly
use one through UIAction, or explicitly use one from C++.
I think the goal should be not to have such a split at all.
Presumably you suggest that UIAction is not a visible element, but its
properties need to be bound to Text {} elsewhere?
Rectangle {
UIAction {
id : uiAction
action : _cpp_exported_action
}
Text {
text : uiAction.text
}
MouseArea {
onClicked : uiAction.trigger()
}
}
Why not just this:
Rectangle {
property QtObject action :
_cpp_exported_action_manager.get(_cpp_exported_action)
Text {
text : action.text
}
MouseArea {
onClicked : action.trigger()
}
}
Because this isn't a realistic usecase for Actions.
I think it is. Especially in touch applications where menu bars and toolbars
are not common (especially not in the 'desktop paradigm' sense).
It's like hooking
up a QAction to a QPushButton (a usecase I'm suprised doesn't have its
own convenience API).
QPushButton is worlds apart from what QML provides and is used for. I think
that the QML code I wrote above is equivalent to the C++ code:
QAction *action = actionManager-getAction(_cpp_exported_action);
QPushButton *button = new QPushButton;
connect(button, SIGNAL(clicked()), SLOT(trigger()));
See also QToolButton. Such buttons can be made outside of toolbars, just like
is more common on touch screens. Consider also the 'play' button on media
players, which is often in a more prominent location than the toolbar
(consider also Qt creator).
The realistic usecase is to have a Menu or
ToolBar control with a property listAction powering it.
For touch applications, do you think that is still true? Or do you imagine a
menubar and a toolbar which are very different to the ones we use on a
Re: [Development] QAction-like API for QML
On Tuesday, December 18, 2012 12:55:50 Stephen Kelly wrote: Some of this came up before by the way, so it's another discussion to review when designing this: http://thread.gmane.org/gmane.comp.lib.qt.devel/957/focus=1883 Another funny thread from almost a full year ago: http://thread.gmane.org/gmane.comp.lib.qt.devel/1093/focus=1180 Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Monday, December 17, 2012 01:11:55 Bache-Wiig Jens wrote:
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 don't want
to implement menus with ActionGroup, I'd still recommend that you have
something like it (which can take a list of Action/QAction) so that
you only need to list all the actions once, where-ever that may be,
and then add them to other places en masse.
Agreed. But we can provide convenience even if we treat tool bars as a
visual item. For instance, you would have to do this to follow the model
approach of actions:
RowLayout { Repeater { model: myActions ; ToolButton { action: modelData} }
}}
Granted, a bit too verbose. However with a little bit of convenience, we can
for instance reduce this to just: ActionRowLayout { model: myActions }
This looks about right to me.
Thanks,
--
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Monday, December 17, 2012 08:39:14 Alan Alpert wrote: On Sun, Dec 16, 2012 at 4:38 PM, Bache-Wiig Jens jens.bache-w...@digia.com wrote: 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 you'd need the QtWidgetEnablers plugin available at runtime for any application using the components (assuming they include an import QtWidgetEnablers 1.0 line). I also don't know how you'd write the C++ module to avoid having a libQt5Widgets runtime dependency. Well we have the same issue with components so we really have to find a solution if we have any plans of making those widget independent in the future. Embedded would be fine regardless since you could still ifdef QT_NO_WIDGETS from your qtbuild before deployment. I thought the plan was to get away from all widget dependencies in the component set ASAP. The idea was that anything the component set needed which was still in widgets (but not widget-specific) would get abstracted out of widgets. That's why it was a mistake to not extract a QGuiAction from QAction imo, but it's a mistake we have to live with and deal with as best we can (for both C++ and QML APIs). Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Sunday, December 16, 2012 21:12:18 Bache-Wiig Jens wrote: 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? Yes. That is exactly what I am proposing. We will support the parts of QAction that we can for legacy and portability, but we will introduce a new QQuickAction class for QML. You can use both with QML but you can only (directly) use QAction with widgets. Please not QQuickAction, but QGuiAction. Design it to be UI independent, not tied to a UI implementation (Qt Quick). Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Tue, Dec 18, 2012 at 12:55 PM, Stephen Kelly stephen.ke...@kdab.com wrote: The details of the split was just following Andre's suggestion. text/secondaryText might fit into CoreAction, icon will not. Why not? Because QML doesn't do QIcons? The reason for that is not clear either to me. I don't think there's any reason it couldn't. A QIcon is a QPixmap, after all, and QIcon lives in QtGui, so there's no dependency issue either. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is Generic Linux Device QtCreator feature still working and maintained?
Hi, On 17 December 2012 23:13, Michael Hall mhall...@ubuntu.com wrote: I am able to get Qtcreator to connect over ssh to my Nexus 7, but I can't figure out how to get a project to run on anything by my local machine. maybe it's a problem of my netbook? Which version of QtCreator and Ubuntu are you using to connect from and wichi version of Ubuntu to connect to? Thanks. p.s: I will try to increase the timeout value, maybe it helps -- Andrea Grandi - Software Engineer / Qt Ambassador Ubuntu Member: https://launchpad.net/~andreagrandi website: http://www.andreagrandi.it ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Tuesday 18 December 2012 13:24:59 Stephen Kelly wrote: That's why it was a mistake to not extract a QGuiAction from QAction imo, but it's a mistake we have to live with and deal with as best we can (for both C++ and QML APIs). I would like to mention that one can still consider the possibility to put QAction back into QtGui even in Qt 5.1. Moving from one library to another has already been done with QXmlStreamReader in Qt 4 times. It is a bit hackish on some platform but had worked well. The only QWidget dependency are some functions that takes pointer to QWidget* and QMenu* But we can put the impementation of those few functions in the QtWidgets and use hooks like we do for QVariant. (So the function would only print a warning if QtWidgets was not loaded) I just want to point out that it is technically possible if we want to, and we should not discard the idea completely. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Tuesday 18 December 2012 13:33:59 Robin Burchell wrote: On Tue, Dec 18, 2012 at 12:55 PM, Stephen Kelly stephen.ke...@kdab.com wrote: The details of the split was just following Andre's suggestion. text/secondaryText might fit into CoreAction, icon will not. Why not? Because QML doesn't do QIcons? The reason for that is not clear either to me. I don't think there's any reason it couldn't. A QIcon is a QPixmap, after all, and QIcon lives in QtGui, so there's no dependency issue either. QIcon is more than a QPixmap: QIcon is scalable (it can use different pixmap for different sizes) QIcon has the notion of state (Enabled/Disabled/Selected/Toggled) In summary. QIcon is perfect for this use case. (It was designed for that) -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] OpenGL in Qt 5.1 and onwards
Hi, I would like to start a discussion on the future level of support for OpenGL enablers in Qt for those that are interested. So here goes... I would like to add in a bunch more OpenGL enablers but am not sure on where to best put them. Some things I have in mind are: 1) Classes that contain member functions for all OpenGL functions of a given version and profile. E.g. no need to use GLEW or similar. WIP version of this at https://codereview.qt-project.org/#change,35408 This needs resubmitting against dev of course which I will do after some refactoring of the underlying code-generator and trying an experiment with a different inheritance hierarchy. Where should this live? It fits in nicely with obtaining pointers to such objects directly from QOpenGLContext. However, it does add size to QtGui so some people may object to this being located there. The vast majority of functions are inline. The other option is to put it into a Qt3D OpenGL-enabler library and create the objects via some factory class. At present I have a bunch of other WIP patches based upon this work but they could be refactored to resolve the necessary GL functions themselves. Using these classes would make the others easier to implement but not impossible without. 2) An QOpenGLVertexArrayObject class. This would be just a thin wrapper around a VAO with possibly some API to make it easier to use with QOpenGLBuffer and QOpenGLShaderProgram. This could potentially find use in QtQuick 2 so putting it in QtGui alongside the other QOpenGL* classes makes sense. I think the lack of VAO's in qtdeclarative is what makes it necessary to still use a compatibility profile with QtQuick 2. This limits the GL features we can use in conjunction with QQ2 on Mac as Apple only implement the Core Profile for GL 3.x. That is another story though. 3) OpenGL occlusion and timing query objects. Again these are good candidates for QtGui I think but if people object they could go into Qt3D again. The timing query object in particular would be valuable for profiling the GPU time spent in rendering QtQuick 2 scenes. Iirc then right now only the CPU time is available in qtdeclarative but that is only half the story for profiling this stuff. 4) Transform feedback object. Another small but useful candidate for inclusion in QtGui. These objects allow you to perform calculations on the GPU and write the results to a bound buffer object before the rasterisation stage. This can be used to perform animation updates for particles or physical simulations on the GPU for example. The output buffer is then used in a second pass to render with the calculated parameters. Would be very nice to integrate with QOpenGLBuffer and QOpenGLShaderProgram again. 5) Provide support for Geometry, Tessellation Control, Tessellation Evaluation and Compute Shader support in QOpenGLShaderProgram. I don't see anything contentious with these. They are just extending QOpenGLShader and/or QOpenGLShaderProgram. 6) Integrate support for the GL_ARB_debug_output extension into the Qt debug message system. Peppe has said he will start to look at this shortly and I think this would be an awesome feature to have available where the extension is supported. 7) More enabler classes for textures, samplers, and higher-level abstractions. I think these would be good candidates for a Qt3D library, unless someone would really like to see a subset in QtGui. Any feedback welcomed. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5 RC Testing
Hello, There is new version available for testing: http://releases.qt-project.org/digia/5.0.0/backups/2012-12-18-389/ Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - From: Motyka Rafal Sent: Monday, December 17, 2012 1:44 PM To: development@qt-project.org; Digia Site Oslo Nydalen Subject: RE: Qt 5 RC Testing Hello, Please make sure that the form: http://testresults.qt-project.org/forms/release-testing/ is submitted after you finish testing. Best regards, /Rafal From: Motyka Rafal Sent: Monday, December 17, 2012 10:52 AM To: development@qt-project.org; Digia Site Oslo Nydalen Subject: RE: Qt 5 RC Testing Hello, New packages are available and ready for testing: http://releases.qt-project.org/digia/5.0.0/backups/2012-12-17-386/ Please use it for testing. With this version we addressed remaining P0 and P1 issues. Here is the list of changes (at this moment under verification): https://codereview.qt-project.org/42825 https://codereview.qt-project.org/42823 https://codereview.qt-project.org/42821 https://codereview.qt-project.org/42820 https://codereview.qt-project.org/42819 https://codereview.qt-project.org/42834 https://codereview.qt-project.org/42833 https://codereview.qt-project.org/42832 https://codereview.qt-project.org/42831 https://codereview.qt-project.org/42828 https://codereview.qt-project.org/42846 https://codereview.qt-project.org/42845 https://codereview.qt-project.org/42844 https://codereview.qt-project.org/42843 https://codereview.qt-project.org/42848 https://codereview.qt-project.org/42850 https://codereview.qt-project.org/42849 Best regards, /Rafal - From: Motyka Rafal Sent: Wednesday, December 05, 2012 12:36 PM To: development@qt-project.org Subject: Qt 5 RC Testing Hello, New packages are available and ready for testing: http://releases.qt-project.org/digia/5.0.0_rc1/backups/2012-12-05-365/ Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - From: Motyka Rafal Sent: Tuesday, December 04, 2012 12:10 PM To: development@qt-project.org Subject: Qt 5 RC Testing Hello, There are new packages available for testing on Linux and Mac. We're working on Windows installer package. http://releases.qt-project.org/digia/5.0.0_rc1/backups/2012-12-04-363/ Please feel free to test them. We will appreciate your feedback. Known issues are to be found here: http://qt-project.org/wiki/Qt500RC1KnownIssues Best regards, /Rafal From: Motyka Rafal Sent: Monday, December 03, 2012 12:34 PM To: development@qt-project.org Subject: Qt 5 RC Testing Hello, Qt 5 RC release testing continues. We would like to kindly ask the Qt Community for help by testing the new packages. 1. Installer packages are available here: http://releases.qt-project.org/digia/5.0.0_rc1/backups/2012-12-03-362/ http://releases.qt-project.org/digia/5.0.0_rc1/backups/2012-11-29-358/ 2. We're still working to fix issues. The
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 12/18/2012 12:26 PM, Oswald Buddenhagen wrote: On Tue, Dec 18, 2012 at 10:00:25AM +, Vladimir Minenko wrote: How do we proceed now? More comments? Some details for the expressed doubts? Some actions? i created the branch 4.8.4-bb10 (which is also the version number you should announce your release as). members of the group Blackberry10 Branch Owners (which you and peter are the admins of) may direct-push and submit changes into it (adjustments possible at any time). for the next release you'll obviously need the next vendor-release branch. provided you actually use it to start from scratch (by rebasing on top of the latest official release), this is cleaner than a permanent vendor branch where you only merge from upstream (and get yourself a fine mess of already upstreamed and still proprietary patches). if the number of patches which are not supposed to be upstreamed is is too big, going for the permanent vendor branch would be more reasonable, though. Thanks for setting up the branch; however, would it be possible to get a 4.8-blackberry10 branch (without reference to the patch release number)? We are not really releasing our own versions of 4.8.4, 4.8.5 etc., but have our own release cycle for NDK and device images, which is not related to the Qt 4 release cycle in any way. So that branch to be created where we make releases (builds for NDK / devices) from is always the 4.8 branch + some not yet upstreamed commits; a branch called 4.8-blackberry10 would suit that better IMO. We are never actually starting from scratch for new patch releases; in fact, the patch release number (i.e. whether the libs are called e.g. *.4.8.4 or *.4.8.5) is just a minor detail to us. Also (nitpicking), maybe the suffix should be -blackberry10 instead of -bb10, because I guess not everybody knows what bb10 stands for. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 12/18/2012 12:05 PM, Sean Harmer wrote: (...) In case we decide to proceed with creation of a vendor branch, is it planned to be a temporary solution or something permanent? some months ago, I was confident that this would be something temporary; unfortunately, practice has shown that so far we always had a few commits (1-10) that we needed to short-circuit into our branch because some internal team needed a commit urgently (maybe people that have worked on the N9 remember that situation). So I don't expect that branch to go away anytime soon, to be honest. I suppose that entirely depends upon what gets committed there. The general idea is to keep this branch as the minimum set of patches needed for this platform that cannot be merged into the Qt mainline. Peter already mentioned one such patch. Yes, this is another reason why the branch will most likely not become redundant... Peter The case of expediting patches in this branch is to allow this to happen in the open in the spirit of the Qt project. Wherever possible the idea is to upstream the patches into the Qt mainline so that the vendor branch remains as close as possible to the official Qt Project version. Vladimir and Peter may have more to add of course. All the best, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 18.12.2012 17.06, Peter Hartmann phartm...@rim.com wrote: On 12/18/2012 12:05 PM, Sean Harmer wrote: (...) In case we decide to proceed with creation of a vendor branch, is it planned to be a temporary solution or something permanent? some months ago, I was confident that this would be something temporary; unfortunately, practice has shown that so far we always had a few commits (1-10) that we needed to short-circuit into our branch because some internal team needed a commit urgently (maybe people that have worked on the N9 remember that situation). So I don't expect that branch to go away anytime soon, to be honest. Eventually we need to have a policy for these in the Qt Project. There are thousands of different embedded devices being created, and gets hard if we create branch for everyone. I know that you are very busy now, so we do not need to decide this at the moment. But it just something to plan going forward. Yours, Tuukka I suppose that entirely depends upon what gets committed there. The general idea is to keep this branch as the minimum set of patches needed for this platform that cannot be merged into the Qt mainline. Peter already mentioned one such patch. Yes, this is another reason why the branch will most likely not become redundant... Peter The case of expediting patches in this branch is to allow this to happen in the open in the spirit of the Qt project. Wherever possible the idea is to upstream the patches into the Qt mainline so that the vendor branch remains as close as possible to the official Qt Project version. Vladimir and Peter may have more to add of course. All the best, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How I'm using qtchooser
On terça-feira, 18 de dezembro de 2012 08.59.16, Hausmann Simon wrote: Did you forget to push / integrate qtchooser by chance? The repo is empty for me No, I didn't. https://codereview.qt-project.org/#q,project:qt/qtchooser,n,z The changes haven't been approved yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How I'm using qtchooser
That's what I was afraid of. Perhaps your instructions should be extended to include fetching the latest changeset (something like git pull origin refs/changes/20/43120/5 ). Otherwise the clone produces an empty checkout. Simon From: development-bounces+simon.hausmann=digia@qt-project.org [development-bounces+simon.hausmann=digia@qt-project.org] on behalf of Thiago Macieira [thiago.macie...@intel.com] Sent: Tuesday, December 18, 2012 4:57 PM To: development@qt-project.org Subject: Re: [Development] How I'm using qtchooser On terça-feira, 18 de dezembro de 2012 08.59.16, Hausmann Simon wrote: Did you forget to push / integrate qtchooser by chance? The repo is empty for me No, I didn't. https://codereview.qt-project.org/#q,project:qt/qtchooser,n,z The changes haven't been approved yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Monday 17 December 2012 14:55:51 Peter Hartmann wrote: Alternatively I guess we could just clone the repo into a team clone. What is wrong with that option? Is it really important that everyone who wants to clone Qt 4 will also have your branch? Maybe separate clones are the way to go for that kind of patches. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
With all the discussion about the C++ API and the C++ compatibility
let me clarify that it is a different topic to the QML API. They're
both important topics and I'd like to see both implemented perfectly,
but they are separate topics with potentially separate
implementations.
The exposed QML API can be implemented in a variety of ways from C++,
and this does not matter to QML. A completely different C++ type can
implement the same QML type and no-one will notice the difference -
you can even do that in a minor version if you're careful. The worst
case is that the type checking goes from compile-time to run-time for
some properties.
I agree that it's ideal to resolve these related topics at the same
time, but it's not essential. Hypothetically assume the QML API is
trivial to implement and the C++ API takes years, in that situation
you can still implement the QML API now and when the C++ API is ready
it just slides in and you're still at the ideal solution and the ideal
set of exposed APIs. Moving away from the hypothetical situation, in
this case it's probable that it would be both efficient and possible
to implement the C++ and QML APIs at the same time. Still doesn't mean
we have to. So please let us approach this as two separate issues,
both important, and without feeling like the C++ side is being
neglected in favor of QML-only applications.
So the unresolved questions that I see for the 'QAction-like API for QML' topic.
Used like Jens suggested for components:
RowLayout { Repeater { model: myActions ; ToolButton { action: modelData} }
}}
Granted, a bit too verbose. However with a little bit of convenience, we can
for instance reduce this to just: ActionRowLayout { model: myActions }
Given this approach do we need the ActionGroup type? Are
exclusive/collapsible needed now?
Also given the shortcut discussion are Actions sufficient for
launching shortcuts or should a simple Shortcut{} be added too?
I'm of the opinion that Shortcut{} is just confusing, it adds the
cognitive load of having a choice on how to implement a shortcut for
no good reason.
On Tue, Dec 18, 2012 at 4:00 AM, Stephen Kelly stephen.ke...@kdab.com wrote:
On Tuesday, December 18, 2012 12:55:50 Stephen Kelly wrote:
Some of this came up before by the way, so it's another discussion to
review when designing this:
http://thread.gmane.org/gmane.comp.lib.qt.devel/957/focus=1883
Another funny thread from almost a full year ago:
http://thread.gmane.org/gmane.comp.lib.qt.devel/1093/focus=1180
He brings up a good point, QtQuick doesn't need an Action type. But it
has to go somewhere, so either it goes in QtQuick for use as a
'graphical-related primitive', QtQml, or QtWidgetEnablers (if it still
has the widgets dependency).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Tue, Dec 18, 2012 at 5:04 PM, Olivier Goffart oliv...@woboq.com wrote: On Monday 17 December 2012 14:55:51 Peter Hartmann wrote: Alternatively I guess we could just clone the repo into a team clone. What is wrong with that option? Different workflow, less visibility from the Qt contributors and so forth. Is it really important that everyone who wants to clone Qt 4 will also have your branch? I have never realized that a burden, but perhaps I am missing something. Maybe separate clones are the way to go for that kind of patches. Perhaps not. See above. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)
Summary of the topic so far: Existing and future Applications have a need for managing actions in C++, and these need to be the same actions as QML is dealing with. How do we implement this? Here are the four options I recall being suggested so far, A) QQuickAction is added to create the QML API, properties match QAction where possible and all property access goes through the meta-object system to make the type 'meta-isomorphic' B) QAction is moved to Gui and is used to create the QML API. C) QGuiAction is added to Gui and is used to create the QML API and the bridge with QActions. D) QCoreAction is added to Core or Gui and has even less functionality, QQuickAction and QAction/QGuiAction build on top of that to fill out their API. Are there other options we can consider? My favorite of those is C), but there is the unresolved question of how to make an effective bridge given that we can no longer make QAction inherit from QGuiAction. On Tue, Dec 18, 2012 at 5:11 AM, Olivier Goffart oliv...@woboq.com wrote: On Tuesday 18 December 2012 13:33:59 Robin Burchell wrote: On Tue, Dec 18, 2012 at 12:55 PM, Stephen Kelly stephen.ke...@kdab.com wrote: The details of the split was just following Andre's suggestion. text/secondaryText might fit into CoreAction, icon will not. Why not? Because QML doesn't do QIcons? The reason for that is not clear either to me. I don't think there's any reason it couldn't. A QIcon is a QPixmap, after all, and QIcon lives in QtGui, so there's no dependency issue either. It's already in Gui? Good, then it's just the Widget* properties that are preventing the move (and I'm not saying that's an insurmountable obstacle). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Tue, Dec 18, 2012 at 5:40 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Dec 18, 2012 at 5:04 PM, Olivier Goffart oliv...@woboq.comwrote: On Monday 17 December 2012 14:55:51 Peter Hartmann wrote: Alternatively I guess we could just clone the repo into a team clone. What is wrong with that option? Different workflow, less visibility from the Qt contributors and so forth. ... or you meant to suggest the increase of the repository numbers on the current Gerrit instance instead of branch numbers? IMO, it is better to put the details into branches, especially if it is just about a few (and small) commits, and see less repositories from the contributor's point of view. As for me, it would be more unpleasant to clone two separate repositories with minor or at least negligible differences to the base repository size. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
7) More enabler classes for textures, samplers, and higher-level abstractions. I think these would be good candidates for a Qt3D library, unless someone would really like to see a subset in QtGui. What exactly do you mean by more texture enabler into Qt3D on the top of the existing texture class? I briefly discussed the texture topic a few days ago with Samuel and Gunnar. I would personally like to see something basic in QtGui. I see the same feature set reimplemented at least in 2-3 Qt projects for the basic operations, but perhaps there are more around. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On 18 December 2012 18:39, Alan Alpert 4163654...@gmail.com wrote:
Used like Jens suggested for components:
RowLayout { Repeater { model: myActions ; ToolButton { action: modelData} }
}}
Granted, a bit too verbose. However with a little bit of convenience, we can
for instance reduce this to just: ActionRowLayout { model: myActions }
Given this approach do we need the ActionGroup type? Are
exclusive/collapsible needed now?
We discussed it in the office, and Jens made the point that if you
need to expose a list of actions from C++ so that the QML can create a
toolbar from them as described above, then it can just be a plain
QList of actions. (And putting all of the actions from an entire menu
into a toolbar, to make basically a duplicate of one menu, is usually
not good UI design anyway.) Likewise making a tree structure to
represent all the actions in the whole menu system may be the
exception rather than the rule, and in any case it could be an
external tree structure. It doesn't actually make sense to call
something an action if its only purpose is to contain other actions;
it would be the action that doesn't act. Likewise the exclusive group
can be a separate thing, but we still have to decide how exactly to
implement it.
So now it seems to me that we can get rid of exclusive and
collapsible, so as to simplify what goes into action so that we can
get it implemented, and then continue thinking about the best way to
expose collections of them from C++, or expose individual ones, as
well as create them in QML.
But I still think the action needs a name, which can be used by the
image provider to find the icon. (This is independent of whether the
image provider uses files or resources; the icon will be found by name
either way.) Maybe we can reuse objectName for that. So the action
is just called open but the image provider can go looking for
icon-open-action.png or something, using its own naming convention.
The point of that is to avoid repeating yourself in QML.
Whether the images are provided by a QIcon, or by some other means of
providing multiple images at different resolutions, could also be a
detail of the image provider. So we can keep the action pretty well
away from the View part of MVC: it's an abstract representation of one
atom of the Control layer, not a visual representation, although it
contains enough information to be able to construct a visual
representation, so that you can stick it directly in a tool button or
a menu item without having to add extra information first in your own
QML.
The explicit properties that we put into the C++ implementation of the
action class can be limited to the ones that we know every component
implementation will need, as long as we can still add dynamic
properties (or new properties in subclasses) for the platforms that
need something extra.
I'm of the opinion that Shortcut{} is just confusing, it adds the
cognitive load of having a choice on how to implement a shortcut for
no good reason.
That I agreed with from the beginning; I don't see a point in having
anonymous shortcuts, because they should usually be in the menus so
that users can find them. Even if you disagree, you can still create
an action and then leave it out of the menus; we just have to ensure
that the shortcut works whenever the action is enabled.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How I'm using qtchooser
On terça-feira, 18 de dezembro de 2012 16.11.44, Hausmann Simon wrote: That's what I was afraid of. Perhaps your instructions should be extended to include fetching the latest changeset (something like git pull origin refs/changes/20/43120/5 ). Otherwise the clone produces an empty checkout. I was hoping someone would approve. If no one does in the next 6 hours, I'll self-approve. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)
On terça-feira, 18 de dezembro de 2012 09.46.13, Alan Alpert wrote: B) QAction is moved to Gui and is used to create the QML API. You can't do that. QAction is QtWidgets and that's where it will stay until Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Tue, Dec 18, 2012 at 10:18 AM, Shawn Rutledge
shawn.t.rutle...@gmail.com wrote:
On 18 December 2012 18:39, Alan Alpert 4163654...@gmail.com wrote:
Used like Jens suggested for components:
RowLayout { Repeater { model: myActions ; ToolButton { action: modelData} }
}}
Granted, a bit too verbose. However with a little bit of convenience, we can
for instance reduce this to just: ActionRowLayout { model: myActions }
Given this approach do we need the ActionGroup type? Are
exclusive/collapsible needed now?
We discussed it in the office, and Jens made the point that if you
need to expose a list of actions from C++ so that the QML can create a
toolbar from them as described above, then it can just be a plain
QList of actions. (And putting all of the actions from an entire menu
into a toolbar, to make basically a duplicate of one menu, is usually
not good UI design anyway.) Likewise making a tree structure to
represent all the actions in the whole menu system may be the
exception rather than the rule, and in any case it could be an
external tree structure. It doesn't actually make sense to call
something an action if its only purpose is to contain other actions;
it would be the action that doesn't act. Likewise the exclusive group
can be a separate thing, but we still have to decide how exactly to
implement it.
So now it seems to me that we can get rid of exclusive and
collapsible, so as to simplify what goes into action so that we can
get it implemented, and then continue thinking about the best way to
expose collections of them from C++, or expose individual ones, as
well as create them in QML.
Okay, forget about ActionGroup as a type for now. We can group them
with other methods in QML as well.
But I still think the action needs a name, which can be used by the
image provider to find the icon. (This is independent of whether the
image provider uses files or resources; the icon will be found by name
either way.) Maybe we can reuse objectName for that. So the action
is just called open but the image provider can go looking for
icon-open-action.png or something, using its own naming convention.
The point of that is to avoid repeating yourself in QML.
objectName has its uses, don't just give it an extra meaning. I see no
problem with adding a separate actionName or name property if that's
helpful, despite the presence of objectName.
Whether the images are provided by a QIcon, or by some other means of
providing multiple images at different resolutions, could also be a
detail of the image provider. So we can keep the action pretty well
away from the View part of MVC: it's an abstract representation of one
atom of the Control layer, not a visual representation, although it
contains enough information to be able to construct a visual
representation, so that you can stick it directly in a tool button or
a menu item without having to add extra information first in your own
QML.
How is this going to work? If no iconSource or imageSource exists on
the Action then the delegate in QtQuickControls uses
image://icons/action-name.png? Or would that be in the
QtQuickControls, that the delegate renders that url if no source is
found? While an image provider would be perfect for this, it would
probably have to go in QtQuickControls and then it can't be in the
Action type (unless this is a QtQuickControls specific Action type,
which I don't think is a good idea).
The explicit properties that we put into the C++ implementation of the
action class can be limited to the ones that we know every component
implementation will need, as long as we can still add dynamic
properties (or new properties in subclasses) for the platforms that
need something extra.
Of course. I think that's implicit in the Action type being a type for
QML instead of specifically for QtQuickControls.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 12/18/2012 07:13 PM, Oswald Buddenhagen wrote: On Tue, Dec 18, 2012 at 03:54:20PM +0100, Peter Hartmann wrote: Thanks for setting up the branch; however, would it be possible to get a 4.8-blackberry10 branch (without reference to the patch release number)? We are not really releasing our own versions of 4.8.4, 4.8.5 etc., but have our own release cycle for NDK and device images, which is not related to the Qt 4 release cycle in any way. this is immaterial. you are at some point merging from upstream, which is also when you should rebase your version number. this thinking is also reflected in vladimir's questions about the versioning. also, consider that users want to think in terms of upstream release + minimal delta, not rolling release based on older upstream. this is predestined for a rebase workflow. also, for actually upstreaming your patches, you need to rebase them anyway. latest when you have conflicts, you'll really enjoy using a non-rebased branch (because you can resolve twice or thrice - once to merge upstream, once to submit upstream, and in the worst case once more to merge back the upstreamed version) - and after some time you'll have a history with conflicted merges and duplicated commits all over the place, where it's really hard to find out where something comes from and what was already upstreamed. given the low number of unmergable vendor patches you are aiming at, you'd really do yourself and everyone else a favor by rebasing. but if you are the s/m type, you can have your long-living vendor branch. ;) You are completely right about rebasing - that is exactly what we do currently: We rebase our internal branch on top of the upstream 4.8 branch regularly (at least once a week). Where I don't follow you is why we would need several branches, each one based on a patch release, for that; IMO we just need one branch (4.8-blackberry10) that we can rebase periodically on top of the upstream 4.8 branch. So yes, long-living vendor branch please :) Peter Also (nitpicking), maybe the suffix should be -blackberry10 instead of -bb10, because I guess not everybody knows what bb10 stands for. somebody who doesn't know it wouldn't care about that branch to start with - and most our branch names are not exactly self-explanatory to the uninitiated. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)
On Tue, Dec 18, 2012 at 6:46 PM, Alan Alpert 4163654...@gmail.com wrote: Summary of the topic so far: Existing and future Applications have a need for managing actions in C++, and these need to be the same actions as QML is dealing with. How do we implement this? Here are the four options I recall being suggested so far, A) QQuickAction is added to create the QML API, properties match QAction where possible and all property access goes through the meta-object system to make the type 'meta-isomorphic' B) QAction is moved to Gui and is used to create the QML API. C) QGuiAction is added to Gui and is used to create the QML API and the bridge with QActions. D) QCoreAction is added to Core or Gui and has even less functionality, QQuickAction and QAction/QGuiAction build on top of that to fill out their API. Are there other options we can consider? My favorite of those is C), but there is the unresolved question of how to make an effective bridge given that we can no longer make QAction inherit from QGuiAction. On Tue, Dec 18, 2012 at 5:11 AM, Olivier Goffart oliv...@woboq.com wrote: On Tuesday 18 December 2012 13:33:59 Robin Burchell wrote: On Tue, Dec 18, 2012 at 12:55 PM, Stephen Kelly stephen.ke...@kdab.com wrote: The details of the split was just following Andre's suggestion. text/secondaryText might fit into CoreAction, icon will not. Why not? Because QML doesn't do QIcons? The reason for that is not clear either to me. I don't think there's any reason it couldn't. A QIcon is a QPixmap, after all, and QIcon lives in QtGui, so there's no dependency issue either. It's already in Gui? Good, then it's just the Widget* properties that are preventing the move (and I'm not saying that's an insurmountable obstacle). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Another option. Create a QAbstractAction with the bare minimum that is QML and QWidget independent. QQuickAction on top of QAbstractAction to implement the QML specifics. QAction also on top of QAbstractAction for the QWidget module. Or just leave the QAction in there as it is since it's completed anyway. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
On 18/12/2012 18:18, Alan Alpert wrote: On Tue, Dec 18, 2012 at 5:34 AM, Sean Harmer sean.har...@kdab.com wrote: 7) More enabler classes for textures, samplers, and higher-level abstractions. I think these would be good candidates for a Qt3D library, unless someone would really like to see a subset in QtGui. Do you mean something like QGLTexture2D, which abstracts a 2D GL texture? Because that already exists in the already existing Qt3D library - perhaps that can just be brought back from addon land and development can continue? Something along those lines but also for Sampler objects where available and higher level too e.g. A set of Texture Unit Configurations and also that supports more features such as texture arrays (layered textures). Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How I'm using qtchooser
On terça-feira, 18 de dezembro de 2012 10.19.31, Thiago Macieira wrote: On terça-feira, 18 de dezembro de 2012 16.11.44, Hausmann Simon wrote: That's what I was afraid of. Perhaps your instructions should be extended to include fetching the latest changeset (something like git pull origin refs/changes/20/43120/5 ). Otherwise the clone produces an empty checkout. I was hoping someone would approve. If no one does in the next 6 hours, I'll self-approve. Packages for now: http://macieira.org/~thiago/qtchooser-6-gc26b2d3.tar.gz http://macieira.org/~thiago/qtchooser-6-gc26b2d3.zip -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Tuesday, December 18, 2012 4:06 PM, Peter Hartmann wrote: some months ago, I was confident that this would be something temporary; unfortunately, practice has shown that so far we always had a few commits (1-10) that we needed to short-circuit into our branch because some internal team needed a commit urgently (maybe people that have worked on the N9 remember that situation). So I don't expect that branch to go away anytime soon, to be honest. If like this, we can assume that there are some patches(commits x1-n) which are planned to merge into upstream(current official qt repo) and some other tmp patches(commits y1-n) which maybe never goes to upstream. I think you can have a qt 4.8-bb10 branch in official repo to have those commits x1-n, and should be tested via CI to make sure those changes will not break other platforms. Then you could also have your own clone repo based on that branch and have other tmp commits y1-n(which are only for BB10) in 4.8-bb10-release branch, for example. And you could try to merge 4.8-bb10 from upstream to 4.8-bb10-release weekly or daily, if conflicts happened, I think you should rebase 4.8-bb10-release and fix those tmp patches. You could push changes into 4.8-bb10-release branch at first if needed, and if some of them could pass CI and go into 4.8-bb10 branch, you can remove them from 4.8-bb10-release later. And for 4.8-bb10-release branch, you could also try another solution, to store those tmp patches into a repo(sth like Qt Modularized project did), then use script to apply them on 4.8-bb10 branch in your own CI or test system. Just a suggestion for practice. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On 18 December 2012 19:35, Alan Alpert 4163654...@gmail.com wrote: How is this going to work? If no iconSource or imageSource exists on the Action then the delegate in QtQuickControls uses image://icons/action-name.png? Yes that's what I was thinking. Pros: - after you name the action, you don't repeat yourself (the action name is part of the icon filename) - don't need to worry about the exact path to find the icon; that's an application-wide issue, not something to specify as part of each action - makes it clear an action is abstract, so maybe no qualms about pre-creating them in C++, because there's nothing that looks like view functionality - the naming convention exists already on Linux (/usr/share/icons/theme-name/32x32/actions/*.png for example) - the image provider could still reuse QIcon by having its own QHashQString, QIcon m_iconCache or something like that - most of the time you can avoid giving an iconSource at all. If you do that in QML, then I suppose the image provider will have to use QIcon to generate the other sizes and modes? Cons: - if we don't put the icon in the action, is it even possible to specify icons for different sizes and modes in QML? or are you just stuck with a fixed icon image, or the auto-generated variants, if you give the iconSource? Or would that be in the QtQuickControls, that the delegate renders that url if no source is found? While an image provider would be perfect for this, it would probably have to go in QtQuickControls and then it can't be in the Action type (unless this is a QtQuickControls specific Action type, which I don't think is a good idea). Yep. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
On Tue, Dec 18, 2012 at 7:12 PM, Sean Harmer sean.har...@kdab.com wrote: Something along those lines but also for Sampler objects where available and higher level too e.g. A set of Texture Unit Configurations and also that supports more features such as texture arrays (layered textures). Ah, I have just realized we were discussing texture atlas as well that could be a reusable component, perhaps. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)
On 18 December 2012 20:05, Mark mark...@gmail.com wrote: On Tue, Dec 18, 2012 at 6:46 PM, Alan Alpert 4163654...@gmail.com wrote: D) QCoreAction is added to Core or Gui and has even less functionality, QQuickAction and QAction/QGuiAction build on top of that to fill out their API. Another option. Create a QAbstractAction with the bare minimum that is QML and QWidget independent. QQuickAction on top of QAbstractAction to implement the QML specifics. QAction also on top of QAbstractAction for the QWidget module. Or just leave the QAction in there as it is since it's completed anyway. How is that different than D? Having a base class would at least give us the chance to reparent QAction to inherit from it in Qt 6; isn't that the only advantage? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
On Tue, Dec 18, 2012 at 11:26 AM, Shawn Rutledge shawn.t.rutle...@gmail.com wrote: On 18 December 2012 19:35, Alan Alpert 4163654...@gmail.com wrote: How is this going to work? If no iconSource or imageSource exists on the Action then the delegate in QtQuickControls uses image://icons/action-name.png? Yes that's what I was thinking. Pros: - after you name the action, you don't repeat yourself (the action name is part of the icon filename) - don't need to worry about the exact path to find the icon; that's an application-wide issue, not something to specify as part of each action - makes it clear an action is abstract, so maybe no qualms about pre-creating them in C++, because there's nothing that looks like view functionality - the naming convention exists already on Linux (/usr/share/icons/theme-name/32x32/actions/*.png for example) - the image provider could still reuse QIcon by having its own QHashQString, QIcon m_iconCache or something like that - most of the time you can avoid giving an iconSource at all. If you do that in QML, then I suppose the image provider will have to use QIcon to generate the other sizes and modes? Cons: - if we don't put the icon in the action, is it even possible to specify icons for different sizes and modes in QML? or are you just stuck with a fixed icon image, or the auto-generated variants, if you give the iconSource? If you want more complex icon functionality, perhaps the way to do that would be to register QIcons with the image provider? An additional Icon type could be provided which registers new ones with the image provider. This does separate the icon from the action somewhat, but that's probably for the best if the icon is a complex object with state. I think iconSource should mean a fixed image. It's there for the case where you don't want the delegate second-guessing you, just use this image. You could provide it specific image provider strings of course, but to get the delegate to choose what icon variant to use has to go through the delegate process (which is when name is set but iconSource isn't). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] test for Mouse Buttons on OS-X
Hi. I would like someone with a Mac to perform the following test procedure. It attempts to verify mouse button numbering on the OS-X software stack, and proper interaction with the Window frame (Strut). (I don't have access to an Apple desktop machine). Hardware Prerequisite: a Mouse with middle button AND Back/Forward thumb buttons. Thanks in advance, to anyone who can do this (1) Build Qt5 (Developer Build), with Cocoa platform plugin. Qtbase is all you need. Configure to use Qt5 qmake and libraries. (1A) If you did not build all examples, go into directory examples/widgets/widgets/mousebuttons. Build the project (using Qt5). (2) Run the resulting buttontester program. - - - - tests within the white test area - - - - Within the GUI borders, please verify the following: (3A) Click of each button, all by itself. (Program should indicate Mouse Release: with correct Qt::MouseButton, and heldbuttons NoButton). NOTE: If the listed button is shown as Qt::ExtraButton3, or higher, when you press the Back or Forward Button -- you have Confirmed one of the theoretical Bugs already. Thanks, keep going! (3B) Press and hold a Thumb Button, verify that heldbuttons indicates this button WHILE you click other buttons. Please be sure to include the _other_ thumb button among your clicks. (3C) Press and Hold LeftButton, Press and hold BackButton (i.e., ExtraButton1), drag the mouse a short distance (still within the test area), then release BackButton. Verify the displayed event (Mouse Release: BackButton with heldbuttons LeftButton.) (3D) Now Release LeftButton, verify that the displayed event is Mouse Release: LeftButton with heldbuttons NoButton.) - - - - tests involving the window frame - - - - (4A) Press and hold both LeftButton and BackButton inside the area. Drag, buttons held, into the window frame. Now Release both. Did buttontester see any of the Release events? (4B) With no buttons pressed, Move back into the testarea Gui. Click any button, holding nothing. Does buttontester think any buttons ARE still in held state? - - - - tests involving the dekstop - - - - Repeat 4A, but drag out to a blank area of the desktop (not covered by any application window). Repeat 4B. (4C) With no buttons pressed, move from the buttontester area to a blank spot on the desktop. Click LeftButton. Does ButtonTester see the click? (4D) Still in the empty desktop location: Press both LeftButton and BackButton, then release BackButton. Did Buttontester see the Release, and does it show heldbuttons BackButton? if the test shows mis-behavior, please reply on the list. With Qt5, we actually support up to 16 mouse buttons on OS-X. But any mistakes which Qt would make on ExtraButton6, or etc., will already be visible with just the BackButton, AKA ExtraButton1, so a 5-button mouse is adequate. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Tue, Dec 18, 2012 at 07:54:37PM +0100, Peter Hartmann wrote: You are completely right about rebasing - that is exactly what we do currently: We rebase our internal branch on top of the upstream 4.8 branch regularly (at least once a week). Where I don't follow you is why we would need several branches, each one based on a patch release, for that; IMO we just need one branch (4.8-blackberry10) that we can rebase periodically on top of the upstream 4.8 branch. oh. eh. this is somewhat more extreme than expected. in fact, your branch is everything *but* a long-living branch - it's basically a scratch branch which is recreated every few days. the problem with rebasing is that you detach the actual history, so your tags are floating in limbo (provided you make tags at all). that's why i suggested a branch per upstream release. but if you rebase that often, this becomes pointless of course (you'd need a separate branch per rebase). there you have your 4.8-bb10 branch where *only* direct pushing (incl. forced pushes) is enabled. i'll leave it at noting that this is somewhat weird, and that the project may still decide that this doesn't belong into the upstream repo. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On Tue, Dec 18, 2012 at 10:06 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: i'll leave it at noting that this is somewhat weird, and that the project may still decide that this doesn't belong into the upstream repo. While it does sound a bit extreme, and I sort of pity the folks working on that branch, I'd actually say that, in terms of vendors, it's exactly what we'd want. It means they're actively working at upstreaming their work, and don't want to diverge too far from us. Having lost far too many hours of my life digging into obscure changes between vendor branches and upstream of all sorts of software in the past, I'd love this approach. The project has an additional benefit of course, in that all changes are already under the CLA, meaning that we can pick and choose pieces that are beneficial to us in some way rather than having to play the wait-and-hope-they-get-submitted game. But on the other hand, if you want to easily keep people like me employed, feel free to not do this. :-) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] branch namespacing policy?
moin, prompted by the discussion about the blackberry branch, i again started to wonder about a cleaner separation of the branches. in the qtcreator repository for example i established the convention that temporary branches must all have a wip/ prefix. a similar convention could be adopted for vendor branches, say a vendor/ (gasp!) prefix. go/no-go? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)
On Tuesday 18 December 2012 10:20:39 Thiago Macieira wrote: On terça-feira, 18 de dezembro de 2012 09.46.13, Alan Alpert wrote: B) QAction is moved to Gui and is used to create the QML API. You can't do that. QAction is QtWidgets and that's where it will stay until Qt 6. We moved QXMLStreamReader from QtXml to QtCore in Qt4 time, and this worked. As for the dependency, as i wrote in the other mail, it is only forward declared class, and the implemention of thos few QWidget-specific can stay in QtWidgets uning hook like QVariant does. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] X Error: BadDrawable with Qt4.8.4
I compiled Qt4.8.4 in Redhat6(i386), but when I run my application, X Error: BadDrawable(invalid Pixmap or Window parameter) 9 ocurrerd chenyw3892___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] If you're waiting for reviews from me...
Congratulations ! On Tue, Dec 18, 2012 at 9:18 PM, Marc Mutz marc.m...@kdab.com wrote: ... please cut me some slack while I handle the attached non-maskable interrupt :) Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ 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] If you're waiting for reviews from me...
What a beautifull project you got there in your hands :) Congratulations and all the best João de Deus De: Marc Mutz marc.m...@kdab.com Para: development@qt-project.org Enviadas: Terça-feira, 18 de Dezembro de 2012 23:18 Assunto: [Development] If you're waiting for reviews from me... ... please cut me some slack while I handle the attached non-maskable interrupt :) Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ 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] branch namespacing policy?
On terça-feira, 18 de dezembro de 2012 22.15.04, Oswald Buddenhagen wrote: moin, prompted by the discussion about the blackberry branch, i again started to wonder about a cleaner separation of the branches. in the qtcreator repository for example i established the convention that temporary branches must all have a wip/ prefix. a similar convention could be adopted for vendor branches, say a vendor/ (gasp!) prefix. go/no-go? I'd say go. qtbase already has a lot of branches that will need renaming (ios, winrt, etc.) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How I'm using qtchooser
On terça-feira, 18 de dezembro de 2012 10.19.31, Thiago Macieira wrote: On terça-feira, 18 de dezembro de 2012 16.11.44, Hausmann Simon wrote: That's what I was afraid of. Perhaps your instructions should be extended to include fetching the latest changeset (something like git pull origin refs/changes/20/43120/5 ). Otherwise the clone produces an empty checkout. I was hoping someone would approve. If no one does in the next 6 hours, I'll self-approve. I did get reviews. Unfortunately, they included -1s, so I could not in good conscious self-approve. The release of qtchooser is therefore delayed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)
On terça-feira, 18 de dezembro de 2012 23.19.50, Olivier Goffart wrote: On Tuesday 18 December 2012 10:20:39 Thiago Macieira wrote: On terça-feira, 18 de dezembro de 2012 09.46.13, Alan Alpert wrote: B) QAction is moved to Gui and is used to create the QML API. You can't do that. QAction is QtWidgets and that's where it will stay until Qt 6. We moved QXMLStreamReader from QtXml to QtCore in Qt4 time, and this worked. No, it didn't. Not really. That was a bad idea and we should not repeat that. It required renaming the class on Mac anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] If you're waiting for reviews from me...
Op 19-12-2012 0:18, Marc Mutz schreef: ... please cut me some slack while I handle the attached non-maskable interrupt :) Oh dear, you're in for a long-term project indeed! Congrats! André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Read binary file
Dear colleagues !
I have to read binary file via Qt. In console application I make
FILE * fid5 = fopen (./test_data/source.rgg, rb);
...
for (int i=1; i=na; i++)
{
fread (st+i-1, sizeof (unsigned long), nd2, fid5);
...
}
and all work fine. In Qt application I try
QString fileName = QFileDialog::getOpenFileName (this, tr(Select
source file), QDir::currentPath(), tr(All files (*)));
if (fileName.isEmpty())
return;
...
QFile * fData = new QFile (fileName);
for (int i=1; i=na; i++)
{
char * colData = new char [nd2*sizeof (unsigned long)];
qint64 colLength = fData-readLine (colData, nd2*sizeof
(unsigned long));
if (colLength 0)
{
qDebug () __PRETTY_FUNCTION__ QString (Read error);
continue;
}
QByteArray buff (colData);
delete [] colData;
//qDebug () __PRETTY_FUNCTION__ i buff;
QBuffer lBuf (buff);
lBuf.open (QIODevice::ReadOnly);
QDataStream numStr (lBuf);
quint64 num;
for (int ii=0; iind2; ii++)
{
numStr num;
qDebug () __PRETTY_FUNCTION__ num;
st[ii] = num;
}
...
}
And for the same file in debug numbers do not read properly.
Thanks a lot.
--
Best regards,
Sincerely yours,
Yuriy Rusinov.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)
Op 18-12-2012 20:34, Shawn Rutledge schreef: On 18 December 2012 20:05, Mark mark...@gmail.com wrote: On Tue, Dec 18, 2012 at 6:46 PM, Alan Alpert 4163654...@gmail.com wrote: D) QCoreAction is added to Core or Gui and has even less functionality, QQuickAction and QAction/QGuiAction build on top of that to fill out their API. Another option. Create a QAbstractAction with the bare minimum that is QML and QWidget independent. QQuickAction on top of QAbstractAction to implement the QML specifics. QAction also on top of QAbstractAction for the QWidget module. Or just leave the QAction in there as it is since it's completed anyway. How is that different than D? Having a base class would at least give us the chance to reparent QAction to inherit from it in Qt 6; isn't that the only advantage? I don't see why QAction needs to inherit from a QCoreAction, and why that would be an advantage. It could simply encapsulate one. If you don't assing one manually, it just owns a default constructed one, so there is no need to use QCoreAction explicitly if you don't want to. Same goes for a QML variant. My preference is D, obviously. I think it makes a lot of sense to be able to use actions in core, non-GUI layers of the application. I've been in places where the policy was even to not use Qt at all there, but not using QtGUI and above in core libs is almost a given. Having a QCoreAction to expose functions that can be wrapped at the GUI level with all the stuff the core doesn't want to know about (icons, shortcuts, help texts, etc.) would be very, very helpful in such cases. I think that QAction could be retrofitted to use such a QCoreAction. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Read binary file
Op 19-12-2012 8:54, Yuriy Rusinov schreef: Dear colleagues ! I have to read binary file via Qt. In console application I make I think you'd be better of asking this in inter...@qt-project.org. This list is about the development *of* Qt itself, not the development *with* Qt. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
