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

[François KUBLER]

Thanks a lot your answer !

Just to be sure I've understand, I should basically :

- Build a custom QEvent, let's say "ItemClickEvent", with a "data"
property,
- Set my QListView to accept "ItemClickedEvent",
- Connect the QAbstractView::clicked ( const QModelIndex &index ) signal
to a custom slot (which I already do),
- Add a transition from my source state to my targeted state when the
ItemClickedEvent occurs (using a QEventTransition),
- In my custom slot, instantiate my ItemClickedEvent class, set its "data"
property to whatever I need, and send the Event via
QCoreApplication::notify(),
- And finally, use the event handed to my target state onEntry() method.

(I tried something quite similar, but, instead of sending a QEvent, I
tried to send a custom signal -and it didn't work-.)

Thanks again for your help, I really appreciate it !

-- 
François




On Fri, 6 Aug 2010 08:59:55 -0400, "K. Frank" <kfrank29.c at gmail.com>
wrote:
> 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
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest