Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Bo Thorsen]

Hi Frank,

Den 12-01-2016 kl. 22:40 skrev Frank Rueter | OHUfx:

I just joined this list so hello everybody.
I'm using QT via PySide mainly to create tools for vfx workflows and
custom tools for the software Nuke.

I'm not a programmer by trade, more of a vfx artist and technician using
Python/PySide to enhance pipelines and workflows for myself and other
companies.
Currently I am writing a custom spreadsheet that will need many custom
ItemDelegates and a controlled way of data input/output when a cell's
data is changed.
I will also need to write a feature that allows for multiple cells to be
changed at the same time (haven't got that far yet though).

The amount of items will potentially be in the 100,000s and a lot of
filtering will be going on.

I started using the QStandardItemModel and so far things are working
fine, but I haven't implemented the delegates or editors yet, and I
believe I will also have to override the data()/setData() methods in
order to control how the data is managed on IO.

I can't make up my mind if I should switch to using the
QAbstractTableModel before proceeding.
I am using some of the QStandardItemModel's method's, such as clear()
and item() and setItem(), but I guess those are easy to re-implement.

The docs say that one should consider using QAbstractTableModel (or
QAbstractItemModel) for efficiency and flexibility, but I am struggling
to make an educated decision because I haven't used model/views often
enough yet to know about all the pros and cons, and I can't find a
discussion concerning this online.

I have started re-writeing the code using QAbstractTableModel, trying to
get to the same level I'm at with the code using the QStandardItemModel.
It seems a bit harder than I thought, but I will keep going for training
purposes if nothing else, hoping that I might even have a more
responsive model in the end, but I'm just not sure if it's worth it in
my case, or if I should just stick to the pre-fab QStandardItemModel.

Any advice from more experienced programmers on how to make that
decision would be very much appreciated. I'd hate to finish writing the
code only to find out that it's too slow for large data sets, and then
re-jig everything to use the QAbstractTableModel.


To me, the standard item model has always been something I use as little 
as I can. It's bad in so many ways. But I do understand why sometimes 
it's a quick fix for a small problem.


Implementing a proper table model is not as easy, but in the long run 
you will prefer it. Once a proper model is done, it just keeps working. 
And it can handle the large load you are talking about.


If it was me, I wouldn't have to think about this. It's a clear case of 
a proper table model.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to create a list.

[Konstantin Tokarev]

13.01.2016, 04:10, "william.croc...@analog.com" :
> On 01/12/2016 07:37 PM, Elvis Stansvik wrote:
>>  2016-01-12 15:37 GMT+01:00 Bill Crocker:
>>>  Hello:
>>>
>>>  Could someone please show me the few lines of code required
>>>  to add a list *of three elements* to a QTextDocument using low
>>>  level (i.e QTextBlock, QTextCursor, QTextList, etc.) classes.
>>
>>  This would be one way:
>
> That is all good stuff.
>
> I had solved my problem and was going to fess up in the next few hours.
> The part I needed was that little itsy-bitsy, under documented function
> named add() which is hidden in plain sight at the top of the QTextList
> documentation.
>
> In my own defense, it is not used in qtexthtmlparser.cpp or qtextedit.cpp
> which were the fist two stops (Qt 4.8.6) I made looking for answers.
>
> Also, the documentation (Qt 4.8.6) does not appear to show you how to add the
> second item to a list which is not at all like adding the first.
>
> My application is also a little different. I am parsing my own XML 
> representation
> of a document, and so would not parse the text and then make a second pass
> to apply the structure. But I am good now that I know the add() trick.

Hi Bill,

You may want to use DOM parser to make things more convenient. If you don't 
want to use QDom (there a many reasons not to use it), you cat try great 
PugiXML parser:

http://pugixml.org/

>
> Thanks.
>
> Bill
>
>>  #include
>>  #include
>>  #include
>>  #include
>>  #include
>>  #include
>>  #include
>>
>>  int main(int argc, char *argv[]) {
>>   QApplication app(argc, argv);
>>
>>   QTextEdit edit;
>>   QTextDocument *doc = edit.document();
>>
>>   // Insert text.
>>   QTextCursor cursor(doc);
>>   cursor.insertText("A list of three items:\n");
>>   cursor.insertText("One\n");
>>   cursor.insertText("Two\n");
>>   cursor.insertText("Three");
>>
>>   // Position cursor on "One".
>>   cursor.movePosition(QTextCursor::Start);
>>   cursor.movePosition(QTextCursor::NextBlock);
>>
>>   // Insert list.
>>   QTextListFormat listFormat;
>>   listFormat.setStyle(QTextListFormat::ListDisc);
>>   QTextList *list = cursor.insertList(listFormat);
>>
>>   // Add "Two".
>>   cursor.movePosition(QTextCursor::NextBlock);
>>   list->add(cursor.block());
>>
>>   // Add "Three".
>>   cursor.movePosition(QTextCursor::NextBlock);
>>   list->add(cursor.block());
>>
>>   edit.show();
>>
>>   return app.exec();
>>  }
>>
>>  Regards,
>>  Elvis
>>
>>>  Thanks.
>>>
>>>  --
>>>  Bill
>>>  ___
>>>  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

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

Re: [Interest] How to create a list.

[william.croc...@analog.com]

On 01/13/2016 05:33 AM, Konstantin Tokarev wrote:



13.01.2016, 04:10, "william.croc...@analog.com":

On 01/12/2016 07:37 PM, Elvis Stansvik wrote:

  2016-01-12 15:37 GMT+01:00 Bill Crocker:

  Hello:

  Could someone please show me the few lines of code required
  to add a list *of three elements* to a QTextDocument using low
  level (i.e QTextBlock, QTextCursor, QTextList, etc.) classes.


  This would be one way:


That is all good stuff.

I had solved my problem and was going to fess up in the next few hours.
The part I needed was that little itsy-bitsy, under documented function
named add() which is hidden in plain sight at the top of the QTextList
documentation.

In my own defense, it is not used in qtexthtmlparser.cpp or qtextedit.cpp
which were the fist two stops (Qt 4.8.6) I made looking for answers.

Also, the documentation (Qt 4.8.6) does not appear to show you how to add the
second item to a list which is not at all like adding the first.

My application is also a little different. I am parsing my own XML 
representation
of a document, and so would not parse the text and then make a second pass
to apply the structure. But I am good now that I know the add() trick.


Hi Bill,

You may want to use DOM parser to make things more convenient.
If you don't want to use QDom (there a many reasons not to use it), you cat try 

great PugiXML parser:

I parse XML and traverse with QDom. That is not the problem.
Figuring out how to create a QTextDocument from it for use by QTextEdit was the 
problem.
(IMHO QTextDocument has design and usability issues, but I would probably not 
have done any

better given the complexity of the problem domain.)

I could just use the native HTML read/write capability, but I need to add my own 
special

object types and it does not appear possible to save/restore them with HTML.

Is it possible save/restore my own objects using HTML?

I use the QTextObjectInterface interface to add them to QTextDocument, but did
not see how to save/restore. That is why I was forced to my own XML file format.

Thanks.

Bill



http://pugixml.org/



Thanks.

Bill


  #include
  #include
  #include
  #include
  #include
  #include
  #include

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

   QTextEdit edit;
   QTextDocument *doc = edit.document();

   // Insert text.
   QTextCursor cursor(doc);
   cursor.insertText("A list of three items:\n");
   cursor.insertText("One\n");
   cursor.insertText("Two\n");
   cursor.insertText("Three");

   // Position cursor on "One".
   cursor.movePosition(QTextCursor::Start);
   cursor.movePosition(QTextCursor::NextBlock);

   // Insert list.
   QTextListFormat listFormat;
   listFormat.setStyle(QTextListFormat::ListDisc);
   QTextList *list = cursor.insertList(listFormat);

   // Add "Two".
   cursor.movePosition(QTextCursor::NextBlock);
   list->add(cursor.block());

   // Add "Three".
   cursor.movePosition(QTextCursor::NextBlock);
   list->add(cursor.block());

   edit.show();

   return app.exec();
  }

  Regards,
  Elvis


  Thanks.

  --
  Bill
  ___
  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] User comments on web pages?

[Curtis Mitch]

I've always thought it would be cool to have some kind of web interface to the 
documentation that allowed edit suggestions from users, with a review system 
that pinged the doc team/relevant maintainers to approve or give feedback on 
those edits. It would solve the problem of the barrier to entry for new users.

Perhaps something similar to moderated edits on Wikis?

I think that comments are useful, but it's better to improve the documentation 
directly.
 
> -Original Message-
> From: Interest [mailto:interest-boun...@qt-project.org] On Behalf Of Jason
> H
> Sent: Tuesday, 12 January 2016 3:58 PM
> To: Interests Qt 
> Subject: [Interest] User comments on web pages?
> 
> There are a few things I'd like to add to the documentation, but the
> barrier to entry is too high.
> I'm wondering if we could allow comments by users (or those with
> bugreports account, or has an an account and is authorized) to be able to
> comment on the online help? I found the PHP comments helpful, when they
> were not completely off-base (let's face it, it's PHP :-))
> 
> It would also be cool is QtCreator could fetch these (assuming it ends up
> happening) ___
> 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] git initr-epository error

[Jason H]

Aliasing ../../../qtrepotools/git-hooks/gerrit_commit_msg_hook
  as qt3d/.git/hooks/commit-msg ...
Cannot create forwarding script qt3d/.git/hooks/commit-msg: Not a directory

What should I do?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] is this a bug on QMediaPlayer on Android ?

[Gian Maxera]

Hello,
my app crash when trying to play a sound with QMediaPlayer on Android.
This is the error:

No implementation found for void 
org.qtproject.qt5.android.multimedia.QtAndroidMediaPlayer.onStateChangedNative(int,
 long)

I’m using Qt 5.5.1

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

[Interest] Qt and remote files?

[Matthew Woehlke]

I see that in Qt 5, QFileDialog has gained methods to work with URL's
instead of (just) local paths. How does this work? (Does it integrate
with e.g. KIO where supported?) And how do I go about opening or saving
such a remote file via Qt? (Are they supported directly by QFile /
QSaveFile, or do I need to use other mechanisms?)

-- 
Matthew

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

Re: [Interest] Qt and remote files?

[Thiago Macieira]

On Wednesday 13 January 2016 10:16:36 Matthew Woehlke wrote:
> I see that in Qt 5, QFileDialog has gained methods to work with URL's
> instead of (just) local paths. How does this work? (Does it integrate
> with e.g. KIO where supported?) 

The Qt file dialog doesn't. The URL-based APIs are there to support 
KFileDialog, which gets used via the KDE integration plugin.

> And how do I go about opening or saving
> such a remote file via Qt? (Are they supported directly by QFile /
> QSaveFile, or do I need to use other mechanisms?)

You use KIO or another remote file API. Qt doesn't provide one.

-- 
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] Qt and remote files?

[Matthew Woehlke]

On 2016-01-13 11:06, Thiago Macieira wrote:
> On Wednesday 13 January 2016 10:16:36 Matthew Woehlke wrote:
>> I see that in Qt 5, QFileDialog has gained methods to work with URL's
>> instead of (just) local paths. How does this work? (Does it integrate
>> with e.g. KIO where supported?) 
> 
> The Qt file dialog doesn't. The URL-based APIs are there to support 
> KFileDialog, which gets used via the KDE integration plugin.

Oookay... So on Linux/KF5, QFileDialog::getOpenFileUrl will use the KF5
dialog and can return network locations, correct? What about on other
platforms, e.g. Windows?

>> And how do I go about opening or saving
>> such a remote file via Qt? (Are they supported directly by QFile /
>> QSaveFile, or do I need to use other mechanisms?)
> 
> You use KIO or another remote file API. Qt doesn't provide one.

Bah. KF5's tutorials (which say to use QSaveFile) are wrong, then :-(.

Thanks.

-- 
Matthew

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

[Interest] How do i monitor DBus functions (not signals)

[Mark Gaiser]

Hi,

I'm trying to monitor "org.freedesktop.Notifications" for the notifications
(see [1] for reference) that broadcasted from there. Every notification
ends up in a "Notify" method on that dbus interface.

I'm trying to monitor that, but kinda fail at it... I can monitor the
notifications with dbus-monitor
"interface='org.freedesktop.Notifications',member='Notify',type='method_call',eavesdrop='true'",
doing the same in code is not firing the slot i'd like it to call..

The code:

...
QDBusConnection::sessionBus().connect("",
  "",
  "org.freedesktop.Notifications",
  "Notify",
  this,
  SLOT(notify(QDBusMessage)));

// This is the exact same match line as from the command.
QString matchString =
"interface='org.freedesktop.Notifications',member='Notify',type='method_call',eavesdrop='true'";
QDBusInterface busInterface("org.freedesktop.DBus",
"/org/freedesktop/DBus",
"org.freedesktop.DBus");
busInterface.call("AddMatch", matchString);
...

In the connect line the "this" object is a simple one function class
inheriting from QObject with a "notify(QDBusMessage message)" member as
public slot.

In the app i've set the env variable: QDBUS_DEBUG=1 (for debugging purpose).

If i run my app and send a notify message like so:
notify-send -a "Chrome" "aaa"

Then i am getting console output in my app like this:
QDBusConnectionPrivate(0x623760) got message (signal):
QDBusMessage(type=MethodCall, service=":1.522",
path="/org/freedesktop/Notifications",
interface="org.freedesktop.Notifications", member="Notify",
signature="susssasa{sv}i", contents=("Chrome", 0, "", "aaa", "", {},
[Argument: a{sv} {"urgency" = [Variant(uchar): 1]}], -1) )
QDBusConnectionPrivate(0x623760) sending message (no reply):
QDBusMessage(type=Error, service="", error
name="org.freedesktop.DBus.Error.UnknownObject", error message="No such
object path '/org/freedesktop/Notifications'", signature="", contents=() )

But the slot notify(QDBusMessage) is not being called...
What am i doing wrong?

I see the error: "No such object path '/org/freedesktop/Notifications", but
if i add this to my code:
QDBusConnection::sessionBus().registerObject("/org/freedesktop/Notifications",
"org.freedesktop.Notifications", this);

I get roughly the same dbus message, but with this error:
No such interface 'org.freedesktop.Notifications' at object path
'/org/freedesktop/Notifications'

And i'm not even sure if i need to look at that error at all...

I hope someone with dbus knowledge can point me in the right direction for
this?

Thank you,
Mark


[1] http://www.galago-project.org/specs/notification/0.9/
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Frank Rueter | OHUfx]

Thanks Bo,

when you say "it's bad in so many ways", are you referring to performance?

I just realised that my last conversation with Jason had dropped the CC 
to the list, so here it is again :


   so a few lines into the new code and I believe I'm starting to
   realise that QAbstractTableModel is the wrong choice for me, let's
   see if I get this right:

   I need each cell to:

 * store a reference to a custom object in the host application
 * get it's background and foreground colour from the host
   application's object
 * determine the right delegate output based on the data type/
   external object class
 * drive the external object's value upon datatChanged
 * etc.

   When I got as far as implementing the background role in my
   QAbstractTableModel's data method, the resulting view took about 4
   seconds to resize, while scrolling left me with the ol' spinning
   beach ball (OSX).
   The same code utilising QStandarItemModel reacts instantaneously
   without trouble, even with way more data.

   I suppose this is because I am storing those object references in
   each QStandarItem as I construct the data when using
   QStandarItemModel. So later on, those values are readily available
   within my data model.
   When putting those references into QAbstractTableModel.data(), they
   are constantly called upon as the view changes, causing the massive
   slow down.

   In order to keep the view fast, I need to refactor my code and
   somehow store the custom data only once, so things like background
   colour etc. are determined within my model's data when needed,
   rather than having to call the host application constantly to
   retrieve the same info.
   Which essentially turns the table model into an item model, and I
   might as well use the QStandardItemModel or at least
   QAbstractItemModel to begin with.

   Does that sound about right?


Bo, reading your reply makes me feel like I should keep playing with 
QAbstractTableModel (or QAbstractItemModel) and write all the behaviour 
I need from QStandardItemModel myself?
I feel like the item based approach is handier as I can subclass a 
QStandardItem and give it a reference to the external object it 
represents, then have the data read/write from/to that.

I don't think I get that with a table model unless I re-invent the wheel.

Any thoughts on the above?

Thanks,
frank



On 13/01/16 10:27 pm, Bo Thorsen wrote:

Hi Frank,

Den 12-01-2016 kl. 22:40 skrev Frank Rueter | OHUfx:

I just joined this list so hello everybody.
I'm using QT via PySide mainly to create tools for vfx workflows and
custom tools for the software Nuke.

I'm not a programmer by trade, more of a vfx artist and technician using
Python/PySide to enhance pipelines and workflows for myself and other
companies.
Currently I am writing a custom spreadsheet that will need many custom
ItemDelegates and a controlled way of data input/output when a cell's
data is changed.
I will also need to write a feature that allows for multiple cells to be
changed at the same time (haven't got that far yet though).

The amount of items will potentially be in the 100,000s and a lot of
filtering will be going on.

I started using the QStandardItemModel and so far things are working
fine, but I haven't implemented the delegates or editors yet, and I
believe I will also have to override the data()/setData() methods in
order to control how the data is managed on IO.

I can't make up my mind if I should switch to using the
QAbstractTableModel before proceeding.
I am using some of the QStandardItemModel's method's, such as clear()
and item() and setItem(), but I guess those are easy to re-implement.

The docs say that one should consider using QAbstractTableModel (or
QAbstractItemModel) for efficiency and flexibility, but I am struggling
to make an educated decision because I haven't used model/views often
enough yet to know about all the pros and cons, and I can't find a
discussion concerning this online.

I have started re-writeing the code using QAbstractTableModel, trying to
get to the same level I'm at with the code using the QStandardItemModel.
It seems a bit harder than I thought, but I will keep going for training
purposes if nothing else, hoping that I might even have a more
responsive model in the end, but I'm just not sure if it's worth it in
my case, or if I should just stick to the pre-fab QStandardItemModel.

Any advice from more experienced programmers on how to make that
decision would be very much appreciated. I'd hate to finish writing the
code only to find out that it's too slow for large data sets, and then
re-jig everything to use the QAbstractTableModel.


To me, the standard item model has always been something I use as 
little as I can. It's bad in so many ways. But I do understand why 
sometimes it's a quick fix for a small problem.


Implementing a proper table model is not as easy, but in the long run 

Re: [Interest] Qt and remote files?

[Thiago Macieira]

On Wednesday 13 January 2016 13:49:32 Matthew Woehlke wrote:
> On 2016-01-13 11:06, Thiago Macieira wrote:
> > On Wednesday 13 January 2016 10:16:36 Matthew Woehlke wrote:
> >> I see that in Qt 5, QFileDialog has gained methods to work with URL's
> >> instead of (just) local paths. How does this work? (Does it integrate
> >> with e.g. KIO where supported?)
> > 
> > The Qt file dialog doesn't. The URL-based APIs are there to support
> > KFileDialog, which gets used via the KDE integration plugin.
> 
> Oookay... So on Linux/KF5, QFileDialog::getOpenFileUrl will use the KF5
> dialog and can return network locations, correct? What about on other
> platforms, e.g. Windows?

Correct. On other platforms, it depends on the capabilities of their file 
dialogs.

> >> And how do I go about opening or saving
> >> such a remote file via Qt? (Are they supported directly by QFile /
> >> QSaveFile, or do I need to use other mechanisms?)
> > 
> > You use KIO or another remote file API. Qt doesn't provide one.
> 
> Bah. KF5's tutorials (which say to use QSaveFile) are wrong, then :-(.

QSaveFile is local file only.
-- 
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] How do i monitor DBus functions (not signals)

[Thiago Macieira]

On Wednesday 13 January 2016 21:19:33 Mark Gaiser wrote:
> Hi,
> 
> I'm trying to monitor "org.freedesktop.Notifications" for the notifications
> (see [1] for reference) that broadcasted from there. Every notification
> ends up in a "Notify" method on that dbus interface.

Hi Mark. "Monitoring" in D-Bus usually means running dbus-monitor and you do 
that for debugging purposes. I don't think that's what you mean.

Do you mean listening to signals? If you mean that, there's no "method" 
(a.k.a. a slot), only "signal".

> I'm trying to monitor that, but kinda fail at it... I can monitor the
> notifications with dbus-monitor
> "interface='org.freedesktop.Notifications',member='Notify',type='method_call
> ',eavesdrop='true'", doing the same in code is not firing the slot i'd like
> it to call..

Eavesdrop implies debugging. QtDBus will not do this, no matter how much you 
try. Forget 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

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Bo Thorsen]

Den 13-01-2016 kl. 23:07 skrev Frank Rueter | OHUfx:

Thanks Bo,

when you say "it's bad in so many ways", are you referring to performance?

I just realised that my last conversation with Jason had dropped the CC
to the list, so here it is again :

so a few lines into the new code and I believe I'm starting to
realise that QAbstractTableModel is the wrong choice for me, let's
see if I get this right:

I need each cell to:

  * store a reference to a custom object in the host application
  * get it's background and foreground colour from the host
application's object
  * determine the right delegate output based on the data type/
external object class
  * drive the external object's value upon datatChanged
  * etc.

When I got as far as implementing the background role in my
QAbstractTableModel's data method, the resulting view took about 4
seconds to resize, while scrolling left me with the ol' spinning
beach ball (OSX).
The same code utilising QStandarItemModel reacts instantaneously
without trouble, even with way more data.

I suppose this is because I am storing those object references in
each QStandarItem as I construct the data when using
QStandarItemModel. So later on, those values are readily available
within my data model.
When putting those references into QAbstractTableModel.data(), they
are constantly called upon as the view changes, causing the massive
slow down.

In order to keep the view fast, I need to refactor my code and
somehow store the custom data only once, so things like background
colour etc. are determined within my model's data when needed,
rather than having to call the host application constantly to
retrieve the same info.
Which essentially turns the table model into an item model, and I
might as well use the QStandardItemModel or at least
QAbstractItemModel to begin with.

Does that sound about right?


Bo, reading your reply makes me feel like I should keep playing with
QAbstractTableModel (or QAbstractItemModel) and write all the behaviour
I need from QStandardItemModel myself?


Well, you almost already answered the question yourself. It's obvious 
your access from data() the real model is where the problem lies.



I feel like the item based approach is handier as I can subclass a
QStandardItem and give it a reference to the external object it
represents, then have the data read/write from/to that.
I don't think I get that with a table model unless I re-invent the wheel.


MyObject** references;

Can't be much faster than that.


Any thoughts on the above?


To me QStandardItemModel is a quick hack I sometimes use when I just 
want to show a bit on the screen. But those temporary things have a 
tendency to stick around, and at some point I always end up rewriting 
the stuff with the real thing.


If you have performance issues with a QAbstractTableModel over a 
QStandardItemModel, you're doing something wrong.


I think the only place where I might use a QStandardItemModel for 
something real is if you have a static set of information that you just 
need to show. If it never changes, then it's an easy model to use.


At the DevDays in 2006 (I think) I did a presentation on the model view 
classes. I basically told everyone that QStandardItemModel is the path 
to the dark side there as well. And one of the Trolltech guys came up 
and we had an interesting discussion about it. He did argue that 
sometimes there are cases where this makes sense.


But I'm biased. I hate that class and I really like the table and list 
model classes.


Bo.


On 13/01/16 10:27 pm, Bo Thorsen wrote:

Hi Frank,

Den 12-01-2016 kl. 22:40 skrev Frank Rueter | OHUfx:

I just joined this list so hello everybody.
I'm using QT via PySide mainly to create tools for vfx workflows and
custom tools for the software Nuke.

I'm not a programmer by trade, more of a vfx artist and technician using
Python/PySide to enhance pipelines and workflows for myself and other
companies.
Currently I am writing a custom spreadsheet that will need many custom
ItemDelegates and a controlled way of data input/output when a cell's
data is changed.
I will also need to write a feature that allows for multiple cells to be
changed at the same time (haven't got that far yet though).

The amount of items will potentially be in the 100,000s and a lot of
filtering will be going on.

I started using the QStandardItemModel and so far things are working
fine, but I haven't implemented the delegates or editors yet, and I
believe I will also have to override the data()/setData() methods in
order to control how the data is managed on IO.

I can't make up my mind if I should switch to using the
QAbstractTableModel before proceeding.
I am using some of the QStandardItemModel's method's, such as clear()
and item() and setItem(), but I guess those are easy to r

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Bo Thorsen]

Den 13-01-2016 kl. 23:07 skrev Frank Rueter | OHUfx:

when you say "it's bad in so many ways", are you referring to performance?


Performance and ease of data manipulation are the two biggest points.

But it's really simpler than this. To use an old design phrase - that 
class just smells bad.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Andreas Pakulat]

Hi,

On Wed, Jan 13, 2016 at 11:07 PM, Frank Rueter | OHUfx 
wrote:

> Thanks Bo,
>
> when you say "it's bad in so many ways", are you referring to performance?
>
> I just realised that my last conversation with Jason had dropped the CC to
> the list, so here it is again :
>
> so a few lines into the new code and I believe I'm starting to realise
> that QAbstractTableModel is the wrong choice for me, let's see if I get
> this right:
>
> I need each cell to:
>
>- store a reference to a custom object in the host application
>- get it's background and foreground colour from the host
>application's object
>- determine the right delegate output based on the data type/ external
>object class
>- drive the external object's value upon datatChanged
>- etc.
>
> When I got as far as implementing the background role in my
> QAbstractTableModel's data method, the resulting view took about 4 seconds
> to resize, while scrolling left me with the ol' spinning beach ball (OSX).
> The same code utilising QStandarItemModel reacts instantaneously without
> trouble, even with way more data.
>
> I suppose this is because I am storing those object references in each
> QStandarItem as I construct the data when using QStandarItemModel. So later
> on, those values are readily available within my data model.
> When putting those references into QAbstractTableModel.data(), they are
> constantly called upon as the view changes, causing the massive slow down.
>
> In order to keep the view fast, I need to refactor my code and somehow
> store the custom data only once, so things like background colour etc. are
> determined within my model's data when needed, rather than having to call
> the host application constantly to retrieve the same info.
> Which essentially turns the table model into an item model, and I might as
> well use the QStandardItemModel or at least QAbstractItemModel to begin
> with.
>
> Does that sound about right?
>
>
> Bo, reading your reply makes me feel like I should keep playing with
> QAbstractTableModel (or QAbstractItemModel) and write all the behaviour I
> need from QStandardItemModel myself?
> I feel like the item based approach is handier as I can subclass a
> QStandardItem and give it a reference to the external object it represents,
> then have the data read/write from/to that.
> I don't think I get that with a table model unless I re-invent the wheel.
>
> Any thoughts on the above?
>

First of all: Take this with a grain of salt, I haven't written a custom
item model since a few years now and have also not kept up to speed with
changes in the QStandardItemModel.

One thing to keep in mind with the item model is that it requires to create
an object for each and every item. That onehas a another object as
d-pointer which then has a bunch of member variables that also need memory.
So depending on what you use from it and how many items you have, your
memory footprint increases quite a bit without providing anything that you
actually use.

The idea with the custom model is that you only have the data in memory
that is really 'stored' and you calculate everything for the view on the
fly (like colors etc.) from this bare minimum of data. So the memory
footprint can get smaller with this - especially with a huge number of
items - but of course it means access to the data must be fast. Or you need
to consider to cache some (but not all) of the data 'up front' to make it
seem fast (I think this happens - behind the scenes - with sql table models
based on queries).

You could still benefit from imlementing a custom model event if it
replicates some of the item model's logics. If the struct you use for
storing the attributes to be returned from data() is considerably smaller
than the qstandarditem class your overall memory footprint might decrease
while the performance is kept at par with the standard item model.

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

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Stephen Kelly]

Bo Thorsen wrote:
> To me QStandardItemModel is a quick hack I sometimes use when I just
> want to show a bit on the screen. But those temporary things have a
> tendency to stick around, and at some point I always end up rewriting
> the stuff with the real thing.

Me too. I only ever use QSIM in test code to provide 'fake data'.

Thanks,

Steve.


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

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Frank Rueter | OHUfx]

Thanks Andreas, that all makes sense.
Will give the more manual approach some more attention.

Cheers,
frank

On 14/01/16 12:00 pm, Andreas Pakulat wrote:

Hi,

On Wed, Jan 13, 2016 at 11:07 PM, Frank Rueter | OHUfx 
mailto:fr...@ohufx.com>> wrote:


Thanks Bo,

when you say "it's bad in so many ways", are you referring to
performance?

I just realised that my last conversation with Jason had dropped
the CC to the list, so here it is again :

so a few lines into the new code and I believe I'm starting to
realise that QAbstractTableModel is the wrong choice for me,
let's see if I get this right:

I need each cell to:

  * store a reference to a custom object in the host application
  * get it's background and foreground colour from the host
application's object
  * determine the right delegate output based on the data
type/ external object class
  * drive the external object's value upon datatChanged
  * etc.

When I got as far as implementing the background role in my
QAbstractTableModel's data method, the resulting view took
about 4 seconds to resize, while scrolling left me with the
ol' spinning beach ball (OSX).
The same code utilising QStandarItemModel reacts
instantaneously without trouble, even with way more data.

I suppose this is because I am storing those object references
in each QStandarItem as I construct the data when using
QStandarItemModel. So later on, those values are readily
available within my data model.
When putting those references into QAbstractTableModel.data(),
they are constantly called upon as the view changes, causing
the massive slow down.

In order to keep the view fast, I need to refactor my code and
somehow store the custom data only once, so things like
background colour etc. are determined within my model's data
when needed, rather than having to call the host application
constantly to retrieve the same info.
Which essentially turns the table model into an item model,
and I might as well use the QStandardItemModel or at least
QAbstractItemModel to begin with.

Does that sound about right?


Bo, reading your reply makes me feel like I should keep playing
with QAbstractTableModel (or QAbstractItemModel) and write all the
behaviour I need from QStandardItemModel myself?
I feel like the item based approach is handier as I can subclass a
QStandardItem and give it a reference to the external object it
represents, then have the data read/write from/to that.
I don't think I get that with a table model unless I re-invent the
wheel.

Any thoughts on the above?


First of all: Take this with a grain of salt, I haven't written a 
custom item model since a few years now and have also not kept up to 
speed with changes in the QStandardItemModel.


One thing to keep in mind with the item model is that it requires to 
create an object for each and every item. That onehas a another object 
as d-pointer which then has a bunch of member variables that also need 
memory. So depending on what you use from it and how many items you 
have, your memory footprint increases quite a bit without providing 
anything that you actually use.


The idea with the custom model is that you only have the data in 
memory that is really 'stored' and you calculate everything for the 
view on the fly (like colors etc.) from this bare minimum of data. So 
the memory footprint can get smaller with this - especially with a 
huge number of items - but of course it means access to the data must 
be fast. Or you need to consider to cache some (but not all) of the 
data 'up front' to make it seem fast (I think this happens - behind 
the scenes - with sql table models based on queries).


You could still benefit from imlementing a custom model event if it 
replicates some of the item model's logics. If the struct you use for 
storing the attributes to be returned from data() is considerably 
smaller than the qstandarditem class your overall memory footprint 
might decrease while the performance is kept at par with the standard 
item model.


Andreas


--
ohufxLogo 50x50  	*vfx compositing 
 | *workflow customisation 
and consulting * *


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

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Frank Rueter | OHUfx]

Thanks Bo,

I made some progress with QStandardItemModel, an d will try to pull even 
with the QAbstractTable model approach, hopefully that will help getting 
a feeling for it all.


>>If you have performance issues with a QAbstractTableModel over a 
QStandardItemModel, you're doing something >>wrong.
In my case I definitely did by putting all the calls to the external 
objects int' the data() method. I will rework this to prepare all that 
up front and make the required data accessible to data().


Cheers,
frank

On 14/01/16 11:46 am, Bo Thorsen wrote:



Den 13-01-2016 kl. 23:07 skrev Frank Rueter | OHUfx:

Thanks Bo,

when you say "it's bad in so many ways", are you referring to 
performance?


I just realised that my last conversation with Jason had dropped the CC
to the list, so here it is again :

so a few lines into the new code and I believe I'm starting to
realise that QAbstractTableModel is the wrong choice for me, let's
see if I get this right:

I need each cell to:

  * store a reference to a custom object in the host application
  * get it's background and foreground colour from the host
application's object
  * determine the right delegate output based on the data type/
external object class
  * drive the external object's value upon datatChanged
  * etc.

When I got as far as implementing the background role in my
QAbstractTableModel's data method, the resulting view took about 4
seconds to resize, while scrolling left me with the ol' spinning
beach ball (OSX).
The same code utilising QStandarItemModel reacts instantaneously
without trouble, even with way more data.

I suppose this is because I am storing those object references in
each QStandarItem as I construct the data when using
QStandarItemModel. So later on, those values are readily available
within my data model.
When putting those references into QAbstractTableModel.data(), they
are constantly called upon as the view changes, causing the massive
slow down.

In order to keep the view fast, I need to refactor my code and
somehow store the custom data only once, so things like background
colour etc. are determined within my model's data when needed,
rather than having to call the host application constantly to
retrieve the same info.
Which essentially turns the table model into an item model, and I
might as well use the QStandardItemModel or at least
QAbstractItemModel to begin with.

Does that sound about right?


Bo, reading your reply makes me feel like I should keep playing with
QAbstractTableModel (or QAbstractItemModel) and write all the behaviour
I need from QStandardItemModel myself?


Well, you almost already answered the question yourself. It's obvious 
your access from data() the real model is where the problem lies.



I feel like the item based approach is handier as I can subclass a
QStandardItem and give it a reference to the external object it
represents, then have the data read/write from/to that.
I don't think I get that with a table model unless I re-invent the 
wheel.


MyObject** references;

Can't be much faster than that.


Any thoughts on the above?


To me QStandardItemModel is a quick hack I sometimes use when I just 
want to show a bit on the screen. But those temporary things have a 
tendency to stick around, and at some point I always end up rewriting 
the stuff with the real thing.


If you have performance issues with a QAbstractTableModel over a 
QStandardItemModel, you're doing something wrong.


I think the only place where I might use a QStandardItemModel for 
something real is if you have a static set of information that you 
just need to show. If it never changes, then it's an easy model to use.


At the DevDays in 2006 (I think) I did a presentation on the model 
view classes. I basically told everyone that QStandardItemModel is the 
path to the dark side there as well. And one of the Trolltech guys 
came up and we had an interesting discussion about it. He did argue 
that sometimes there are cases where this makes sense.


But I'm biased. I hate that class and I really like the table and list 
model classes.


Bo.


On 13/01/16 10:27 pm, Bo Thorsen wrote:

Hi Frank,

Den 12-01-2016 kl. 22:40 skrev Frank Rueter | OHUfx:

I just joined this list so hello everybody.
I'm using QT via PySide mainly to create tools for vfx workflows and
custom tools for the software Nuke.

I'm not a programmer by trade, more of a vfx artist and technician 
using

Python/PySide to enhance pipelines and workflows for myself and other
companies.
Currently I am writing a custom spreadsheet that will need many custom
ItemDelegates and a controlled way of data input/output when a cell's
data is changed.
I will also need to write a feature that allows for multiple cells 
to be

changed at the same time (haven't got that far yet though).

The am

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[André Somers]

Op 14/01/2016 om 01:08 schreef Stephen Kelly:

Bo Thorsen wrote:

To me QStandardItemModel is a quick hack I sometimes use when I just
want to show a bit on the screen. But those temporary things have a
tendency to stick around, and at some point I always end up rewriting
the stuff with the real thing.

Me too. I only ever use QSIM in test code to provide 'fake data'.

As do I, but I do find it an improvement over using the Widget variants 
of the views...


André

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

[Interest] Text mode/hex mode for opened file

[Igor Mironchik]

Hi,

Is it possible to switch from text mode to hex mode in the QtCreator's 
editor and vice versa?


I have text file: "test.gen" and it opens in hex mode. How can I switch 
to text mode?


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