[Interest] CoreText font rendering changes in 5.9?

[René J . V . Bertin]

Hi,

I know there have been some changes to FreeType font rendering in 5.9 (to use 
stem-darkening). Have there been any changes to the CoreText fontengine too?

Reason for asking:
https://github.com/annulen/webkit/issues/703

Thanks,
R.

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

Re: [Interest] Getting at the metadata (or simply the file names) of currently loaded plugins

[René J . V . Bertin]

On Thursday December 28 2017 21:34:28 Konstantin Tokarev wrote:

> > Hmm, so the staticplugins list should contain the fusion, windows and 
> > macintosh
> > styles, but as I said it was empty. Curious but not a priority ATM.
> 
> You probably have to initialize them with Q_IMPORT_PLUGIN macro

Why? They must be loaded because they show up in qtdiag and other applications 
that provide a widget-style selector.

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

Re: [Interest] Getting at the metadata (or simply the file names) of currently loaded plugins

[Konstantin Tokarev]

28.12.2017, 21:16, "René J. V. Bertin" :
> Thiago Macieira wrote:
>
>>>  Which also explains why the built-in styles don't show up because they're 
>>> in
>>>  a shared library?
>>
>>  Those would also be staticplugins. If they are compiled into a library or 
>> the
>>  executable, as opposed to a dynamically-loaded module, they're 
>> staticplugins.
>
> Hmm, so the staticplugins list should contain the fusion, windows and 
> macintosh
> styles, but as I said it was empty. Curious but not a priority ATM.

You probably have to initialize them with Q_IMPORT_PLUGIN macro

>
>>>  I'm a bit surprised though that this is so difficult. Plugin metadata is a
>>>  special case of QObject metadata, no? I can't find any methods to query 
>>> that
>>>  information (except via QPluginLoader for plugins), why is that?
>>
>>  No. It's a special section in the executable so that QLibrary can find it
>>  without loading the actual library. Then we read in the binary JSON that is
>>  stored there.
>
> Well, obviously that data is also stored in the plugin file in a way that the
> plugin loader can find and use it. So I guess it could be both.
>
> Either way it's a lot more straightforward to use the
> QPlatformNativeInterface::NativeResourceForIntegrationFunction mechanism for
> what I wanted to achieve, esp. if the target QPA already has one that can be
> extended.
>
> Thanks,
> R.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] Getting at the metadata (or simply the file names) of currently loaded plugins

[René J . V . Bertin]

Thiago Macieira wrote:


>> Which also explains why the built-in styles don't show up because they're in
>> a shared library?
> 
> Those would also be staticplugins. If they are compiled into a library or the
> executable, as opposed to a dynamically-loaded module, they're staticplugins.

Hmm, so the staticplugins list should contain the fusion, windows and macintosh 
styles, but as I said it was empty. Curious but not a priority ATM.


>> I'm a bit surprised though that this is so difficult. Plugin metadata is a
>> special case of QObject metadata, no? I can't find any methods to query that
>> information (except via QPluginLoader for plugins), why is that?
> 
> No. It's a special section in the executable so that QLibrary can find it
> without loading the actual library. Then we read in the binary JSON that is
> stored there.

Well, obviously that data is also stored in the plugin file in a way that the 
plugin loader can find and use it. So I guess it could be both.

Either way it's a lot more straightforward to use the 
QPlatformNativeInterface::NativeResourceForIntegrationFunction mechanism for 
what I wanted to achieve, esp. if the target QPA already has one that can be 
extended.

Thanks,
R.

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

[Interest] QT3D bug on basic Shapes example on Android

[Pierre Chicoine]

The QT3D C++ basicsshapes example receives events in Qt3d window on
desktop. The 3d shapes can move with mouse. Simultaneously the widget side
works.

The same example does not receive any Qt3d window events on Android. The
shapes don't move.

The events on the widget side on Android do receive events, the checkboxes
do shut off the 3d objects. So the widget side on Android is working.

I've tried this with the input controllers with a different program and
also with an event filter. The Qt3d side receives no input events.

File a bug QTBUG-57450 
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Is there a QML way for doing web requests? Just for data, not for rendering.

[Mark Gaiser]

On Thu, Dec 28, 2017 at 2:33 PM, Konstantin Tokarev 
wrote:

>
>
> 28.12.2017, 15:23, "Mark Gaiser" :
>
> On Fri, Dec 22, 2017 at 11:19 PM, Mark Gaiser  wrote:
>
> Hi,
>
> You know those fancy REST api's out there.
> How does one use them in QML?
>
> For websockets the answer is simple: QML WebSocket.
> But i didn't find a way to just do a web request to some url and get it's
> data, at least not a way that seems "QMLified".
>
> Sure, javascript can be used with it's XMLHttpRequest which will work just
> fine, but using it seems so.. not QML like. So is there a QML way to do
> such things?
>
>
> Best regards,
> Mark
>
>
> Bump..
>
>
> Did you see http://www.cutehacks.com/blog/2016/9/23/friendlier-network-
> requests-in-qml
> This is among first things that search engines show
>
> I apparently didn't do a good job at searching (which i did) :)
That looks like a really powerful "cURL for QML" api heavily inspired on
Javascript Promises.

I wouldn't use that directly in QML (it looks too low level for QML...) but
it can serve as base to implement some fancy models.
Thank you for that link!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Is there a QML way for doing web requests? Just for data, not for rendering.

[Mark Gaiser]

On Thu, Dec 28, 2017 at 2:25 PM, Shawn Rutledge 
wrote:

> On 22 Dec 2017, at 23:19, Mark Gaiser  wrote:
> >
> > Hi,
> >
> > You know those fancy REST api's out there.
> > How does one use them in QML?
> >
> > For websockets the answer is simple: QML WebSocket.
> > But i didn't find a way to just do a web request to some url and get
> it's data, at least not a way that seems "QMLified".
> >
> > Sure, javascript can be used with it's XMLHttpRequest which will work
> just fine, but using it seems so.. not QML like. So is there a QML way to
> do such things?
>
> Not AFAIK, except for anything (like Image) which has a source URL.
>
> Why don’t you like XMLHttpRequest?  How would you want the QML API to look
> then? Do you expect to do some data processing in JS after you fetch the
> data, or just looking for a way to pass the data to some C++ code?  If the
> latter, why not do the loading in C++ too?
>
> (at least some of those are rhetorical questions… ;-)
>
>
Well, in my ideal situation the web request fills a model which is then
hooked into a view.
An hypothetical API like:

WebRequestModel {
  id: webRequest
  url: "https://some/webservice/url;
  parseType: WebRequestModel.JSON
}

ListView {
  model: webRequest
  .. and some delegate stuff ..
}

Done :)
That would look really clean to me and be very powerful for QML. I'm
slightly surprised that QML doesn't have something like this yet.

A little explanation for the hypothetical "WebRequestModel". As i wrote it
above it should have multiple ways to parse it's data. JSON in this case,
but also XML and YAML at the very least.
The QML -> C++ passing would just be the url from the QML side to the C++
QAIM implementation. There the JSON (and other types) would be parsed.
This structure would only work with simple data outputs from web services.
Not if there is cruft around the data that you'd need to filter out first.
You could add a hypothetical property to the hypothetical WebRequestModel
called "path" or "xpath" which would define the part of the data to use for
the model.

As for not liking XMLHttpRequest. It works I just don't like it's API.
It looks very verbose and very specific for website backends. Not really
fitting (api wise) for QML.
Did i answer all your questions? :)
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Is there a QML way for doing web requests? Just for data, not for rendering.

[Konstantin Tokarev]

  28.12.2017, 15:23, "Mark Gaiser" :On Fri, Dec 22, 2017 at 11:19 PM, Mark Gaiser  wrote:Hi, You know those fancy REST api's out there.How does one use them in QML? For websockets the answer is simple: QML WebSocket.But i didn't find a way to just do a web request to some url and get it's data, at least not a way that seems "QMLified". Sure, _javascript_ can be used with it's XMLHttpRequest which will work just fine, but using it seems so.. not QML like. So is there a QML way to do such things?  Best regards,Mark Bump.. Did you see http://www.cutehacks.com/blog/2016/9/23/friendlier-network-requests-in-qmlThis is among first things that search engines show ,___Interest mailing listInterest@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/interest  -- Regards,Konstantin ___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Is there a QML way for doing web requests? Just for data, not for rendering.

[Shawn Rutledge]

On 22 Dec 2017, at 23:19, Mark Gaiser  wrote:
> 
> Hi,
> 
> You know those fancy REST api's out there.
> How does one use them in QML?
> 
> For websockets the answer is simple: QML WebSocket.
> But i didn't find a way to just do a web request to some url and get it's 
> data, at least not a way that seems "QMLified".
> 
> Sure, javascript can be used with it's XMLHttpRequest which will work just 
> fine, but using it seems so.. not QML like. So is there a QML way to do such 
> things?

Not AFAIK, except for anything (like Image) which has a source URL.

Why don’t you like XMLHttpRequest?  How would you want the QML API to look 
then? Do you expect to do some data processing in JS after you fetch the data, 
or just looking for a way to pass the data to some C++ code?  If the latter, 
why not do the loading in C++ too?

(at least some of those are rhetorical questions… ;-)

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

Re: [Interest] Is there a QML way for doing web requests? Just for data, not for rendering.

[Mark Gaiser]

On Fri, Dec 22, 2017 at 11:19 PM, Mark Gaiser  wrote:

> Hi,
>
> You know those fancy REST api's out there.
> How does one use them in QML?
>
> For websockets the answer is simple: QML WebSocket.
> But i didn't find a way to just do a web request to some url and get it's
> data, at least not a way that seems "QMLified".
>
> Sure, javascript can be used with it's XMLHttpRequest which will work just
> fine, but using it seems so.. not QML like. So is there a QML way to do
> such things?
>
>
> Best regards,
> Mark
>

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

Re: [Interest] Getting at the metadata (or simply the file names) of currently loaded plugins

[Thiago Macieira]

On quinta-feira, 28 de dezembro de 2017 08:08:30 -02 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > Remember: staticplugins are not plugins.
> 
> Actually, I couldn't remember that. The name suggested they might, but the
> documentation doesn't (at least what I read of it).
> 
> > They are regular, static
> > libraries whose only access point is via the plugin loader mechanism.
> 
> Which also explains why the built-in styles don't show up because they're in
> a shared library?

Those would also be staticplugins. If they are compiled into a library or the 
executable, as opposed to a dynamically-loaded module, they're staticplugins.

> > If you poke through the internals of QPluginLoader, you'll find it. See
> > the
> > QLibraryStore global static instance in qlibrary.cpp.
> 
> I started doing that, traced the metadata getter to a rawMetaData symbol
> which is a QtPluginMetaDataFunction which is a function pointer, and got
> lost there.

I think that QPluginLoader will leave the QLibraryPrivate in a IsAPlugin 
state, which means the QJsonObject metaData meber should be filled.

> I'll have a look at qlibrary.cpp and see if that gets me where I want though
> I guess that would oblige me to trawl the plugin directory myself to
> enumerate all plugins of potential interest.

Right, that's what QFactoryLoader does.

> I'm a bit surprised though that this is so difficult. Plugin metadata is a
> special case of QObject metadata, no? I can't find any methods to query that
> information (except via QPluginLoader for plugins), why is that?

No. It's a special section in the executable so that QLibrary can find it 
without loading the actual library. Then we read in the binary JSON that is 
stored there.

-- 
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] Getting at the metadata (or simply the file names) of currently loaded plugins

[René J . V . Bertin]

Thiago Macieira wrote:

> Remember: staticplugins are not plugins.

Actually, I couldn't remember that. The name suggested they might, but the 
documentation doesn't (at least what I read of it).
> They are regular, static
> libraries whose only access point is via the plugin loader mechanism.

Which also explains why the built-in styles don't show up because they're in a 
shared library?

> If you poke through the internals of QPluginLoader, you'll find it. See the
> QLibraryStore global static instance in qlibrary.cpp.

I started doing that, traced the metadata getter to a rawMetaData symbol which 
is a QtPluginMetaDataFunction which is a function pointer, and got lost there.


I'll have a look at qlibrary.cpp and see if that gets me where I want though I 
guess that would oblige me to trawl the plugin directory myself to enumerate 
all 
plugins of potential interest.
I'm a bit surprised though that this is so difficult. Plugin metadata is a 
special case of QObject metadata, no? I can't find any methods to query that 
information (except via QPluginLoader for plugins), why is that?



Meanwhile I'm trying to approach my experiment in a different way, via a custom 
platform integration function in the QPA plugin. I should have thought of that 
at once :)

R.

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