Raphael Junqueira a écrit 337 commentaires

J'aimerais faire remarquer qu'on n'est pas à l'abri d'un changement de license des prochaines versions de QT. Donc poursuivre le développement de GTK est important.

on 'sen fout qt/xfree est dipo en license libre ... cf toutes les en-tetes des source Qt :)

Et puis un peu de diversité ne fait jamais de mal. C'est la diversité qui fait avancer les choses : chacun apporte son petit truc pour faire la différence et copie les idées des autres. Au bout du compte tout le monde y gagne.

Je suis pour, mais a condition de faire de la copie intelligente et surtout d'innover. Car malgre sur certains aspects graphiques (tres bons les designers du projet) et sur l'utilisabilite (merci sun) de gnome, je ne prouve pas gnome top interressant. Et du point de vu d'un developpeur c'est criant :(

le troll honteux

le pire ce sont generalement des options assez interressantes, mais malheureusement des que l'on donne un peu de souplesse a une interface ca entraine bcp d'options.

Des exemples "enormes" existent dans la logiciel de dessin, ils sont ultra souple au niveau interfaces, plugins, macros,... mais en contrepartie tu a le droit a un sacre tablo de bord pour les options

Le seul truc utile de ces regedit-like serait de pouvoir profiter à l'avance de paramétrages qui n'ont pas encore intégré à l'interface de configuration classique de l'appli (Je pense à la fonctionnalité de changement de bureau avec la roulette de KDE qui existe mais n'est pas activable via interface)

Justement, au niveau de kde il y a une discussion pour savoir si il vaut mieux pour prendre en compte des options avancees de "customization" des applis et de l'interface:
- etendre le control-center avec des boutons "advanced" partout
- avoir un equivalent de tweakUI et autres joyeuseries a la custom windows
- avoir une application sommaire du style regedit

et disont que le choix entre avoir deux applis pour la conf dont une qui sera assez complexe a maitrise (soit l'equivalent tweakUi, soit l'equivalent regedit) et un complexification (ca se dit?) de l'interface, qui entraine deja de nombreux cauchemars a la team usability de kde, du control-center, ben la team usability elle sait pas quoi dire ... a part "y a pas troisieme possibilite?"

l'appli regedit existera en tout cas, car elle servira au minimum a bien "tuner" la conf generique (potentielement kiosk) des users par un admin. Maintenat pour le power user moyen qui veut "customizer" pas mal tout en ne sachant pas grand chose du fonctionnement de DE que faire ?

Très juste. gconf-editor est à usage exceptionnel. Quand je parlais d'outil générique de configuration, je ne voulais pas dire que toutes les applis allaient être configurées par l'utilisateur par gconf-editor par exemple. Je voulais dire que toutes les applis utilise le même système générique pour la configuration de la appli. Ce qui permet pour quelque cas particulier d'utiliser un outil générique, ou d'authorisé l'édition des fichiers de conf par d'autres applis (style control-center).

De ce cote les deux DE utilisent un format de fichiers de confs "standard" (les config, un equivalent des .ini pour kde, des fichiers pour gnome je croit) donc facilement reexploitable de facon generique par outil simple d'edition

hmmm du gros troll bien poilu

mais justement c le meme format (cf doc sur site) de fichier
donc on peut facilement avoir une appli du genre regedit pour les .desktop si t'y tient (je pense meme avoir vu passer le debut de dev d'une appli de ce type sur les ml-kde, ptet dans kdenonbeta)

non,

regarde sur le meme site la documents sur le protocole netWM et surtout les .desktop (me rappellle plus le titre exacte du document) afin d'avoir un moyen commun pour les racourcis, enregistrement de capacites (mimes, facotries, ...) ce a quoi sert justement la majorite de la base de registre (le reste entant la sauvegarde des confs internes aux applis ce qui a l'heure actuelle n'est pas reelement partagee entre les desktops)

Ben regarde donc du cote de kde: liquid, d'ici peu tu auras l'equivalent d'aqua.

Mais au final, tu te rendra compte que le fort de macosx n'est pas reelement aqua comme tout le monde semble le penser mais plutot qwartz (et l'evolution extreme de celui-ci) acqua n'etant que la face visible de l'iceberg.

En modifiant liquid tu peut facilement obtenir un clone d'aqua, mais aura t-il cette nettete/finesse, la meme reactivite ou bien encore tous les petits effects vectoriels qui finissent le tout... non. Car actuellement, linux ne possede que des moteurs de rendus "bitmaps" avec des effets "bitmaps". Au nivo de Kde et de gnome, actuellement ils travaillent sur des couche svg pour combler ce defaut tout en rajoutant plein d'effets graphique a leurs moteurs de rendus; alors que du cote de Xfree freetype, xrender et consort tendent a combler des manques enormes du protocole X

Donc d'ici qques temps on pourra enfin avoir une interface avec la meme finesse que macosx, et pas l'effet taille a la hache comme windows

oupsssssssssssssssssss

cochonnerie de mozilla, il ma plante dans les mains en me refusant l'envoi et l'a qd meme fait :((((((((((

>Ca ne me dit rien ... C'est quoi exactement gsl ?
GSL - Generic Sound Layer
un couche en c developpee conjoitement par des devs arts et gnome (cf la vieille rumeur comme quoi gnome allait utilise arts)
(cf version kde http://webcvs.kde.org/cgi-bin/cvsweb.cgi/arts/flow/gsl(...))

>il existe cependant un plugin arts ;)
bizarre, sachant kde arts/audio n'est qu'une faible surcouche fonctionnelle a gsl

>C'est un peu le but de GStreamer fournir un framework multimedia
> dont le coeur repose uniquement sur popt, libxml et glib.

J'en convient, maintenant si on pouvait eviter de dedoubler les efforts, sachant que, personnelement, je pense que les deux projets sont complementaires actuellement. Cela entraine que les deux desktops "attendent" la stabilite des API de gestion de manipulations videos (pire gnome attend encore la stabilisation de l'API de manipulation video)

> Il est vrai qu'aujourd'hui *peu* de personnes travaillent sur
> GStreamer si on compare avec mplayer ...
malheureusement, mais c assez dur a developper et le temps/dev manque :(

> Ca ne me dit rien ... C'est quoi exactement gsl ?

Generic Sound Layer
(cf http://webcvs.kde.org/cgi-bin/cvsweb.cgi/arts/flow/gsl/(...))
develope conjoitenement par deux dev "arts" et un dev (ou plusieurs) dev "gnome". D'ailleurs gsl depend de la glib, ce qui fait des dependances bizarres du cote d'arts :)


> Il existe cependant un plugin arts ;)
bizarre ... sachant que arts/audio n'est qu'une faible surcouche fonctionnelle a gsl

>C'est un peu le but de GStreamer fournir un framework multimedia
> dont le coeur repose uniquement sur popt, libxml et glib.

je suis bien d'accord, mais ca irait plus vite s'ils ne dedoublaient pas les efforts (surtout qu'a mon avis les deux projets actuellement sont assez complementaires). De plus ca eviterait que les deux desktop "attendent" la stabilisation d'une API complete de gestions de streams video (arts/kde ne gerant que les streams audio alors que gnome eux restent a ne gerer que les "players" audios)

>Il est vrai qu'aujourd'hui *peu* de personnes travaillent sur
> GStreamer si on compare avec mplayer ...
malheureusement :(

comme kde3.1 ;)

enfin personne n'a eut le courage de faire une interface Arts:::Video sur gstreamer. Pire la definition de Arts::Video est gelee en attendant qu'un API de gestion video se stabilise (dans les startingblocks: gstreamer et mplayer) :(

xine ne fournit qu'un API de decompression, son but n'est d'etre qu'un player (enfin pour la version 1.0 pour le futur ...)

Pour gstreamer, c'est vrai que l'API est assez bien pensee et assez simple, mais il reste encore bcp de boulot pour qu'elle soit reelement complete.
Il est par exmple tres difficile de developper un logiciel de montage complexes avec actuellement (bon ca ne saurait tarder, malheureusement je trouve que ca avance trop lentement ;( ) Et cela du a quelques "manques" basiques.

mplayer justement n'est pas qu'un player, c un framework video comme tu le voulait ;) (il gere la compression et la decompression)

maintenant, le probleme de mplayer c'est que l'API n'est pas tres "stable" d'ou le fait que, par exemple, du cote de kde on ait prefere utilise xine (en "bridant" le framework arts/video de kde juste pour des players) qui est plus simple et a une API plus stable (d'ailleurs les changements entre la 0.9 et la 1.0 sont vraiment minimes).


Maintenant si je me rappelle bien gstreamer utilise la meme base audio "gsl" que arts non ?

ca serait bien si par exemple que les projets gstreamer et mplayer travaillent sur une veritable et completes API video afin que kde et gnome puissent en faire une fondation solides des futurs versions de leurs desktops ;)

tu voulait juste t'integrer dans la mainloop de facon asynchrone ?

meme je ne voit tjs po ce qui est "exclusif" en terme d'utilisation de sockets + toolkit + timers + ... j'ai de nombreuses fois developpe des progs multi-sockets avec des GUI au besoin (dont qques fois sur une autre becane, de facon reparties: a la recherche de l'admin :) ) etc... Maintenant, j'aimerait bien comprendre ton probleme/besoin, pcque meme en passant par des ignobles cochonneries je n'ai jamais ete limite par mon un tk de "haut niveau" :)

en etant honnete xfree86 a bcp evolue dans le bon sens dernierement, je pense qu'il peut devenir tres competitif lorsqu'il sera apte a gerer des commandes avec notions d'alpha (en dehors de passer par l'openGL) et quand il sera possible de bien controler autant les drawbles que les relations entre drawables sans de hacks ingnobles du windows manager (cf possibilitees de faire de l'alpha blendig entre deux fenetres, des ombres portees sur les contours de fenetres, ...) pour le plus de dev sur GNUStep ... je ne dirait que, personnellement et sans vouloir troller, je pense que l'API de KDE est actuellement devenue/en voie d'etre (sur les parties multimedia encore a la traine) plus coherente, plus intuitive, plus puissante que celle de macosX qui est pourtant vraiment tres bien foutue. j'ai d'ailleurs facilement reussi a le montrer a d'ex-devs gnustep et macosx (j'ai honte, j'ai corrompu d'honnetes devs) Pour les applis, ca commence a arriver et avec les promesses du futur noyau linux en terme de "multimedia" (au sens marketing du terme) je pense que linux va faire son entree par la grande porte de l'OS tout "multimedia" (ce que beos n'a pu reelement faire): musique, video, interfaces kitchs, ... :) Le probleme c'est qu'indirectement, linux risque de rentrer en conflit avec le marche d'apple plus que celui de microsoft (a part les serveurs) tant que sur le user desktop il ne s'impose pas (et la qu'un seul et unique espoir: une suite "office" complete, simple, intuitive,pleins de gadgets,... avec ~100% de compatibilite d'import avec celle de microsoft)

???????????? pkoi parle tu de sockets ? si tu veut parler de la gestion multi-screen voir multi-server d'une appli regarde avant les API de Qt (exemple: http://doc.trolltech.com/3.1/qdesktopwidget.html) , et si jamais tu ne trouve tjs pas ton bonheur tu peut tjs acceder a un mix API xlib/Qt via les interfaces Qt speciales x11 (voir les ::winId, etc...) pour la recuperation des events: http://doc.trolltech.com/3.1/qeventloop.html devrait te convenir Pour Gtk+, il doit clairement avoir la meme chose. Donc qu'est ce qui te gene ?

Si Qt le fait :)
pour Gtk+ je le pense aussi mais je n'en suit pas sur

Maintenant la personne qui me dit que la xlib est moins abstraite que Qt ... la xlib c'est pour moi proche de la braxxxx intellectuelle pour une API de moteur d'affichage. A cote qwartz c'est de l'assembleur graphique.

Les qques fois ou j'ai du me passer de Qt, mes interfaces ont etes developpees avec l'API OpenGL qui, pour moi, est nettement plus adaptee que celle de la xlib pour ca. (les personnes ayant essaye de faire qques effets sur, par exemple, des menus en xlib pure me comprendront).

/dev/random c'est pas vraiment portable.

de meme les comportements de random varient bcp en fonction des implementations:
- sur la gnu libc, il commence a etre potable dernierement
- sur les unix pro ils sont assez mauvais a l'exception de sgi et sun (et encore dans certains cas seulement)

en general si tu veux un vrai random potable en terme de mathematiques, il faut utiliser un code fait maison :)

j'en suis bien conscient, bien maintenant je commence a bien en connaitre 2-3 mais les differences de comportement sont telles ...

par exemple: sur une station SGI une appli n'e peut allouer qu'au dessus du premier Go jusqu'au deuxieme (le 3eme n'est accessible que par mmap)

apres si tu rajoute des comportements de scheduler differents ... tu pleure

d'ailleurs si qqu'un saurait comment suspendre une thread sous solaris 5.8 en etant certain de ne pas etre dans la libc (donc en n'ayant pas une mutex de la libc prise) :)

c'est clair que c'est ca qu'il me faudrait,
et bizzarrement aucun editeur sous linux ne permet ca ;(

a se demander si il y a jamais eut personne qui s'est plaint des meme problemes

non
j' ai une machine puissante et bcp de mem. et il est inutilisable: impossible de bouger le curseur sans 5-6s de latence ;((

par exemple kate s'en sort nettement mieux que emacs dans ce cas la

hmmm redhat je le concoit bosse surtout sur gnome et gcc
maintenant niveau noyau conectiva, ibm et sgi sont largement les plus gros developpeurs (redhat ne travaille sur le kernel que pour des besoins assez specifiques cf alan cox). Pour la libc, c'est vrai que redhat 'a fortement contribuer au NTPL' mais ce qui me fait un peu mal c qu'ils se mettent en avant en disant que c'est eux qui l'ont fait alors que c'est la contribution de nombreux devellopeurs kernel (dont ceux de connectiva) qui a permis cela.

Pour debian, ce n'est pas direct comme apport.
Et suse, il a une juste un dev continu sur alsa et kde (deja pas mal)

Au final, j'appuit mon idee :)

1) 3) 4) 5) 7)
tout a fait d'accord

2) ???

6)
faux, connectiva utilise une surcouche apt pour rpm :)

8)
enfin l'interet et assez minime dans ce cas (bien que c quasiment ce que je finit par faire)

Vi faut les aider :)

connectiva :)
c'est la seule qui avec mandrake qui a reelement apportee quelquechose ces 2 dernieres annees

le seul hic c qu'elle va suivre united linux (on peut tjs esperer que connectiva tire UL vers le bon chemin mais g des doutes vu l'optique suse)