Salut 4ian,
J’ai récemment fait des tests de l’extension Widgets sur Game Develop Linux (celle que tu as fournis à Darkhog et qui est indépendante de la distribution).
Le problème, l’extension semble ne pas récupérer les événements de la SFML.
Il doit y avoir un problème avec Scene::GetRenderTargetEvents().
D’ailleurs, (est-ce lié) la version compilée d’un de mes tests de l’extension Widgets semble planter (la fenêtre reste mais est vide).
Merci d’avance.
Bizarre, il n’y a pourtant rien de spécial là dedans.
D’autres tests fonctionnent eux ?
Pour compiler, tu as linké à libgdl.so ?
Apparemment, d’après les derniers tests, je capte pas les clics (sf::MousePressed) mais je capte bien les autres événements de mouvement de la souris.
Un exemple de gestion des événements (la fonction WidgetsCommonTools::GetViewsPosition permet de convertir les coordonnées par rapport à la fenêtre en vraies coordonnées) :
https://github.com/victorlevasseur/Widgets-Extension/blob/master/src/textbox/TextAreaObject.cpp (dans la fonction UpdateTime(float))
Si tu pouvais tester l’extension (télécharge la dernière version du git, libsfgui.so est inclus dans extlibs/SFGUI/lib, il faut surtout pas linké avec le .a qui est pour Windows mais bien avec le .so). 
J’ai testé et en effet j’arrive pas à faire bouger une glissière. En fait, j’ai testé aussi avec l’expression qui renvoie le déplacement de la molette de la souris ( La fonction utilise getRenderTargetEvents() ) et celle ci renvoie toujours 0.
Ce serait dû à la SFML ?
Faudrait peut-être faire des tests de la SFML sans Game Develop.
J’ai testé avec l’exemple Pong de SFML, j’ai pas d’évènements capté lors des clics de souris ni mouvement de la molette. ( Mais lors du déplacement de la souris oui ). Ca semble être un bug de SFML, mais peut être que ça a été corrigé depuis.
En même temps, un bug aussi gênant a peu de chance d’être resté longtemps. T’as juste téléchargé la SFML le mauvais jour 
.
La version définitive de la sfml2 ne devrait plus tarder : Laurent refait l’api de la gestion du temps et change totalement les conventions de nommage de la SFML (heureusement que le chercher/remplacer existe 
), ensuite elle serait prête
D’un autre coté, c’est pas le genre de truc qu’on teste souvent, car pour la souris on utilise plutôt sf::Mouse.
Je viens d’aller faire un tour sur le forum de SFML, il faudra en effet aussi mettre à jour tout les noms de fonctions, mais bon, avec la nouvelle API graphique, j’ai déjà prévu de devoir faire de l’adaptation un jour ou l’autre. Ça permettra de refaire un petit tour dans le code à des endroits où je vais pas souvent 
.
Pour notre problème ici, j’ai pourtant pas vu d’indications d’un correction liée à ça dans les commits… Je vais tester sur une version récente si le problème est toujours là pour être sûr.
Ce qui me parait d’autant plus étrange, c’est que le développeur de SFGUI utilise Linux, et donc il aurait pu remarquer le bug.
Je disais n’importe quoi, en fait les évènements sont tous bien capturés quand je teste dans l’exemple Pong.
Par contre, ça ne marche plus quand je fais un test minimal avec wxWidgets+SFML. Je crains que çe soit le même problème qu’auparavant, avant que sf::Input ne soit transformé en sf::Mouse/sf::Keyboard : Les clics ne sont bizarrement pas capturés, ni les touches au clavier.
Ah, c’est emm**dant. 
Peut-être ont-ils une solution sur le forum de la SFML.
Est-ce que ça marche en mode “Aperçu dans une fenêtre ?” (tu utilises une sf::RenderWindow ?)
Non, c’est aussi une fenêtre wxWidgets avec un wxSFMLCanvas d’integré.
A mon avis ça vient de l’intégration de SFML, au niveau de wxSFMLCanvas, mais c’est pas d’un usage ultra répandu 