@Marcus, I think I had just read his description from a different angle as you did. In the first post, he didn't mention how the model was being edited. Then his follow up to your reply described "editable fields". To me, I just took that as the tree view being modified and he was refreshing everything based on that. But I think you interpreted it as another view changing the data to which the tree view then needed to be refreshed.
I definitely agree that if you are showing multiple views onto the data, then the model/view approach would make that easier. Like Marcus said, editing one view would drive changes in another view that share the same model. QTreeView doesn't deal with "items" in the way the higher level widget does. In the higher level approach, the abstraction is that each item completely represents its own little data container. In QTreeView, it is meant to sit on top of a model and just handle user interactions and send/receive interactions to the data model. The next step down from QTreeWidget is to use QTreeView and a QStandardItemModel, which still maintains that item-based approach, where you do those operations on the model (not the view). Then the next step down from there is an QAbstractItemModel, where you don't deal with individual items representing their data, but rather define in the model exactly how to access the underlying data. That is, given some row/column/parent, what data should be returned for what role? The item-based abstraction is gone. Justin On Thu, Apr 16, 2015 at 9:04 AM Ben Hearn <[email protected]> wrote: > Thanks again for some solid info Marcus and Justin. I have been thinking > about how to solve this and did not think to update the current item. I > think this would be a good approach to go on as it would keep my current > hierarchy as it is. The other approach to completely refreshing the tree > widget would be to store the hierarchy in a dictionary of lists, For > example root-child-sibling-last item if said last items parent is expanded > > I think I will try to implement an update on the current item and save a > full refresh for a different case. > > As per implementing a tree view with models what does this mean exactly, > is the model itself the type of data passed into the tree view. If a tree > widget takes a tree widget item as an item type, would you be passing in an > abstract model item for example as an item i.e. > QTreeView.append(QAbstractModelItem) > > Cheers, > > Ben > > > On Wednesday, 15 April 2015, Marcus Ottosson <[email protected]> > wrote: > >> It depends. >> >> The current outcome could potentially never have been a problem to begin >> with if the view simply represented the same data between being refreshes. >> This was at least my motivation for suggesting it in the first place. >> >> Spontaneously, I'm thinking that the XML hierarchy would be parsed into >> an object hierarchy which would be directly represented by the view. The >> view and model would inherently support being edited and any ad-hoc >> solutions would become superflous. >> >> The problem the OP is having basically sounds like what the item views >> were designed to solve and I'd think it would consume more time and effort >> to try and re-implement it on top of convenience objects. >> >> I couldn't say for sure. It's merely an observation based on the >> information I got. >> >> Best, >> Marcus >> >> On 15 Apr 2015, at 21:25, Justin Israel <[email protected]> wrote: >> >> Switching to a view/model is not going to change the outcome of the >> current approach. Clearing the data is still clearing the data. QTreeWidget >> is a subclass of QTreeView with a built in model. You could use >> QPersistentModelIndex, and get the model from the widget with model(), but >> if you clear it, then the index will invalidate anyways. >> >> There are two approaches you could take. One would be to change how you >> handle updates to data and not respond by clearing the whole model, but >> rather to update data for what has actually changed, and add and remove >> items. It would be the same with a view/model, except you would be handling >> the changes from the model instead of the widget. Then persistent model >> indexes would also work. >> >> Or you could continue dumping and rebuilding every time, but store some >> kind of unique reference as data on each item so that you can save it >> before clearing, and check for it when you restore. Maybe some kind of xml >> path. If there is no unique type of identifier that you can associate with >> each item in reference to the xml, then you probably don't have a choice >> but to be more granular with how you manage the changes to your data. >> >> Justin >> >> On Thu, 16 Apr 2015 5:00 AM Marcus Ottosson <[email protected]> >> wrote: >> >>> The strength of widget views in general is that they are very easy to >>> get started with compared to item views, but fall short in more complex >>> use-cases. >>> >>> It does sound like you would be better off with an item view, however >>> whether or not it's viable to switch is mostly a matter of how much further >>> you intend on extending and maintaining your current implementation. It's >>> quite likely that you are at a point where the amount of work involved in >>> adding new functionality requires an exponentially increasing amount of >>> work to get done due to having to fight the convenience provided by the >>> widget view, and jidging by your example I'd say that this seems to be the >>> case. On the other hand, if you're close to finishing and don't think it >>> will need much maintenance once done then it's questionable whether the >>> effort is worth it. >>> >>> Item views are undeniably more complex than their widget counterparts >>> but their complexity is really only a reflection of how complex the data >>> you're working with really is, and hierarchical data especially is amongst >>> the most complex data there is. >>> >>> To put an analogy on your problem, you've been working with Microsoft >>> Movie Maker and are looking to do things that Nuke has no problem doing. Do >>> you learn Nuke, or find ways around the problem in Movie Maker? >>> >>> On 15 Apr 2015, at 17:17, Ben Hearn <[email protected]> wrote: >>> >>> I am representing XML data in a tree view and enabling the editing of >>> this XML data, when the user changes some data in the editable fields the >>> view is then updated to represent this new data. >>> >>> I have not used QTreeView or any model information yet. Are there any >>> huge differences with adding items and editing them? Also is there that >>> much of a benefit in switching from QtTreeWidget especially since I am >>> quite a leap into the project at current. >>> >>> >>> On 15 April 2015 at 17:37, Marcus Ottosson <[email protected]> >>> wrote: >>> >>>> Without fully understanding what you're up to, you may be better off >>>> with a QTreeView and QAbstractItemModel. The model would keep track of >>>> hierarchy, and your view simply represent it. Thus if you refresh the view, >>>> the data remains the same and if you change the data, the view updates >>>> accordingly. >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "Python Programming for Autodesk Maya" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/python_inside_maya/SR3v1N1zYuc/unsubscribe >>>> . >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD_M7Myk_4LXkgGn-QWtum53FjsAYQQVMg_ii5y1_eJvQ%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD_M7Myk_4LXkgGn-QWtum53FjsAYQQVMg_ii5y1_eJvQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> >>> Tel - +46 76245 92 90 (Sweden) >>> LinkedIn: http://www.linkedin.com/pub/ben-hearn/50/a64/33b >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/CAM2ybkUwuA5Z00taxccfLUnZaUeKBgjRbdqKpu-%2BGaNE7TDWLA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAM2ybkUwuA5Z00taxccfLUnZaUeKBgjRbdqKpu-%2BGaNE7TDWLA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/4EF72B65-6EE8-4D48-9BAE-B7CF2644F877%40gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/4EF72B65-6EE8-4D48-9BAE-B7CF2644F877%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3K0eHy95GbUb_utvKCxiNyGOyjbbLM5GLNgR798-tynw%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3K0eHy95GbUb_utvKCxiNyGOyjbbLM5GLNgR798-tynw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Python Programming for Autodesk Maya" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/python_inside_maya/SR3v1N1zYuc/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/51B61068-5567-47CE-BB5E-13EA899DEA54%40gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/51B61068-5567-47CE-BB5E-13EA899DEA54%40gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > > Tel - +46 76245 92 90 (Sweden) > LinkedIn: http://www.linkedin.com/pub/ben-hearn/50/a64/33b > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAM2ybkXE9mJKTDeu9VAe4eE%2Bb%2BwtPV8KTL4sz6SFWpY%2BV6K-7w%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAM2ybkXE9mJKTDeu9VAe4eE%2Bb%2BwtPV8KTL4sz6SFWpY%2BV6K-7w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0Q2q49494cujMbnQ93mTqk5-SGy7uK%3Dx-QozVyXwFB%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
