Re: [Interest] QTimer Freeze in 4.8

[Thiago Macieira]

On quinta-feira, 23 de junho de 2016 21:53:00 PDT Simone wrote:
> Is ther a way to configure gdb to see the the qt sources when debugging?

If you built Qt in debug mode, that should already be the case.

-- 
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] QTimer Freeze in 4.8

[Simone]

Sorry, I did not pay attention to the mail recipients.
Today, after many tests I discovered that also a simple application with a 
QMainWindow only and a timer that increase a counter, is freezed after about 3 
hours.
The timer run every 250ms.
The touch screen press recover the situation, and everything resume working 
magically, it seems that the event loop is waiting for some signals, but 
unfortunately I cannot follow the sources.
Gdb is working if I put a breakpoint, i can follow my code step by step, but 
since the event dispatcher is in qt libraries, I cannot see where it stuck.

Any suggestion about some tests that I can do?
Is ther a way to configure gdb to see the the qt sources when debugging?

Thanks a lot





> Il giorno 22/giu/2016, alle ore 21:41, Thiago Macieira 
>  ha scritto:
> 
>> On quarta-feira, 22 de junho de 2016 14:49:39 PDT Cjb_SW Freescale wrote:
>> yes and no, I mean that every other process is executed proper by Linux,
>> and also a second QThread running in the GUI application is running fine.
>> Seems that only the graphic Thread is "freezed". It will resume by touching
>> the Touchscreen (which is USB, managed via Tslib).
>> 
>> Unfortunately I cannot build backtraces, I have problems with GDB. I can
>> launch the program under gdbserver, and I can set breakpoints, but if I
>> press the Interrupt button, then I can see a disassembly window, and I
>> can't see where it is the programcounter in my sources. So I tried to
>> Interrupt the application while is in the freeze state, but I can't see
>> something useful.
> 
> Please, always reply to the mailing list. If you reply to me personally, it 
> may get lost in inbox and I may never reply. And no one else would have the 
> opportunity to, either.
> 
> Anyway, since you said that other processes are running just fine and even 
> other threads in the same process, my conclusion is that something is 
> blocking 
> the GUI thread in your application. We've seen this happen in Qt 5 with XCB, 
> whenever the screensaver is on or when you swap to another virtual terminal: 
> there's a function call we make that blocks on waiting for a reply from the X 
> server, which won't come until the display is unlocked.
> 
> Clearly that's not your case, but you get the idea of what it might be.
> 
> Unfortunately, I can't help you without a backtrace (and one with debug 
> symbols, at that). I have NEVER built a QWS build of Qt and I don't even have 
> a Qt 4.8 source handy to look things up. Sorry.
> 
> My recommendations are:
> * fix GDB. It's unacceptable for it not to work.
> * consider upgrading to Qt 5.6 or 5.7 (which means dropping QWS for something 
>else)
> 
> Note that you can work around a non-working gdbserver by causing your process 
> to dump core while in the frozen state (kill -ABRT, for example), then 
> loading 
> that core file on your host machine's target gdb.
> 
> -- 
> 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] Problems with QDockWidgets in Qt5.6.1 and Qt5.7

[Chris Gripeos]

I wonder if this is related to my problem:


https://github.com/qt/qtbase/commit/f54bd20f6afbbd7bcbc55b3f3f59ed15f91f8ecd

[https://avatars3.githubusercontent.com/u/959326?v=3=200]

Revert "End the drag if the dockwidget is being hidden" · 
qt/qtbase@f54bd20
github.com
This reverts commit 75b705fec8e9517047d7dfa98203edff69f2bf8a and 
798e0064e9be78f8320ff25a9af50d1b5e5badb1. This broke drag and drop of 
QDockWidget if there is no animations (QTBUG-54185) and this...





From: Interest 
 on behalf of 
Chris Gripeos 
Sent: Thursday, June 23, 2016 7:25:12 PM
To: interest@qt-project.org
Subject: [Interest] Problems with QDockWidgets in Qt5.6.1 and Qt5.7


Hello,


I'm seeing some new and strange behaviour after upgrading our app from Qt5.6.0 
to Qt5.6.1 and even Qt5.7.0 (5.6.1 and 5.7 have the same exact behaviour).


I have a QDockWidget with:


setAllowedAreas(Qt::AllDockWidgetAreas)


And I have a QMainWindow with:


setDockOptions(QMainWindow::AllowTabbedDocks | QMainWindow::AllowNestedDocks);
setTabPosition(Qt::AllDockWidgetAreas, QTabWidget::North);


The QMainWindow is populated with a Central Widget that has a minimum width, 
but still has plenty of room to add the QDockWidget to the left or right areas.


The QDockWidget has a minimum width and height, but still has plenty of room to 
be docked in the QMainWindow.



Now, when I drag the QDockWidget in the QMainWindow, Qt highlights the areas on 
the left, top, bottom, and right as I drag the QDockWidget around. This tells 
me that if the dock areas are highlighted I should be allowed to drop the 
QDockWidget on them.


The problem is that as soon as i drop the QDockWidget in those areas, the 
Widget only gets docked on the Right Area.


No matter which area I try to drop it on, it always ends up on the Right.


In Qt5.6.0 and earlier (we were on Qt4.8 before that):

- Qt would *only* highlight areas where a Widget was allowed to be docked. 
Qt5.6.1 seems to highlight all areas, even when not allowed (no-fit).

- Docking was possible on the highlighted areas without the QDockWidget always 
getting docked on the Right.


Has anybody else experience such a problem with Qt5.6.1 or Qt5.7.0?


Does anybody know what it might be that we're doing wrong?



Thanks in advance for any help with this problem!


- Chris

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

[Interest] Problems with QDockWidgets in Qt5.6.1 and Qt5.7

[Chris Gripeos]

Hello,


I'm seeing some new and strange behaviour after upgrading our app from Qt5.6.0 
to Qt5.6.1 and even Qt5.7.0 (5.6.1 and 5.7 have the same exact behaviour).


I have a QDockWidget with:


setAllowedAreas(Qt::AllDockWidgetAreas)


And I have a QMainWindow with:


setDockOptions(QMainWindow::AllowTabbedDocks | QMainWindow::AllowNestedDocks);
setTabPosition(Qt::AllDockWidgetAreas, QTabWidget::North);


The QMainWindow is populated with a Central Widget that has a minimum width, 
but still has plenty of room to add the QDockWidget to the left or right areas.


The QDockWidget has a minimum width and height, but still has plenty of room to 
be docked in the QMainWindow.



Now, when I drag the QDockWidget in the QMainWindow, Qt highlights the areas on 
the left, top, bottom, and right as I drag the QDockWidget around. This tells 
me that if the dock areas are highlighted I should be allowed to drop the 
QDockWidget on them.


The problem is that as soon as i drop the QDockWidget in those areas, the 
Widget only gets docked on the Right Area.


No matter which area I try to drop it on, it always ends up on the Right.


In Qt5.6.0 and earlier (we were on Qt4.8 before that):

- Qt would *only* highlight areas where a Widget was allowed to be docked. 
Qt5.6.1 seems to highlight all areas, even when not allowed (no-fit).

- Docking was possible on the highlighted areas without the QDockWidget always 
getting docked on the Right.


Has anybody else experience such a problem with Qt5.6.1 or Qt5.7.0?


Does anybody know what it might be that we're doing wrong?



Thanks in advance for any help with this problem!


- Chris

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

Re: [Interest] universal builds on OS X

[Jean-Michaël Celerier]

Some people are working on a toolchain for cross-compiling OS X software;
maybe
it could be extended to iOS? It "only" requires the SDK that you can borrow
from a
friend's mac (or even by downloading xcode yourself).

Here's a link :
https://github.com/tpoechtrager/osxcross

But I guess the hardest part would be all the signing that Xcode does to
allow
you to run some code you wrote on your 800$ iphone...

Best,
Jean-Michaël Celerier

On Wed, Jun 22, 2016 at 10:16 PM, Thiago Macieira  wrote:

> On quarta-feira, 22 de junho de 2016 09:45:17 PDT Kevin Mcintyre wrote:
> > Is it possible to build for IPhone from Ubuntu?  Any tutorials of starter
> > docs would be greatly appreciated.
>
> The tricky part is installing the toolchain. As far as I know, Apple only
> provides it for OS X/macOS.
>
> So if you don't own a Mac, you can't develop for iPhone.
>
> I seriously don't get how people put up with that... but Apple gets away
> with
> it.
>
> --
> 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 mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Custom QSGGeometryNode Scene blending issue

[Roberto Garrido]

Gunnar,
thanks for your detailed response.
We don't discard going for the QQuickFramebufferObject soon, but currently
what we have is the Item/QSGGeometryNode setup.
I've been doing some tests, and I cannot manage to get the desired effect.
The most silly example I can think of is to clear our buffer with a fully
transparent color (as you suggested), then render a fullscreen quad with
also a fully transparent color (using premultiplied alpha -> 1, 1 -
SRC_ALPHA). That should give us fully transparent item, and the qml scene
behind should be shown. But what we see is the desktop itself, not the QML
items behind. Does it give you any clue on what could I be doing wrong?

Our node (derived from QSGGeometryNode) takes a QSGTextureMaterial (with
the default shader for this type of material), and we have also activated
the QSGMaterial::Blending flag.

Thanks,
Robert.

On 7 June 2016 at 09:41, Gunnar Sletta  wrote:

> Hi Roberto,
>
> The opacity of any geometry node is decided by the opacity that comes out
> of the fragment shader of its material. Depending on how the alpha logic
> exists in your custom GL renderer, there are two ways to do this.
>
> Option 1: If most of the FBO is partially transparent, or if there are
> bits and pieces that are overlaid on top of the rest of the UI, like
> controls on a HUD, then you want to render into an FBO with an alpha
> buffer, clear it with fully transparent, draw your custom GL stuff and then
> alpha blend the entire FBO on top of the QML scene. You do alpha blending
> of the fbo content by setting the QSGMaterial::Blending flag and returning
> a premultiplied alpha color from the fragment shader. The
> QSGTextureMaterial has a fragment shader that does the right thing.
>
> Option 2: If you have an opaque FBO with certain sections, say a given
> rectangle, fully transparent, you can draw the FBO as fully opaque, but
> create a geometry that excludes the fully transparent region. This has the
> benefit you will be drawing more opaque stuff which is generally faster for
> the GPU to handle, compared to blended stuff.
>
> It is of course possible to do a mixture of 1 and 2, by creating two
> separate materials, both referring to the FBO. For the fully opaque
> sections of the FBO, you use an opaque material to draw it which is fast.
> For the semi-transparent sections of the FBO you use a different geometry
> node with a material that enables blending. The fully transparent regions
> are fully excluded from either geometry, so those cost nothing. (something
> like the MaskedImage I have here:
> https://github.com/qtproject/playground-scenegraph/tree/master/shapes)
>
> Btw, if you used QQuickFramebufferObject instead of rolling your own
> custom Item/node/material, you would get option 1 by default :)
>
> cheers,
> Gunnar
>
> > On 06 Jun 2016, at 18:05, Roberto Garrido <
> robertogarridomar...@gmail.com> wrote:
> >
> > Hi all!
> > We have a custom QQuickItem which in turn creates a custom
> QSGGeometryNode. We reimplement the QSGGeometryNode's preprocess() method
> in order to draw our scene to a FrameBufferObject with a texture attached.
> This OpenGL texture ID is shared with the QSGGeometryNode's material. This
> way, we can render our custom OpenGL scene into a QML item. So far, so good.
> >
> > However, we want to use alpha blending on some parts of our scene, in
> order to let the user see the QML items behind our custom item. Something
> similar to what Item::opacity value is doing, but only for a specific area
> of our Item. It's like having a hole inside our Item that allows the user
> to see what's behind. The information about the specific region that should
> be transparent is handled inside our custom OpenGL renderer.
> >
> > I've been trying to find out what Qt is doing in order to change the
> opacity of a QML item, with no luck.
> >
> > Any idea on how can we achieve this effect, with our Item/Node
> configuration?
> > Thanks in advance,
> > Robert.
> >
> > --
> > Website: http://robertogarrido.com
> > Twitter: http://twitter.com/che1404
> > LinkedIn: http://es.linkedin.com/in/robertogarrido/en
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
>


-- 
Website: http://robertogarrido.com
Twitter: http://twitter.com/che1404
LinkedIn: http://es.linkedin.com/in/robertogarrido/en
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QMAKE_DEFAULT_INCDIRS = "/opt/local/include /usr/include" and building QtWebengine

[Thiago Macieira]

On quinta-feira, 23 de junho de 2016 16:14:46 PDT René J.V. Bertin wrote:
> Hi,
> 
> I have been running into issues building QtWebEngine on Linux, for
> installation into /opt/local. Almost at the end of the L O O N G build
> process I get a failure from moc that claims about receiving multiple
> files.
> 
> It took me a while to figure out why the system tried to execute commands
> like
> 
> /opt/local/libexec/qt5/bin/moc $(DEFINES)
> -I/opt/local/share/qt5/mkspecs/linux-g++-64  SNIP */-I'/opt/local/include
> /usr/include'/*
> /.../qtwebengine/src/webenginewidgets/ui/messagebubblewidget_p.h -o
> .moc/moc_messagebubblewidget_p.cpp
> 
> and my core_generated.gyp had lines like
> 
>   '-I.',
>   '-I/opt/local/include',
> */  '/usr/include',/*
>   'location_provider_qt.cpp',
>   '-o',
>   '<(SHARED_INTERMEDIATE_DIR)/moc/location_provider_qt.moc',
> 
> but I think I finally traced it to a line in qconfig.pri :
> 
> QMAKE_DEFAULT_INCDIRS = "/opt/local/include /usr/include"
> 
> I have a very comparible build on OS X which has comparible settings for
> that variable except *without the quotes*.
> 
> On both hosts that variable is set when !host_build so I'm not it's the
> actual culprit. If not, how do I figure out what's going on here? If it is,
> any ideas how the quotes got in there?

First of all, since this functionality changed very recently, what released 
version or Git commit are you at?

-- 
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] QMAKE_DEFAULT_INCDIRS = "/opt/local/include /usr/include" and building QtWebengine

[René J . V . Bertin]

Hi,

I have been running into issues building QtWebEngine on Linux, for installation 
into /opt/local. Almost at the end of the L O O N G build process I get a 
failure from moc that claims about receiving multiple files.

It took me a while to figure out why the system tried to execute commands like

/opt/local/libexec/qt5/bin/moc $(DEFINES) 
-I/opt/local/share/qt5/mkspecs/linux-g++-64  SNIP */-I'/opt/local/include 
/usr/include'/* 
/.../qtwebengine/src/webenginewidgets/ui/messagebubblewidget_p.h -o 
.moc/moc_messagebubblewidget_p.cpp

and my core_generated.gyp had lines like

  '-I.',
  '-I/opt/local/include',
*/  '/usr/include',/*
  'location_provider_qt.cpp',
  '-o',
  '<(SHARED_INTERMEDIATE_DIR)/moc/location_provider_qt.moc',

but I think I finally traced it to a line in qconfig.pri :

QMAKE_DEFAULT_INCDIRS = "/opt/local/include /usr/include"

I have a very comparible build on OS X which has comparible settings for that 
variable except *without the quotes*.

On both hosts that variable is set when !host_build so I'm not it's the actual 
culprit. If not, how do I figure out what's going on here? If it is, any ideas 
how the quotes got in there?

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

[Interest] Enable sample buffers / samples on QGLWidget from Python

[Elvis Stansvik]

Hi all,

Sorry if this is slightly off-topic.

I'm working with a QGLWidget-based widget. I know it's deprecated, but
I'm tied to it for the moment since I'm working with VTK (something
QOpenGLWidget-based will come eventually..).

I have a need to enable sample buffers and set the number of samples,
to enable anti-aliasing.

I thought I could do (self is the QGLWidget):

glFormat = self.format()
glFormat.setSampleBuffers(True)
glFormat.setSamples(8)
self.setFormat(glFormat)

But realize now that setFormat has been made obsolete in Qt 5, and
PyQt as a policy does not wrap obsolete stuff.

Am I screwed or is there some other way to do this?

Thanks for any help,
Elvis
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Qt3D] Custom texture loader and material shaders

[Xavier Bigand]

Ok I was able to reproduce the leak with material-cpp sample
https://bugreports.qt.io/browse/QTBUG-54311

2016-06-21 12:08 GMT+02:00 Sean Harmer :

> On Tuesday 21 June 2016 00:11:23 Xavier Bigand wrote:
> > I am trying to check the material sample, but when launching the program
> > with gDebugger it can't be initialized with opengl render, always DX or
> the
> > software emulation (when I am trying to force the application attributs).
> >
> > Is there CMAKE files to build samples with Visual Studio?
>
> You can generate MSVC project files using qmake -tp vc myexample.pro.
> We've
> used this to then profile in Visual Studio with the nVidia nSight plugin.
>
> Cheers,
>
> Sean
>
> >
> > 2016-06-20 22:55 GMT+02:00 Sean Harmer :
> > > The textures should be cached in a similar way to the shaders. If they
> are
> > > not in your case, it's a bug. Please file a test case.
> > >
> > > Cheers,
> > >
> > > Sean
> > >
> > > On 20/06/2016 16:37, Xavier Bigand wrote:
> > >
> > > I just put a QHash table to return the previous
> > > generated Qt3DRender::QTextureImageDataPtr, but it doesn't work.
> > >
> > > Need I fill a bug for this?
> > >
> > > 2016-06-20 17:15 GMT+02:00 Xavier Bigand :
> > >> I took a look with nsight and it appears that my textures are
> currently
> > >> loaded many times, certainly one for each object instance.
> > >>
> > >> Need I manage textures resources my self?
> > >>
> > >>
> > >>
> > >> 2016-06-02 20:39 GMT+02:00 Xavier Bigand <  >
> > >>
> > >> flamaros.xav...@gmail.com>:
> > >>> I forgot to precise that mipmaps are already generated in our file
> > >>> format and texture compressed (PVRTC, DXTC,...)
> > >>>
> > >>> 2016-06-02 18:41 GMT+02:00 Xavier Bigand < <
> flamaros.xav...@gmail.com>
> > >>>
> > >>> flamaros.xav...@gmail.com>:
> >  Hi,
> > 
> >  I finally come back into Qt3D tests.
> > 
> >  For the texture loader, I made my own QAbstractTextureImage
> >  and QTextureDataFunctor, I do the loading of our files in the
> override
> >  of QTexImageDataPtr operator ()().
> >  But I don't understand how to give to Qt3D texture's format,
> >  mipmaps,... because I can set only buffer, pixelType and pixelFormat
> >  on QTexImageData class.
> > 
> > 
> >  Need I also implement my own QAbstractTextureProvider functor to
> >  provide other properties?
> > 
> > 
> >  2016-03-28 10:45 GMT+02:00 Sean Harmer < 
> > 
> >  s...@theharmers.co.uk>:
> > > Hi,
> > >
> > > sorry, forgot to reply to the texture part.
> > >
> > > On 27/03/2016 23:53, Xavier Bigand wrote:
> > >
> > > Hi,
> > >
> > > Is there a way to add a loader for our custom texture format?
> > >
> > >
> > > I think you can use the functor approach exposed by
> > > QAbstractTextureProvider or QAbstractTextureImage.
> > >
> > > Cheers,
> > >
> > > Sean
> > >
> > >
> > > We also have to use our existing shaders for materials, but I don't
> > > know how to manage uniforms. We are generating our shaders based on
> > > macros
> > > depending of the number and types of light sources,..., is it
> possible
> > > to
> > > keep that?
> > >
> > > --
> > > Xavier
> > >
> > >
> > > ___
> > > Interest mailing
> > > listInterest@qt-project.orghttp://
> lists.qt-project.org/mailman/listin
> > > fo/interest
> > >
> > >
> > >
> > > ___
> > > Interest mailing list
> > > Interest@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/interest
> > 
> >  --
> >  Xavier
> > >>>
> > >>> --
> > >>> Xavier
> > >>
> > >> --
> > >> Xavier
> > >
> > > --
> > > Xavier
> > >
> > >
> > >
> > > --
> > > 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
>
> --
> 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
>



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

Re: [Interest] 5.8 Features?

[ekke]

Hi Maurice,
I'll go on and will try to find solutions and to write blogs / sample
apps / bugreports ...
and discuss here

having time is also an issue for me - working as an independent developer

hopefully others will also make their solutions public.

coming from BlackBerry Cascades it's not always easy to figure out how
it works in Android via JNI and iOS / ObjectiveC
I'm using Qt to avoid this ;-)

so for the moment I think it will consume much time to make apps running
for my customers - don't know when I'll reach a point to make contributions

ekke

Am 23.06.16 um 09:52 schrieb Maurice Kalinowski:
>
> Hi Ekke,
>
>  
>
> Thx for all the effort you put into the mobile platforms for Qt,
> evangelizing as well as sharing your knowledge on it.
>
>  
>
> Even when the items mentioned are not on the immediate roadmap as
> such, why not take the next step and consider creating a crossplatform
> API on your own, developed on the playground? Based on your knowledge
> of using those features, you seem like a natural candidate for this.
>
>  
>
> This might be a good place to start, you can ask the community and
> contributors to check for API consistency and if there are others
> needing those features as well, there is a likelihood that you will
> get feedback on those, maybe even contributions?
>
>  
>
> Having time is always an issue, so it is for the others. So, be
> proactive and start the initiative. There is no need to be done with
> it for FF of 5.8. If you are afraid of not being able to maintain this
> in the future, somebody else might take over but needs a head-start.
> After all, this would be on the playground.
>
>  
>
> Maurice
>
>  
>
>  
>
> *From:*ekke [mailto:e...@ekkes-corner.org]
> *Sent:* Thursday, June 23, 2016 7:15 AM
> *To:* Maurice Kalinowski ; Matthias
> Degenkolb ; interest@qt-project.org
> *Subject:* Re: [Interest] 5.8 Features?
>
>  
>
> thx Maurice,
>
> Am 22.06.16 um 12:22 schrieb Maurice Kalinowski:
>
> > Highest prio from my personal perspective:
>
> > >> - Background processing API
>
> > >> - In-app Notifications: local, remote
>
> > + add Windows Store to Qt Purchasing module
>
> there's more missing:
> - avoid flicker for android apps out-of-the-box
> - easy way to 'share' content with/from other apps (Intents, Deep
> Linking) Android, iOS
> such common use-cases should be abstracted and available via Qt API
>
> coming from BlackBerry 10 Cascades/QML APP Development I'm astonished
> how many common mobile tasks are missing
>
> I want to motivate my enterprise customers to use Qt for mobile
> x-platform development
> they're comparing with Xamarin, Ionic, Angular ...
>
> I still believe Qt is the best solution for mobile x platform and hope
> there will be really progress on this
> esp. after providing QtQuickControls2 Material style for great looking
> apps
>
> ekke
>
>  
>
> https://codereview.qt-project.org/#/c/149602/
>
> https://codereview.qt-project.org/#/c/162992/
>
>  
>
> ;)
>
>  
>
> Maurice
>
>  
>
>  
>
> *From:*Interest
> [mailto:interest-bounces+maurice.kalinowski=qt...@qt-project.org]
> *On Behalf Of *Matthias Degenkolb via Interest
> *Sent:* Wednesday, June 22, 2016 11:25 AM
> *To:* ekke  
> *Cc:* interest@qt-project.org 
> *Subject:* Re: [Interest] 5.8 Features?
>
>  
>
> I fully agree to ekke's and Jason's wishes. The features mentioned
> are all topics I also miss urgently since our first app
> development tests with Qt ..
>
> Not having cross-platform access to those "standard" mechanisms
> for mobile OS really makes me wonder whether my next projects will
> be based on Qt ...
>
>  
>
> Highest prio from my personal perspective:
>
> >> - Background processing API
> >> - In-app Notifications: local, remote
>
> + add Windows Store to Qt Purchasing module
>
>  
>
>  
>
> 2016-06-22 10:45 GMT+02:00 ekke  >:
>
> Am 22.06.16 um 10:36 schrieb Bo Thorsen:
>
> > Den 21-06-2016 kl. 22:55 skrev Jason H:
> >> I feel like the last few releases have been run by the
> trolls, and
> >> not the users of Qt. I was hoping open governance would
> enable the
> >> community to direct Qt development, but I seem to have
> misinterpreted
> >> what it means. I'm looking for what's going into 5.8.. not much
> >> listed on the releases page.
> >>
> >> I'd like to suggest that mobile get some much needed love.
> >> - Application state transitions; Foreground, background
> >> - Background processing API
> >> - Screen wake lock API
> >> - In-app Notifications: local, remote
> >>
> >> While I have those 

Re: [Interest] Qt 5.7 android C++ smooth scrolling

[Harish Surana]

If you don't want to use qml look at old examples
https://blog.qt.io/blog/2009/07/19/kinetic-scrolling-on-any-widgets/

On Thu, Jun 23, 2016 at 9:38 AM, Oleg Shalnev 
wrote:

> Good day.
>
> My pain is in scrolling.
>
> I hope that standard situation with creation QScrollArea, and placing
> viewport widget there, creating layout in viewport and placing custom
> widgets in this layout will work good on android.
>
> The result of this experiment is so sad.
> Yes it's working, but scrolling quality is ugly.
> Tuning by QScrollerProperties was not so fruitful.
>
> Google shows few recommendations. About QListView and using qml.
>
> Scrolling is one of the most useful gui features in mobile developing.
> May be there is the way to make scrolling more useful in c++ world?
>
> Please help!
>
> I can't beleive that everybody in the world creates there applications for
> androind only using qml.
> Thank's a lot!
>
> --
> Oleg Shalnev  (Kalpa Knowledge Integration Initiative)
> --
> mailto: o...@kalpa.ru
> skype:  oleg_shalnev
> cell:  +79111603306
> cell:  +79187417217
>
>
> ___
> 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] 5.8 Features?

[Maurice Kalinowski]

Hi Ekke,

Thx for all the effort you put into the mobile platforms for Qt, evangelizing 
as well as sharing your knowledge on it.

Even when the items mentioned are not on the immediate roadmap as such, why not 
take the next step and consider creating a crossplatform API on your own, 
developed on the playground? Based on your knowledge of using those features, 
you seem like a natural candidate for this.

This might be a good place to start, you can ask the community and contributors 
to check for API consistency and if there are others needing those features as 
well, there is a likelihood that you will get feedback on those, maybe even 
contributions?

Having time is always an issue, so it is for the others. So, be proactive and 
start the initiative. There is no need to be done with it for FF of 5.8. If you 
are afraid of not being able to maintain this in the future, somebody else 
might take over but needs a head-start. After all, this would be on the 
playground.

Maurice


From: ekke [mailto:e...@ekkes-corner.org]
Sent: Thursday, June 23, 2016 7:15 AM
To: Maurice Kalinowski ; Matthias Degenkolb 
; interest@qt-project.org
Subject: Re: [Interest] 5.8 Features?

thx Maurice,

Am 22.06.16 um 12:22 schrieb Maurice Kalinowski:
> Highest prio from my personal perspective:
> >> - Background processing API
> >> - In-app Notifications: local, remote
> + add Windows Store to Qt Purchasing module
there's more missing:
- avoid flicker for android apps out-of-the-box
- easy way to 'share' content with/from other apps (Intents, Deep Linking) 
Android, iOS
such common use-cases should be abstracted and available via Qt API

coming from BlackBerry 10 Cascades/QML APP Development I'm astonished how many 
common mobile tasks are missing

I want to motivate my enterprise customers to use Qt for mobile x-platform 
development
they're comparing with Xamarin, Ionic, Angular ...

I still believe Qt is the best solution for mobile x platform and hope there 
will be really progress on this
esp. after providing QtQuickControls2 Material style for great looking apps

ekke


https://codereview.qt-project.org/#/c/149602/
https://codereview.qt-project.org/#/c/162992/

;)

Maurice


From: Interest 
[mailto:interest-bounces+maurice.kalinowski=qt...@qt-project.org] On Behalf Of 
Matthias Degenkolb via Interest
Sent: Wednesday, June 22, 2016 11:25 AM
To: ekke 
Cc: interest@qt-project.org
Subject: Re: [Interest] 5.8 Features?

I fully agree to ekke's and Jason's wishes. The features mentioned are all 
topics I also miss urgently since our first app development tests with Qt ..
Not having cross-platform access to those "standard" mechanisms for mobile OS 
really makes me wonder whether my next projects will be based on Qt ...

Highest prio from my personal perspective:
>> - Background processing API
>> - In-app Notifications: local, remote
+ add Windows Store to Qt Purchasing module


2016-06-22 10:45 GMT+02:00 ekke 
>:
Am 22.06.16 um 10:36 schrieb Bo Thorsen:
> Den 21-06-2016 kl. 22:55 skrev Jason H:
>> I feel like the last few releases have been run by the trolls, and
>> not the users of Qt. I was hoping open governance would enable the
>> community to direct Qt development, but I seem to have misinterpreted
>> what it means. I'm looking for what's going into 5.8.. not much
>> listed on the releases page.
>>
>> I'd like to suggest that mobile get some much needed love.
>> - Application state transitions; Foreground, background
>> - Background processing API
>> - Screen wake lock API
>> - In-app Notifications: local, remote
>>
>> While I have those characterized as "mobile" there are things like
>> notifications occurring on desktop platforms.
>>
>> Any thoughts?
>
> There's only one reason why you don't see more features for the mobile
> parts: There are not enough developers on it. And that's not because
> QtCompany is doing anything wrong, they just have their priorities
> different from what you have.
>
> Personally I don't care about mobile at all. I haven't had a mobile
> customer since 2011 and I don't see that changing. My focus is almost
> entirely on Linux embedded and Windows desktop. Those are the areas
> where a lot of applications are written.
>
> I'd love to see the mobile platforms thrive. But unless you Qt users
> start becoming Qt developers and contribute to it, I don't see that
> happening.
hmmm
the only reason for me to use Qt is mobile
using new Qt Quick Controls 2 Qt is a great platform for mobile app
development and I hope many new developers will start with Qt on mobile
to make this easier I'm writing example apps and a blog series
http://j.mp/qt-x

I really hope that there will be development on the topics Jason H
mentioned above

ekke

>
> Bo Thorsen,
> Director, Viking Software.
>

Re: [Interest] Qt 5.7 android C++ smooth scrolling

[ekke]

Please try out new QtQuickControls2 with material Style for Android.
Should work much better
to try out some apps - I did some example apps:
http://bit.ly/qtquick2-demo-apps
ekke

Am 23.06.16 um 09:38 schrieb Oleg Shalnev:
> Good day.
>
> My pain is in scrolling.
>
> I hope that standard situation with creation QScrollArea, and placing
> viewport widget there, creating layout in viewport and placing custom
> widgets in this layout will work good on android.
>
> The result of this experiment is so sad.
> Yes it's working, but scrolling quality is ugly.
> Tuning by QScrollerProperties was not so fruitful.
>
> Google shows few recommendations. About QListView and using qml.
>
> Scrolling is one of the most useful gui features in mobile developing. 
> May be there is the way to make scrolling more useful in c++ world?
>
> Please help!
>
> I can't beleive that everybody in the world creates there applications
> for androind only using qml.
> Thank's a lot!
>
> -- 
> Oleg Shalnev  (Kalpa Knowledge Integration Initiative)
> --
> mailto: o...@kalpa.ru 
> skype:  oleg_shalnev
> cell:  +79111603306
> cell:  +79187417217
>
>
>
> ___
> 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] Interest Digest, Vol 57, Issue 27

[Jakub Michałowski]

Szanowni Państwo,

Dziękuję za przesłanie wiadomości.

W dniach od 19 do 24 czerwca 2016 roku jestem poza biurem w związku z 
międzynarodowymi targami Firex w Londynie.

W sprawach szkoleń proszę o kontakt z panem Krzysztofem Nowakowskim pod numerem 
52 36 39 265 lub z działem wsparcia technicznego pod numerem 52 36 39 261.

Realizacją zapytań ofertowych zajmuje się nasz dystrybutor AAT Holding S.A. 
Listę oddziałów dystrybutora można uzyskać na stronie www.aat.pl.

W sprawach nieprawidłowości i usterek proszę o kontakt z działem serwisu pod 
numerem 52 36 39 375.

W sprawach pomocy technicznej na temat obecnych w ofercie urządzeń proszę o 
kontakt z naszym działem wsparcia technicznego pod numerem telefonu: 52 36 39 
261 lub adresem e-mail: polona...@polon-alfa.pl

Serdecznie pozdrawiam

Jakub Michałowski
Młodszy Konstruktor

Polon-Alfa Spółka z ograniczoną odpowiedzialnością Sp. k.
85-861 Bydgoszcz, ul. Glinki 155
Tel.  +48 52 36 39 265
Fax  +48 52 36 39 264
Kom.  +48 601 380 401
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 5.8 Features?

[ekke]

Am 23.06.16 um 08:57 schrieb Shawn Rutledge:
>> On 23 Jun 2016, at 07:15, ekke  wrote:
>>
>> thx Maurice,
>>
>> Am 22.06.16 um 12:22 schrieb Maurice Kalinowski:
 Highest prio from my personal perspective:
>> - Background processing API
>> - In-app Notifications: local, remote
 + add Windows Store to Qt Purchasing module
>> there's more missing:
>> - avoid flicker for android apps out-of-the-box
> What does that mean, just the initial appearance at startup? 
yep. would be great to start Android Apps without flicker by default.
Now I must follow instructions like this:
https://medium.com/@benlaud/complete-guide-to-make-a-splash-screen-for-your-qml-android-application-567ca3bc70af#.demzldbe9

>  My pet peeve is that startup of Qt Android apps takes too long, compared to 
> Java apps.  Ironically it's Java apps that are too slow on desktop platforms. 
>  So I just wish I had a modern Qt-based phone, so that there’s one copy of 
> the libs in memory already.  Apps would be small and fast.
yep :) How fast this can be I know from BlackBerry10 Cascades/Qt/QML
apps. But I have to look forward and provide x-platform apps for
Android/iOS (perhaps W10 later)
>
>> - easy way to 'share' content with/from other apps (Intents, Deep Linking) 
>> Android, iOS
>> such common use-cases should be abstracted and available via Qt API
> Yes but it should be good, portable, future-proof API, to be worthwhile.  
> Ideally even portable between desktops and mobiles.  It’s hard to predict the 
> future, too.  There is a disconnect that on desktop platforms you share by 
> saving files in one application and re-opening in another, or via the 
> clipboard, or drag-and-drop, whereas on mobile platforms this stuff got 
> re-invented.  I’m not sure if it’s an improvement: applications seem mostly 
> isolated now, effectively.  Not that I’ve tried very hard to use a tablet for 
> office-y stuff, but I’m not sure if everything that was possible on the 
> desktop is possible on those platforms.  If you extend the platform to 
> include cloud services (since not all data is even stored locally, I guess 
> it’s supposed to mean that inter-app sharing must include sharing of access 
> to data which is stored only on the cloud), do you trust them: are they 
> secure? are they going to still be there in a few years?  will they continue 
> to have a gazillion non-interoperable ways to do similar stuff?  How much 
> abstraction can we do, to make sharing locally or via the cloud look similar? 
>  Would you dare to start a university degree program for example, and do all 
> your work only on a tablet?  If you do that, can you still open anything that 
> you did in a decade or two?  If the inter-app sharing mechanisms are 
> hindering people from getting work done, maybe they will be re-invented 
> again?  So it seems hard to create APIs now that won’t look foolish in 
> retrospect later on.
>
> The file abstraction is nice because of being so universal.  Even cloud 
> storage (with offline caching) can be done by making it a virtual filesystem. 
>  Yet the file abstraction does seem long in the tooth, because we no longer 
> rely on hard disks as much, and installing flash memory as a “disk” instead 
> of “memory” is so arbitrary - it will end some day, especially if most memory 
> ends up being non-volatile eventually.  But what is the long-term-stable 
> replacement for the hierarchical filesystem?  Will we keep using it just 
> because it’s such a human-friendly metaphor?  Or will sharing between all 
> apps end up looking more like today’s mobile APIs, where you first have to 
> open one app, and select the data, and “send” it to another; or, one app 
> invokes another to “pull” something?  I guess the reason is that active 
> transfer between apps which are both running at the same time is deemed more 
> secure than passive file-reading.  Or is there another reason?  But the 
> protocols for that data transfer seem like shifting sand to me.
from my enterprise customers requirements for x-platform android/ios:
* support for incoming intents: employee opens a file (pdf, image, ...)
and can open this one with Qt App to upload to server or so
* support for outgoing intents: employee downloads file from server,
then wants to open this one in Acrobat to read pdf, etc
there are more use-cases for open-in-map (Google, here), open Phone-Call
from phone-number, ...
For my customers security is no question because app is running on BES12
server and AndroidForWork / SamsungKNOX on Android and
secure-VPN-connection on iOS 9.x - so the app has only restricted access
inside work data

>  
> https://bugreports.qt.io/browse/QTBUG-36015 has links to some lower-level 
> tasks like support for intents, anyway.
>
thx mentioning this. will read through and add comments / bugreports.

-- 

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
BlackBerry 10 | Qt Mobile 

[Interest] Qt 5.7 android C++ smooth scrolling

[Oleg Shalnev]

Good day.

My pain is in scrolling.

I hope that standard situation with creation QScrollArea, and placing
viewport widget there, creating layout in viewport and placing custom
widgets in this layout will work good on android.

The result of this experiment is so sad.
Yes it's working, but scrolling quality is ugly.
Tuning by QScrollerProperties was not so fruitful.

Google shows few recommendations. About QListView and using qml.

Scrolling is one of the most useful gui features in mobile developing.
May be there is the way to make scrolling more useful in c++ world?

Please help!

I can't beleive that everybody in the world creates there applications for
androind only using qml.
Thank's a lot!

-- 
Oleg Shalnev  (Kalpa Knowledge Integration Initiative)
--
mailto: o...@kalpa.ru
skype:  oleg_shalnev
cell:  +79111603306
cell:  +79187417217
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Raster Engine Issues

[Alper Sağlam]

Hi Harri,

Thanks for your great recommendation, running application in valgrind is
not possible in my case, since the application run in an embedded
varlgrind-uninstallable system. Can you recommend any other thing?



On Thu, Jun 23, 2016 at 10:08 AM Harri Porten  wrote:

> Hello Alper,
>
> On Thu, 23 Jun 2016, Alper Sağlam wrote:
>
> > The issue is not-reproducible so running with the valgrind is not a way
> > to go. Any new comment on raster engine bugs will make me happier.
>
> As I tried to suggest below: Valgrind may find issues even in the absence
> of crash.
>
> Harri.
>
>
> >
> > Thanks in advance.
> >
> > On Fri, Jun 10, 2016 at 11:08 AM Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
> >   Also, -fsanitize=address ; -fsanitize=undefined.
> >
> >
> >
> >
> > On Fri, Jun 10, 2016 at 9:27 AM, Harri Porten 
> wrote:
> >   On Thu, 9 Jun 2016, Alper Sağlam wrote:
> >
> > I am deailing with qt backtrace from a core file, it looks
> like it is not reproducible (sporadic) and happened three times in our
> environments. My findings
> > shows that some issues occurred in qt raster engine and qt
> text engine. I am pasting the bt to here and I just want to know that is
> there any known issues
> > (bugs or misuses) of raster engine, text engines and fonts.
> >
> >
> >   I suggest to run the application via Valgrind. It may report the
> root cause of the problem even for cases where the result is not crash.
> >
> >   Harri.
> >   ___
> >   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 mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Raster Engine Issues

[Harri Porten]

Hello Alper,

On Thu, 23 Jun 2016, Alper Sağlam wrote:

The issue is not-reproducible so running with the valgrind is not a way 
to go. Any new comment on raster engine bugs will make me happier. 


As I tried to suggest below: Valgrind may find issues even in the absence 
of crash.


Harri.




Thanks in advance. 

On Fri, Jun 10, 2016 at 11:08 AM Jean-Michaël Celerier 
 wrote:
  Also, -fsanitize=address ; -fsanitize=undefined.




On Fri, Jun 10, 2016 at 9:27 AM, Harri Porten  wrote:
  On Thu, 9 Jun 2016, Alper Sağlam wrote:

I am deailing with qt backtrace from a core file, it looks like it 
is not reproducible (sporadic) and happened three times in our environments. My 
findings
shows that some issues occurred in qt raster engine and qt text 
engine. I am pasting the bt to here and I just want to know that is there any 
known issues
(bugs or misuses) of raster engine, text engines and fonts.


  I suggest to run the application via Valgrind. It may report the root 
cause of the problem even for cases where the result is not crash.

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

Re: [Interest] 5.8 Features?

[Shawn Rutledge]

> On 23 Jun 2016, at 07:15, ekke  wrote:
> 
> thx Maurice,
> 
> Am 22.06.16 um 12:22 schrieb Maurice Kalinowski:
>> > Highest prio from my personal perspective:
>> > >> - Background processing API
>> > >> - In-app Notifications: local, remote
>> > + add Windows Store to Qt Purchasing module
> there's more missing:
> - avoid flicker for android apps out-of-the-box

What does that mean, just the initial appearance at startup?  My pet peeve is 
that startup of Qt Android apps takes too long, compared to Java apps.  
Ironically it's Java apps that are too slow on desktop platforms.  So I just 
wish I had a modern Qt-based phone, so that there’s one copy of the libs in 
memory already.  Apps would be small and fast.

> - easy way to 'share' content with/from other apps (Intents, Deep Linking) 
> Android, iOS
> such common use-cases should be abstracted and available via Qt API

Yes but it should be good, portable, future-proof API, to be worthwhile.  
Ideally even portable between desktops and mobiles.  It’s hard to predict the 
future, too.  There is a disconnect that on desktop platforms you share by 
saving files in one application and re-opening in another, or via the 
clipboard, or drag-and-drop, whereas on mobile platforms this stuff got 
re-invented.  I’m not sure if it’s an improvement: applications seem mostly 
isolated now, effectively.  Not that I’ve tried very hard to use a tablet for 
office-y stuff, but I’m not sure if everything that was possible on the desktop 
is possible on those platforms.  If you extend the platform to include cloud 
services (since not all data is even stored locally, I guess it’s supposed to 
mean that inter-app sharing must include sharing of access to data which is 
stored only on the cloud), do you trust them: are they secure? are they going 
to still be there in a few years?  will they continue to have a gazillion 
non-interoperable ways to do similar stuff?  How much abstraction can we do, to 
make sharing locally or via the cloud look similar?  Would you dare to start a 
university degree program for example, and do all your work only on a tablet?  
If you do that, can you still open anything that you did in a decade or two?  
If the inter-app sharing mechanisms are hindering people from getting work 
done, maybe they will be re-invented again?  So it seems hard to create APIs 
now that won’t look foolish in retrospect later on.

The file abstraction is nice because of being so universal.  Even cloud storage 
(with offline caching) can be done by making it a virtual filesystem.  Yet the 
file abstraction does seem long in the tooth, because we no longer rely on hard 
disks as much, and installing flash memory as a “disk” instead of “memory” is 
so arbitrary - it will end some day, especially if most memory ends up being 
non-volatile eventually.  But what is the long-term-stable replacement for the 
hierarchical filesystem?  Will we keep using it just because it’s such a 
human-friendly metaphor?  Or will sharing between all apps end up looking more 
like today’s mobile APIs, where you first have to open one app, and select the 
data, and “send” it to another; or, one app invokes another to “pull” 
something?  I guess the reason is that active transfer between apps which are 
both running at the same time is deemed more secure than passive file-reading.  
Or is there another reason?  But the protocols for that data transfer seem like 
shifting sand to me.
 
https://bugreports.qt.io/browse/QTBUG-36015 has links to some lower-level tasks 
like support for intents, anyway.

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

Re: [Interest] Raster Engine Issues

[Alper Sağlam]

Hi all,

The issue is not-reproducible so running with the valgrind is not a way to
go. Any new comment on raster engine bugs will make me happier.

Thanks in advance.

On Fri, Jun 10, 2016 at 11:08 AM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> Also, -fsanitize=address ; -fsanitize=undefined.
>
>
>
>
> On Fri, Jun 10, 2016 at 9:27 AM, Harri Porten 
> wrote:
>
>> On Thu, 9 Jun 2016, Alper Sağlam wrote:
>>
>> I am deailing with qt backtrace from a core file, it looks like it is not
>>> reproducible (sporadic) and happened three times in our environments. My
>>> findings shows that some issues occurred in qt raster engine and qt text
>>> engine. I am pasting the bt to here and I just want to know that is there
>>> any known issues (bugs or misuses) of raster engine, text engines and fonts.
>>>
>>
>> I suggest to run the application via Valgrind. It may report the root
>> cause of the problem even for cases where the result is not crash.
>>
>> Harri.
>> ___
>> 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 mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest