C'est techniquement possible, mais nécessite du travail dans le compositeur RDP. En gros, il faut y tracker les fenêtres. Je vois comment faire, mais doute avoir le temps durant les prochains semaines.
En attendant, une solution de contournement est d'utiliser ce hack. La mise en place est plus lourde, mais le résultat visuel proche.
Je viens de discuter avec les gens de FreeRDS, cela devrait. Cependant j'avoue n'avoir testé que le compositeur RDP de Weston pour l'instant (je ne sais pas builder ni utiliser FreeRDS). Un retour là-dessus serait donc utile.
Y a pas de problème :-), de toute façon on n'y peut pas grand-chose car le nom était plus ou moins "forcé" (xfreerdp pour X11, wfreerdp pour Windows…). Mais je peut garantir que je maintiendrai ce code et qu'il ne partira pas en roue libre !
L'implémentation actuelle du compositeur RDP ne peut pas faire de "vrai" seamless car elle n'interagit pas avec le shell/window manager pour cibler la fenêtre qui nous intéresse. Je suis cependant certain qu'on peut le modifier pour ça devienne possible.
Fullscreen-shell est un shell alternatif poussé par Jason Ekstrand, qui se builde avec --enable-fullscreen-shell et s'utilise avec --shell=fullscreen-shell.so. Il a la particularité de n'avoir aucune interface et de n'afficher qu'une surface à la fois, sur fond noir, comme quand on passe en mode "fullscreen" (F11) dans weston-terminal p.ex. Les applications doivent le gérer, mais toutes celles intégrées à Weston ont déjà été adaptées.
Je suis incapable de t'en faire une vidéo maintenant car mes installs sont custom, mais je vais voir.
Oui le backend RDP marche bien, voilà une vidéo sous Tizen et voilà comment l'utiliser. Tu remarques que les applis GL marchent, car j'ai ajouté le support Gallium qui "pipe" le calcul en mode software.
Pour l'instant le hack consiste à faire ainsi :
compiler fullscreen-shell et le compositeur RDP ;
lancer le compositeur RDP avec fullscreen-shell ;
lancer une application dans ce compositeur, elle sera fullscreen ;
se connecter à partir de xfreerdp.
Cela revient à dire : 1 compositeur = 1 appli. On pourrait bien sûr automatiser ces étapes avec des scripts et hacks.
Pour l'instant, tout le bureau ; mais en utilisant fullscreen-shell (qui met une seule appli en plein écran à la fois) on obtient plus ou moins l'effet souhaité.
Weston fournit une interface non-standardisée pour les captures d'écran ; les développeurs déconseillent de l'utiliser jusqu'à ce qu'une décision soit prise sur une éventuelle standardisation liée à l'aspect sécurité (une appli capable de faire des screenshots pourrait voler des numéros de carte bancaire, etc…).
Il faudra simplement m'expliquer comment créer les paquets pour chaque librairie.
Les paquets sont "assemblés", un peu de manière manuelle, via des scripts disposés sur la machine de build chez GNOME. Je vais essayer de te les récupérer, mais avec le temps libre dont je "dispose" je m'engage pas sur le timing.
Par contre, fournir une aide pour corriger les très nombreux (si, si !!!) bugs (mineurs) sous Windows est une autre affaire.
Bien d'accord. Perso mon principal problème était que l'entretien du build system devenant de plus en plus compliqué, et que par ailleurs les bugs s'accumulant, mon temps libre devenant plus réduit, le jeu n'en valait plus la chandelle.
Généralement, trouver comment corriger un de ces bugs me prend au minimum une demi-journée
Pareil ici, et même pire parfois (les bugs de police -Cairo- notamment).
Par contre, je n'ai pas réessayé depuis si la librairie compile sous Win64 depuis MinGW.
GTK+ ne marche pas bien dans ReactOS, car le support des polices via Cairo y est cassé. J'ai identifié le problème la semaine dernière et commencé un patch, mais ça m'a pris des heures, et au final j'ai pas pu terminer avant que mon travail me "remange" mon cerveau. Mes découvertes sont dispo pour qui pense avancer avec.
Il faudrait surtout que GTK de façon générale recommence à envoyer du rêve
Moi ce qui à l'époque m'avait fait tripper, c'était Broadway. Et effectivement, ça y est ça marche, on pourrait faire fonctionner GIMP-LibreOffice-etc en cloud avec ça. Il fait juste le polir, notamment pour supporter l'authentification et le multi-session.
Qt à la bouche, qui pourtant a l'énorme inconvénient d'être écrit en c++, ce qui rend les bindings vers les autres langages nettement plus compliqués.
Point important, merci de le souligner ! On peut très facilement faire du Python, Vala, PHP… avec GTK.
J'imagine que des sponsors de GNOME comme Red Hat ou Canonical ne désirent pas employer quelqu'un pour maintenir la version Windows.
Effectivement, ils n'y ont pas d'intérêt direct.
rétrocéder une partie, même faible, de leur donations au toolkit
Ce serait effectivement bien ; dans la pratique ça marche plutôt à sens unique, l'application utilise GTK+ et quand ce dernier ne fonctionne plus assez bien à son goût, elle migre vers un autre framework (Qt p.ex.) plutôt que de contribuer. Et une application de moins, ça signifie moins d'intérêt de la part des devs coeur, donc la qualité baisse encore… c'est un cercle vicieux.
Le choix de cairo s'est imposé naturellement pour ce que tu cherchais a faire ?
Oui, car c'est d'une part une dépendance de Weston (donc susceptible d'être déjà installée sur les systèmes du public "cible" de wlmessage), et d'autre part je le connaissais bien pour avoir déjà bossé avec GTK+.
C'est un portage de xmessage ou bien tu es reparti d'une page blanche sans trop regarder comment le truc de base était fait ?
Page blanche, j'avoue (rougit). J'ignore si j'aurais pu réutiliser un peu ou beaucoup.
Ça me semble pas forcement pertinent. Comment tu vas faire pour l'intégration du style?
Il n'y en aura pas, je pense. wlmessage gardera la même apparence partout.
Pourquoi ne pas faire une interface commune et 2 ou 3 backends (GTK 3.0/Qt et EFL) qui seront choisis au runtime?
Ça c'est une riche idée ! Et je pense que ça pourrait être un projet intéressant pour une personne désireuse de s'initier au monde des toolkits.
À titre personnel, je ne voulais pas le faire pour garder le côté "léger" du logiciel. Je vais sans doute finir par retirer la dépendance à la GLib p.ex. ; ça s'inscrit dans cette démarche.
Mais il est clair qu'ils n'ont pensé qu'à GNOME au moment de faire cette modification. Pour un toolkit/framework se voulant à une époque cross-plateforme, ça veut dire au mieux : "on a un boulot à faire sur GNOME, on y va en bourrins, si ça dérange quelqu'un il patchera derrière".
Le problème étant que les développeurs compétents ayant tous peu de temps, ils ont autant de chance de patcher que de switcher vers un toolkit concurrent qui ne leur fera pas le même coup à l'avenir…
C'est en fait l'application qui a été codée pour utiliser GtkHeaderBar ; ce nouveau widget remplace la barre de titre habituelle et jouant avec des "hints" du gestionnaire de fenêtres.
Le problème est effectivement que ça n'a pas de sens sous les DE non-GNOME, ni sous Win32, ni sous OS X. Or, depuis GTK 3.12 de mémoire, GtkHeaderBar est utilisé même par les applications de base :-|.
Une solution serait de patcher GtkHeaderBar pour avoir un comportement "natif" -en gros détecter qu'elle n'est pas sous GNOME, réafficher une barre native, et éventuellement dessiner ses widgets custom dans un espace en-dessous.. Mais j'ignore si ce serait accepté par GNOME.
Je viens d'essayer de le faire tourner sous Wayland, ça ne fonctionne pas (probablement parce qu'il y a bien plus que GTK+ dans le moteur de rendu Firefox, qui ne l'utilise peut-être que pour les widgets) :
export GDK_BACKEND=wayland
firefox-gtk3
Ici ça bloque sur la recherche d'un "display: :0".
Il est bien sûr possible que je me trompe ; dans ce cas faites signe !
Si j'étais lui, j'aurais juste envie de te dire d'aller te faire voir ailleurs et que si tu crache sur des débuts de solutions sans chercher à discuter t'as qu'à aller voir ailleurs puisque l'herbe y est si verte
Oh ça va, je prends pas ça tellement à coeur… Zenitram ;-).
Sinon, blague à part, je viens de finir de porter le code de GCR et Evolution vers win32. Ca veut dire qu'à l'exception du bureau lui-même, la quasi-totalité du framework est maintenant compilable pour cet OS.
Je repasse sur le toolkit, et en profite pour réitérer mon appel à contributions du côté Win32 et OSX.
Rien à faire des modules, dans Qt c'est une très simple commande et point barre.
OK, d'accord.
Tu pourrais au moins concéder une certaine honte a écrire ce qu'on t'as dit tellement c'est énorme comme réponse. Tu carricatures le journal sur la partie "l'attitude détestable des devs Gtk/GNOME".
Honte ? Et puis quoi encore ? Non mais faut pas exagérer, on parle d'un choix de design qui ne fait pas l'unanimité, pas d'un crime de lèse-UI :D.
Tu dramatises beaucoup tout ça… Moi ça ne me choque pas, parce que je n'en ai pas besoin (sinon je n'utiliserais pas GTK+) ; tu me poses une question, je vais te chercher la réponse, elle ne te convient pas, qu'est-ce-j'y peux ? Je ne suis pas d'accord avec tout ce que fait l'équipe non plus.
Le point principal est que si cela n'existe pas, il faut le créer. Qt (Digia) a un support dédié pour cela, GTK+ peut le faire d'un façon quelconque mais il n'y a pas de secret.
# Merci
Posté par Tarnyko (site web personnel) . En réponse au journal Les vidéos de la X.Org Developer Conference 2014 sont disponibles. Évalué à 2.
Très utile ; bravo, et merci Martin !
[^] # Re: Plus clairement ?
Posté par Tarnyko (site web personnel) . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 4.
C'est disponible depuis longtemps. Cette page et cette vidéo pourront te renseigner.
Le journal parle de la création d'un client Wayland ; c'est-à-dire, un "visualiseur" qui lui tourne sur Wayland à l'instar des versions X11, Android…
Oui. Il faut démarrer un compositeur par utilisateur.
Avec le compositeur RDP de Weston, non. Avec FreeRDS, peut⁻être, mais cela nécessite des informations (voir ci-dessus).
[^] # Re: un troll de moins ?
Posté par Tarnyko (site web personnel) . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 4.
C'est techniquement possible, mais nécessite du travail dans le compositeur RDP. En gros, il faut y tracker les fenêtres. Je vois comment faire, mais doute avoir le temps durant les prochains semaines.
En attendant, une solution de contournement est d'utiliser ce hack. La mise en place est plus lourde, mais le résultat visuel proche.
[^] # Re: FreeRDS
Posté par Tarnyko (site web personnel) . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 4. Dernière modification le 13 octobre 2014 à 15:14.
Je viens de discuter avec les gens de FreeRDS, cela devrait. Cependant j'avoue n'avoir testé que le compositeur RDP de Weston pour l'instant (je ne sais pas builder ni utiliser FreeRDS). Un retour là-dessus serait donc utile.
[^] # Re: Roue libre
Posté par Tarnyko (site web personnel) . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 7.
Y a pas de problème :-), de toute façon on n'y peut pas grand-chose car le nom était plus ou moins "forcé" (xfreerdp pour X11, wfreerdp pour Windows…). Mais je peut garantir que je maintiendrai ce code et qu'il ne partira pas en roue libre !
[^] # Re: triste
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
Oui, dans l'état actuel, c'est ça.
L'implémentation actuelle du compositeur RDP ne peut pas faire de "vrai" seamless car elle n'interagit pas avec le shell/window manager pour cibler la fenêtre qui nous intéresse. Je suis cependant certain qu'on peut le modifier pour ça devienne possible.
[^] # Re: triste
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 4. Dernière modification le 09 octobre 2014 à 16:19.
Fullscreen-shell est un shell alternatif poussé par Jason Ekstrand, qui se builde avec --enable-fullscreen-shell et s'utilise avec --shell=fullscreen-shell.so. Il a la particularité de n'avoir aucune interface et de n'afficher qu'une surface à la fois, sur fond noir, comme quand on passe en mode "fullscreen" (F11) dans weston-terminal p.ex. Les applications doivent le gérer, mais toutes celles intégrées à Weston ont déjà été adaptées.
Je suis incapable de t'en faire une vidéo maintenant car mes installs sont custom, mais je vais voir.
Oui le backend RDP marche bien, voilà une vidéo sous Tizen et voilà comment l'utiliser. Tu remarques que les applis GL marchent, car j'ai ajouté le support Gallium qui "pipe" le calcul en mode software.
Pour l'instant le hack consiste à faire ainsi :
Cela revient à dire : 1 compositeur = 1 appli. On pourrait bien sûr automatiser ces étapes avec des scripts et hacks.
[^] # Re: triste
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
Pour l'instant, tout le bureau ; mais en utilisant fullscreen-shell (qui met une seule appli en plein écran à la fois) on obtient plus ou moins l'effet souhaité.
[^] # Re: A noter: la release a été faite par Pekka Paalanen.
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 3.
Weston fournit une interface non-standardisée pour les captures d'écran ; les développeurs déconseillent de l'utiliser jusqu'à ce qu'une décision soit prise sur une éventuelle standardisation liée à l'aspect sécurité (une appli capable de faire des screenshots pourrait voler des numéros de carte bancaire, etc…).
Il devrait y avoir une discussion là-dessus cette semaine ;-).
[^] # Re: Enregistrements
Posté par Tarnyko (site web personnel) . En réponse à la dépêche La X.Org Developer Conference 2014 à Bordeaux. Évalué à 2.
Impeccable, bon à savoir :-).
En attendant de s'y retrouver ; bons préparatifs !
[^] # Re: Une bouteille à la mer
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 1.
Hello Bansan,
Je te remets !
Les paquets sont "assemblés", un peu de manière manuelle, via des scripts disposés sur la machine de build chez GNOME. Je vais essayer de te les récupérer, mais avec le temps libre dont je "dispose" je m'engage pas sur le timing.
Bien d'accord. Perso mon principal problème était que l'entretien du build system devenant de plus en plus compliqué, et que par ailleurs les bugs s'accumulant, mon temps libre devenant plus réduit, le jeu n'en valait plus la chandelle.
Pareil ici, et même pire parfois (les bugs de police -Cairo- notamment).
Ca fonctionne. Il faut utiliser MinGW64.
[^] # Re: conditions de travail
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 5.
Re vincent, j'ai du nouveau,
Suite à ton comm, j'ai mis grand un coup ; je viens de finir le patch ReactOS qui y fait fonctionner GTK+ (2 et 3) :
https://jira.reactos.org/browse/CORE-8306
Je regarde si on peut builder avec aussi ; ce qui nous permettrait de ne plus dépendre du "Win32" commercial pour au moins le workflow basique .
[^] # Re: conditions de travail
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 2.
Hello Vincent,
GTK+ ne marche pas bien dans ReactOS, car le support des polices via Cairo y est cassé. J'ai identifié le problème la semaine dernière et commencé un patch, mais ça m'a pris des heures, et au final j'ai pas pu terminer avant que mon travail me "remange" mon cerveau. Mes découvertes sont dispo pour qui pense avancer avec.
Sinon au pire, il y a Wine.
[^] # Re: job
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 6.
Moi ce qui à l'époque m'avait fait tripper, c'était Broadway. Et effectivement, ça y est ça marche, on pourrait faire fonctionner GIMP-LibreOffice-etc en cloud avec ça. Il fait juste le polir, notamment pour supporter l'authentification et le multi-session.
Point important, merci de le souligner ! On peut très facilement faire du Python, Vala, PHP… avec GTK.
[^] # Re: job
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 1.
Effectivement, ils n'y ont pas d'intérêt direct.
Ce serait effectivement bien ; dans la pratique ça marche plutôt à sens unique, l'application utilise GTK+ et quand ce dernier ne fonctionne plus assez bien à son goût, elle migre vers un autre framework (Qt p.ex.) plutôt que de contribuer. Et une application de moins, ça signifie moins d'intérêt de la part des devs coeur, donc la qualité baisse encore… c'est un cercle vicieux.
[^] # Re: job
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 2.
Nécessitait.
[^] # Re: Oups!
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 2.
Doit remarcher maintenant.
[^] # Re: job
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 4.
La réalité.
:-D :-(
[^] # Re: Cairo ?
Posté par Tarnyko (site web personnel) . En réponse au journal wlmessage, un équivalent à xmessage. Évalué à 2.
Hello nazcafan,
Oui, car c'est d'une part une dépendance de Weston (donc susceptible d'être déjà installée sur les systèmes du public "cible" de wlmessage), et d'autre part je le connaissais bien pour avoir déjà bossé avec GTK+.
Page blanche, j'avoue (rougit). J'ignore si j'aurais pu réutiliser un peu ou beaucoup.
[^] # Re: Ne pas dépendre d'un toolkit == créer un autre toolkit linké statiquement
Posté par Tarnyko (site web personnel) . En réponse au journal wlmessage, un équivalent à xmessage. Évalué à 7. Dernière modification le 30 mai 2014 à 13:47.
Salut, et merci pour tes encouragements,
Il n'y en aura pas, je pense. wlmessage gardera la même apparence partout.
Ça c'est une riche idée ! Et je pense que ça pourrait être un projet intéressant pour une personne désireuse de s'initier au monde des toolkits.
À titre personnel, je ne voulais pas le faire pour garder le côté "léger" du logiciel. Je vais sans doute finir par retirer la dépendance à la GLib p.ex. ; ça s'inscrit dans cette démarche.
[^] # Re: GNOME et le gestionnaire de fenêtre
Posté par Tarnyko (site web personnel) . En réponse au journal De Xfce à KDE, merci Gnome.... Évalué à 5. Dernière modification le 30 mai 2014 à 13:01.
Ne me fais pas dire ce que je n'ai pas dit :-).
Mais il est clair qu'ils n'ont pensé qu'à GNOME au moment de faire cette modification. Pour un toolkit/framework se voulant à une époque cross-plateforme, ça veut dire au mieux : "on a un boulot à faire sur GNOME, on y va en bourrins, si ça dérange quelqu'un il patchera derrière".
Le problème étant que les développeurs compétents ayant tous peu de temps, ils ont autant de chance de patcher que de switcher vers un toolkit concurrent qui ne leur fera pas le même coup à l'avenir…
[^] # Re: GNOME et le gestionnaire de fenêtre
Posté par Tarnyko (site web personnel) . En réponse au journal De Xfce à KDE, merci Gnome.... Évalué à 4.
C'est en fait l'application qui a été codée pour utiliser GtkHeaderBar ; ce nouveau widget remplace la barre de titre habituelle et jouant avec des "hints" du gestionnaire de fenêtres.
Le problème est effectivement que ça n'a pas de sens sous les DE non-GNOME, ni sous Win32, ni sous OS X. Or, depuis GTK 3.12 de mémoire, GtkHeaderBar est utilisé même par les applications de base :-|.
Une solution serait de patcher GtkHeaderBar pour avoir un comportement "natif" -en gros détecter qu'elle n'est pas sous GNOME, réafficher une barre native, et éventuellement dessiner ses widgets custom dans un espace en-dessous.. Mais j'ignore si ce serait accepté par GNOME.
# Pas pur Wayland
Posté par Tarnyko (site web personnel) . En réponse au journal Firefox en GTK3. Évalué à 3.
Je viens d'essayer de le faire tourner sous Wayland, ça ne fonctionne pas (probablement parce qu'il y a bien plus que GTK+ dans le moteur de rendu Firefox, qui ne l'utilise peut-être que pour les widgets) :
Ici ça bloque sur la recherche d'un "display: :0".
Il est bien sûr possible que je me trompe ; dans ce cas faites signe !
[^] # Re: Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 5.
Oh ça va, je prends pas ça tellement à coeur… Zenitram ;-).
Sinon, blague à part, je viens de finir de porter le code de GCR et Evolution vers win32. Ca veut dire qu'à l'exception du bureau lui-même, la quasi-totalité du framework est maintenant compilable pour cet OS.
Je repasse sur le toolkit, et en profite pour réitérer mon appel à contributions du côté Win32 et OSX.
[^] # Re: Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 5.
OK, d'accord.
Honte ? Et puis quoi encore ? Non mais faut pas exagérer, on parle d'un choix de design qui ne fait pas l'unanimité, pas d'un crime de lèse-UI :D.
Tu dramatises beaucoup tout ça… Moi ça ne me choque pas, parce que je n'en ai pas besoin (sinon je n'utiliserais pas GTK+) ; tu me poses une question, je vais te chercher la réponse, elle ne te convient pas, qu'est-ce-j'y peux ? Je ne suis pas d'accord avec tout ce que fait l'équipe non plus.
Le point principal est que si cela n'existe pas, il faut le créer. Qt (Digia) a un support dédié pour cela, GTK+ peut le faire d'un façon quelconque mais il n'y a pas de secret.