Re: [Interest] using QSetting when host application is using it as well

2017-02-02 Thread Frank Rueter | OHUfx 

Thanks.
I'm stuck with QT 4.8.5 at the moment so QStandardPaths is not 
available, but I could use QDesktopServices instead, e.g.:


QtGui.QDesktopServices.storageLocation(QtGui.QDesktopServices.HomeLocation)


What would be the difference to os.path.expanduser('~') though?

Cheers,
frank



On 2/02/17 8:19 PM, Constantin Makshin wrote:

Hi Frank.

Looks like the host application uses QSettings::setPath()
(http://doc.qt.io/qt-5/qsettings.html#setPath) to enforce a specific
directory for configuration files. Calling that method from your code is
obviously a bad idea (high risk of screwing up the host application), so
your "fallback" is the easiest solution. It'll be even better if you
replace the "~/.config" part with proper runtime detection of user
settings' directory (e.g.
QStandardPaths::writableLocation(QStandardPaths::GenericConfigLocation)).

On 02/02/2017 08:35 AM, Frank Rueter | OHUfx wrote:

In the meantime I am falling back on using this:
  os.path.expanduser('~/.config/companyName/appName')

While this does not give me the OS' native support directory for the
respective user at least it's consistent :)

I'd still be interested in a QSettings solution though.

Cheers,
frank

On 2/02/17 4:51 PM, Frank Rueter | OHUfx wrote:

Hi all,

I have been using QSettings for reading/writing user settings.
All works well until I run my (PySide) application inside a host
application that is also written in QT, and which also uses the
QSettings object.

I am now struggling to understand how I can properly differentiate
between the host application's settings instance and my own.
In particular, I need to use QSettings().fileName() to determine the
correct support path for my ini files for each platform.
But this line gives me different values inside and outside the host
application:

 QtCore.QSettings(QtCore.QSettings.IniFormat,
 QtCore.QSettings.UserScope, "companyName", "appName").fileName()

E.g.:
Outside the host application I get what I want:

 /Users/frank/.config/companyName/appName.ini

But the return value is a completely different inside the host app and
actually points to the host app's internal file structure.
Fair enough too I guess.

So my question is:
How can I use QSettings to determine support paths etc while making
sure that I don't accidentally mess with the host applications QSettings?

Cheers,
frank



___
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] QML async/await support?

2017-02-02 Thread Samuel Gaist 

> On 2 Feb 2017, at 18:02, Jason H  wrote:
> 
> When will QML get proper async/await support? I'm not using Promises, since 
> my callback hell is manageable, but I do look forward to async/await.
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

Hi,

Looking for something like https://github.com/benlau/quickpromise ?

Regards,
Samuel


signature.asc
Description: Message signed with OpenPGP
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML async/await support?

2017-02-02 Thread Vlad Stelmahovsky 
may be its better for you to switch on something pure JS?
JS in Qt/QML just for non performance sensitive small peaces of code
If your main logic based on ECMAScript, its non optimal from Qt's
perspective

On Thu, Feb 2, 2017 at 7:54 PM, Jason H  wrote:

> Yes, I know that. I do that regularly.
>
> But AJAX and the LocaStorage are both async in nature. My apps make heavy
> use of both APIs. Having Ecmascript async/await support is desired, and
> becoming very popular.
>
> *Sent:* Thursday, February 02, 2017 at 1:26 PM
>
> *From:* "Vlad Stelmahovsky" 
> *To:* "Jason H" 
> *Cc:* "interestqt-project.org" 
> *Subject:* Re: [Interest] QML async/await support?
> In C++. you can always fallback to C++ from QML
>
> On Thu, Feb 2, 2017 at 7:24 PM, Jason H  wrote:
>>
>> In QML?
>>
>> *Sent:* Thursday, February 02, 2017 at 1:21 PM
>> *From:* "Vlad Stelmahovsky" 
>> *To:* "Jason H" 
>> *Cc:* "interestqt-project.org" 
>> *Subject:* Re: [Interest] QML async/await support?
>> QThread, QConcurrent, QEventLoop etc?
>>
>> On Thu, Feb 2, 2017 at 6:02 PM, Jason H  wrote:
>>>
>>> When will QML get proper async/await support? I'm not using Promises,
>>> since my callback hell is manageable, but I do look forward to async/await.
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>>
>> --
>> Best regards,
>> Vlad
>>
>
>
> --
> Best regards,
> Vlad
>



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

Re: [Interest] QML async/await support?

2017-02-02 Thread Jason H 

Yes, I know that. I do that regularly.

 

But AJAX and the LocaStorage are both async in nature. My apps make heavy use of both APIs. Having Ecmascript async/await support is desired, and becoming very popular. 

 

Sent: Thursday, February 02, 2017 at 1:26 PM
From: "Vlad Stelmahovsky" 
To: "Jason H" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] QML async/await support?


In C++. you can always fallback to C++ from QML

 
On Thu, Feb 2, 2017 at 7:24 PM, Jason H  wrote:




In QML?
 

Sent: Thursday, February 02, 2017 at 1:21 PM
From: "Vlad Stelmahovsky" 
To: "Jason H" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] QML async/await support?




QThread, QConcurrent, QEventLoop etc?

 
On Thu, Feb 2, 2017 at 6:02 PM, Jason H  wrote:

When will QML get proper async/await support? I'm not using Promises, since my callback hell is manageable, but I do look forward to async/await.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

 

 
--


Best regards,
Vlad













 

 
--


Best regards,
Vlad







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

Re: [Interest] QML async/await support?

2017-02-02 Thread Vlad Stelmahovsky 
In C++. you can always fallback to C++ from QML

On Thu, Feb 2, 2017 at 7:24 PM, Jason H  wrote:

> In QML?
>
> *Sent:* Thursday, February 02, 2017 at 1:21 PM
> *From:* "Vlad Stelmahovsky" 
> *To:* "Jason H" 
> *Cc:* "interestqt-project.org" 
> *Subject:* Re: [Interest] QML async/await support?
> QThread, QConcurrent, QEventLoop etc?
>
> On Thu, Feb 2, 2017 at 6:02 PM, Jason H  wrote:
>>
>> When will QML get proper async/await support? I'm not using Promises,
>> since my callback hell is manageable, but I do look forward to async/await.
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
> --
> Best regards,
> Vlad
>



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

Re: [Interest] QML async/await support?

2017-02-02 Thread Jason H 
In QML?
 

Sent: Thursday, February 02, 2017 at 1:21 PM
From: "Vlad Stelmahovsky" 
To: "Jason H" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] QML async/await support?


QThread, QConcurrent, QEventLoop etc?

 
On Thu, Feb 2, 2017 at 6:02 PM, Jason H  wrote:

When will QML get proper async/await support? I'm not using Promises, since my callback hell is manageable, but I do look forward to async/await.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

 

 
--


Best regards,
Vlad







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

[Interest] QML async/await support?

2017-02-02 Thread Jason H 
When will QML get proper async/await support? I'm not using Promises, since my 
callback hell is manageable, but I do look forward to async/await.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QTreeView::resizeColumnToContents not accurate enough

2017-02-02 Thread Elvis Stansvik 
2017-02-02 12:51 GMT+01:00 Elvis Stansvik :
> 2017-02-02 11:39 GMT+01:00 Elvis Stansvik :
>> 2017-02-02 11:23 GMT+01:00 Elvis Stansvik :
>>> WIth the following minimal example:
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main(int argc, char *argv[])
>>> {
>>> QApplication app(argc, argv);
>>>
>>> QStandardItemModel model(3, 2);
>>> model.setHorizontalHeaderLabels({ "Header 1", "Header 2" });
>>>
>>> for (int row = 0; row < 3; ++row) {
>>> for (int column = 0; column < 2; ++column) {
>>> model.setItem(row, column, new QStandardItem("Foo"));
>>> }
>>> }
>>>
>>> QTreeView view;
>>> view.setModel();
>>> view.show();
>>> view.resizeColumnToContents(0);
>>>
>>> return app.exec();
>>> }
>>>
>>> I get the attached result. Note how the first column does not snugly
>>> fit the contents. The limiting factor should be the width of the
>>> header ("Header 1"), but there's plenty of room left to shrink the
>>> column.
>>>
>>> Anyone else had this problem? Is there a way to improve the accuracy
>>> of QTreeView::resizeColumnToContents ?
>>>
>>> This is with Qt 5.5.1 (Ubuntu 16.04 package).
>>
>> I wonder, considering the amount of extra space, could it be that the
>> calculation is taking the width of a sorting indicator (the ^ and v
>> arrows) into account, even if no such handle is visible (sorting is
>> not enabled)? If so, should that be considered a bug that I should
>> report?
>
> Nevermind, I realized now that QHeaderView delegates to the style to
> draw the header section, and that this is a bug in my style (Breeze).
> With the Fusion style the result is as expected.
>
> Breeze should take the sort indicator into account somewhere around
> here: 
> https://github.com/KDE/breeze/blob/master/kstyle/breezestyle.cpp#L2901-L2940
>
> I'll report it to the KDE folks.

(For those interested, I submitted this patch to fix it:
https://phabricator.kde.org/D4406)

>
> Elvis
>
>>
>> Elvis
>>
>>>
>>> Thanks in advance,
>>> Elvis
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QTreeView::resizeColumnToContents not accurate enough

2017-02-02 Thread Elvis Stansvik 
2017-02-02 11:39 GMT+01:00 Elvis Stansvik :
> 2017-02-02 11:23 GMT+01:00 Elvis Stansvik :
>> WIth the following minimal example:
>>
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> int main(int argc, char *argv[])
>> {
>> QApplication app(argc, argv);
>>
>> QStandardItemModel model(3, 2);
>> model.setHorizontalHeaderLabels({ "Header 1", "Header 2" });
>>
>> for (int row = 0; row < 3; ++row) {
>> for (int column = 0; column < 2; ++column) {
>> model.setItem(row, column, new QStandardItem("Foo"));
>> }
>> }
>>
>> QTreeView view;
>> view.setModel();
>> view.show();
>> view.resizeColumnToContents(0);
>>
>> return app.exec();
>> }
>>
>> I get the attached result. Note how the first column does not snugly
>> fit the contents. The limiting factor should be the width of the
>> header ("Header 1"), but there's plenty of room left to shrink the
>> column.
>>
>> Anyone else had this problem? Is there a way to improve the accuracy
>> of QTreeView::resizeColumnToContents ?
>>
>> This is with Qt 5.5.1 (Ubuntu 16.04 package).
>
> I wonder, considering the amount of extra space, could it be that the
> calculation is taking the width of a sorting indicator (the ^ and v
> arrows) into account, even if no such handle is visible (sorting is
> not enabled)? If so, should that be considered a bug that I should
> report?

Nevermind, I realized now that QHeaderView delegates to the style to
draw the header section, and that this is a bug in my style (Breeze).
With the Fusion style the result is as expected.

Breeze should take the sort indicator into account somewhere around
here: 
https://github.com/KDE/breeze/blob/master/kstyle/breezestyle.cpp#L2901-L2940

I'll report it to the KDE folks.

Elvis

>
> Elvis
>
>>
>> Thanks in advance,
>> Elvis
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QTreeView::resizeColumnToContents not accurate enough

2017-02-02 Thread Elvis Stansvik 
2017-02-02 11:23 GMT+01:00 Elvis Stansvik :
> WIth the following minimal example:
>
> #include 
> #include 
> #include 
> #include 
>
> int main(int argc, char *argv[])
> {
> QApplication app(argc, argv);
>
> QStandardItemModel model(3, 2);
> model.setHorizontalHeaderLabels({ "Header 1", "Header 2" });
>
> for (int row = 0; row < 3; ++row) {
> for (int column = 0; column < 2; ++column) {
> model.setItem(row, column, new QStandardItem("Foo"));
> }
> }
>
> QTreeView view;
> view.setModel();
> view.show();
> view.resizeColumnToContents(0);
>
> return app.exec();
> }
>
> I get the attached result. Note how the first column does not snugly
> fit the contents. The limiting factor should be the width of the
> header ("Header 1"), but there's plenty of room left to shrink the
> column.
>
> Anyone else had this problem? Is there a way to improve the accuracy
> of QTreeView::resizeColumnToContents ?
>
> This is with Qt 5.5.1 (Ubuntu 16.04 package).

I wonder, considering the amount of extra space, could it be that the
calculation is taking the width of a sorting indicator (the ^ and v
arrows) into account, even if no such handle is visible (sorting is
not enabled)? If so, should that be considered a bug that I should
report?

Elvis

>
> Thanks in advance,
> Elvis
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] QTreeView::resizeColumnToContents not accurate enough

2017-02-02 Thread Elvis Stansvik 
WIth the following minimal example:

#include 
#include 
#include 
#include 

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

QStandardItemModel model(3, 2);
model.setHorizontalHeaderLabels({ "Header 1", "Header 2" });

for (int row = 0; row < 3; ++row) {
for (int column = 0; column < 2; ++column) {
model.setItem(row, column, new QStandardItem("Foo"));
}
}

QTreeView view;
view.setModel();
view.show();
view.resizeColumnToContents(0);

return app.exec();
}

I get the attached result. Note how the first column does not snugly
fit the contents. The limiting factor should be the width of the
header ("Header 1"), but there's plenty of room left to shrink the
column.

Anyone else had this problem? Is there a way to improve the accuracy
of QTreeView::resizeColumnToContents ?

This is with Qt 5.5.1 (Ubuntu 16.04 package).

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