Alors il s'agit plus de définir une ABI compatible entre les différents "vendors",
mais du moins ça a été discuté dans le C++ Committee Meeting de juin 2014 :
Je vous laisse regarder un peu, pas eu le temps de survoler pour un petit résumé.
Ce qui est déjà un grand pas, l'ABI C++ a tendance à jouer la danse de la saint Guy dès qu'un bout de son environnement change (msvc, je te regardes).
A voir s'ils vont réussir à se mettre d'accord, que le respect du standard tienne ;
et peut être par effet de bord on aura une petite facilité à maintenant une ABI entre chaque changement de code.
J'espère que tu ne penses pas à celui fourni avec les PowerToys de Microsoft, qui est de loin le plus mauvais que j'avais eu en main à l'époque d'XP.
Depuis deux ans je ne jure plus que par VirtuaWin (non, rien à voir avec Sega).
Testé sous Vista et Seven, approuvé.
Le seul bug est, parfois, le changement de la décoration de fenêtre sur les programmes à une seule instance, lorsqu'ils sont déjà ouverts sur un vdesk différent ; pas de quoi balancer le PC à travers le bureau.
Il y a une nouvelle API/outils par Miscrosoft depuis PowerToys ?
J'ai déjà récupéré des parties de configurations que je voulais uniquement à l'aide de cette hiérarchie de fichiers XML (gconf),
avec un blob binaire (dconf) c'est une autre triste triste histoire.
Il y a indigeste et pratique, et indigeste indigeste.
Le truc c'est que boost garde le principe de la stl, rester générique, là où Qt semble tendre vers l'écriture rapide du cas usuel (sur ces conteneurs).
Dernièrement ce que j'ai voulu c'était un
std::stringstr"string to split";std::set<std::string>strs;boost::split(strs,str,boost::is_any_of(" "));
pas de std::vector ici.
Et je suppose que je pourrais tout aussi bien faire un
Avec Qt il faut que j'attende que mon objet implémente une sortie vers mon conteneur (ou que je passe par des objets intermédiaires), avec la stl/boost, c'est mon conteneur qui doit respecter le contrat.
Les deux libs ne sont pas pensées pour les même cas d'utilisation.
Sympa, je viens d'essayer ça marche bien (et ça reprend le ctr-m des qt apps).
- Ça ne semble pas faire planter firefox.
- Sous shotwell ça fait aussi des trucs pas commun,
. il faut absolument être sur la catégorie photo pour que ça fonctionne la première fois ;
. après, comme shotwell a plusieurs barres de menu, l'état affiché/caché est gardé par catégorie, donc la barre s'affiche, se cache, quand on navigue.
- Si on ouvre evince sans document actif, il n'est pas possible d'afficher le menu, comme la fenêtre est en mode inactif, mais c'est rare d'ouvrir evince sans document ;
toutes les applications qui mettent un mode inactif sur leur fenêtre auront sûrement ce problème.
- Sinon sur evince encore, là aussi il affiche son menu quand il reçoit le focus, mais il y a pas grand chose à faire à part interdire l'affichage du menu en dehors du module.
- _Ça fonctionne_ avec gnome-mplayer, du moins ça cache le menu, gnome-mplayer a déjà un raccourci sur ctrl-m qui supprime celui du module ;
c'est d'ailleurs pour ça que j'avais choisi un ctrl-touche-menu, pour éviter ce genre de conflit.
C'est pas forcément évident de traiter la barre de menu d'une application dès que celle-ci joue avec.
Je me demande comment se comporte le appmenu-gtk avec shotwell, d'ailleurs.
Ha, je suis ravi de voir qu'il y a du monde pour se pencher sur l'idée de cacher ces menus.
Le mode à la macos a un autre désavantage, pas de sélection de fenêtre par survol de curseur ; entre la fenêtre et la barre en haut, il curseur a le temps d'en rencontrer d'autres, de fenêtres, pas bon du tout.
Les menus je trouve pas ça top moumoute, pratique parfois, mais à la louche, 95% de mon temps je ne m'en sers pas, ça gâche la vue.
J'en ai eu assez un jour, j'ai écrit vite fait un module pour gtk pour régler mon problème.
C'est écrit brouillon, pas fini, mais si jamais quelqu'un veut s'en servir comme bootstrap ou quoi que ce soit, c'est là : [http://pastie.org/1575968]
Il suffit juste d'un GTK_MODULES="/foo/bar/libgtkhidemenu.so" pour que ça fonctionne.
Et un ctrl+touche-menu pour afficher, cacher le menu.
Pas besoin de lib autre que gtk, ou de pacther gtk.
Alors j'annonce de suite :
- éloignez tout de suite madame michue, c'est pas pour elle,
- je ne nettoierai, compléterai, fixerai, featurai le code d'aucune manière, en somme j'y touche plus ; comme le dit bien le dlfpiens, tu veux quelque chose, bha tu le code (sic).
- ça fait peut être planter firefox depuis une certaine mise à jour,
- ça marche pas, ou pas bien partout, certaines applications jouent avec leur menu,
. comme evince, qui réaffiche sa barre lorsqu'il a le focus,
. comme shotwell qui a plusieurs menus qu'il affiche/crée par catégorie, ça fait un petit glitch,
. comme gnome-mplayer, là ça ne marche pas du tout, mais je lui pardonne, il a d'autres choses à faire, comme gérer mplayer,
. et certainement d'autres.
Ce changement de politique de gnome-shell me fait sourire face à la politique de nautilus, dont le mot d'ordre était "If this can be done outside the WM it should be" ;
ll suffit de parcourir le toujours intéressant blog de "…for the adult in you" [http://blogs.gnome.org/metacity/] pour y retrouver cette conclusion.
Et enfin il y a Jython et JRuby, les ports, plus performants que les originaux de Python et Ruby. Pas de risque d'être dépaysé.
Je ne suis pas allé chercher les benchs pour vérifier que cette affirmation tombe du ciel ou non, en revanche je suis un peu le dev de Waf.
Il y a eu un patch pour qu'il puisse tourner justement sous Jython, et d'après leur outils de test, non Jython n'est certainement pas plus rapide : http://code.google.com/p/waf/issues/detail?id=434&can=1&(...) .
D'aucuns me diront que c'était sous un Jython beta, mais c'est l'exemple concret que j'ai sous la main.
[^] # Re: Quelqu'un peut-il m'expliquer le problème avec l'ABI de KDE
Posté par grochon . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 4.
Alors il s'agit plus de définir une ABI compatible entre les différents "vendors",
mais du moins ça a été discuté dans le C++ Committee Meeting de juin 2014 :
Je vous laisse regarder un peu, pas eu le temps de survoler pour un petit résumé.
Ce qui est déjà un grand pas, l'ABI C++ a tendance à jouer la danse de la saint Guy dès qu'un bout de son environnement change (msvc, je te regardes).
A voir s'ils vont réussir à se mettre d'accord, que le respect du standard tienne ;
et peut être par effet de bord on aura une petite facilité à maintenant une ABI entre chaque changement de code.
[^] # Re: KenObi1
Posté par grochon . En réponse au sondage Sur quel environnement de bureau misez-vous dans le futur ?. Évalué à 2.
J'espère que tu ne penses pas à celui fourni avec les PowerToys de Microsoft, qui est de loin le plus mauvais que j'avais eu en main à l'époque d'XP.
Depuis deux ans je ne jure plus que par VirtuaWin (non, rien à voir avec Sega).
Testé sous Vista et Seven, approuvé.
Le seul bug est, parfois, le changement de la décoration de fenêtre sur les programmes à une seule instance, lorsqu'ils sont déjà ouverts sur un vdesk différent ; pas de quoi balancer le PC à travers le bureau.
Il y a une nouvelle API/outils par Miscrosoft depuis PowerToys ?
[^] # Re: Rha mais oui mais non !
Posté par grochon . En réponse à la dépêche Cinnamon 1.2, le fork de Gnome-shell. Évalué à 1.
Je m'insurge !
Confondre ainsi gconf et dconf, bhou.
J'ai déjà récupéré des parties de configurations que je voulais uniquement à l'aide de cette hiérarchie de fichiers XML (gconf),
avec un blob binaire (dconf) c'est une autre triste triste histoire.
Il y a indigeste et pratique, et indigeste indigeste.
[^] # Re: Quelle est la raison ?
Posté par grochon . En réponse au journal LINUX 2.8.0. Évalué à 0.
[http://lkml.org/lkml/2005/3/2/247]
Vivement la 4.x.x, que l'on accepte enfin que Visual Basic était en avance.
[^] # Re: Boost ? c'est quoi ?
Posté par grochon . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 6.
Le truc c'est que boost garde le principe de la stl, rester générique, là où Qt semble tendre vers l'écriture rapide du cas usuel (sur ces conteneurs).
Dernièrement ce que j'ai voulu c'était un
pas de std::vector ici.Et je suppose que je pourrais tout aussi bien faire un
si jamais j'en ai la nécessité un jour.Avec Qt il faut que j'attende que mon objet implémente une sortie vers mon conteneur (ou que je passe par des objets intermédiaires), avec la stl/boost, c'est mon conteneur qui doit respecter le contrat.
Les deux libs ne sont pas pensées pour les même cas d'utilisation.
[^] # Re: Mon hack à moi
Posté par grochon . En réponse au journal Quand Ubuntu me régale. Évalué à 3.
Si les applications qt font les choses par défaut maintenant, comment voulez-vous troller à l'aveuglette maintenant ?
[^] # Re: Mon hack à moi
Posté par grochon . En réponse au journal Quand Ubuntu me régale. Évalué à 1.
- Ça ne semble pas faire planter firefox.
- Sous shotwell ça fait aussi des trucs pas commun,
. il faut absolument être sur la catégorie photo pour que ça fonctionne la première fois ;
. après, comme shotwell a plusieurs barres de menu, l'état affiché/caché est gardé par catégorie, donc la barre s'affiche, se cache, quand on navigue.
- Si on ouvre evince sans document actif, il n'est pas possible d'afficher le menu, comme la fenêtre est en mode inactif, mais c'est rare d'ouvrir evince sans document ;
toutes les applications qui mettent un mode inactif sur leur fenêtre auront sûrement ce problème.
- Sinon sur evince encore, là aussi il affiche son menu quand il reçoit le focus, mais il y a pas grand chose à faire à part interdire l'affichage du menu en dehors du module.
- _Ça fonctionne_ avec gnome-mplayer, du moins ça cache le menu, gnome-mplayer a déjà un raccourci sur ctrl-m qui supprime celui du module ;
c'est d'ailleurs pour ça que j'avais choisi un ctrl-touche-menu, pour éviter ce genre de conflit.
C'est pas forcément évident de traiter la barre de menu d'une application dès que celle-ci joue avec.
Je me demande comment se comporte le appmenu-gtk avec shotwell, d'ailleurs.
# Mon hack à moi
Posté par grochon . En réponse au journal Quand Ubuntu me régale. Évalué à 3.
Le mode à la macos a un autre désavantage, pas de sélection de fenêtre par survol de curseur ; entre la fenêtre et la barre en haut, il curseur a le temps d'en rencontrer d'autres, de fenêtres, pas bon du tout.
Les menus je trouve pas ça top moumoute, pratique parfois, mais à la louche, 95% de mon temps je ne m'en sers pas, ça gâche la vue.
J'en ai eu assez un jour, j'ai écrit vite fait un module pour gtk pour régler mon problème.
C'est écrit brouillon, pas fini, mais si jamais quelqu'un veut s'en servir comme bootstrap ou quoi que ce soit, c'est là : [http://pastie.org/1575968]
Il suffit juste d'un GTK_MODULES="/foo/bar/libgtkhidemenu.so" pour que ça fonctionne.
Et un ctrl+touche-menu pour afficher, cacher le menu.
Pas besoin de lib autre que gtk, ou de pacther gtk.
Alors j'annonce de suite :
- éloignez tout de suite madame michue, c'est pas pour elle,
- je ne nettoierai, compléterai, fixerai, featurai le code d'aucune manière, en somme j'y touche plus ; comme le dit bien le dlfpiens, tu veux quelque chose, bha tu le code (sic).
- ça fait peut être planter firefox depuis une certaine mise à jour,
- ça marche pas, ou pas bien partout, certaines applications jouent avec leur menu,
. comme evince, qui réaffiche sa barre lorsqu'il a le focus,
. comme shotwell qui a plusieurs menus qu'il affiche/crée par catégorie, ça fait un petit glitch,
. comme gnome-mplayer, là ça ne marche pas du tout, mais je lui pardonne, il a d'autres choses à faire, comme gérer mplayer,
. et certainement d'autres.
Et parce que je suis sympa, je vous donne un aperçu de ce que pourrait être un monde sans menu dans les applications :
* evince : [http://i.imgur.com/h5hbn.png]
* gedit : [http://i.imgur.com/9oZga.png]
* nautilus : [http://i.imgur.com/ZQOqJ.png]
En bonus, je vous donne ça pour demain :
Tu vois qt fanboy, moi avec mon gtk j'écris un module et c'est réglé (ou presque).
[^] # Re: Fluxbox et E17
Posté par grochon . En réponse au journal gnome3.org. Évalué à 0.
bien entendu.
[^] # Re: Fluxbox et E17
Posté par grochon . En réponse au journal gnome3.org. Évalué à 2.
Ce changement de politique de gnome-shell me fait sourire face à la politique de nautilus, dont le mot d'ordre était "If this can be done outside the WM it should be" ;
ll suffit de parcourir le toujours intéressant blog de "…for the adult in you" [http://blogs.gnome.org/metacity/] pour y retrouver cette conclusion.
L'un des devs avait d'ailleurs fait une note sur le principe/particularité de ranger les fenêtres par bureau virtuel [http://blogs.gnome.org/metacity/2008/11/02/window-matching/]
[^] # Re: gitk --all
Posté par grochon . En réponse au journal Mercurial ou GIT. Évalué à 3.
Tu te fais un p'tit .desktop qui lance gitk --all au lieu de gitk.
Mais arg! éditeur de text /o\
[^] # Re: Tres bonne nouvelle!
Posté par grochon . En réponse au journal VP8 libéré, WebM est né. Évalué à 7.
[^] # Re: Solution
Posté par grochon . En réponse au journal Quand microsoft fait de l'open source. Évalué à 6.
#define MemSetA(a,b,c) memset(a,c,b)
#define MemSetExA(a,b,c) memset(a,c,b)
Le dev. ms vous rétorquera que ce n'est pas dans l'ordre des arguments qu'il s'est trompé, mais dans le nom de l'appel. Tous tombé dans le panneau.
[^] # Re: Ça passe très bien :)
Posté par grochon . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 1.
Je ne suis pas allé chercher les benchs pour vérifier que cette affirmation tombe du ciel ou non, en revanche je suis un peu le dev de Waf.
Il y a eu un patch pour qu'il puisse tourner justement sous Jython, et d'après leur outils de test, non Jython n'est certainement pas plus rapide :
http://code.google.com/p/waf/issues/detail?id=434&can=1&(...) .
D'aucuns me diront que c'était sous un Jython beta, mais c'est l'exemple concret que j'ai sous la main.