Re: [Development] Scope of source code license files
On 4/05/2016 7:39 PM, Lars Knoll wrote: On 02/05/16 14:37, "Development on behalf of Sze Howe Koh" wrote: Hello, The LICENSE.GPLvX and LICENSE.LGPLvX files from http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with "The Qt Toolkit is Copyright (C) 2015...", but then they go on to say "You may use, distribute and copy the Qt GUI Toolkit under the terms of..." Is this correct? What about non-GUI parts of the toolkit? The GUI in here is just a historical thing. It applies to Qt. Wording should probably should be changed then as times have changed and Qt is certainly no longer just a GUI toolkit. Cheers, Lars ___ 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] [5.7-beta] qtgamepad compile failure
On sexta-feira, 6 de maio de 2016 11:35:16 PDT Tim Blechmann wrote: > ah, thanks for the pointer ... importing qt tarballs into git repos is > full of surprises: qtgamepad/.gitignore ignores 'include' The release tarballs should have removed the .gitignore file. Compare http://code.qt.io/cgit/qt/qtbase.git/tree/.gitattributes?h=v5.7.0-beta1 with http://code.qt.io/cgit/qt/qtgamepad.git/tree/.gitattributes?h=v5.7.0-beta1 -- 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] Suggestion: how to know when object is scheduled for deletion
Yep correct
2016-05-06 1:01 GMT+02:00 Thiago Macieira :
> On quinta-feira, 5 de maio de 2016 22:21:08 PDT Filippo Cucchetto wrote:
> > void invokeDeleteLater(QObject* other) {
> > other->deleteLater();
> > emit aboutToBeDeleted(other)
> > }
>
> You want the emit before the deleteLater(), if the object can be in another
> thread.
>
> --
> 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
>
--
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt Quick] Automatically restoring focus to last focused item
That's a very universal solution to a specific problem and one that's going
to have all kinds of unintended consequences. Without knowing why focus was
taken from an item and given to another and why that other object
relinquished focus it's impossible to know whether focus should be restored
to that first item. That memory may have to go back more than one item as
well, after all if you open one menu then another then the previous focus
item is the first window and that's obviously not what you want to give
focus to.
What you want to do instead is introduce a FocusScope to ApplicationWindow.
If the window's content item is a focus scope then giving focus to a menu
which is outside of this scope will not affect focus within the scope, then
whatever logic closes the menu can give focus back to the content item and
that will implicitly return active focus to your item in the window body.
Andrew
On Fri, May 6, 2016 at 12:08 AM, Mitch Curtis wrote:
> Consider the example below (requires Qt 5.7):
>
> import QtQuick 2.6
> import QtQuick.Layouts 1.1
> import QtQuick.Window 2.2
> import QtQuick.Controls 2.0
>
> ApplicationWindow {
> width: 400
> height: 200
> visible: true
>
> onActiveFocusItemChanged: print("activeFocusItem", activeFocusItem)
>
> header: ToolBar {
> RowLayout {
> focus: false
> implicitWidth: children[0].implicitWidth
> implicitHeight: children[0].implicitHeight
>
> ToolButton {
> text: qsTr("File")
> onClicked: fileMenu.open()
>
> Menu {
> id: fileMenu
> y: parent.height
>
> MenuItem {
> text: qsTr("New")
> }
> MenuItem {
> text: qsTr("open")
> }
> MenuItem {
> text: qsTr("Close")
> }
> }
> }
> }
> }
>
> FocusScope {
> id: focusScope
> focus: true
> anchors.fill: parent
>
> property bool toggled: false
> onToggledChanged: print("toggled", toggled)
>
> Keys.onPressed: {
> if (event.modifiers === Qt.AltModifier) {
> focusScope.toggled = true;
> }
> }
> Keys.onReleased: {
> if ((event.modifiers === Qt.AltModifier || event.key ===
> Qt.Key_Alt) && !event.isAutoRepeat) {
> focusScope.toggled = false;
> }
> }
>
> RowLayout {
> anchors.centerIn: parent
>
> Button {
> id: penButton
> text: qsTr("Pen")
> highlighted: !focusScope.toggled
> }
> Button {
> id: eyedropperButton
> text: qsTr("Eyedropper")
> highlighted: focusScope.toggled
> }
> }
> }
> }
>
> The idea is that holding the Alt key down will toggle between two "modes".
> The mode is indicated by a highlighted button.
>
> Try switching between the buttons. Now open the menu by clicking the
> "File" button. The menu will receive focus and the focus scope will lose
> it. If you then close the menu and try to switch between the buttons again,
> it won't work because the focus scope never regained focus (the root item
> now has it). This is explained here [1]:
>
> "When a QML Item explicitly relinquishes focus (by setting its focus
> property to false while it has active focus), the system does not
> automatically select another type to receive focus. That is, it is possible
> for there to be no currently active focus."
>
> I'm not sure if "explicitly relinquishes focus" is exactly what's
> happening here, though. The FocusScope loses focus because something else
> was open temporarily. So now the developer has no other option than to
> listen to e.g. the menu visibility changes and explicitly set focus on the
> FocusScope accordingly. That's pretty gross if you ask me. I think we can
> do better. Specifically, I think that we should remember the last focused
> item, and give that focus, rather than give it to the root item. The
> question is, would it be an acceptable change for Qt 5? I'd assume that
> users are already working around this anyway, and so the fix wouldn't hurt.
>
> [1] http://doc.qt.io/qt-5/qtquick-input-focus.html
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development
[Development] HEADS UP: Qt 5.6.1 branching ongoing
The 5.6.1 branch is now available. Please start using it for changes targeting the Qt 5.6.1 release. We will merge the 5.6 branch to 5.6.1 a last time somewhen next week, so there should be enough time to finalize ongoing changes in 5.6, and start using 5.6.1 for new changes. Changes done on 5.6.1 are forward-merged to 5.6, 5.7, and dev - as usual. Don't cherry-pick in either direction if at all avoidable - as usual. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [5.7-beta] qtgamepad compile failure
>>> I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and >>> confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present >> >> ah, thanks for the pointer ... importing qt tarballs into git repos is >> full of surprises: qtgamepad/.gitignore ignores 'include' >> >> my usual workflow is to import the qt-everywhere-enterprise-src*.tar >> tarball into a git repo, as i need to apply 10-40 patches to work around >> qt bugs. of course .gitignore or .gitmodules files don't exactly make >> this a no-brainer :/ > > Which bugs? Can you not upstream the fixes? most of the fixes were backports or have been merged upstream at one point, but waiting for the next qt version wasn't an option. some of the fixes (including some provided by qtcompany or qtsupport) were rejected because they were not considered 'correct' (though for some issues an ugly hack is better than a crash of an end-user application). some of my patches were not adopted as submitted, but the algorithm was rewritten, but not merged yet. -- i cannot tell to end-users: "hey, i know this is going to crash, but the fix hasn't arrived upstream, yet" :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [5.7-beta] qtgamepad compile failure
>>> I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and >>> confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present >> >> ah, thanks for the pointer ... importing qt tarballs into git repos is >> full of surprises: qtgamepad/.gitignore ignores 'include' >> >> my usual workflow is to import the qt-everywhere-enterprise-src*.tar >> tarball into a git repo, as i need to apply 10-40 patches to work around >> qt bugs. of course .gitignore or .gitmodules files don't exactly make >> this a no-brainer :/ > > If you are using git anyway why don't you directly clone from the > git repos? for practical reasons: qt is not one repo, but several glued together with submodules, so i'd have to mirror all submodule repos separately using the same structure as the upstream repos to make sure the 'url' works. whenever a new submodule is added one has to explicitly mirror it. also one will constantly run into merge conflicts in the main repository, as the git revisions will differ. if the qt repo were monolithic i'd be more than happy to use it directly, but with submodules it calls for trouble :/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [5.7-beta] qtgamepad compile failure
On Friday 06 May 2016 11:35:16 Tim Blechmann wrote: > > I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and > > confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present > > ah, thanks for the pointer ... importing qt tarballs into git repos is > full of surprises: qtgamepad/.gitignore ignores 'include' > > my usual workflow is to import the qt-everywhere-enterprise-src*.tar > tarball into a git repo, as i need to apply 10-40 patches to work around > qt bugs. of course .gitignore or .gitmodules files don't exactly make > this a no-brainer :/ Which bugs? Can you not upstream the fixes? Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [5.7-beta] qtgamepad compile failure
On Fri, May 06, 2016 at 11:35:16AM +0200, Tim Blechmann wrote: > > I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and > > confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present > > ah, thanks for the pointer ... importing qt tarballs into git repos is > full of surprises: qtgamepad/.gitignore ignores 'include' > > my usual workflow is to import the qt-everywhere-enterprise-src*.tar > tarball into a git repo, as i need to apply 10-40 patches to work around > qt bugs. of course .gitignore or .gitmodules files don't exactly make > this a no-brainer :/ If you are using git anyway why don't you directly clone from the git repos? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [5.7-beta] qtgamepad compile failure
> I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and > confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present ah, thanks for the pointer ... importing qt tarballs into git repos is full of surprises: qtgamepad/.gitignore ignores 'include' my usual workflow is to import the qt-everywhere-enterprise-src*.tar tarball into a git repo, as i need to apply 10-40 patches to work around qt bugs. of course .gitignore or .gitmodules files don't exactly make this a no-brainer :/ thanks a lot! tim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
