Re: [Interest] [OS X] creating a QDialog from a WId?

[Nuno Santos]

Yes, I’m writing a plugin and the ptr is a NSView provided by the host.

I had already tried several other options until I found QMacNativeWidget to the 
rescue. It works like charm now.

Sorry, I don’t know what KF5 is.

Nuno

> On 09/12/2015, at 00:05, René J. V. Bertin  wrote:
> 
> Nuno Santos wrote:
> 
> 
> Hello Nunos,
> 
> Have you tried using a `ptr` that comes from another application? I think 
> that's 
> the context in which I get the crash.
> 
> I'll keep your code in mind though; the crash issue also reminded me that KF5 
> KWindowSystem doesn't yet have a plugin (backed) implemented for OS X, so I'm 
> porting the one from KDE4... Fun times!
> 
> R.
> 
>> Rene,
>> 
>> I have recently dealt with creating content within a native window on mac
>> given a pointer. This was I got to:
>> 
>> QMacNativeWidget* IVstEditor::fromWindowRef(void *ptr)
>> {
>>NSView* view = (NSView*) ptr;
>> 
>>QMacNativeWidget *nativeWidget = new QMacNativeWidget(view);
>> 
>>nativeWidget->move(0, 0);
>>nativeWidget->setPalette(QPalette(Qt::red));
>>nativeWidget->setAutoFillBackground(true);
>>nativeWidget->setWindowFlags(Qt::FramelessWindowHint |
>>Qt::WindowDoesNotAcceptFocus);
>> 
>>NSView *nativeWidgetView = reinterpret_cast>*>(nativeWidget->winId());
>> 
>>[view addSubview:nativeWidgetView];
>> 
>>nativeWidget->show();
>> 
>>return nativeWidget;
>> }
>> 
>> I don’t know if you can turn a simple widget into a QDialog but maybe you can
>> find something useful here.
> 
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [OS X] creating a QDialog from a WId?

[René J . V . Bertin]

On Wednesday December 09 2015 08:30:44 Nuno Santos wrote:

Hi!

>Yes, I’m writing a plugin and the ptr is a NSView provided by the host.

That's not a different application! Plugins are loaded by what's indeed called 
a host application, but afterwards their code executes in the address space of 
the host.

My context is one in which the application that puts up the dialog receives the 
WId (or NSView* in your case) from another application that created the 
corresponding window.

>Sorry, I don’t know what KF5 is.

KF5 = "KDE Frameworks 5". Those frameworks are intended to be a cross-platform 
set of useful extensions to Qt5.

R.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] New CI for Qt (and OpenSource Qt/QtC 3rd parties)

[Ch'Gans]

On 9 December 2015 at 20:22, Alejandro Exojo  wrote:
> El Monday 07 December 2015, Ch'Gans escribió:
>> Sorry to hijack the thread a bit, but I was thinking recently about
>> adding contributor projects to some sort of CI.
>>
>> There's some nice Qt libraries around and some nice out-of-tree
>> QtCreator plugins in the wild, wouldn't it be nice if such Open Source
>> projects were integrated in such CI systems?
>> Even if they are clearly marked as
>> unsupported/unofficial/untested/?
>
> I've seen some open source projects use Travis CI (or Appveyor or similar)
> integrated in their Github workflows to provide not only the continuous
> integration (e.g. run the tests at every push) but also to provide the
> compiled "artifacts" to users.
>
> I think it will be difficult for the Qt project to support all third party
> libraries or applications out there, and I don't think that the same
> infrastructure has to be shared in order to be useful to the same degree.
>
> However, the Qt Installer Framework has a repository system that it could be
> useful for 3rd parties to provide their add-ons in a nice user interface. And
> if that is too difficult, there is QPM and Qt-Pods, which already have nicely
> packaged the source code.

Could you elaborate on this Qt Installer Framework repository, maybe
just send a link?

For those who don't know about QPM and Qt-POD (like me 5 minutes ago):
 - http://www.qt-pods.org (qmake based, in source tree, project
dependency management)
 - https://www.qpm.io (project dependency building and packaging system)

Haven't try them yet.

Chris

>
> --
> Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
> http://barnacity.net/ | http://disperso.net
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Qt3D] Camera controller

[Sean Harmer]

Hi,

On Wednesday 09 Dec 2015 08:54:58 Nye wrote:
> Hello Sean,
> 
> So I've implemented my simple camera controller. Before going into the
> detailed text, here is how I set it up:
> http://codepad.org/mXiL5Rs7
> and then what I do in the controller itself:
> http://codepad.org/9oARCaOv
> 
> The code is for testing, so please try to tolerate the stupid variable
> names. Also, any comments, especially if I'm doing something wrongly, are
> appreciated.
> 
> Now I'll go into the details of my experience:
> Firstly, I'd like to note the responsiveness is somewhat poor (possibly
> because I'm not using the onFrameUpdate part of the QML), maybe the problem
> originates from all that string comparisons or maybe because Qt is
> struggling to handle the amount signal-slot invocations, I'm not quite
> sure. This I believe is a serious problem, which should be addressed
> somehow. (As a side note: I'd like to use Qt3D for a game, so this is quite
> important for me).

Hmm the QML version works fine for me. I'll try a C++ app similar to yours. It 
may well be the lack of delta t causing it.

> As a second note, the initialization and device mapping is quite cumbersome
> to do, but this is not a real dealbraker, because can be wrapped nicely in
> the user's class. One thing that I was wondering about is why it was
> decided to pass the actions triggered by their name, is this because QML
> support is needed? As I see it, maybe it's better to directly emit a
> started()/finished() signal for the QAction object?

Right, this is mainly for QML API. We probably should add the signals directly 
to the actions/axes for C++ uses to make that less cumbersome.

> Thirdly, if I want to setup some key combination (for example camera
> rotation by left AND right mouse buttons) for operating on a given entity,
> I'd need to put quite a lot of code to handle each of the actions
> separately and then depending on my controller's internal state decide
> whether or not I should rotate/manipulate the entity. Maybe it's a good
> idea to think about the function of the action object. The ActionInput
> abstraction I very much like, but maybe an action should be triggered if
> all the inputs are in the provided state - this would abstract the
> button/axis mapping more cleanly I believe. In QML it probably would look
> like this:
> 
> LogicalDevice {  // Maybe rename to InputController/InputAdapter?
> id: cameraControlDevice
> actions: [
> Action {
> name: "RotateX"
> 
> inputs: [
> ActionInput {
> sourceDevice: mouseSourceDevice
> key: MouseController.Left
> },
> 
> ActionInput {
> sourceDevice: mouseSourceDevice
> keys: MouseController.Right
> },
> 
> AxisInput {
> sourceDevice: mouseSourceDevice
> axis: MouseController.X
> }
> ]
> 
> // Some code (signal/slot w/e) when the action is triggered -
> triggered when all the ActionInput-s are set?
> }
> ]
> }

This is the Chords feature I mentioned in my earlier email. At the moment any 
of the ActionInputs trigger the containing action to be fired. I'm planning on 
adding InputChord and InputSequence types (names pending) that allow to 
specify either a combination of ActionInputs or a sequence of ActionInputs 
within a specified time period are needed to fire the containing Action.

This is kind of analogous to the ParallelAnimation/SequentialAnimation feature 
in Qt Quick. So it would look something like this:

LogicalDevice {
id: gamepadLogicalDevice

actions: [
Action {
name: "fire"
inputs: [ // Require any of the ActionInputs to trigger
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Cross]
},
ActionInput {
sourceDevice: keyboardSourceDevice
keys: [Qt.Key_Space]
}
]
},

Action {
name: "bigBomb"
inputs: [
InputChord { // Require two buttons to fire the "bigBomb"
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Triangle]
},
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Left]
}
}
]
},

Action {
name: "specialMoveCombo"
inputs: [
InputSequence { // Require a sequence within 0.5 seconds to 
fire the "specialMoveCombo"
duration: 500

ActionInput {
sourceDevice: ps3SourceDevice

Re: [Interest] [Qt3D] Camera controller

[Nye]

Hello,
I don't know how much you're open to "larger" changes, but I'd like to
argue my case further, if you'd bear with me a bit more.

>This is the Chords feature I mentioned in my earlier email. At the moment
any
>of the ActionInputs trigger the containing action to be fired. I'm
planning on
>adding InputChord and InputSequence types (names pending) that allow to
>specify either a combination of ActionInputs or a sequence of ActionInputs
>within a specified time period are needed to fire the containing Action.

Currently, it seems that the Action is just a container for it's
ActionInputs. I suggest the following, and you decide if it's applicable or
it's something worth implementing:

1. Suppose you have an InputKey with properties the source device and a
single key and InputAxis with the source device and the axis (both probably
having a common superclass InputSource).
2. Then you may put a InputMap as a superclass for all types of InputSource
behaviours - alternatives, sequences and chords. Let's say
InputAlternatives defines the current behaviour - fires an action if one of
the keys is triggered.
InputGroup would perform the chord feature - checks all the required key
actions and fires the events when all are pressed
InputSequence configures the sequence of InputSources needed to fire the
action.
3. Then your action object will take a single InputMap instance (one of the
three possibilities at this point), and will be an abstraction for an
action, not input mapping. The action would then be indifferent to the
input mapping provided, but will follow its event depending on the InputMap
you've set as a property.

It'd look something like this in QML:

Action  {
   name: "shootCannons"
   input: InputAlternatives  {
   sources: [
InputKey  {
 sourceDevice: mouseDevice
 key: MouseController.Left
},
InputKey  {
 sourceDevice: keyboardDevice
 key: Qt.Key_Space
}
   ]
   }
},
Action  {
   name: "shootRockets"
   input: InputGroup  {
   time: 0.1
   sources: [
InputKey  {
 sourceDevice: mouseDevice
 key: MouseController.Left
},
InputKey  {
 sourceDevice: keyboardDevice
 key: Qt.Key_Shift
}
   ]
   }
}

You keep the flexibility to change the input map at any one point, of
course. And it'd be nice to be able to treat the Axis events on an equal
footing with the button events (for example when emitting the action's
signal the data from all InputMaps could be collected and passed as
parameter).

I think this'd be interesting to consider, because it makes the aggregation
tree a bit less complex (less branches and nodes are needed to obtain the
functionality). Also, as I see it, ActionInput objects in the current
architecture are practically always used with a single key.

I'd be willing to contribute source as well, but I'm afraid my knowledge of
the underlying classes is pretty limited.

Kind regards,
Konstantin.

On Wed, Dec 9, 2015 at 12:22 PM, Sean Harmer  wrote:

> Hi,
>
> On Wednesday 09 Dec 2015 08:54:58 Nye wrote:
> > Hello Sean,
> >
> > So I've implemented my simple camera controller. Before going into the
> > detailed text, here is how I set it up:
> > http://codepad.org/mXiL5Rs7
> > and then what I do in the controller itself:
> > http://codepad.org/9oARCaOv
> >
> > The code is for testing, so please try to tolerate the stupid variable
> > names. Also, any comments, especially if I'm doing something wrongly, are
> > appreciated.
> >
> > Now I'll go into the details of my experience:
> > Firstly, I'd like to note the responsiveness is somewhat poor (possibly
> > because I'm not using the onFrameUpdate part of the QML), maybe the
> problem
> > originates from all that string comparisons or maybe because Qt is
> > struggling to handle the amount signal-slot invocations, I'm not quite
> > sure. This I believe is a serious problem, which should be addressed
> > somehow. (As a side note: I'd like to use Qt3D for a game, so this is
> quite
> > important for me).
>
> Hmm the QML version works fine for me. I'll try a C++ app similar to
> yours. It
> may well be the lack of delta t causing it.
>
> > As a second note, the initialization and device mapping is quite
> cumbersome
> > to do, but this is not a real dealbraker, because can be wrapped nicely
> in
> > the user's class. One thing that I was wondering about is why it was
> > decided to pass the actions triggered by their name, is this because QML
> > support is needed? As I see it, maybe it's better to directly emit a
> > started()/finished() signal for the QAction object?
>
> Right, this is mainly for QML API. We probably should add the signals
> directly
> to the actions/axes for C++ uses to make that less cumbersome.
>
> > Thirdly, if I want to setup some key combination (for example camera
> > rotation by left AND 

Re: [Interest] New CI for Qt (and OpenSource Qt/QtC 3rd parties)

[rpzrpz...@gmail.com]

What's missing are any comment from Qt on its new CI and the specs 
behind it.


That would have been a great topic during Qt World 2015.

md

On 12/9/2015 3:31 AM, Ch'Gans wrote:

>I think it will be difficult for the Qt project to support all third party


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] `pkg-config --cflags Qt5Gui Qt5Widgets Qt5Core` with Qt 5.4.2 on Yosemite

[Sherif Ghali]

After installing
qt-opensource-mac-x64-clang-5.4.2.dmg
(size:616,135,300 bytes) and setting
export
PKG_CONFIG_PATH="/usr/local/Qt5.4.2/5.4/clang_64/lib/pkgconfig:${PKG_CONFIG_PATH}"
in .bash_profile, I am expecting that typing
pkg-config --cflags Qt5Gui Qt5Widgets Qt5Core
pkg-config --libs Qt5Gui Qt5Widgets Qt5Core
will produce appropriate settings (when compiling without qmake).

The output of the latter (--libs) makes sense:
-F/usr/local/Qt5.4.2/5.4/clang_64/lib -framework QtWidgets
-F/usr/local/Qt5.4.2/5.4/clang_64/lib -framework QtGui
-F/usr/local/Qt5.4.2/5.4/clang_64/lib -framework QtCore

but the output of the former (--cflags):
-I/usr/local/Qt5.4.2/5.4/clang_64/include/QtWidgets
-I/usr/local/Qt5.4.2/5.4/clang_64/include
-I/usr/local/Qt5.4.2/5.4/clang_64/include/QtGui
-I/usr/local/Qt5.4.2/5.4/clang_64/include
-I/usr/local/Qt5.4.2/5.4/clang_64/include/QtCore
-I/usr/local/Qt5.4.2/5.4/clang_64/include
seems wrong because /usr/local/Qt5.4.2/5.4/clang_64/include has
the four folders:
QtOpenGLExtensions QtPlatformHeaders QtPlatformSupport QtUiTools
but doesn't have QtWidgets, QtGui, or QtCore.

Where should I be looking to fix this problem? I'm on OS X 10.10.5
(Yosemite).

Sherif Ghali
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] New CI for Qt (and OpenSource Qt/QtC 3rd parties)

[NoRulez]

Why not using Qt with CMake and Jenkins CI?
With this combination you could also use non Qt related projects.

Best Regards

> Am 09.12.2015 um 14:26 schrieb "rpzrpz...@gmail.com" :
> 
> What's missing are any comment from Qt on its new CI and the specs behind it.
> 
> That would have been a great topic during Qt World 2015.
> 
> md
> 
>> On 12/9/2015 3:31 AM, Ch'Gans wrote:
>> >I think it will be difficult for the Qt project to support all third party
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] Qt 5.7 feature freeze postponed, new date to be agreed

[m...@rpzdesign.com]

Tuuka:

I was looking around for "Coin CI" information on google.

Can you provide links and additional insight into this CI?

We have a thread on the interest list related to CI.

md


On 12/9/2015 9:58 AM, Turunen Tuukka wrote:


Hi,

15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is 
to have the currently TP modules (at least many of them) supported 
with Qt 5.7 and also to drop the non-C++11 compilers as already 
discussed, agreed and implemented for dev. Therefore the content of Qt 
5.7 is to a large extent already shaping up and in case someone has 
new features just starting, these are probably better to aim towards 
Qt 5.8. I really would like us the finally get to the desired April & 
October release cycle during 2016 with the new Coin CI. Even though 
moving Qt 5.7 FF to 15^th Jan means the final being in May instead of 
April, I think it is something we can accept.


Yours,

  Tuukka

*From:*Development [mailto:development-boun...@qt-project.org] *On 
Behalf Of *Heikkinen Jani

*Sent:* keskiviikkona 9. joulukuuta 2015 12.22
*To:* developm...@qt-project.org
*Subject:* [Development] Qt 5.7 feature freeze postponed, new date to 
be agreed

*Importance:* High

Hi all,

According to original plans we should have Qt 5.7 FF next Friday (18th 
Dec). But we are still fighting to get Qt 5.6 (beta) out so there is 
no point to start freezing Qt 5.7 yet. We discussed about that 
yesterday's release team meeting & agreed to start discussion in ML 
about the issue. Ideally we should wait Qt 5.6.0 RC before start 
freezing Qt 5.7. But waiting Qt 5.6.0 RC might cause unnecessary delay 
for Qt 5.7 as well and I don't want to postpone 5.7 so much. That's 
why I propose 15th Jan 2016 for new feature freeze date for Qt 5.7. It 
should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out 
during next week as planned).


br,

Jani



___
Development mailing list
developm...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] New CI for Qt (and OpenSource Qt/QtC 3rd parties)

[rpzrpz...@gmail.com]

Because the original question is to explore the NEW CI that the Qt 
Company dev team has chosen

and understand it.

But other suggestions improve awareness as well.

md

On 12/9/2015 11:41 AM, NoRulez wrote:

Why not using Qt with CMake and Jenkins CI?
With this combination you could also use non Qt related projects.

Best Regards


Am 09.12.2015 um 14:26 schrieb "rpzrpz...@gmail.com" :

What's missing are any comment from Qt on its new CI and the specs behind it.

That would have been a great topic during Qt World 2015.

md


On 12/9/2015 3:31 AM, Ch'Gans wrote:

I think it will be difficult for the Qt project to support all third party

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] `pkg-config --cflags Qt5Gui Qt5Widgets Qt5Core` with Qt 5.4.2 on Yosemite

[Thiago Macieira]

On Wednesday 09 December 2015 12:10:09 Sherif Ghali wrote:
> Where should I be looking to fix this problem? I'm on OS X 10.10.5
> (Yosemite).

It's a bug in the generated pkg-config files because no one tests or uses them 
on OS X. We barely test them on Linux where frameworks don't exist...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Qt3D] Camera controller

[Nye]

Hello again,
I've run some more extensive tests regarding the action's signals and here
is what I gather from that. It seems that even if I don't release the mouse
key at all I get a actionFinished signal fired, not sure why. Here's an
example from my code (I just print out in the debug the slot's calls):
http://codepad.org/jWVZW3I7
It seems on the one hand that I get actionFinished/actionStarted signals
when I shouldn't (the mouse button was not released at any one point while
dragging it around. And also that for some reason events might be getting
rearranged a bit, note the difference in values, although the direction of
the mouse moving was not changed except at the boundaries (where I get the
started/finished actions actually).

I hope this helps in tracking that issue.
Kind regards.



On Wed, Dec 9, 2015 at 1:40 PM, Nye  wrote:

> Hello,
> I don't know how much you're open to "larger" changes, but I'd like to
> argue my case further, if you'd bear with me a bit more.
>
> >This is the Chords feature I mentioned in my earlier email. At the moment
> any
> >of the ActionInputs trigger the containing action to be fired. I'm
> planning on
> >adding InputChord and InputSequence types (names pending) that allow to
> >specify either a combination of ActionInputs or a sequence of ActionInputs
> >within a specified time period are needed to fire the containing Action.
>
> Currently, it seems that the Action is just a container for it's
> ActionInputs. I suggest the following, and you decide if it's applicable or
> it's something worth implementing:
>
> 1. Suppose you have an InputKey with properties the source device and a
> single key and InputAxis with the source device and the axis (both probably
> having a common superclass InputSource).
> 2. Then you may put a InputMap as a superclass for all types of
> InputSource behaviours - alternatives, sequences and chords. Let's say
> InputAlternatives defines the current behaviour - fires an action if one of
> the keys is triggered.
> InputGroup would perform the chord feature - checks all the required key
> actions and fires the events when all are pressed
> InputSequence configures the sequence of InputSources needed to fire the
> action.
> 3. Then your action object will take a single InputMap instance (one of
> the three possibilities at this point), and will be an abstraction for an
> action, not input mapping. The action would then be indifferent to the
> input mapping provided, but will follow its event depending on the InputMap
> you've set as a property.
>
> It'd look something like this in QML:
>
> Action  {
>name: "shootCannons"
>input: InputAlternatives  {
>sources: [
> InputKey  {
>  sourceDevice: mouseDevice
>  key: MouseController.Left
> },
> InputKey  {
>  sourceDevice: keyboardDevice
>  key: Qt.Key_Space
> }
>]
>}
> },
> Action  {
>name: "shootRockets"
>input: InputGroup  {
>time: 0.1
>sources: [
> InputKey  {
>  sourceDevice: mouseDevice
>  key: MouseController.Left
> },
> InputKey  {
>  sourceDevice: keyboardDevice
>  key: Qt.Key_Shift
> }
>]
>}
> }
>
> You keep the flexibility to change the input map at any one point, of
> course. And it'd be nice to be able to treat the Axis events on an equal
> footing with the button events (for example when emitting the action's
> signal the data from all InputMaps could be collected and passed as
> parameter).
>
> I think this'd be interesting to consider, because it makes the
> aggregation tree a bit less complex (less branches and nodes are needed to
> obtain the functionality). Also, as I see it, ActionInput objects in the
> current architecture are practically always used with a single key.
>
> I'd be willing to contribute source as well, but I'm afraid my knowledge
> of the underlying classes is pretty limited.
>
> Kind regards,
> Konstantin.
>
> On Wed, Dec 9, 2015 at 12:22 PM, Sean Harmer  wrote:
>
>> Hi,
>>
>> On Wednesday 09 Dec 2015 08:54:58 Nye wrote:
>> > Hello Sean,
>> >
>> > So I've implemented my simple camera controller. Before going into the
>> > detailed text, here is how I set it up:
>> > http://codepad.org/mXiL5Rs7
>> > and then what I do in the controller itself:
>> > http://codepad.org/9oARCaOv
>> >
>> > The code is for testing, so please try to tolerate the stupid variable
>> > names. Also, any comments, especially if I'm doing something wrongly,
>> are
>> > appreciated.
>> >
>> > Now I'll go into the details of my experience:
>> > Firstly, I'd like to note the responsiveness is somewhat poor (possibly
>> > because I'm not using the onFrameUpdate part of the QML), maybe the
>> problem
>> > originates from all that string comparisons or maybe because Qt is
>> > struggling to handle the amount signal-sl

[Interest] MenuContentItem.qml Acccessible is not defined

[Jérôme Godbout]

Hi,
We are trying to move to Qt 5.5 (were in Qt5.3.0 before). We are creating
our own style and replacing the Controls style and I end up with this error:

Qt55/msvc2015_64_opengl/qml/QtQuick/Controls/Private/MenuContentItem.qml:178:
ReferenceError: Acccessible is not defined

This is weird, since the import QtQuick 2.2 is there, I guess the
Accessible element exist into that version. Maybe someone can tell me if
this is a missing part import or wrong version. Since this is not our code
itself, not sure if I should change that.

This happen with menu for contexual menu and for button menu.

We had to change our combo box style that now await some color to be
defined into the panel Component. Except that our style seem to be working
as expected.

Jerome
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Qt 5.6+ WebView

[Jérôme Godbout]

Hi,
I have a question, I known that WebKit will no more be part of Qt, but I
was woundering what will happen with WebView into Qml?

   - will it be removed?
   - Do we have to compile WebKit on the side to make it work?
   - Is it Chromium that replace it?

I'm trying to plan what to do with it, we already had some problem
compiling WebKit with Qt 5.5 under Windows. Wonder if I should ditch that
entirely or try to make it work?

Thanks,
Jerome
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.6+ WebView

[Konstantin Tokarev]

09.12.2015, 21:27, "Jérôme Godbout" :
> Hi,
> I have a question, I known that WebKit will no more be part of Qt, but I was 
> woundering what will happen with WebView into Qml?
>
> * will it be removed?
> * Do we have to compile WebKit on the side to make it work?
> * Is it Chromium that replace it?
> I'm trying to plan what to do with it, we already had some problem compiling 
> WebKit with Qt 5.5 under Windows. Wonder if I should ditch that entirely or 
> try to make it work?

You can use 5.6 branch from here:

git://code.qt.io/qt/qtwebkit.git


-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MenuContentItem.qml Acccessible is not defined

[Michael R Nelson]

Hi,

I believe you are running into https://bugreports.qt.io/browse/QTBUG-47847. You 
can fix simply by fixing the typo (“Accessible”, not “Acccessible”) in 
MenuContentItem.qml.

Mike

From: Interest [mailto:interest-boun...@qt-project.org] On Behalf Of Jérôme 
Godbout
Sent: Wednesday, December 09, 2015 1:21 PM
To: Interests Qt 
Subject: [Interest] MenuContentItem.qml Acccessible is not defined

Hi,
We are trying to move to Qt 5.5 (were in Qt5.3.0 before). We are creating our 
own style and replacing the Controls style and I end up with this error:

Qt55/msvc2015_64_opengl/qml/QtQuick/Controls/Private/MenuContentItem.qml:178: 
ReferenceError: Acccessible is not defined

This is weird, since the import QtQuick 2.2 is there, I guess the Accessible 
element exist into that version. Maybe someone can tell me if this is a missing 
part import or wrong version. Since this is not our code itself, not sure if I 
should change that.

This happen with menu for contexual menu and for button menu.

We had to change our combo box style that now await some color to be defined 
into the panel Component. Except that our style seem to be working as expected.

Jerome


Please be advised that this email may contain confidential information. If you 
are not the intended recipient, please notify us by email by replying to the 
sender and delete this message. The sender disclaims that the content of this 
email constitutes an offer to enter into, or the acceptance of, any agreement; 
provided that the foregoing does not invalidate the binding effect of any 
digital or other electronic reproduction of a manual signature that is included 
in any attachment.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] New CI for Qt (and OpenSource Qt/QtC 3rd parties)

[Edward Sutton]

>Because the original question is to explore the NEW CI that the Qt Company dev 
>team has chosen
and understand it.

I too would like to learn about the Qt move to a new CI system.

Has Qt moved away from Jenkins to a Puppet based system?

https://puppetlabs.com/puppet/what-is-puppet

-Ed



But other suggestions improve awareness as well.

md

On 12/9/2015 11:41 AM, NoRulez wrote:
Why not using Qt with CMake and Jenkins CI?
With this combination you could also use non Qt related projects.

Best Regards

Am 09.12.2015 um 14:26 schrieb 
"rpzrpz...@gmail.com" 
mailto:rpzrpz...@gmail.com>>:

What's missing are any comment from Qt on its new CI and the specs behind it.

That would have been a great topic during Qt World 2015.

md

On 12/9/2015 3:31 AM, Ch'Gans wrote:
I think it will be difficult for the Qt project to support all third party
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] New CI for Qt (and OpenSource Qt/QtC 3rd parties)

[Alejandro Exojo]

El Wednesday 09 December 2015, Ch'Gans escribió:
> Could you elaborate on this Qt Installer Framework repository, maybe
> just send a link?

Now I don't remember much about this topic in the documentation of the Qt 
Installer Framework, but some time ago when I used it for a project, I got the 
idea that the online versions of the installer support different repositories 
from possibly different parties.

You can see it yourself in the Maintenance Tool of the Qt installer. Choose 
Add/Update components, and you'll have a settings button. Click it, and you 
can choose repositories there. I imagine that's the way the commercial add-ons 
can be added to an already existing installation of the rest of Qt.

I don't know if there are limitations in practice, though. This are the IFW 
docs:

http://doc.qt.io/qtinstallerframework/

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.6+ WebView

[Thiago Macieira]

On Wednesday 09 December 2015 21:28:52 Konstantin Tokarev wrote:
> 09.12.2015, 21:27, "Jérôme Godbout" :
> > Hi,
> > I have a question, I known that WebKit will no more be part of Qt, but I
> > was woundering what will happen with WebView into Qml?
> > 
> > * will it be removed?
> > * Do we have to compile WebKit on the side to make it work?
> > * Is it Chromium that replace it?
> > I'm trying to plan what to do with it, we already had some problem
> > compiling WebKit with Qt 5.5 under Windows. Wonder if I should ditch that
> > entirely or try to make it work?
> You can use 5.6 branch from here:
> 
> git://code.qt.io/qt/qtwebkit.git

Don't use the 5.6 branch. Use the 5.5.1 release.

We'll fix the failures to build.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] Qt 5.7 feature freeze postponed, new date to be agreed

[Turunen Tuukka]

Hi,

A blog post is in the works, but not yet published. Now we have been focusing 
to get the Qt 5.6 beta out.

We have not changed how Qt is built, codereview or the HW of CI, it is only the 
CI SW side that is renewed.

Yours,

--
Tuukka

"m...@rpzdesign.com" 
mailto:m...@rpzdesign.com>> kirjoitti 9.12.2015 kello 19.46:

Tuuka:

I was looking around for "Coin CI" information on google.

Can you provide links and additional insight into this CI?

We have a thread on the interest list related to CI.

md


On 12/9/2015 9:58 AM, Turunen Tuukka wrote:

Hi,

15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is to have 
the currently TP modules (at least many of them) supported with Qt 5.7 and also 
to drop the non-C++11 compilers as already discussed, agreed and implemented 
for dev. Therefore the content of Qt 5.7 is to a large extent already shaping 
up and in case someone has new features just starting, these are probably 
better to aim towards Qt 5.8. I really would like us the finally get to the 
desired April & October release cycle during 2016 with the new Coin CI. Even 
though moving Qt 5.7 FF to 15th Jan means the final being in May instead of 
April, I think it is something we can accept.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Heikkinen Jani
Sent: keskiviikkona 9. joulukuuta 2015 12.22
To: developm...@qt-project.org
Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed
Importance: High


Hi all,



According to original plans we should have Qt 5.7 FF next Friday (18th Dec). 
But we are still fighting to get Qt 5.6 (beta) out so there is no point to 
start freezing Qt 5.7 yet. We discussed about that yesterday's release team 
meeting & agreed to start discussion in ML about the issue. Ideally we should 
wait Qt 5.6.0 RC before start freezing Qt 5.7. But waiting Qt 5.6.0 RC might 
cause unnecessary delay for Qt 5.7 as well and I don't want to postpone 5.7 so 
much. That's why I propose 15th Jan 2016 for new feature freeze date for Qt 
5.7. It should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out 
during next week as planned).



br,
Jani



___
Development mailing list
developm...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
developm...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest