[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: QTableView from model
From: Maurizio Berti <maurizio.berti () gmail ! com>
Date: 2023-09-11 3:34:54
Message-ID: CAPn+-XQzp_k7nkqY0UmrHQaREFqOf=SqucrjOy7TSBfBvE1sHg () mail ! gmail ! com
[Download RAW message or body]
Adding further insights to what Baz correctly pointed out.
First of all, models should know **nothing** about the views connected to
them. That's not their responsibility and their behavior should not change
depending on it (do some research about encapsulation and separation of
concerns). That's important, since models could be shown in multiple and
very different views (or not even shown at all): they should work
transparently and consistently, in any case.
So, in principle, there is no direct nor immediate way for a model to know
the view(s) it's been shown, because there shouldn't.
If the model needs to know the views that are connected to it in order to
work properly, 99% of the time it's because important concepts behind the
program are poorly implemented (simply put: you're doing the wrong thing
for the wrong reasons).
If different views have to respond differently to what the same model
returns, then you probably need proper item delegates, as that's their
purpose. *Then* you could eventually implement some custom functions in the
model that may return specific data based on the circumstances, but it's
still a matter of responsibilities that the model shouldn't immediately be
aware of, at least in its basic implementation.
Still, there may be some fringe situations: I cannot think of reasonable
ones right now, but I'm thinking about the parallel of graphics scenes (and
their items), which sometimes *do* need to know the paint device (or the
view) they're being shown.
If you really need that, then just implement it in your views and models:
override `setModel()` (or implement a related function) for the view and
add related support in a model subclass, so that it keeps track of the
views it's been set. For safety reasons, you should also ensure that you
connect the view's destroyed signal in order to remove any reference for
deleted views.
But, as said, that shouldn't be necessary, and if you think that you need
it then think twice, because you're probably doing it for the wrong reason.
Regards,
MaurizioB
Il giorno dom 10 set 2023 alle ore 16:59 Glenn Holmer <cenbe@protonmail.com>
ha scritto:
> Is there any way to get a reference to a table model's table (from the
> model)?
>
> --
> Glenn Holmer (Linux registered user #16682)
> "After the vintage season came the aftermath -- and Cenbe."
>
>
--
È difficile avere una convinzione precisa quando si parla delle ragioni del
cuore. - "Sostiene Pereira", Antonio Tabucchi
http://www.jidesk.net
[Attachment #3 (text/html)]
<div dir="ltr"><div><div><div>Adding further insights to what Baz correctly pointed \
out.</div><div><br></div><div>First of all, models should know **nothing** about the \
views connected to them. That's not their responsibility and their behavior \
should not change depending on it (do some research about encapsulation and \
separation of concerns). That's important, since models could be shown in \
multiple and very different views (or not even shown at all): they should work \
transparently and consistently, in any case.</div><div><br></div><div>So, in \
principle, there is no direct nor immediate way for a model to know the view(s) \
it's been shown, because there shouldn't.<br></div><div>If the model needs to \
know the views that are connected to it in order to work properly, 99% of the time \
it's because important concepts behind the program are poorly implemented (simply \
put: you're doing the wrong thing for the wrong reasons).</div>If different views \
have to respond differently to what the same model returns, then you probably need \
proper item delegates, as that's their purpose. *Then* you could eventually \
implement some custom functions in the model that may return specific data based on \
the circumstances, but it's still a matter of responsibilities that the model \
shouldn't immediately be aware of, at least in its basic \
implementation.<br><br></div>Still, there may be some fringe situations: I cannot \
think of reasonable ones right now, but I'm thinking about the parallel of \
graphics scenes (and their items), which sometimes *do* need to know the paint device \
(or the view) they're being shown.<br></div><div>If you really need that, then \
just implement it in your views and models: override `setModel()` (or implement a \
related function) for the view and add related support in a model subclass, so that \
it keeps track of the views it's been set. For safety reasons, you should also \
ensure that you connect the view's destroyed signal in order to remove any \
reference for deleted views.</div><div><br></div><div>But, as said, that \
shouldn't be necessary, and if you think that you need it then think twice, \
because you're probably doing it for the wrong \
reason.</div><div><br></div><div>Regards,</div><div>MaurizioB<br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno dom 10 set 2023 alle \
ore 16:59 Glenn Holmer <<a \
href="mailto:cenbe@protonmail.com">cenbe@protonmail.com</a>> ha \
scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is there any way to \
get a reference to a table model's table (from the <br> model)?<br>
<br>
-- <br>
Glenn Holmer (Linux registered user #16682)<br>
"After the vintage season came the aftermath -- and Cenbe."<br>
<br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- \
</span><br><div dir="ltr" class="gmail_signature">È difficile avere una convinzione \
precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", \
Antonio Tabucchi<br><a href="http://www.jidesk.net" \
target="_blank">http://www.jidesk.net</a></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic