(PyQt) General Model/View complexity question...

[jkrienert]

Currently at a fork in the road as far as allocating a highly variable model/view build.

Several QMenus all trigger a singular model/view; within which are relativistic formatting parameters
determined by a indication string detailing the type of model/view needed (included w/the button trigger).

While things run 'fine' at current, I have some concerns about moving the design beyond the bench - and making it available to new users. In that, will this manner of condensed capability result in errors down the road?

As broad as the question may be, I feel I can narrow it best by the following:

Is a multi-tool or swiss-army-knife style (as far as capabilities within a single model/view) acceptable?
Or is it idealized to divide each particular model/view format into its own module (*.py file)?

Best thanks,

[neuronet]

It would really help to have a much more specific question: yours is so general it is very hard to interpret what you are asking.

To the extent I get your question, I think you probably want to frame it not about how many .py files you need, but how many different classes you need, and the interface you provide to the user to access those classes. But without more details it is impossible to tell. For instance, what kind of model is it (tree/table/list) and how do you want to display it? What classes are you subclassing?

[jkrienert]

Your right (neuronet), I could definitely bring more details in...

Working with a [QtableView]<===>[QAbstractItemModel] framework.

On the organizational aspects:
External to this, I have 3 buttons which each send a unique signal upon calling the model/view framework.
These signals act as strings for establishing many if/else statements within the table-model for formatting.
By format - the changes are somewhat extensive; button function and position, signals-slots, colorations, ect.

On the Class structure:
As far as a literal count, There are only three classes in the module (*.py file); the main QtableView, a
sub-classed delegate for read-only parameters, and the QAbstractTableModel. Perhaps if I had a greater
expertise in writing script - there would be more (or less?), but as is - it works relatively well.

Other thoughts:
My looming concern is if its generally seen as improper to type-format a model/view, rather then just
having several altered duplicate model/views.
All-this might be over analytical, and therefore possibly unwarranted. - but I just hope to make the user happy.

[neuronet]

If I understand, you are wondering if for each format change (or certain subsets of format change) you would want a new model or a new view. That seems like overkill and would lead to way much code reduplication. There are people here with much better knowledge than me, but it sounds like you are doing it right. Now if I had a tree versus a table or something, then of course I would use different views. But it doesn't sound like that, it sounds like a simple case of giving the user a table with tons of formatting options.

I would probably set it so when the user first launches the app I open a dialog to select their formatting from the start. Then it opens with those settings, next time and then just give them a single button to press whenever they want to bring up that dialog again. ONce their table is open, you could have this dialog be selection-specific (so they can change the format of a row, column, etc), providing a way to deviate from the default they set on program startup.

[jkrienert]

Thanks for the feedback neuronet!

Your elaboration (second paragraph) follows some of what is currently done; in a bit different manner:
From the Qtoolbar in an application, there are 3 button choices - one for each table formatting type (as mentioned earlier). Once the formatted-Table opens and is edited
as needed, the 'apply' button is pressed to save changes to the data-source before closing.
It seems like this might workout as is, but there is something else (related) I am wondering...


There is a processing algorithm function available as a button in one of the table views. Its output over/writes a (*.csv) which is advertently the data-source of another of
the 3-table types.
Here is the catch... I have been looking for documentation or possibilities to establish the following; a signal - slot situation between these two related tables.
Wherein once the algorithm completes, if both table type windows are open the one resourcing this algorithm's output CSV would be automatically reloaded.

Is this a possibly functionality?

[d_stranz]

It seems like what you are describing is an excellent use case for proxy models. Unless your formatting logic is so complex that the differences between the three states triggered by the buttons can't be split into three unique proxies, then I would implement this as a core QAbstractItemModeland 3 proxies derived from QAbstractProxyModel, one for each format. It the content remains the same, you could use QIdentityProxyModel and save a little work.

I don't understand what you are trying to decribe with the CSV file being the source of the information in the table view. I suspect you have your thinking cap on sideways.

When the user clicks the button that updates the calculated results, then the results should be updated in the source model used by the table views. To update the CSV file, create a separate class that connects to the modelReset() signal for the source model, and have that class write out the CSV file. There is no need to implement some kind of complicated round-trip write/read scenario. Treat the CSV file as just another "view" onto the source model; it just happens to be a persistent one stored on disk. Just be sure to use the beginModelReset() / endModelReset() methods when you update the source model, and all of the "views" will update themselves accordingly.