[Qt-interest] Several problems (QState, QToolBar, QFileIconProvider, stylesheets...)

[K. Frank]

Hi François -

2010/8/6 François KUBLER <francois at kubler.org>:
> Hi guys,
>
> I'm not really used to beggin' for help but I'm stuck with some problems
> related to Qt.

Beg away!  I do all the time...

>
> 1. Regarding QState + signal/slot :
>
> As you can see on the screenshot, I have a QListView. This screen
> corresponds to a QState that I called 'listState'. I have another state
> which is called 'playerState' where the screen is a video player. The
> problem I have is to switch from the 'listState' to the 'playerState' when
> I click on a list item.
>
> The important fact in this transition is that the playerState needs to
> know what item has been clicked.
> I played around with the QAbstractView::clicked ( const QModelIndex &
> index ) signal and it works quite well.

Using state-machine techniques, the usual way to handle such a
requirement is to have the event that triggers the transition carry
some "event data."

In your case, your state machine is in its 'listState' and an
event -- call it ItemClickedEvent -- triggers the transition to the
'playerState.'  The instance of ItemClickedEvent can carry
event data -- some handle to the clicked item (for example, the
index of the row clicked) -- as a public data member or as a
property with a getter method.

In the Qt state-machine framework, the event that triggers
the transition is handed to the new state's onEntry function.
So your 'playerState' gets the event on entry, and can query
its event data to discover which item was clicked.

> My problem is that I can :
> - add a transition to the 'playerState' using the QState::addTransition (
> QObject * sender, const char * signal, QAbstractState * target ) method
> with the clicked signal,
> - OR retrieve the QModelIndex representing the clicked item using a basic
> SIGNAL/SLOT connection.
> But I need both !

(I'm not sure what you mean by "needing both.")

In any event, there shouldn't be a need to get the item index after
the fact -- i.e., after you've made the transition to 'playerState.'
It just seems to complicate the design.  The usual state-machine
approach of having the the event carry that information as some
sort of event data gives you the information when you need it, and
seems like it should work fine for what you're doing.

(As always, there are many, many ways to achieve your end goal.
You could, for example, query a global variable.  But when using a
state machine, having the event carry the information as event data
is the "natural" approach.)

> I tried several things to do that without success (I can describe them if
> you want, or even post code).
> Is there a way to do that ? What am I missing ?

If I've misunderstood what you are trying to accomplish, please
ask some follow-up questions and post some example code.

> ...
> I know it's a long email so please accept my apologies if it's not the
> place to ask that kind of questions.

This is the right place to ask these questions, although sometimes
it's easier for the list if you ask unrelated questions in separate posts.

> Thanks a lot for your help, hints or ideas,
> --
> François

Good luck.


K. Frank