Re: [Interest] What don't you like about Qt?

[Bernhard Lindner]

1. New features (quantity) are priorized over bug fixing (quality). Suggestions 
are almost sensless. I reduced writing bug reports and totally gave up writing 
suggestions due to this.

2. Widgets have too low priority. In general new fancy features are priorized 
above bread-and-butter features from my point of view.

3. Components have been declared outdated while the replacements did not 
provide the same feature set. This seriously damages Qt's reputation.

> It's not unusual for us developers and contributors to lose
> perspective of what's important.
> After many years spent on very particular implementation details, it
> becomes difficult to see outside of the box.
> 
> And because we already know the good aspects I'm asking only about the bad.
> No need to discuss or reach an agreement, just go ahead and enumerate
> what you don't like.

-- 
Regards, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Qt3D] Best way to do operations before rendering

[Sean Harmer]

Hi,

a QFrameAction is for code that should be executed once per frame not a 
one time thing. It's mainly useful for prototyping as it can be quite 
expensive due the backend/frontend synchronisation it entails.


To have some operation completed before rendering a part of your scene 
graph, just defer adding that subtree to the scene graph until it is 
done. That is, call your function that builds your uber shader then when 
that is done add your sub-tree that uses that shader to the main scene 
graph.


Cheers,

Sean

On 02/10/2016 22:22, Xavier Bigand wrote:

I have some operations that I need to do before the scene-graph start
the rendering or a least be able to do an operation before a specific
node is rendered.

I want to start by building the source code of the uber-shader used by
my custom material. So I tried to use a QFrameAction on my root scene
node, but the slot isn't called.
I have attached the QFrameAction as component of root node and then
connect my slot to it, but the slot is never called.

My I missed something, or it is simply not the good way to do?


--
Xavier


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



--
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
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [OS X] 10.12 SDK breaks qt5-qtconnectivity build (on 10.11)

[Mike Krus]

HI

went for a more all encompassing (or brutal) approach here:
https://codereview.qt-project.org/#/c/172612/ 




Mike

> On 2 Oct 2016, at 21:51, René J.V. Bertin  wrote:
> 
> On Sunday October 02 2016 21:26:13 Samuel Gaist wrote:
> 
>> I don’t have the older SDK at hand to test that so I have protected the new 
>> includes with SDK checks.
> 
> That seems sufficient on OS X 10.9, I'll post the patch on the MacPorts 
> ticket and let you know if ever it doesn't do the trick.
> Thanks!
> 
> René
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

--
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908   Mobile +44 7833 491941
KDAB - The Qt Experts

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

Re: [Interest] [Qt3D] Best way to do operations before rendering

[Xavier Bigand]

Hi,

I think that I didn't explain correctly how I use the uber shader, it's a
shader that will change with properties of the material. Our shader is
rebuild when lighting, engine settings,... changed so it might be rebuild
at anytime for already existing objects. To avoid to regenerate the shader
to much i am using dirty flag, but by doing that I need a slot called at
each frame to check it.

I'll certainly will have some other operations to do at each frame, like
lights sorting for shadows,...
I have a class responsible of the root node, that will be responsible to
manage those operations, this will allow us to have only one
synchronization point.

Maybe that it is simplier to use the QQuickWindow::beforeRendering?


2016-10-03 9:21 GMT+02:00 Sean Harmer :

> Hi,
>
> a QFrameAction is for code that should be executed once per frame not a
> one time thing. It's mainly useful for prototyping as it can be quite
> expensive due the backend/frontend synchronisation it entails.
>
> To have some operation completed before rendering a part of your scene
> graph, just defer adding that subtree to the scene graph until it is done.
> That is, call your function that builds your uber shader then when that is
> done add your sub-tree that uses that shader to the main scene graph.
>
> Cheers,
>
> Sean
>
>
> On 02/10/2016 22:22, Xavier Bigand wrote:
>
>> I have some operations that I need to do before the scene-graph start
>> the rendering or a least be able to do an operation before a specific
>> node is rendered.
>>
>> I want to start by building the source code of the uber-shader used by
>> my custom material. So I tried to use a QFrameAction on my root scene
>> node, but the slot isn't called.
>> I have attached the QFrameAction as component of root node and then
>> connect my slot to it, but the slot is never called.
>>
>> My I missed something, or it is simply not the good way to do?
>>
>>
>> --
>> Xavier
>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
> --
> 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
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



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

Re: [Interest] [OS X] 10.12 SDK breaks qt5-qtconnectivity build (on 10.11)

[René J . V . Bertin]

On Monday October 03 2016 09:21:28 Mike Krus wrote:

> went for a more all encompassing (or brutal) approach here:
> https://codereview.qt-project.org/#/c/172612/ 
> 
> 

Re: testing with older SDKs: Samuel's conditional check works on 10.9 with the 
10.9 SDK so should work everywhere (if it indeed checks for the actual SDK 
version being used).

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

Re: [Interest] What don't you like about Qt?

[John C. Turnbull]

It's ironic in a way that every major graphical toolkit (and with many large 
software projects in general) that I've worked with over decades now, the 
attitude has commonly seemed to have been that "new" is better than "stable".

The end result is a product full of both older and newer unstable features.

Then credibility and reputation both take a major hit and for serious 
production users, frustration overwhelms them as they wait for features they 
have been using and investing years of effort/time/money into to simply work 
without major defects.

More often than not though, if these features are not part of the "new shiny 
strategy", they tend to just rot...

> On 3 Oct. 2016, at 18:14, Bernhard Lindner  
> wrote:
> 
> 1. New features (quantity) are priorized over bug fixing (quality). 
> Suggestions 
> are almost sensless. I reduced writing bug reports and totally gave up 
> writing 
> suggestions due to this.
> 
> 2. Widgets have too low priority. In general new fancy features are priorized 
> above bread-and-butter features from my point of view.
> 
> 3. Components have been declared outdated while the replacements did not 
> provide the same feature set. This seriously damages Qt's reputation.
> 
>> It's not unusual for us developers and contributors to lose
>> perspective of what's important.
>> After many years spent on very particular implementation details, it
>> becomes difficult to see outside of the box.
>> 
>> And because we already know the good aspects I'm asking only about the bad.
>> No need to discuss or reach an agreement, just go ahead and enumerate
>> what you don't like.
> 
> -- 
> Regards, Bernhard
> ___
> 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] QObject::dumpObjectTree() & const

[Thiago Macieira]

On domingo, 2 de outubro de 2016 20:05:49 MDT Andy wrote:
> Why aren't QObject::dumpObjectTree() and QObject::dumpObjectInfo() const?
> Surely they shouldn't be modifying the state of the object.

Because they don't need to be. You can call any function from the debugger, 
regardless of actual constness of the object.

They were designed to be called from the debugger itself, never by your code.

> I occasionally add them to my own debug dump() methods which are const
> (ensures no modification is happening accidentally) and have to work around
> this each time.
> 
> Obviously not a huge deal, just curious if anyone knows why that decision
> was made.

-- 
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

[Interest] Qt3D not deleting buffers

[Juan José Casafranca]

Hello!

I'm posting to act some questions about Qt3D.

I'm trying to show some information for my program. This information consist 
on a regular grid (I'm painting the lines that define the voxels), a distance 
map (in each voxel vertex I store a distance value) and the sources for the 
distance (zones where distance is 0)

The software supports resizing the grid or changing the sources so the views 
must be updated accordingly. To achieve that, I emit a signal when a change in 
the distance or the grid is done and connect that signal to a slot that 
performs the scene preparation. It isn't the best solution but for now is 
enough. 

The scene preparation slots cleans the previously allocated scene 
(m_rootEntity->deleteLater()) and reconstructs the scene. 

The reconstruction generates the geometry data for the different things I want 
to view, creates the renderer and the materials and adds this components to 
different entities. Finally, this entities are added to the root entity. 

To reduce code paths, the first view also performs this steps (removes the 
previously scene, which is null) and creates the new one. This works well. 

My problem is when trying to delete an existing scene. I have been debugging 
with gDEBugger and I have seen that buffers are not deleted (I imagine that VAO 
are also kept) though the buffers are constructed with the geometry as parent, 
and the geometry es an entity children (the entity is delete when I delete 
m_rootEntity). 

After 2 or 3 remeshing steps, the screen goes black and I cant see any 
information. 

I'm using the Qt3D version shipped with Qt 5.7. 

Any idea what I'm doing wrong? I can provide some code if you ask for it, but 
as the software I'm developing is big, I prefer to show the code when you ask 
for it, so I don't fill this question with a lot of code that wouldn't be 
necessary. 

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

Re: [Interest] Qt3D not deleting buffers

[Sean Harmer]

Hi,

could you file a JIRA please ideally along with a small test case that 
reproduces the issue.

Many thanks!

Sean

On Monday 03 October 2016 13:40:36 Juan José Casafranca wrote:
> Hello!
> 
> I'm posting to act some questions about Qt3D.
> 
> I'm trying to show some information for my program. This information consist
> on a regular grid (I'm painting the lines that define the voxels), a
> distance map (in each voxel vertex I store a distance value) and the
> sources for the distance (zones where distance is 0)
> 
> The software supports resizing the grid or changing the sources so the views
> must be updated accordingly. To achieve that, I emit a signal when a change
> in the distance or the grid is done and connect that signal to a slot that
> performs the scene preparation. It isn't the best solution but for now is
> enough.
> 
> The scene preparation slots cleans the previously allocated scene
> (m_rootEntity->deleteLater()) and reconstructs the scene.
> 
> The reconstruction generates the geometry data for the different things I
> want to view, creates the renderer and the materials and adds this
> components to different entities. Finally, this entities are added to the
> root entity.
> 
> To reduce code paths, the first view also performs this steps (removes the
> previously scene, which is null) and creates the new one. This works well.
> 
> My problem is when trying to delete an existing scene. I have been debugging
> with gDEBugger and I have seen that buffers are not deleted (I imagine that
> VAO are also kept) though the buffers are constructed with the geometry as
> parent, and the geometry es an entity children (the entity is delete when I
> delete m_rootEntity).
> 
> After 2 or 3 remeshing steps, the screen goes black and I cant see any
> information.
> 
> I'm using the Qt3D version shipped with Qt 5.7.
> 
> Any idea what I'm doing wrong? I can provide some code if you ask for it,
> but as the software I'm developing is big, I prefer to show the code when
> you ask for it, so I don't fill this question with a lot of code that
> wouldn't be necessary.
> 
> Thanks!
> ___
> 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

[Interest] Qt high-DPI configuration patches for testing

[Morten Sorvig]

Hi all,

Lately I’ve spent some time on high-DPI configuration options for Qt. This is
a somewhat complex area, with many different setups in the field. I’d like to
expose the patches to a wider audience to make sure we implement something that 
works as well as possible. Please feel free to provide any feedback, either
privately or on this list.

The patches are based on Qt 5.6 and are available at: 

https://codereview.qt-project.org/157175

(Use the “checkout” option to get the entire patch series)

Documentation patch is at:

https://codereview.qt-project.org/172125

The scope of the changes is improving the Qt::HighDpiScaling mode, with a focus 
on
configuration. I’ve tested on Windows and X11, with macOS as a dev platform. 
The result
of the work is some behavior changes and several new config options.



Should I test/How to I use this?

1) Set QT_AUTO_SCREEN_SCALE_FACTOR=1 or Qt::HighDpiScaling.

2) If not happy then
   - Try setting QT_FONT_DPI and/or QT_SCALE_FACTOR to see how the application
 reacts. Is it an application or QtWidgets/QtQuick issue?  
   - Set QT_USE_PHYSICAL_DPI=1 (if you know the values are correct)
   - Set QT_SCREEN_SCALE_FACTORS=a;b;c to hardcode scale factors. (Known issue:
 QT_AUTO_SCREEN_SCALE_FACTOR needs to be set as well for this)

3) Report findings to patch author; include "tests/manual/highdpi --metrics” 
outpu
   and screenshots (if possible).

Some platform specific notes:

- X11: If you’ve had problems with mismatched text/ui sizes this should
  now be better (if not solved). Qt now uses the global logical DPI by
  default.

- Windows: Use fractional scale factors (like 150%) directly:

  QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough

  (See below for disclaimer and caveats)



Changes in detail:

- qtbase/tests/manual/highdpi --metrics prints the current configuration. 
Example:

screen name: Virtual1

widget devicePixelRatio: 1
widget logicalDpi: 96

platform screen logicalDpi: 96
platform screen logicalBaseDpi: 96
platform screen devicePixelRatio: 1
platform screen physicalDpi: 96.1115

QT_FONT_DPI:
QT_SCALE_FACTOR: 
QT_AUTO_SCREEN_SCALE_FACTOR:
QT_SCREEN_SCALE_FACTORS: 
QT_USE_PHYSICAL_DPI: 
QT_SCALE_FACTOR_ROUNDING_POLICY: 
QT_DPI_ADJUSTMENT_POLICY:
 
  Here, the “widget” section are the values the application sees, the “platform”
  section are the values returned by the OS/WS via the Qt platform plugin, and
  finally QT_ sections shows the currently set environment variables.

- The screen logical DPI is now used for configuring the devicePixelRatio value.
  This has been the case for Windows for some time; now all relevant platforms 
get
  the same behavior. Set QT_USE_PHYSICAL_DPI to use physical DPI.

- In relation ot the above Qt now uses _either_ the logical or physical DPI,
  which should reduce chance of getting inconsistent text and UI sizes.

- Qt may now optionally use non-integer factors (like 150% on windows):

QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough

  We know that this may cause painting artifacts, in particularly with native
  styles. On the other hand there are rapports that custom-styled apps work
  fine.

- 1.5x (150% on Windows) is now rounded down to 1x: The visual effect of this
  is that content appears visually small on such systems instead of visually
  large. This arguably more acceptable. The rounding policy controls this as 
well:

 QT_SCALE_FACTOR_ROUNDING_POLICY=Round|Ceil|Floor|RoundPreferFloor 
(default)


- QT_FONT_DPI now works on all platforms (mostly for testing purposes)

- QT_SCREEN_SCALE_FACTORS now correctly overrides the screen factors.

- QScreen::physicalDotsPerInch() is now a more physical value, independent of
  Qt or OS scale factors, but not independent of scaling not detectable by Qt
  such as the macOS “More Space” setting.

Thanks for reading this far :)

- Morten

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

Re: [Interest] QObject::dumpObjectTree() & const

[Giuseppe D'Angelo]

Il 03/10/2016 13:18, Thiago Macieira ha scritto:
> Because they don't need to be. You can call any function from the debugger, 
> regardless of actual constness of the object.
> 
> They were designed to be called from the debugger itself, never by your code.

Come on, that's not a justification for being sloppy in our APIs...

=> https://codereview.qt-project.org/172657

Cheers,

-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] [Qt3D] Wrong value passed to the shader when using a QMatrix value

[Xavier Bigand]

Hi,

I am trying to pass a QMatrix object to my shader, but instead of receiving
an identity matrix all field are null.

Here is my parameter declaration :

mTexCoordTransform(new
Qt3DRender::QParameter(QStringLiteral("u_texCoordTransform"),
QMatrix()))


And here my uniform declaration in the shader :

uniform highp mat3 u_texCoordTransform;



Is it a bug or is there a something wrong with my uniform declaration?


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

Re: [Interest] [Qt3D] Wrong value passed to the shader when using a QMatrix value

[Xavier Bigand]

I found the issue :
https://bugreports.qt.io/browse/QTBUG-56337

I think that is the kind of bug I can fix, I suppose that I have to follow
guidelines from http://wiki.qt.io/Portal:Contributors ?

2016-10-03 15:06 GMT+02:00 Xavier Bigand :

> Hi,
>
> I am trying to pass a QMatrix object to my shader, but instead of
> receiving an identity matrix all field are null.
>
> Here is my parameter declaration :
>
> mTexCoordTransform(new 
> Qt3DRender::QParameter(QStringLiteral("u_texCoordTransform"), QMatrix()))
>
>
> And here my uniform declaration in the shader :
>
> uniform highp mat3 u_texCoordTransform;
>
>
>
> Is it a bug or is there a something wrong with my uniform declaration?
>
>
> --
> Xavier
>



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

Re: [Interest] Qt3D not deleting buffers

[Juan Jose Casafranca]

Hi Sean,
thanks for your fast reply.

I dont know what is a JIRA. Anyway, I have prepared a very simple example
where I can reproduce one of the problems I was explaining in my previous
message.
 I go through the code:

The main creates the QApplication, a SceneManager and a timer to call
periodycally a scenemanager slot.
The SceneManager, during ctor, creates a Qt3DWindow, a root entity and
calls the changeScene slot.
The changeScene slot destroys the rootEntity (destroying that way all the
children) and recreates it. Then it create a new geometry (which basically
for this example consist on a red plane) and configures the camera.

Right now the window show a red plane... great, no problem.

When the timer timeouts and the changeScene is called again, the process is
reapeated, but now, no red plane is shown. This is exactly the same problem
I'm having in the complete code. I dont know why I'm having this behavior.
With this example, the buffers are correctly deleted, so  I imagine I have
another problem in the complete code.

Could you provide me some feedback?

Thanks!



2016-10-03 13:57 GMT+02:00 Sean Harmer :

> Hi,
>
> could you file a JIRA please ideally along with a small test case that
> reproduces the issue.
>
> Many thanks!
>
> Sean
>
> On Monday 03 October 2016 13:40:36 Juan José Casafranca wrote:
> > Hello!
> >
> > I'm posting to act some questions about Qt3D.
> >
> > I'm trying to show some information for my program. This information
> consist
> > on a regular grid (I'm painting the lines that define the voxels), a
> > distance map (in each voxel vertex I store a distance value) and the
> > sources for the distance (zones where distance is 0)
> >
> > The software supports resizing the grid or changing the sources so the
> views
> > must be updated accordingly. To achieve that, I emit a signal when a
> change
> > in the distance or the grid is done and connect that signal to a slot
> that
> > performs the scene preparation. It isn't the best solution but for now is
> > enough.
> >
> > The scene preparation slots cleans the previously allocated scene
> > (m_rootEntity->deleteLater()) and reconstructs the scene.
> >
> > The reconstruction generates the geometry data for the different things I
> > want to view, creates the renderer and the materials and adds this
> > components to different entities. Finally, this entities are added to the
> > root entity.
> >
> > To reduce code paths, the first view also performs this steps (removes
> the
> > previously scene, which is null) and creates the new one. This works
> well.
> >
> > My problem is when trying to delete an existing scene. I have been
> debugging
> > with gDEBugger and I have seen that buffers are not deleted (I imagine
> that
> > VAO are also kept) though the buffers are constructed with the geometry
> as
> > parent, and the geometry es an entity children (the entity is delete
> when I
> > delete m_rootEntity).
> >
> > After 2 or 3 remeshing steps, the screen goes black and I cant see any
> > information.
> >
> > I'm using the Qt3D version shipped with Qt 5.7.
> >
> > Any idea what I'm doing wrong? I can provide some code if you ask for it,
> > but as the software I'm developing is big, I prefer to show the code when
> > you ask for it, so I don't fill this question with a lot of code that
> > wouldn't be necessary.
> >
> > Thanks!
> > ___
> > 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
>


Qt3DBuffer.tar.gz
Description: GNU Zip compressed data
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QObject::dumpObjectTree() & const

[Thiago Macieira]

On segunda-feira, 3 de outubro de 2016 14:31:06 CEST Giuseppe D'Angelo wrote:
> Il 03/10/2016 13:18, Thiago Macieira ha scritto:
> > Because they don't need to be. You can call any function from the
> > debugger,
> > regardless of actual constness of the object.
> > 
> > They were designed to be called from the debugger itself, never by your
> > code.
> Come on, that's not a justification for being sloppy in our APIs...
> 
> => https://codereview.qt-project.org/172657

Approved.

Anyway, he asked for the reason why they are like that...

-- 
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] What don't you like about Qt?

[andy fillebrown]

I was hired on to my new job because of my Qt4 experience, and my
first QML related task was to convert a list view to a editable tree
view with drag and drop. It was not a good experience. The TreeView
control provided in Qt was full of bugs and I ended up pulling its
private C++ model adaptor into our project for bug fixes and writing a
bunch of javascript workarounds because there was no other way to get
it working satisfactorily. According to my co-workers, this is par for
the course for QML. Everything takes twice as long because things
don't work correctly out of the box. After having such a good
experience with QtGui widgets in Qt4 I was really sad to see how bad
QML is in comparison.

I like the idea of QML and I think the reasoning behind the shift away
from QtGui widgets is sound. There's just too many bugs, and design
view doesn't work for any .qml files in our project because the way
we're registering our custom controls is not supported in QtCreator
apparently.

Take a look at how Unity3D does their 2D UI elements sometime. It's
much easier to use than QML. It's not an apples to apples comparison
but it's something I feel like Qt should be shooting for when it comes
to ease of use. I learned both systems at the same time and Unity's
system took far less time and is much more stable.

Is the Qt team losing touch with the common developer? ...or is a lack
of resources maybe the root problem?  Both?  More?

I don't know. I'm just an average dev struggling with the new Qt. I do
know I wouldn't use Qt/QML for future projects in its current state
without giving Xamarin or some kind of HTML5 to app conversion a try,
first.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] I can't find QQuickStyle class

[Freddy Martinez Garcia]

Hi guys… as the doc say (http://doc.qt.io/qt-5/qtquickcontrols2-styles.html),
I can do something like this:

#include #include #include 
int main(int argc, char *argv[])
{
QGuiApplication
::setAttribute(Qt
::AA_EnableHighDpiScaling);
QGuiApplication 
app(argc, argv);

QQuickStyle ::setStyle("Material");

QQmlApplicationEngine
 engine;
engine.load(QUrl ("qrc:/main.qml"));

return app.exec();
}

The problem for me is that the include for QQuickStyle faile… file not
found… so I think that I’m missing something… What do I have to add to be
available to run this example?

Regards

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

Re: [Interest] I can't find QQuickStyle class

[J-P Nurmi]

Hi Freddy,

Add "QT += quickcontrols2" to your application's .pro file.

http://doc.qt.io/qt-5/qtquickcontrols2-index.html

--
J-P Nurmi

On 4 Oct 2016, at 06:59, Freddy Martinez Garcia 
mailto:freddy311...@gmail.com>> wrote:


Hi guys... as the doc say (http://doc.qt.io/qt-5/qtquickcontrols2-styles.html), 
I can do something like this:


#include 
#include 
#include 

int main(int argc, char *argv[])
{

QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QGuiApplication app(argc, argv);

QQuickStyle::setStyle("Material");

QQmlApplicationEngine 
engine;
engine.load(QUrl("qrc:/main.qml"));

return app.exec();
}

The problem for me is that the include for QQuickStyle faile... file not 
found... so I think that I'm missing something... What do I have to add to be 
available to run this example?

Regards

Freddy


___
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