Ok, je m'incline alors ;)
bon ok, j'avais pas lu les commentaires.
En fait, l'un des points qui me gène le plus avec hg ... c'est le support eclipse :(
sans cela je l'aurais utilisé pour migrer je pense.
Mais lors de mes derniers tests, entre svn et eclipse, hg était moins bon que bzr
D'ailleurs, j'ai pas vraiment trouvé de réponse sur le net, est-il possible d'avoir un index comme dans git ? (obligeant de sélectionner ce qu'on commit) voir même en utilisant un plugin hein.
On peut évidemment choisir lors du commit, mais j'aime bien le fonctionnement inverse
Au fait, pourquoi être dev hg (si c'est pour le "plaisir") et pas sur un autre ? (en gros pourquoi l'avoir choisit ?)
Etrange car d'après le document ici http://www.infoq.com/articles/dvcs-guide bzr et git stockent l'historique sous forme de snapshot et hg de changeset
A moins que ça ait changé depuis (le document date de 2007)
> En fait git ne fait *rien*. Il ne stocke aucune information sur le mouvement du code ou du fichier mais essaie de le découvrir lors d'un merge avec des heuristiques.
Ben en fait c'est surtout, je crois (mais me trompe peut-être), qu'il utilise aussi des snapshots pour stocker les modifs et non des changesets (bzr utilise aussi des snapshots, hg des changesets) ce qui doit simplifier un peu les choses.
Mais ce qui est bien, c'est surtout qu'il le fasse lui même.
Mais d'un autre côté, il est vrai que rien n'empêche de créer une sorte d'alias (avant status ou commit par exemple, histoire que ce soit fait correctement et presque automatiquement)
> si t'as l'habitude de faire des mv+edit (c'est pas vraiment une bonne idée)
Ben je dirais que ça dépend.
Si on prend un langage dans lequel les classes ont le nom du fichier, ou le namespace en fonction du répertoire parant, lorsqu'on renome un classe on va déplacer le fichier, ou inverssement.
Et dans ce cas j'aime bien que la modif dans son ensemble (déplacement, édition du fichier + édition des imports dans tous les autres fichiers concernés) soit fait en un commit, c'est plus propre je trouve. Maintenant c'est vrai que c'est peut-être aussi un relant de svn, puisque qu'avec les commits locaux on ne push que lorsque que c'est fini et on peut faire de très petits commits facilement.
Note : finalement j'ai réussi à importer mes projets avec ... bzr svn-import et 2 3 options
Très simple finalement (je sais pas ce que j'avais fait avant pour louper avec cet outil...)
Ok, avec les deux on peut, à priori, faire la même chose.
En pratique ... ben y'en a un qui a un peu plus de style que l'autre (non que je veuille bêtement ce style, mais pour l'un il existe et on peu le modifier, pour l'autre ben comme dit plus bas, ça date vraiment du siècle dernier et ça n'a jamais évolué)
heu... pourquoi ?
Rien ne t'empêche de faire des présentations longues et structurées avec autre chose...
Après oui, ça prend ptetre du temps, mais vu que tu en perd beaucoup moins sur le thème, lequel va vraiment plus vite ?
Et sinon, y'a qq part de vrai ressources graphiques pour dia ?
Parce que bon, visio l'intérêt c'est aussi que tu as des objets graphiquement potables...
Quelques uns sont utilisable, y'en a une flopé avec des couleurs très criardes.
Et si tu est à la rache suis pas sur que changer les couleurs va être rapide (à moins de connaitre avant beamer de façon correcte)
Mais surtout souvent on utilise des couleurs + images liées à sa boite / son boulot / son projet
Et s'il faut commencer à faire de la mise en page ... ben on ne peut nier que c'est plus complexe que gérer un masque de diapo dans powerpoint
Alors oui Beamer est très bien, fonctionnellement et une fois qu'on a un thème de près c'est très rapide de bosser avec. Mais faut faire le thème est ça c'est pas toujours gagné à moins d'être un warrior de latex...
> C'est pas comme les thèmes de base d'OOo qui sont... euarghh... :x
Ho oui, tout comme les charts par exemple.
Le seul truc qui est potable dans OOo niveau graphique ... c'est leurs icones
Mais dès qu'on veut dessiner dedans, faire un graphique ou une présentation il se prend une belle claque (à moins d'y passer pas mal de temps) A croire qu'ils :
- n'ont pas envie qu'on l'utilise
- veulent que tout le monde sache lorsqu'on l'utilise...
et par contre, si tu veux faire une mise en page sympa, un thème correct, de belles couleurs, de belles images ...
ben t'en chie un moment quand même !
Non pas que ce soit pas possible (je l'ai fait récemment) mais très chiant. Donc quand tu as une présentation qui foire ou a faire très rapidement, soit tu as un theme beamer potable, soit tu te contente d'un theme merdique, soit tu prend un autre soft...
Quand à la présence d'indesign la réponse de la mise en page me semble normale.
Il est très courant en édition d'avoir des personnes ne faisant que de la mise en page de textes qu'ils n'ont pas écris. Et si Scribus est pas trop mal c'est tout de même pas du même niveau.
Sachant aussi que ce n'est pas la FSF qui a fait le document. Linux n'a pas pour but principal un kernel libre (dans le sens hurd)
Merci pour le addremove, je ne connaissais pas
Par contre, le --similarity est sympa, mais le fait de _devoir_ y passer un paramètre sensé indiqué le degré de ressemblance me gène.
Mais bon, c'est pas mal qd même
En fait, je pensais qu'un jour un système arriverait enfin à trouver ces changements sans problème et sans intervention manuelle. Je crois que git en est pas très loin, avec l'histoire d'index venant perturber un poil aussi. En gros, gérer le répo en une seule donnée et juste des index présentant le début / la fin des fichiers, un renommage de fichier ne devrait être vu que comme un changement d'index, et déplacer une portion de code entre deux fichiers devient également aisée (git le fait)
Donc en gros ce qui m'intéresse n'est pas tant l'index visible de git (qui oblige en fait à sélectionner ce qu'on commit, même si je gère toujours comme ça, y compris sous svn) mais la gestion données / ressources / fichiers qui est derrière.
Pour la deuxième partie du commentaire (et précédemment) :
En fait, la simplicité des commandes est souvent secondaire. Surtout que les alias permettent de simplifier toutes ses commandes.
Pour ce qui est des Hg, c'est pas une commande en particulier, mais plutôt l'ensemble, les choix par défauts (je sais ça va un peu à l'encontre de la phrase précédente) qui sont parfois opposés aux choix de git.
En fait j'aime bien le côté non basé sur les habitudes précédentes des svn/cvs/... de git
Je me fous totalement que ce soit proche ou loin de svn en fait.
Et des trucs manquent dans hg par défaut, comme les branches locales (dispo en extension)
spa faux mais vu que je continuerai a dire que je fais un bzr branch, un checkout depuis un dépôt svn et que je vais merger les deux ... ben j'emploierai les deux sans m'en soucier...
D'ailleurs comment traduire (proprement, avec des mots qui induisent du vrai sens hein, et qui prennent pas trois plombes à expliquer aux autres ce que je veux dire) commit et push par exemple ? ou fetch, update et pull ?
> En général les gens trouvent que la proximité avec les commandes de svn facilite la vie
ben voui, mais uniquement dans le cas où c'est une bonne chose.
C'est pas parce que svn le fait qu'il faut le faire. d'ailleurs c'est bien comme ça que svn existe : "cvs le fait" ;)
En fait, surtout avec des utilisateurs ne connaissant que les gui pour svn je préfère largement avoir un fonctionnement totalement différent et des commandes différentes mais que ce soit mieux et plus performant.
> Ou alors t'es super fan de l'index de git ? Mais dans ce cas on ne le retrouve pas non plus dans bzr
Merdouille, j'avais pas fait gaffe :(
voui, cet index est _vraiment_ une fonctionnalité intéressante !
Je ne compte même plus où certains dev viennent me voir car ils ont copié / renomé / déplacé des fichiers sans passer par svn. Et lorsque le gars tente de commiter après 1 semaine de dev à tout changer ... ben c'est la merde (même si c'est une connerie en soit)
Faudrait ptetre que je vois si c'est possible d'écrire un plugin pour le gérer
(j'ai commencé à écrire quelques plugins, en partie pour masquer les urls et les faire façon launchpad : bzr push id:~user/project/branch d'ailleurs qqn sait dans launchpad ce que veut dire les + ?)
Par contre il est vrai que dans les spécificités le dépot svn que j'ai ... est un merdier sans nom
Je crois d'ailleurs que c'est la dernière fois que je gère un même dépot pour plusieurs projets (quelque soit le système)
Tu l'as importé avec quoi ?
Autant git-svn fonctionne bien, autant le même dépot attaqué avec Hg j'ai pas réussi :-(
Donc pour le moment je pense passé par l'export git
Il me reste donc juste à faire git -> bzr
Tiens au fait, comment faites vous (si vous l'utiliser) avec les svn:externals ? J'en ai toute une tripoté dans mon répo...
c'est ce qu'on utilise en partie pour le moment mais :
- support windows bof
- support eclipse nul
- impossibilité de faire du merge de branches distantes (faut faire un rebase)
donc finalement je souhaiterais utiliser un système full dcvs
On est moins de 15 dev sur plusieurs projets en parallèle, mais le problème n'est pas vraiment sur la taille (la taille n'est qu'un facteur aggravant des migrations)
Le problème est qu'on doit gérer plusieurs branches de certains softs (une ou deux branches de dev centralisées, une a deux branches de maintenance plus des branches spécifiques à d'autres besoins)
Ben sans avoir de quoi faire un merge potable ... ça pue
Et là ben svn (ou cvs) c'est naze (voir mon précédent journal sur ce que j'en pense)
Mais ok, on peut surement faire avec. Mais surement pas aussi facilement, rapidement.
Faire une branche d'un soft (pour par exemple une adaptation spécifique pour un client) avec une mise à jour de cette branche par rapport à la mainline (qui n'est pas la branche de dev) mais également avec report de certaines choses faites dans la branche spécifique vers une branche elle de dev ... ben sans outils de merge suffisamment corrects c'est une perte de temps monstruseuse alors que c'est si simple avec les bons outils
D'ailleurs dans les "workflows" proposés par bazaar, l'un deux est en fait calqué sur cvs/svn donc développement centralisé, pas de branche (tout juste des commits locaux) mais tout de même une vrai gestion de branche.
Ha oui, j'oubliais, dans le modèle de dev que nous utilisons, certains branches sont à accès restreints. Tout le monde n'a pas les droits de commit sur les branches de maintenance, et ceux corrigeant les bugs ne l'ont pas forcément (l'intégration passe donc pas une autre personne). Pour ce genre de chose, de multiples branches, voir des branches perso publiques sont vraiment un plus.
> ça veut dire en environnement plus que complet, où tous les outils sont KDE.
> KPartitionManager, sorti en version stable il y a quelques temps ? Il faudrait que quelqu'un rassemble tout ça dans un paquet (typiquement le contenu d'un LiveCD, pas un .deb), pour que les gens découvrent des applis KDE formidables mais peu connue.
oui, donc en fait tu confirme, tu confonds deux choses, le développement des outils et l'intégration dans une distrib, qui sont deux choses totalement différentes.
Si tu as debian et que kpartitionmanager n'est pas dispo, package le
Si tu as besoin d'un soft inexistant, développe le.
Mais ce sont bien des choses distinctes.
Bon ok, à la rigueur forker une distrib en rajoutant simplement des dev de nouveaux softs peut marcher aussi.
Quant au site, déjà c'est quoi "une gestion des paquets" sur un site web ?
Et pour le reste, non pas que c'est une mauvaise idée hein, mais n'y a-t-il pas déjà des projets à améliorer ?
launchpad par exemple ? (maintenant que les sources sont dispo)
> Bref, si au lieu de dire «Je fais en GTK pour que mon appli tourne sur Linux/Windows», ce serait bien que les gens disent «Je vais mon appli en Qt pour qu'elle tourne sous Linux et Windows». Une appli GTK n'est compatible qu'avec "une moitié" de Linux, une appli Qt est compatible avec tout.
heu...
(note : je suis vraiment pas du genre à défendre GTK, j'aime po GTK)
mais ça veut dire quoi "GTK compatible qu'avec une moitié de Linux" ?
Autant oui pour pousser Qt pour du cross plateforme parce qu'il s'intègre mieux sous windows, qu'il n'y a pas besoin d'installer un Gtk à côté du soft, etc, autant dire que Qt est mieux pour linux que Gtk ben je pige pas.
J'utilise au taf un bon mélange de libs (kde 4.3, evolution comme outil gnome, gimp / inkscape pour du gtk, quelques applis Qt non kde, etc)
J'ai pas de bureau gnome du tout, mais des bouts un peu partout, des libs, etc
Si j'étais sous gnome et que je continuais à utiliser mes softs kde (kdesvn, dolphin, etc) j'aurais exactement l'inverse.
Et dans les deux cas j'aurais une mauvaise intégration des softs (boites de dialogues différentes par exemple)
Mais si GTK ne marche qu'avec une moitié de linux, comment font les distribs full gtk (genre redhat, ubuntu) ?
> Le but de Logram (une distrib que je compte développer) est de proposer un KDE utilisable, c'est à dire pas un KDE qui marchotte plus ou moins (empaquetage douteux, et le problème de ce journal).
voui, donc en fait tu confond bien ton environnement de bureau avec ta distrib...
spa de bol, mais finalement j'ai un Kde 4.3 utilisable, suffisamment bien empaqueté (les paquets sont sur le ftp de kde) et pas de probleme de kpackagetruc puisque inutile dans mon cas
(ok je suis sous mandriva, mais j'ai entendu que arch avait aussi un kde pas trop mal, mais n'ayant pas essayé je n'en dirai pas plus)
> C'est que justement, je compte développer un gestionnaire de paquets graphique pour KDE, utilisant APT (si on veut du portable, on a déjà KPackageKit qui va bien finir par tourner).
Et pourquoi pas améliorer KPackageKit par exemple ?
surtout lorsque tu dis juste après : "Pour ne pas réinventer la roue"
> wiki, forum, gestion des paquets, demande, websvn, etc. Tout ceci, je le fais générique
> - Il utilise intensivement les notifications GNOME (voir screenshots), et donc, sous KDE, on ne voit rien
Comment fonctionnent les notifications GNOME ?
Si je demande ça, c'est que la réponse peut avoir son importance.
Ex : je suis en train de pas mal tester bzr en ce moment.
Un collègue ayant une ubuntu l'a installé avec tout un tas de plugins non dispos sur ma distrib (mandriva 2009.1 + KDE 4.3) donc un plugin qui affiche des notifications lorsqu'on fait des pull par exemple.
Je me suis justement dit que ça devait être des notifications Gnome, un truc ubuntu/gnome centric quoi.
Pourtant, une fois le plugin installé j'ai bien mes notifications Gnome sous Kde 4.3 ...
Donc en gros, faut voir, faut essayer quoi, installe le, lance le et tu verra bien ce que ça donne. Il est bien trop dur de supposer du résultat comme ça.
Genre, si tu installe en plus des trucs du style libnotify, notify-daemon avec un dbus qui tourne, à mon avis tes notifications tu les a aussi...
Donc voilà, problème des notifications probablement réglées, les autres c'est juste l'icone dans le systray (ça marche) et hop, si c'est que ça faut pas s'embêter.
Après, ptetre que les dev de Kde n'utilisent pas kpackagekit tout simplement, ou que personne n'a le temps de s'en occuper, etc
> Bref, je suis dégoûté. Pour quelle raison est-ce que GNOME bénéficie de tout ça, et KDE de rien ?
Tiens, une question comme ça
T'es sur de pas tout confondre ?
Quelques lignes plus haut tu indiques qu'en fait tu as essayé KPackageKit de Ubuntu sous Debian et que ça marche pas top.
Tu indiques ensuite qu'il n'y a pas de paquet pour Debian.
En clair, ton problème où'c'k'il est ?
Le problème est sur KPackageKit moins bien que PackageKit ?
Ou sur KPackageKit Ubuntu marche pas sur Debian (noooon spa vrai ?) ?
\begin{troll}
Ben sinon fallait installer une vrai distrib user frendly bisournours compliant genre ubuntu ou mandriva - n'a pas packagekit mais je trouve que drakrpm c'est vraiment bien amélioré
\end{troll}
> c' est d' autant plus dommage que catia va entrer en concurence frontale avec d' autres produits, maintenant qu' il est dispo sur windows...
oué enfin c'est pas depuis aujourd'hui qu'il est dispo sous windows hein...
la première fois que je m'en suis servi sous windows, ça devait être en 2001, et le support officiel windows date en fait de 1998 avec le début de la V5
La V6 par contre elle supprime le support UNIX (donc à mon avis pour Linux c'est pas mieux parti...) (sortie en 2008 la V6)
> "Pourquoi payer une licence catia pour faire du "petit" quant un autre soft moins cher le fait aussi bien sur le même pc ?"
ben même lorsque Catia n'était que sous Unix tu pouvais déjà te dire ça
En général t'achète souvent ton ordi pour Catia, la matos en fonction du soft et non l'inverse (bon ok, disons aussi que à chaque fois que j'ai fait / vu faire du Catia c'était sur des stations dédiées uniquement à Catia, de temps en temps un peu de calcul en plus mais ça se limitait beaucoup)
> 3DS à fait une erreur majeure en proposant catia pour windows
Pourquoi ?
> les mêmes égards (et stratégie) qu' une célèbre base de donnée
Laquelle ?
> Cdlt.
désolé mais j'adore ce genre de raccourci inutile ;)
pitetre, mais le fait d'une manière très .... merdique, une sorte de bâtard quoi...
c'est juste un gros merdier
on a une fenetre vide tout ca pour pas perturber les utilisateurs avec les menus, alors elle est toujours visible
j'adore par exemple fermer la seule image ouverte ... et que ça ne ferme pas le logiciel mais me remette cette fenêtre alacon
Mais surtout, les fenêtre volantes étaient précédemment assez bien gérées (même si beaucoup n'avaient pas l'habitude de les gérer)
Mais maintenant ce qui est fort c'est qu'elles sont gérées différemment du reste. Elles ne font plus partie des fenêtres visibles sous Alt-Tab par ex, mais le sont dans la "barre des tâches"
Alors pourquoi pas, je comprend bien le but
Mais dans ce cas, qu'elles reviennent au premier plan lorsqu'on file le focus au dessin
Surtout si on a un gros dessin (genre en plein écran) ça devient vraiment moisi
En fait on a droit à un hybride entre les multi-fenêtres classique, et le soft mono fenêtre avec barres d'outils integrées. Mais on a ni le fonctionnement de l'un, ni l'ergonomie de l'autre.
En gros on a tout et rien, surtout rien.
Alors oui, certains de ces problèmes viennent peut-être de mon gestionnaire de fenêtre (quoique...) mais dans tous les cas le fonctionnement n'est pas bon. Il vaudrait mieux un fonctionnement comme ... krita ... que bon nombre d'utilisateurs demandent depuis ... pfiou vaut mieux pas savoir, ni regarder la liste des autres demandes en fait
jsais pas, au pif :
- parce que les gens n'ont pas du multiécran
- parce que les gens n'ont pas de bureaux multiples non plus
- parce que les gens on un window(s) manager pourri
- parce que l'interface de gimp (surtout la dernière version) elle pue
C'est pour ça que certains "bug trackers" voient les choses un peu différemment.
Depuis qqn temps qd même j'utilise http://www.redmine.org
On ne parle d'ailleurs pas de bug mais de demande (issue)
Et une demande peut être de nature diverse (tracker) et configurable.
Sur certains projets j'ai par exemple :
- anomalie
- amélioration
- suggestion
- assistance
M'enfin, tout ça pour dire que c'est le même outil mais que seul les libellés changent...
Si on renome le bug tracker en issue tracker alors le problème est réglé
Bon allez, je fais la version longue :
- tout d'abord j'ai jamais essayé C-{c|v|x} sous emacs, même si ça existe (puisqu'il faut montrer papates blanches pour avoir le droit d'utiliser emacs on dirait...)
- ensuite, quel rapport avec les raccourcis claviers ? c'est configurable et tant mieux, spa parce qu'un gars a décidé d'un raccourcis qu'il te plait forcément (ex : j'ai C-z en undo et M-g en goto-line, très pratique ceux là ... et très "windows" faut croire...)
Mais le point intéressant n'est pas là (faut croire que tu ne l'a pas essayé) : il permet de faire une sélection rectangulaire plus aisément, plus visuelle, et plus pratique que sans ce mode (qui par ailleurs est intégré depuis qq version d'emacs)
[C-Enter] au début de la zone, déplacer le curseur, puis [Enter] pour se déplacer aux 4 coins et saisir du texte devant / après la zone (plus copier, coller, etc)
> Completement inutile ce mode.
faut croire que non vu que certains l'utilisent...
mais associé à
> Et puis debile au possible.
montre un certain état d'esprit...
> Faut deja savoir ce qu'est une marque
Et ?
Qu'est ce qui t'empêche de savoir ce que c'est _et_ d'utiliser cua (tout ou partie hein...)
Pour conduire ma voiture, je suis pas obligé de savoir comment fonctionne le capteur de position de mes papillons d'admission, ni comment fonctionne le boisseau à dépression ... (et pourtant...)
> Et puis bon, si t'utilises emacs, c'est pas pour te taper des shortcuts a la Windows
ptetre que c'est de l'humour...
mais si j'utilise emacs c'est pour ces fonctionnalités, non pour sa configuration initiale.
Et si je veux changer les raccourcis, ben je le fait (vu que ça n'a pas de rapport)
ha oui, et pour les "puristes" d'emacs, pourquoi dans ce cas pouvons nous les changer ?
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 2.
bon ok, j'avais pas lu les commentaires.
En fait, l'un des points qui me gène le plus avec hg ... c'est le support eclipse :(
sans cela je l'aurais utilisé pour migrer je pense.
Mais lors de mes derniers tests, entre svn et eclipse, hg était moins bon que bzr
D'ailleurs, j'ai pas vraiment trouvé de réponse sur le net, est-il possible d'avoir un index comme dans git ? (obligeant de sélectionner ce qu'on commit) voir même en utilisant un plugin hein.
On peut évidemment choisir lors du commit, mais j'aime bien le fonctionnement inverse
Au fait, pourquoi être dev hg (si c'est pour le "plaisir") et pas sur un autre ? (en gros pourquoi l'avoir choisit ?)
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 2.
Etrange car d'après le document ici http://www.infoq.com/articles/dvcs-guide bzr et git stockent l'historique sous forme de snapshot et hg de changeset
A moins que ça ait changé depuis (le document date de 2007)
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 2.
Ben en fait c'est surtout, je crois (mais me trompe peut-être), qu'il utilise aussi des snapshots pour stocker les modifs et non des changesets (bzr utilise aussi des snapshots, hg des changesets) ce qui doit simplifier un peu les choses.
Mais ce qui est bien, c'est surtout qu'il le fasse lui même.
Mais d'un autre côté, il est vrai que rien n'empêche de créer une sorte d'alias (avant status ou commit par exemple, histoire que ce soit fait correctement et presque automatiquement)
> si t'as l'habitude de faire des mv+edit (c'est pas vraiment une bonne idée)
Ben je dirais que ça dépend.
Si on prend un langage dans lequel les classes ont le nom du fichier, ou le namespace en fonction du répertoire parant, lorsqu'on renome un classe on va déplacer le fichier, ou inverssement.
Et dans ce cas j'aime bien que la modif dans son ensemble (déplacement, édition du fichier + édition des imports dans tous les autres fichiers concernés) soit fait en un commit, c'est plus propre je trouve. Maintenant c'est vrai que c'est peut-être aussi un relant de svn, puisque qu'avec les commits locaux on ne push que lorsque que c'est fini et on peut faire de très petits commits facilement.
Note : finalement j'ai réussi à importer mes projets avec ... bzr svn-import et 2 3 options
Très simple finalement (je sais pas ce que j'avais fait avant pour louper avec cet outil...)
[^] # Re: parce que je n'ai que cela à faire
Posté par CrEv (site web personnel) . En réponse au journal Une analyse du développement du noyau Linux. Évalué à 1.
le premier avec dia : http://dia-installer.de/shapes/edpc/images/edpc_en.png
le deuxième avec visio : http://www.visioformac.com/5_ConceptDrawReadyMac.png
Ok, avec les deux on peut, à priori, faire la même chose.
En pratique ... ben y'en a un qui a un peu plus de style que l'autre (non que je veuille bêtement ce style, mais pour l'un il existe et on peu le modifier, pour l'autre ben comme dit plus bas, ça date vraiment du siècle dernier et ça n'a jamais évolué)
[^] # Re: parce que je n'ai que cela à faire
Posté par CrEv (site web personnel) . En réponse au journal Une analyse du développement du noyau Linux. Évalué à 4.
Rien ne t'empêche de faire des présentations longues et structurées avec autre chose...
Après oui, ça prend ptetre du temps, mais vu que tu en perd beaucoup moins sur le thème, lequel va vraiment plus vite ?
[^] # Re: parce que je n'ai que cela à faire
Posté par CrEv (site web personnel) . En réponse au journal Une analyse du développement du noyau Linux. Évalué à 7.
Et sinon, y'a qq part de vrai ressources graphiques pour dia ?
Parce que bon, visio l'intérêt c'est aussi que tu as des objets graphiquement potables...
[^] # Re: parce que je n'ai que cela à faire
Posté par CrEv (site web personnel) . En réponse au journal Une analyse du développement du noyau Linux. Évalué à 6.
Genre ce qu'il y a ici : http://mcclinews.free.fr/latex/beamergalerie/completsgalerie(...) ?
Quelques uns sont utilisable, y'en a une flopé avec des couleurs très criardes.
Et si tu est à la rache suis pas sur que changer les couleurs va être rapide (à moins de connaitre avant beamer de façon correcte)
Mais surtout souvent on utilise des couleurs + images liées à sa boite / son boulot / son projet
Et s'il faut commencer à faire de la mise en page ... ben on ne peut nier que c'est plus complexe que gérer un masque de diapo dans powerpoint
Alors oui Beamer est très bien, fonctionnellement et une fois qu'on a un thème de près c'est très rapide de bosser avec. Mais faut faire le thème est ça c'est pas toujours gagné à moins d'être un warrior de latex...
> C'est pas comme les thèmes de base d'OOo qui sont... euarghh... :x
Ho oui, tout comme les charts par exemple.
Le seul truc qui est potable dans OOo niveau graphique ... c'est leurs icones
Mais dès qu'on veut dessiner dedans, faire un graphique ou une présentation il se prend une belle claque (à moins d'y passer pas mal de temps) A croire qu'ils :
- n'ont pas envie qu'on l'utilise
- veulent que tout le monde sache lorsqu'on l'utilise...
[^] # Re: parce que je n'ai que cela à faire
Posté par CrEv (site web personnel) . En réponse au journal Une analyse du développement du noyau Linux. Évalué à 2.
ben t'en chie un moment quand même !
Non pas que ce soit pas possible (je l'ai fait récemment) mais très chiant. Donc quand tu as une présentation qui foire ou a faire très rapidement, soit tu as un theme beamer potable, soit tu te contente d'un theme merdique, soit tu prend un autre soft...
Quand à la présence d'indesign la réponse de la mise en page me semble normale.
Il est très courant en édition d'avoir des personnes ne faisant que de la mise en page de textes qu'ils n'ont pas écris. Et si Scribus est pas trop mal c'est tout de même pas du même niveau.
Sachant aussi que ce n'est pas la FSF qui a fait le document. Linux n'a pas pour but principal un kernel libre (dans le sens hurd)
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 2.
Par contre, le --similarity est sympa, mais le fait de _devoir_ y passer un paramètre sensé indiqué le degré de ressemblance me gène.
Mais bon, c'est pas mal qd même
En fait, je pensais qu'un jour un système arriverait enfin à trouver ces changements sans problème et sans intervention manuelle. Je crois que git en est pas très loin, avec l'histoire d'index venant perturber un poil aussi. En gros, gérer le répo en une seule donnée et juste des index présentant le début / la fin des fichiers, un renommage de fichier ne devrait être vu que comme un changement d'index, et déplacer une portion de code entre deux fichiers devient également aisée (git le fait)
Donc en gros ce qui m'intéresse n'est pas tant l'index visible de git (qui oblige en fait à sélectionner ce qu'on commit, même si je gère toujours comme ça, y compris sous svn) mais la gestion données / ressources / fichiers qui est derrière.
Pour la deuxième partie du commentaire (et précédemment) :
En fait, la simplicité des commandes est souvent secondaire. Surtout que les alias permettent de simplifier toutes ses commandes.
Pour ce qui est des Hg, c'est pas une commande en particulier, mais plutôt l'ensemble, les choix par défauts (je sais ça va un peu à l'encontre de la phrase précédente) qui sont parfois opposés aux choix de git.
En fait j'aime bien le côté non basé sur les habitudes précédentes des svn/cvs/... de git
Je me fous totalement que ce soit proche ou loin de svn en fait.
Et des trucs manquent dans hg par défaut, comme les branches locales (dispo en extension)
[^] # Re: Repository -> dépôt
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 3.
D'ailleurs comment traduire (proprement, avec des mots qui induisent du vrai sens hein, et qui prennent pas trois plombes à expliquer aux autres ce que je veux dire) commit et push par exemple ? ou fetch, update et pull ?
[^] # Re: tailor
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 2.
Mais il n'a pas des limitations sur l'import des branches entre autre ?
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 1.
ben voui, mais uniquement dans le cas où c'est une bonne chose.
C'est pas parce que svn le fait qu'il faut le faire. d'ailleurs c'est bien comme ça que svn existe : "cvs le fait" ;)
En fait, surtout avec des utilisateurs ne connaissant que les gui pour svn je préfère largement avoir un fonctionnement totalement différent et des commandes différentes mais que ce soit mieux et plus performant.
> Ou alors t'es super fan de l'index de git ? Mais dans ce cas on ne le retrouve pas non plus dans bzr
Merdouille, j'avais pas fait gaffe :(
voui, cet index est _vraiment_ une fonctionnalité intéressante !
Je ne compte même plus où certains dev viennent me voir car ils ont copié / renomé / déplacé des fichiers sans passer par svn. Et lorsque le gars tente de commiter après 1 semaine de dev à tout changer ... ben c'est la merde (même si c'est une connerie en soit)
Faudrait ptetre que je vois si c'est possible d'écrire un plugin pour le gérer
(j'ai commencé à écrire quelques plugins, en partie pour masquer les urls et les faire façon launchpad : bzr push id:~user/project/branch d'ailleurs qqn sait dans launchpad ce que veut dire les + ?)
Je vais voir si je peux améliorer ce point.
[^] # Re: N'élimines pas Mercurial si vite
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 2.
Par contre il est vrai que dans les spécificités le dépot svn que j'ai ... est un merdier sans nom
Je crois d'ailleurs que c'est la dernière fois que je gère un même dépot pour plusieurs projets (quelque soit le système)
Tu l'as importé avec quoi ?
Autant git-svn fonctionne bien, autant le même dépot attaqué avec Hg j'ai pas réussi :-(
Donc pour le moment je pense passé par l'export git
Il me reste donc juste à faire git -> bzr
Tiens au fait, comment faites vous (si vous l'utiliser) avec les svn:externals ? J'en ai toute une tripoté dans mon répo...
[^] # Re: git svn
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 1.
- support windows bof
- support eclipse nul
- impossibilité de faire du merge de branches distantes (faut faire un rebase)
donc finalement je souhaiterais utiliser un système full dcvs
[^] # Re: Tu connais CVS =)
Posté par CrEv (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 3.
On est moins de 15 dev sur plusieurs projets en parallèle, mais le problème n'est pas vraiment sur la taille (la taille n'est qu'un facteur aggravant des migrations)
Le problème est qu'on doit gérer plusieurs branches de certains softs (une ou deux branches de dev centralisées, une a deux branches de maintenance plus des branches spécifiques à d'autres besoins)
Ben sans avoir de quoi faire un merge potable ... ça pue
Et là ben svn (ou cvs) c'est naze (voir mon précédent journal sur ce que j'en pense)
Mais ok, on peut surement faire avec. Mais surement pas aussi facilement, rapidement.
Faire une branche d'un soft (pour par exemple une adaptation spécifique pour un client) avec une mise à jour de cette branche par rapport à la mainline (qui n'est pas la branche de dev) mais également avec report de certaines choses faites dans la branche spécifique vers une branche elle de dev ... ben sans outils de merge suffisamment corrects c'est une perte de temps monstruseuse alors que c'est si simple avec les bons outils
D'ailleurs dans les "workflows" proposés par bazaar, l'un deux est en fait calqué sur cvs/svn donc développement centralisé, pas de branche (tout juste des commits locaux) mais tout de même une vrai gestion de branche.
Ha oui, j'oubliais, dans le modèle de dev que nous utilisons, certains branches sont à accès restreints. Tout le monde n'a pas les droits de commit sur les branches de maintenance, et ceux corrigeant les bugs ne l'ont pas forcément (l'intégration passe donc pas une autre personne). Pour ce genre de chose, de multiples branches, voir des branches perso publiques sont vraiment un plus.
[^] # Re: Retrousse tes manches…
Posté par CrEv (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 2.
> KPartitionManager, sorti en version stable il y a quelques temps ? Il faudrait que quelqu'un rassemble tout ça dans un paquet (typiquement le contenu d'un LiveCD, pas un .deb), pour que les gens découvrent des applis KDE formidables mais peu connue.
oui, donc en fait tu confirme, tu confonds deux choses, le développement des outils et l'intégration dans une distrib, qui sont deux choses totalement différentes.
Si tu as debian et que kpartitionmanager n'est pas dispo, package le
Si tu as besoin d'un soft inexistant, développe le.
Mais ce sont bien des choses distinctes.
Bon ok, à la rigueur forker une distrib en rajoutant simplement des dev de nouveaux softs peut marcher aussi.
Quant au site, déjà c'est quoi "une gestion des paquets" sur un site web ?
Et pour le reste, non pas que c'est une mauvaise idée hein, mais n'y a-t-il pas déjà des projets à améliorer ?
launchpad par exemple ? (maintenant que les sources sont dispo)
[^] # Re: La belle affaire...
Posté par CrEv (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 1.
heu...
(note : je suis vraiment pas du genre à défendre GTK, j'aime po GTK)
mais ça veut dire quoi "GTK compatible qu'avec une moitié de Linux" ?
Autant oui pour pousser Qt pour du cross plateforme parce qu'il s'intègre mieux sous windows, qu'il n'y a pas besoin d'installer un Gtk à côté du soft, etc, autant dire que Qt est mieux pour linux que Gtk ben je pige pas.
J'utilise au taf un bon mélange de libs (kde 4.3, evolution comme outil gnome, gimp / inkscape pour du gtk, quelques applis Qt non kde, etc)
J'ai pas de bureau gnome du tout, mais des bouts un peu partout, des libs, etc
Si j'étais sous gnome et que je continuais à utiliser mes softs kde (kdesvn, dolphin, etc) j'aurais exactement l'inverse.
Et dans les deux cas j'aurais une mauvaise intégration des softs (boites de dialogues différentes par exemple)
Mais si GTK ne marche qu'avec une moitié de linux, comment font les distribs full gtk (genre redhat, ubuntu) ?
[^] # Re: Retrousse tes manches…
Posté par CrEv (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 6.
voui, donc en fait tu confond bien ton environnement de bureau avec ta distrib...
spa de bol, mais finalement j'ai un Kde 4.3 utilisable, suffisamment bien empaqueté (les paquets sont sur le ftp de kde) et pas de probleme de kpackagetruc puisque inutile dans mon cas
(ok je suis sous mandriva, mais j'ai entendu que arch avait aussi un kde pas trop mal, mais n'ayant pas essayé je n'en dirai pas plus)
> C'est que justement, je compte développer un gestionnaire de paquets graphique pour KDE, utilisant APT (si on veut du portable, on a déjà KPackageKit qui va bien finir par tourner).
Et pourquoi pas améliorer KPackageKit par exemple ?
surtout lorsque tu dis juste après : "Pour ne pas réinventer la roue"
> wiki, forum, gestion des paquets, demande, websvn, etc. Tout ceci, je le fais générique
heu ... la différence avec ce qui existe ?
[^] # Re: La belle affaire...
Posté par CrEv (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 3.
Comment fonctionnent les notifications GNOME ?
Si je demande ça, c'est que la réponse peut avoir son importance.
Ex : je suis en train de pas mal tester bzr en ce moment.
Un collègue ayant une ubuntu l'a installé avec tout un tas de plugins non dispos sur ma distrib (mandriva 2009.1 + KDE 4.3) donc un plugin qui affiche des notifications lorsqu'on fait des pull par exemple.
Je me suis justement dit que ça devait être des notifications Gnome, un truc ubuntu/gnome centric quoi.
Pourtant, une fois le plugin installé j'ai bien mes notifications Gnome sous Kde 4.3 ...
Donc en gros, faut voir, faut essayer quoi, installe le, lance le et tu verra bien ce que ça donne. Il est bien trop dur de supposer du résultat comme ça.
Genre, si tu installe en plus des trucs du style libnotify, notify-daemon avec un dbus qui tourne, à mon avis tes notifications tu les a aussi...
Donc voilà, problème des notifications probablement réglées, les autres c'est juste l'icone dans le systray (ça marche) et hop, si c'est que ça faut pas s'embêter.
Après, ptetre que les dev de Kde n'utilisent pas kpackagekit tout simplement, ou que personne n'a le temps de s'en occuper, etc
> Bref, je suis dégoûté. Pour quelle raison est-ce que GNOME bénéficie de tout ça, et KDE de rien ?
Tiens, une question comme ça
T'es sur de pas tout confondre ?
Quelques lignes plus haut tu indiques qu'en fait tu as essayé KPackageKit de Ubuntu sous Debian et que ça marche pas top.
Tu indiques ensuite qu'il n'y a pas de paquet pour Debian.
En clair, ton problème où'c'k'il est ?
Le problème est sur KPackageKit moins bien que PackageKit ?
Ou sur KPackageKit Ubuntu marche pas sur Debian (noooon spa vrai ?) ?
\begin{troll}
Ben sinon fallait installer une vrai distrib user frendly bisournours compliant genre ubuntu ou mandriva - n'a pas packagekit mais je trouve que drakrpm c'est vraiment bien amélioré
\end{troll}
[^] # Re: vivacité
Posté par CrEv (site web personnel) . En réponse à la dépêche Publication d'OpenGL 3.2. Évalué à 2.
oué enfin c'est pas depuis aujourd'hui qu'il est dispo sous windows hein...
la première fois que je m'en suis servi sous windows, ça devait être en 2001, et le support officiel windows date en fait de 1998 avec le début de la V5
La V6 par contre elle supprime le support UNIX (donc à mon avis pour Linux c'est pas mieux parti...) (sortie en 2008 la V6)
> "Pourquoi payer une licence catia pour faire du "petit" quant un autre soft moins cher le fait aussi bien sur le même pc ?"
ben même lorsque Catia n'était que sous Unix tu pouvais déjà te dire ça
En général t'achète souvent ton ordi pour Catia, la matos en fonction du soft et non l'inverse (bon ok, disons aussi que à chaque fois que j'ai fait / vu faire du Catia c'était sur des stations dédiées uniquement à Catia, de temps en temps un peu de calcul en plus mais ça se limitait beaucoup)
> 3DS à fait une erreur majeure en proposant catia pour windows
Pourquoi ?
> les mêmes égards (et stratégie) qu' une célèbre base de donnée
Laquelle ?
> Cdlt.
désolé mais j'adore ce genre de raccourci inutile ;)
[^] # Re: Descente aux enfers
Posté par CrEv (site web personnel) . En réponse au journal Comment les brevets logiciels se retournent contre leurs promoteurs ?. Évalué à 7.
> Ca ne peut faire que du bien (ou presque) au libre, car ça va prouver que MS n'est pas un bloc auquel personne ne touche.
mouaif ... faut voir
on peut aussi faire du libre en en ayant juste rien a foutre de crosoft et uniquement pour le libre...
[^] # Re: pourquoi toujours du monofenêtre ?
Posté par CrEv (site web personnel) . En réponse au journal Un peu de futur pour les traitements de texte. Évalué à 3.
c'est juste un gros merdier
on a une fenetre vide tout ca pour pas perturber les utilisateurs avec les menus, alors elle est toujours visible
j'adore par exemple fermer la seule image ouverte ... et que ça ne ferme pas le logiciel mais me remette cette fenêtre alacon
Mais surtout, les fenêtre volantes étaient précédemment assez bien gérées (même si beaucoup n'avaient pas l'habitude de les gérer)
Mais maintenant ce qui est fort c'est qu'elles sont gérées différemment du reste. Elles ne font plus partie des fenêtres visibles sous Alt-Tab par ex, mais le sont dans la "barre des tâches"
Alors pourquoi pas, je comprend bien le but
Mais dans ce cas, qu'elles reviennent au premier plan lorsqu'on file le focus au dessin
Surtout si on a un gros dessin (genre en plein écran) ça devient vraiment moisi
En fait on a droit à un hybride entre les multi-fenêtres classique, et le soft mono fenêtre avec barres d'outils integrées. Mais on a ni le fonctionnement de l'un, ni l'ergonomie de l'autre.
En gros on a tout et rien, surtout rien.
Alors oui, certains de ces problèmes viennent peut-être de mon gestionnaire de fenêtre (quoique...) mais dans tous les cas le fonctionnement n'est pas bon. Il vaudrait mieux un fonctionnement comme ... krita ... que bon nombre d'utilisateurs demandent depuis ... pfiou vaut mieux pas savoir, ni regarder la liste des autres demandes en fait
(dsl j'étais pas là vendredi ;))
[^] # Re: pourquoi toujours du monofenêtre ?
Posté par CrEv (site web personnel) . En réponse au journal Un peu de futur pour les traitements de texte. Évalué à 7.
- parce que les gens n'ont pas du multiécran
- parce que les gens n'ont pas de bureaux multiples non plus
- parce que les gens on un window(s) manager pourri
- parce que l'interface de gimp (surtout la dernière version) elle pue
Voilou
[^] # Re: Je la teste...
Posté par CrEv (site web personnel) . En réponse à la dépêche KDE 4.3 est sorti. Évalué à 7.
Depuis qqn temps qd même j'utilise http://www.redmine.org
On ne parle d'ailleurs pas de bug mais de demande (issue)
Et une demande peut être de nature diverse (tracker) et configurable.
Sur certains projets j'ai par exemple :
- anomalie
- amélioration
- suggestion
- assistance
M'enfin, tout ça pour dire que c'est le même outil mais que seul les libellés changent...
Si on renome le bug tracker en issue tracker alors le problème est réglé
[^] # Re: alternative?
Posté par CrEv (site web personnel) . En réponse à la dépêche GNU Emacs 23.1 sort sous le soleil. Évalué à 2.
Bon allez, je fais la version longue :
- tout d'abord j'ai jamais essayé C-{c|v|x} sous emacs, même si ça existe (puisqu'il faut montrer papates blanches pour avoir le droit d'utiliser emacs on dirait...)
- ensuite, quel rapport avec les raccourcis claviers ? c'est configurable et tant mieux, spa parce qu'un gars a décidé d'un raccourcis qu'il te plait forcément (ex : j'ai C-z en undo et M-g en goto-line, très pratique ceux là ... et très "windows" faut croire...)
Mais le point intéressant n'est pas là (faut croire que tu ne l'a pas essayé) : il permet de faire une sélection rectangulaire plus aisément, plus visuelle, et plus pratique que sans ce mode (qui par ailleurs est intégré depuis qq version d'emacs)
[C-Enter] au début de la zone, déplacer le curseur, puis [Enter] pour se déplacer aux 4 coins et saisir du texte devant / après la zone (plus copier, coller, etc)
> Completement inutile ce mode.
faut croire que non vu que certains l'utilisent...
mais associé à
> Et puis debile au possible.
montre un certain état d'esprit...
> Faut deja savoir ce qu'est une marque
Et ?
Qu'est ce qui t'empêche de savoir ce que c'est _et_ d'utiliser cua (tout ou partie hein...)
Pour conduire ma voiture, je suis pas obligé de savoir comment fonctionne le capteur de position de mes papillons d'admission, ni comment fonctionne le boisseau à dépression ... (et pourtant...)
> Et puis bon, si t'utilises emacs, c'est pas pour te taper des shortcuts a la Windows
ptetre que c'est de l'humour...
mais si j'utilise emacs c'est pour ces fonctionnalités, non pour sa configuration initiale.
Et si je veux changer les raccourcis, ben je le fait (vu que ça n'a pas de rapport)
ha oui, et pour les "puristes" d'emacs, pourquoi dans ce cas pouvons nous les changer ?