Bon, je ne lui demande pas grand chose de plus que de m'afficher mes documents, éventuellement en plein écran, et de passer d'une page à l'autre.
Essaye sur un petit écran, par exemple le eee701 et apprends à détester la barre de saut de page en bas à cause de sa taille.
J'ai eu de gros problèmes de rendu sur un petit écran quand je faisais rotation pour profiter de la hauteur parce que 'adapter à la largeur, s'adapte toujours à la largeur au lieu de s'adapter à la hauteur (la nouvelle largeur). Donc il n'y a qu'adapter à la page qui marche mais c'est trop petit.
L'aperçu ne fonctionne plus, tu ne navigues plus de haut en bas mais latéralement.
Donc si tu zommes pour adapter la page à l'écran dès que tu fais 'page suivante' au clavier, les pages ne sont pas centrés, il faut les recentrer.
Par contre, ça marche avec la fameuse barre de saut de page en bas, mais celle ci est restée en bas donc sur le coté et impossible de trouver ses boutons dans les raccourcis clavier.
Le comble c'est qu'il me semble qu'un des objectifs du projet KDE avec KDE4, c'était les nouveaux devices comme le eee.
Faut dire que le file selector typé gtk (ou gnome) je l'ai toujours trouvé nul, compliqué, anti ergonomique, pas configurable aisément bref loin de celui typé kde. Il fait partie des détails que j'apprécie chez KDE.
Ce n'est qu'une partie du problème.
L'autre partie, c'est que ça fait des années que c'est comme ça et quand tu discutais ou discutes toujours des problèmes de fonctionnalités ou de performances on te répond que l'HIG est géniale et que le file selector est génial parce que les boutons sont dans le bon ordre.
On m'a aussi dit que dans le logiciel libre c'est comme ça, les gens grattent ou ça les démange, il suffit d'attendre que quelqu'un s'y mette. C'est jamais arrivé.
On m'a aussi dit "ta gueule connard, t'as qu'à coder".
Et aussi que critiquer un boulot de bénévoles ça ne se faisait pas.
Donc je me suis tû pendant plusieurs années, et au final rien n'a changé.
Sauf qu'un jour je tombe sur un type qui avait les même problèmes et un type en face, mais un nouveau, lui ressort les mêmes arguments et le pourrit.
Sauf qu'à la fin, le défenseur du file selector avoue qu'il ne connait pas la fonctionnalité dont parlait l'autre et qu'il ne savait pas que le comportement était comme ça.
Donc, merde! (pas pour toi, le merde)
voilà c'était pour le troll gnome kde
Sauf que la situation est exactement la même pour kde maintenant. Les discussion comme les tab dans nautilus ou le mode spatial par défaut, tu as les même psychodrames dans kde maintenant par exemple avec okular et son UI de merde, où les développeurs ont refusé d'écouter les utilisateurs et ont fini par partir en chougnant après avoir dégouté des utilisateurs qui avaient fait pleins de tests et bien argumenté leur position ("vous etes pas des experts en UI!"c'est le nouveau "t'es pas codeur, ta gueule"); et les catastrophes comme la sortie de gnome2 ben tu as la même chose avec la sortie de KDE4.
Donc merde! (toujours pas)
Toi tu es président d'asso, à un nouveau membre qui dit "qu'il faudrait faire une action" tu répondrais plutôt, "dis donc connard, tu es pas président d'asso alors essaie de l'être avant de parler" ou "non, mais c'est parce que tu as l'habitude des grosses assos qui ont des moyens que tu croies qu'il faut faire ça mais non il faut pas, ça marche bien comme ça" ou "tu sais, on est pas nombreux, on a pas beaucoup de moyens, donc on va étudier ta proposition et ça serait bien si tu t'y mettais toi même d'ailleurs parce qu'on a vraiment une liste de truc à faire longue comme l'intestin qui est plus long que le bras comme chacun sait" ?
Je parie que tu prends pas les gens pour des cons.
je vois très bien ton problème d'utilisation ici mais il faut se méfier de grands aphorismes du genre "ceux qui ignorent l'interface de Photoshop sont condamnés à la réinventer
J'ai pas dit ça. J'utilisais paint shop pro parce que je n'aimais pas l'interface photoshop de l'époque. Je parlais des problèmes propre à gimp, je n'utilisais photoshop qu'en comparaison.
Je n'encense pas l'interface de photoshop ni ne veut descendre à priori celle de gimp.
Mais j'apprécie la facilité d'usage de l'interface de photoshop (quels que soient ses qualité et défaut par ailleurs) ce qui n'est pas le cas avec gimp, je suis obligé de me battre contre elle.
Je parlais aussi de l'attitude qui consiste à répondre aux gens qui émettent des critiques sur gimp soit en bashant photoshop soit en retournant la situation en disant que c'est eux le problème parce qu'ils utilisaient photoshop.
Les discussions dérapent, ne vont nulle part et ont n'extrait pas les points importants et réels de leur commentaire. Et la plupart des gens passent leur chemin, non pas parce qu'ils sont contre les notions de logiciels libres, mais qu'ils sont contre la notion de se faire prendre pour des cons.
dans ton cas précis, une meilleure intégration de Gimp à Gnome ou KDE consisterait à utiliser leurs file selector respectifs
C'est le cas de la distro que j'utilise et ça fait du bien. C'est une des raisons pour laquelle je l'utilise.
Les autres sont stabilité, packaging, infrastructure, innovation, originalité et contribution.
Un ensemble de facteurs que j'appelle intégration et qui est le travail d'une distro. Donc remplacer le file selector gtk peut en faire partie. Mais pas parce que "c'est pas du KDE". Ca, j'en ai rien à foutre.
puis réclamer un file selector avec vignettes, universel, qui prendra encore des années pour satisfaire 0.1%
Non, ça c'est la vraie solution, la seule (l'autre est batarde et peut être source de problèmes), et ça devrait être fait depuis plusieurs années.
Mais le file selector gtk n'est pas fait pour satisfaire les besoins de 90% des gens, ce qui pourrait être acceptable suivant son usage, mais par contre, il n'est pas fait pour satisfaire les besoins d'un utilisateur d'un logiciel graphique, et ça c'est un comble.
J’ai peut-être été plus cinglant que je ne le pensais.
Pareil.
Merci d’avoir détaillé un peu ce que tu trouves plus simple.
Puisque tu t'y intéresses réellement, voici un autre retour sur gimp.
Au niveau performances, j'ai travaillé sur des animations avec des dossiers qui contenait 20 et 30 000 images. Le dossier prend 10s à s'ouvrir dans le file selector gimp sur ma machine, et ensuite je n'avais pas de vignettes exploitables, je dois cliquer sur chaque image pour charger un aperçu. Ca prend beaucoup beaucoup de temps.
Mais même pour quelques images, c'est énervant.
Dans le file selector de KDE, j'ai des vignettes et le dossier de 30 000i prend ~1s pour s'ouvrir. Dans photoshop + XP sous virtualbox sur la même machine, pareil, ~1s.
4.4.3 ici, c'était peut être une régression de qt ou de kde mais j'ai parlé trop vite je crois que ça marche maintenant. Je suis en mode netbook et tout est borderless, mais chrome aussi. J'essaierai en mode desktop plus tard.
Quand j'active les bordures KDE dans chrome, la fonction "avancé > pas de bordures" ne fonctionne pas, les bordures restent, je voulais savoir si c'était pareil.
La vrai question est :
L’outil est-il inadapté ? Ou, va t-il juste à l’encontre de 15 ans d’utilisation différente d’un logiciel équivalent ?
Je peux te répondre dans l'autre sens puisque j'en ai fait l'expérience dernièrement.
Ca fait plus d'une dizaine d'année que j'utilise gimp, et je n'avais jamais touché à photoshop avant l'année dernière. J'avais bien utilisé paint shop pro il y a très lontemps.
J'ai utilisé psp récemment pour tester codeweaver wine et pour tester l'outil resynth contre le nouveau magic wand de psp. Donc psp CS2 et le dernier.
Le truc que ne comprennent pas ceux qui croit que le problème c'est d'être habitué à photoshop et de passer à gimp, c'est que ce que disent les personnes qui font état de leur expérience, même si forcément elles comparent avec ce qu'elles connaissent et donc parlent de psp, est surtout au sujet de gimp en lui même. Et le choc est grand.
Dans mon cas, ayant utilisé gimp, en passant à photoshop, non seulement j'ai tout trouvé tout de suite mais surtout les choses sont 10 fois plus rapides et simples. C'est pas que l'UI est super géniale ou sans défaut, mais elle est intuitive, allez, on va dire compréhensible et utilisable.
Un exemple, quand tu utilises un filtre, tu as pleins de fonctions (mais pleins) qui sont modifiables de façon aisée à la souris avec des visualisation rapides et qui ne s'affichent pas de façon obstructive. Et ça va vite.
Sous gimp, euh, disons que souvent quand tu fais quelque chose, tu as une popup qui se met entre toi et le dessin et il faut la bouger, 9 fois sur 10 tu n'as pas de visualisation, quand tu en as une, elle est minuscule, les options c'est des chiffres dans des champs, le file selector a des vignettes minuscules et des temps d'accés gigantesques, etc.
Le comble c'est comparer les performances de gimp en natif contre photoshop dans du virtualbox. Il se fait éclater.
Bon, je sais que pleins de choses sont en développement, par exemple pour les visualisations dont je parlais.
Mais dire à un pro dont le bifteack dépend de tout ça, "ben mon gars, allons, c'est juste une question d'habitude, tu vas t'y faire", ça revient à lui dire "faire tout 10 fois plus lentement avec 10 fois plus d'efforts tu vas t'y faire sinon c'est ta faute".
Ca ne marche pas.
Et j'ai pas parlé des pans de fonctionnalités entiers qui n'existent pas, genre le vectoriel. Avec psp tu peux en faire. Non, vraiment, à moins d'être d'une mauvaise fois sans borne, l'écart est énorme, et ce n'est pas toujours que parce que psp est bien.
Mais eh! L'écart est énorme dans l'autre sens aussi, le code de gimp est libre! C'est tout ce qui compte ...
Donc, ils vont faire une base solide,
Non, ils vont faire une base stable, c'est à dire une base pas du tout rolling, puisque rolling se traduit par instable/en développement quand on croit pas tout ce qui est écrit sur internet.
Elle sera aussi solide que arch l'est au moment où ils la figeront plus le travail qu'ils pourront fournir en fonction de leurs ressources moins le travail que va demander la mise au point de leurs outils moins le fait que ces outils vont avoir une phase de développement ou ils ne vont être ni solide ni stable, voire pire (genre "aaaaah ma bdd sqllite est corrompue, je peux plus installer ou désinstaller!!! keskejefait?").
Inutile de te dire que les probabilités que ce soit aussi stable ou solide qu'une des distros qui existent actuellement sont quasi nulles avant longtemps mais on peut espérer.
Enfin, pour des utilisateurs de arch, ça devrait pas leur faire peur, et ça ne peut qu'être plus stable.
avec une interface "cutting edge".
Oui, comme tout le monde qui a une distro, sauf qu'eux ils peuvent choisir en plus les paquets stables voire les paquets super stables supportés pendant x années.
Mais c'est génial \o/
Oui, ça s'appelle une distro! C'est fou!
Un truc de dingue qui est pas foutu en l'air quand xorg ou le kernel ou les drivers intel ou autres subissent une évolution. Et qui a aussi une version "rolling" pour les masochistes et les contributeurs qui s'appelle la version de développement!
C'est de la bombe, bébé!
Je suis en mode focus follow mouse depuis quelques années et la seule application qui me pose problème, c'est gimp, parce qu'elle est multi fenêtrée.
Quand tu es en mode "follow the mouse" et que tu as plusieurs images d'ouvertes, ce qui arrive tout le temps, quand tu travailles sur une image et que tu vas vers tes outils par exemple pour faire une opération sur les calques, , si tu passes au dessus d'une autre image sur le chemin ce qui arrive tout le temps, c'est elle qui est sélectionnée, et les opérations que tu effectueras auront lieu dans l'image intermédiaire mais pas dans celle d'origine. oups.
Donc tu passes ton temps à réorganiser tes fenetres pour éviter ça. Pleins de clics.
Ou alors tu désactives, la fonction focus follow mouse dans gimp. Ben oui, elle a été rajoutée dans GIMP pour qu'on puisse l'avoir dans gimp même en étant en "focus si click" dans le gestionnaire de fenêtre ( google chrome se fait crucifier pour beaucoup moins que ça question intégration).
Ah ben oui, mais là, la fenetre ne gagne plus le focus si tu cliques sur sa barre, il faut cliquer sur un menu ou sur l'image carrément. Donc si l'outil en cours c'est un pinceau, gros paté, si c'est le lasso, pleins de clics pour focus puis déselectionner.
Donc au final, tu finis par te servir des menus intégrés directement à la fenêtre pour éviter tout ça, et c'est pleins de clicks.
Ou alors tu utilises les raccourcis dynamiques pour attribuer des raccourcis aux fonctions monter ou descendre les calques par exemple; ce qui est au final la comportement idéal à utiliser avec gimp: clavier + souris.
Sauf que contrairement à blender qui est pensé dès le départ dans cette optique clavier et l'assume (ou l'assumait) dans un workflow efficcace, gimp est censé être pensé "fenêtre".
Mais entre le long héritage du passé, la volonté d'être original et le manque de développeurs, l'expérience utilisateur reste ce mélange de découverte des fonctions (faut la trouver l'option focus dans les préfs) et de contournement des problèmes, pour au final finir par passer par le clavier pour tout.
C'est ce genre de comportements qui font passer leur chemin aux débutants comme aux professionnels, et qui font dire que l'UI de gimp, c'est de la merde en boite. Sauf que c'est abusif et irrespectueux de parler comme ça d'un travail libre et bénévole.
Mais c'est tout autant abusif de dire des "t'as qu'à coder, connard" à des gens qui essaient de transmettre leur expérience et leur ressenti d'utilisateur; ou de leur dire sans réfléchir dans l'autre sens à la réalité des problèmes de l'UI de gimp et des utilisateurs qui le découvrent qu'il est trop génial et que tout va bien madame la marquise.
Voila le log de la réunion avec les parties où ils présentent leur plan d'une semi rolling distro basée sur arch afin de remplir leur mission de faire un desktop kde stable pour leurs utilisateurs ce qui n'est pas possible par dessus arch rolling qui est trop instable. Un core tiré de arch freezé pendant un an avec par dessus un KDE rolling. Plus une présentation des nouveaux outils ou projets conexes comme les paquets externes.
Au final on obtient quelque chose qu'on peut avoir avec une distro normale, garder sa distro dans une version stable et mettre une source "instable" de KDE pour avoir un KDE backporté de la version suivante, ce qu'ils appellent "rolling". Perso, c'est ce que je fais, et je mets à jour mon KDE tous les jours sans soucis.
Par contre, la différence qui n'est pas évidente à première vue, c'est que le core lui est mis à jour tous les ans au lieu de 6 mois. Donc au final, il a la possiblité d'être plus stable que les distros "6 mois", à condition qu'on puisse le garder et qu'il soit maintenu au delà de ces 6 mois. Ce qui n'est pas évident vu l'esprit "rolling distro" arch et leurs ressources. On verra.
[15:37:47] ok, to start: i think at least some of you have noticed that arch linux is a fine platform for what we want to deliver, but there are some little "annoyances"
[15:37:50] mainly:
[15:37:59] -.so bumps every few weeks
[15:38:25] -the general "freshness"
[15:38:37] -a lot of manual interaction needed (sometimes)
[15:39:14] everyone can see these problems when looking at the forums, _most_ of them are related to updates
[15:40:57] in one sentence: to do what we really want to do, we need a stable platform.
[15:44:01] <drf__> exactly. boom1992, the problem funkyou is trying to address is not the fact that arch is breaking on us, but that the rolling release model of arch is not suitable for what we want to achieve
[15:44:20] drf__: so what do we wnat to archieve? :)
[15:44:26] <drf__> basically
[15:44:30] <drf__> a half-rolling release model
[15:44:53] <drf__> so, having as funkyou said, a stable platform, which would be a "freezed" core
[15:45:04] <drf__> and on the top of that, our packaged kde+dependencies
[15:45:08] <drf__> rolling
[15:45:49] <drf__> to provide a stable system to users, which is exactly what we miss now. updates are breaking stuff and some times you need to do manual intervention
[15:46:04] <drf__> and that's also why ras0ir is here I suppose :)
[15:46:16] <drf__> there is a project called archserver
[15:46:25] <drf__> which is doing almost exactly what I told you
[15:46:46] <drf__> for everyone: http://www.archserver.org/
[15:47:20] <drf__> yes, definitely ras0ir could explain everyone better what archserver is and what they are trying to achieve
[15:47:48] ok let me tell some about archserver
[15:48:20] as you know, a server needs more stable packages compared to the rolling releases
[15:48:57] so we've decided to create a stable one
[15:49:04] stable as in debian or centos etc.
[15:49:30] we are thinking of releasing new versions a periodic basis
[15:49:37] on a*
[15:49:53] until a new release, we only get security patches to packages
[15:50:10] ras0ir: are you taking pkgbuilds an building it or you just using the binaries from arch repos?
[15:50:35] jofko: taking pkgbuilds and build them
[15:50:46] we're not taking binaries from arch repos
[15:52:22] How often does this 'release cycle' happen ?
[15:53:50] djszapi: it's not decided yet, but it'll be one release per year
[15:54:49] we might need to add some newer libs etc if needed on top of that when kde needs it ...
[15:55:57] so far there are 2 ideas:
[15:56:01] do the same like the archserver guys = sync core/extra/etc from arch once in a time and apply only bug-/security-fixes
[15:56:41] or (a small variation): work together with the archserver guys on their [server-core] and use that combined with timed snapshots from arch [extra]
[15:57:53] second sounds better for me since they do it a little longer than we ;) and we can trade code and devs
[15:58:03] <drf__> I favor the second option
[15:58:25] <drf__> of course some packages will diverge (kernel for example) but we already do that
[15:58:40] here is the whole idea: http://chakra-project.org/temp/core.png
[16:00:15] 1. we can strip down the archserver core a little bit, i am down at 155 pkgbuilds for [core]
[16:00:38] 2. the dependencies needed for kde: ~300 packages
[16:01:04] (this is with gtk/wx/tk etc, i guess we can strip that down quite a lot)
[16:02:00] funkyou: we can't? as we're not in sync with arch anymore?
[16:02:26] boom1992: well, thats the main thing: it wont be arch anymore, everything will be at our repos
[16:03:12] <drf__> boom1992: it's much more feasible than what appears - "extra" packages out of kde stuff would be handled in a slightly different way
[16:03:24] <drf__> and it will also be possible to sync with arch binaries
[16:04:05] <drf__> we have a ~year of a stable platform (and with platform I mean kernel 'n stuff)
[16:04:15] <drf__> and on the top of that, everything else rolling
[16:05:03] and the "everything else" wont be much, we will do it for kde only, no gtk, no other gui stuff, just based on Qt
[16:05:16] so we stick for example with kernel 2.6.32 series when arch has 2.6.35 for example
[16:05:17] <drf__> it's really not much more than what we do now
[16:05:32] we just take real control over releases
[16:05:45] <drf__> and if you consider the manpower which gets lost in fixing stuff during updates, you have the exact manpower needed for performing the additional packaging
[16:05:48] and I don't have all the troubles I've now with live-cds
[16:08:52] <drf__> do not make stuff "rolling" for the sake of having it rolling
[16:09:00] <drf__> but make stuff roll if it's feasible
[16:09:12] <drf__> now, suppose for a moment there is a conflict in package xyz
[16:09:18] <drf__> or an update on that breaks the whole kde
[16:09:29] <drf__> simply we don't sync that package any longer
[16:09:36] like X or so
[16:09:40] <drf__> the good thing about kde is that we won't have problems with so versions
[16:09:54] it all boils down to what we want: kde on an all-purpose platform (like arch) or KDE on a platform made for KDE (what we would do)
[16:09:54] <drf__> since we can rely on backends that work with older software (take policykit for example)
[16:10:32] for example I need older aufs2 to get livecd working
[16:10:35] <drf__> of course the goal is to deliver a stable platform, and update whenever possible
[16:10:52] <drf__> and to tailor this for
[16:15:39] "Our goal with Chakra is to provide a operating system for desktops that is easy to use, but still has all the functionality, clarity, power and speediness of a KISS operating system. In the long term, we want to build an operating system based on Arch Linux that meets most requirements desktop users have today, like easy installation of software, graphical system administration, configuring power management on mobile devices or sharing an internet connection."
[16:25:18] <drf__> so basically what I want to tell you is an idea that appears bad and controversial, but I urge you to let me finish before any critics :)
[16:25:40] <drf__> to the point: arch's pacman is no longer suitable for us.
[16:25:45] <drf__> now to the explaination
[16:25:53] <drf__> I know pacman pretty well - I hacked the shit out of it
[16:26:25] <drf__> aqpm "kinda" works, but will never be perfect. The problem with it is that simply libalpm is created to be run on a terminal, in a single-threaded blocking program
[16:26:30] <drf__> not really our use case
[16:26:54] <drf__> however, there is one good thing in all of this: pacman is extremely simple, and creating a clone is a matter of nothing
[16:27:02] <drf__> so basically, what is the idea?
[16:27:12] <drf__> create a "pacman clone" in Qt, with some added goodness
[16:27:27] <drf__> like a real database
[16:27:34] <drf__> (sqlite)
[16:27:47] <drf__> hooks in addition to scriptlets, mimetype associations and stuff
[16:28:40] <drf__> now, after some talks with funkyou, we also found out some stuff about bootstrapping and dependencies
[16:28:44] <drf__> this is the main idea
[16:28:52] <drf__> having a 2-level package manager
[16:29:39] <drf__> a library handling transactions (install, remove, stuff), and one handling sync operations (download, etc). Both would be very small and I already have a somewhat working POC. Guess what, it's smaller than aqpm and it manages to handle arch's packages basically
[16:29:56] <drf__> so we're to the point where still remains the problem of third party software
[16:30:16] <drf__> boom1992 was right: if we want to distribute firefox, but we don't package gtk and gecko, what the hell?
[16:30:25] <drf__> I have a solution for this, and it's called bundle
[16:30:53] <drf__> I'm studying a bundle system (integrated with the package manager) which would also be able to take binaries from arch's packages
[16:31:19] <drf__> so basically we would have third party software handled in a single file representing a filesystem (more or less like mac os)
[16:31:40] <drf__> and handle everything "extragear" this way.
[16:32:07] <drf__> in the bundle system? There's no KISS, but your system stays extremely clean and simple
[16:32:22] <drf__> and I can assure you the code needed for all of this is extremely simple
[16:32:35] <drf__> implementing this stuff seems hard, but it's really not
[16:34:15] drf__: so we need to "unpack" a program every time we run it?
[16:34:28] boom1992: no, we just mount an image i guess :)
[16:34:39] every freakin run
[16:34:41] sucks...
[16:34:48] and remember performance...
[16:36:12] <drf__> boom1992: why? trust me, bundles are just as fast as anything else
[16:36:12] and deps as well
[16:36:22] <drf__> boom1992: no deps, it's a bundle because of that
[16:36:37] drf__: so we go back to windows way to have deps installed like hundreds of times...
[16:36:39] <drf__> it is completely self contained except from system libraries
[16:36:44] we have gtk installed 4 times or wut?
[16:36:45] all the deps goes in the bundle
[16:36:48] <drf__> exactly
[16:36:57] firefox will be one pkg with all needed in it.
[16:37:02] yes so we have gtk installed 4 times for 4 differeent gtk progs
[16:37:12] <drf__> what is -not- present in our repo will go into the bundle
[16:41:04] <drf__> boom1992: ah, and bundles also have a strong plus: security
[16:41:11] <drf__> because everything is sandboxed
[16:40:23] so basically our goal is to get from distrolet -> distro
[16:40:36] yes, for the sake of our mission :)
[17:04:39] <drf__> the whole point is that I'm not saying this things just because I like to reinvent the wheel, and you know it, given what I do in kde
[17:05:00] <drf__> it's just because - if we want to reach the goal we have, we have to do some brave decisions
Donc deux mondes qui ne se fréquentent guère: d'un coté le monde des développeurs du libre, de l'autre celui des utilisateurs graphistes/artistes &Cie. Tant que ce deux mondes là ne travailleront pas ensemble
Oui, il faudrait que des graphistes rejoignent les développeurs.
Il ne suffit pas d'avoir du temps et des bras pour coder, faut il encore faire les bons choix.
Temps et bras qu'ils n'ont pas; mais ils ont du chocolat et du papier allu.
Posté par imr .
En réponse au journal Logicomix.
Évalué à 2.
Je ne sais pas qui l'a inventé mais la page wikipedia dit: Trade paperback of Will Eisner's A Contract with God (1978), one of the first books marketed as a "graphic novel", although the concurrent hardcover edition did not carry that label.
Je parie pour le service marketing de la boite. Et encore, je parie pas beaucoup.
Posté par imr .
En réponse au journal Logicomix.
Évalué à 8.
Cette dénomination est un peu étrange et on ne peut s'empêcher de se dire qu'elle a été inventée pour que certaines œuvres échappent à la dénomination jugée infamante de "bande-dessinée".
Ce terme vient des USA où il a été créé pour désigner les BDs d'inspirations européennes par rapport aux comics américains qui sortent en série de courts épisodes mais dont l'histoire générale ne finit souvent jamais.
Donc ce n'était pas infamant mais plutôt pour préciser une différence de nature. Un peu comme série/téléfilm pour la télé.
Tu peux rejoindre les équipes de développement parce que le développement est ouvert. Si tu n'arrives pas avec tes gros sabots en leur expliquant la vie mais en regardant d'abord leurs modes de travail et leurs contraintes puis en leur donnant ton retour et tes suggestions depuis ton point de vue d'utilisateur avancé/pro, ça leur sera utile s'ils ne sont pas déjà au courant de ce que tu avances.
Malheureusement, l'autre point, dont je parlais au dessus, c'est que souvent ces types ne sont pas idiots, qu'ils sont au courant de pas mal de choses déjà, mais ils manquent de devs, ils manquent de temps, il faut écrire ou réécrire des pans entiers du bouzin pour implémenter ces idées.
Donc parce que quelque chose n'est pas dans gimp, ça ne veut pas dire qu'ils ne veulent pas le faire, et même si tu les convaincs d'ajouter quelque chose, ça peut prendre longtemps à être implémenté.
Maintenant, c'est certain que quand on voit gimp, on voit que le workflow d'un graphiste, c'est pas leur priorité. Insérer ici une longue "critique/plainte/gueulante/hululement désespéré" sur le file selector de merde.
J'ai essayé chrome et j'ai bien aimé, pour une première release, c'était du beau travail.
Je suis resté à firefox parce qu'il est plus pratique à utiliser. Je m'étais fait une interface aussi épurée avec une ou deux extensions. J'ai rajouté les fonctionnalités qui me manquaient grace à des extensions, je peux facilement les gérer.
Je n'ai pas retrouvé cette facilité dans chrome, rien que vider la barre d'url est pénible, j'ai une mini icone pour ça dans ff.
Ce qui me manque dans ff, c'est pouvoir rajouter et utiliser puis enlever à la volée des extensions, parce que certaines sont consommatrices de perf. Je ne peux pas les laisser activées. Peut être que jetkit sera la solution.
Ce qui me fait peur avec ff, c'est le passage à des release tous les 6 mois et à vouloir rajouter des modifications importantes à chaque fois. J'ai peur qu'on tombe dans l'enfer des distros avec leurs régressions incessantes comme prix à payer pour les améliorations. C'est une peur seulement pour l'instant. L'architecture propre blahblah c'est bien si c'est releasé quand c'est prêt.
L'autre problème c'est que les développeurs d'extensions n'arrivent pas tous à suivre le rythme. Là aussi, peut être jetkit sera la solution.
C'est un double problème.
D'un coté, le logiciel est tellement avancé et les ressources tellement maigres, que les modifications nécessaires à son amélioration ne sont pas triviales à implémenter et ne peuvent pas être implémentées rapidement malgré la bonne volonté des devs. Exemple, le support du 16 bits qu'on attend depuis des années.
De l'autre, les devs laissent s'installer une réputation détestable même si immérité qui ne va pas contribuer à amener des contributeurs ou des utilisateurs. Cette réputation vient en général de loin, peut être même d'une période ou les dévs actuels n'étaient pas là.
A comparer avec la naissance et le travail de la fondation blender.
Et puis il sépare artificiellement pleins de domaines qui sont liés.
Economiquement, universal music fait partie du groupe vivendi, qui pèse ~25 Milliards, et qui comprend aussi des télécoms et de la gestion d'eau.
Socialement, séparrer les vêtements d'un coté et la culture de l'autre n'a aucun sens, pareil pour la nourriture.
Tout ça, c'est de la culture. La différence, comme dans les bénéfices dont tu parles, est dans les moyens de production, de diffusion et d'utilisation, et c'est pour ça que les différents bizness modèles ne sont pas comparables ou exportables à d'autres secteurs.
non, 901 minimum.
C'est d'autant plus dommage que les autres solutions à base de fbdev ne supportent pas sa résolution alors que là c'est un X donc ça aurait passé, enfin je crois.
Booter en X en quelques secondes, avoir une interface bien foutue, ça m'aurait intéressé.
Ben tant pis, ça m'apprendra à être un "early adopter", on finit toujours par se faire avoir.
Ca me donne envie de vomir de voir comment ont tourné certains de ses membres et de penser que j'allais voir tous leurs films, même les plus ratés, pour l'esprit de folie et d'imagination qu'ils montraient.
J'ai l'impression qu'il y a eu publicité mensongère, on te présente des bouffons, et tu te retrouve avec des auxiliaires de police.
Enfin, ils peuvent faire ce qu'ils veulent, ils arriveront jamais à contrebalancer coluche.
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 2.
Essaye sur un petit écran, par exemple le eee701 et apprends à détester la barre de saut de page en bas à cause de sa taille.
J'ai eu de gros problèmes de rendu sur un petit écran quand je faisais rotation pour profiter de la hauteur parce que 'adapter à la largeur, s'adapte toujours à la largeur au lieu de s'adapter à la hauteur (la nouvelle largeur). Donc il n'y a qu'adapter à la page qui marche mais c'est trop petit.
L'aperçu ne fonctionne plus, tu ne navigues plus de haut en bas mais latéralement.
Donc si tu zommes pour adapter la page à l'écran dès que tu fais 'page suivante' au clavier, les pages ne sont pas centrés, il faut les recentrer.
Par contre, ça marche avec la fameuse barre de saut de page en bas, mais celle ci est restée en bas donc sur le coté et impossible de trouver ses boutons dans les raccourcis clavier.
Le comble c'est qu'il me semble qu'un des objectifs du projet KDE avec KDE4, c'était les nouveaux devices comme le eee.
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 5.
Ce n'est qu'une partie du problème.
L'autre partie, c'est que ça fait des années que c'est comme ça et quand tu discutais ou discutes toujours des problèmes de fonctionnalités ou de performances on te répond que l'HIG est géniale et que le file selector est génial parce que les boutons sont dans le bon ordre.
On m'a aussi dit que dans le logiciel libre c'est comme ça, les gens grattent ou ça les démange, il suffit d'attendre que quelqu'un s'y mette. C'est jamais arrivé.
On m'a aussi dit "ta gueule connard, t'as qu'à coder".
Et aussi que critiquer un boulot de bénévoles ça ne se faisait pas.
Donc je me suis tû pendant plusieurs années, et au final rien n'a changé.
Sauf qu'un jour je tombe sur un type qui avait les même problèmes et un type en face, mais un nouveau, lui ressort les mêmes arguments et le pourrit.
Sauf qu'à la fin, le défenseur du file selector avoue qu'il ne connait pas la fonctionnalité dont parlait l'autre et qu'il ne savait pas que le comportement était comme ça.
Donc, merde! (pas pour toi, le merde)
voilà c'était pour le troll gnome kde
Sauf que la situation est exactement la même pour kde maintenant. Les discussion comme les tab dans nautilus ou le mode spatial par défaut, tu as les même psychodrames dans kde maintenant par exemple avec okular et son UI de merde, où les développeurs ont refusé d'écouter les utilisateurs et ont fini par partir en chougnant après avoir dégouté des utilisateurs qui avaient fait pleins de tests et bien argumenté leur position ("vous etes pas des experts en UI!"c'est le nouveau "t'es pas codeur, ta gueule"); et les catastrophes comme la sortie de gnome2 ben tu as la même chose avec la sortie de KDE4.
Donc merde! (toujours pas)
Toi tu es président d'asso, à un nouveau membre qui dit "qu'il faudrait faire une action" tu répondrais plutôt, "dis donc connard, tu es pas président d'asso alors essaie de l'être avant de parler" ou "non, mais c'est parce que tu as l'habitude des grosses assos qui ont des moyens que tu croies qu'il faut faire ça mais non il faut pas, ça marche bien comme ça" ou "tu sais, on est pas nombreux, on a pas beaucoup de moyens, donc on va étudier ta proposition et ça serait bien si tu t'y mettais toi même d'ailleurs parce qu'on a vraiment une liste de truc à faire longue comme l'intestin qui est plus long que le bras comme chacun sait" ?
Je parie que tu prends pas les gens pour des cons.
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 2.
J'ai pas dit ça. J'utilisais paint shop pro parce que je n'aimais pas l'interface photoshop de l'époque. Je parlais des problèmes propre à gimp, je n'utilisais photoshop qu'en comparaison.
Je n'encense pas l'interface de photoshop ni ne veut descendre à priori celle de gimp.
Mais j'apprécie la facilité d'usage de l'interface de photoshop (quels que soient ses qualité et défaut par ailleurs) ce qui n'est pas le cas avec gimp, je suis obligé de me battre contre elle.
Je parlais aussi de l'attitude qui consiste à répondre aux gens qui émettent des critiques sur gimp soit en bashant photoshop soit en retournant la situation en disant que c'est eux le problème parce qu'ils utilisaient photoshop.
Les discussions dérapent, ne vont nulle part et ont n'extrait pas les points importants et réels de leur commentaire. Et la plupart des gens passent leur chemin, non pas parce qu'ils sont contre les notions de logiciels libres, mais qu'ils sont contre la notion de se faire prendre pour des cons.
dans ton cas précis, une meilleure intégration de Gimp à Gnome ou KDE consisterait à utiliser leurs file selector respectifs
C'est le cas de la distro que j'utilise et ça fait du bien. C'est une des raisons pour laquelle je l'utilise.
Les autres sont stabilité, packaging, infrastructure, innovation, originalité et contribution.
Un ensemble de facteurs que j'appelle intégration et qui est le travail d'une distro. Donc remplacer le file selector gtk peut en faire partie. Mais pas parce que "c'est pas du KDE". Ca, j'en ai rien à foutre.
puis réclamer un file selector avec vignettes, universel, qui prendra encore des années pour satisfaire 0.1%
Non, ça c'est la vraie solution, la seule (l'autre est batarde et peut être source de problèmes), et ça devrait être fait depuis plusieurs années.
Mais le file selector gtk n'est pas fait pour satisfaire les besoins de 90% des gens, ce qui pourrait être acceptable suivant son usage, mais par contre, il n'est pas fait pour satisfaire les besoins d'un utilisateur d'un logiciel graphique, et ça c'est un comble.
[^] # Re: quant l'élite parle des autres
Posté par imr . En réponse au journal La boutique contre le bazar — the death of the open web. Évalué à 4.
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 2.
Pareil.
Merci d’avoir détaillé un peu ce que tu trouves plus simple.
Puisque tu t'y intéresses réellement, voici un autre retour sur gimp.
Au niveau performances, j'ai travaillé sur des animations avec des dossiers qui contenait 20 et 30 000 images. Le dossier prend 10s à s'ouvrir dans le file selector gimp sur ma machine, et ensuite je n'avais pas de vignettes exploitables, je dois cliquer sur chaque image pour charger un aperçu. Ca prend beaucoup beaucoup de temps.
Mais même pour quelques images, c'est énervant.
Dans le file selector de KDE, j'ai des vignettes et le dossier de 30 000i prend ~1s pour s'ouvrir. Dans photoshop + XP sous virtualbox sur la même machine, pareil, ~1s.
[^] # Re: Chrome et Ubuntu
Posté par imr . En réponse à la dépêche En vrac, les autres navigateurs. Évalué à 2.
[^] # Re: Une petite citation
Posté par imr . En réponse au journal La boutique contre le bazar — the death of the open web. Évalué à 5.
[^] # Re: Chrome et Ubuntu
Posté par imr . En réponse à la dépêche En vrac, les autres navigateurs. Évalué à 2.
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 6.
L’outil est-il inadapté ? Ou, va t-il juste à l’encontre de 15 ans d’utilisation différente d’un logiciel équivalent ?
Je peux te répondre dans l'autre sens puisque j'en ai fait l'expérience dernièrement.
Ca fait plus d'une dizaine d'année que j'utilise gimp, et je n'avais jamais touché à photoshop avant l'année dernière. J'avais bien utilisé paint shop pro il y a très lontemps.
J'ai utilisé psp récemment pour tester codeweaver wine et pour tester l'outil resynth contre le nouveau magic wand de psp. Donc psp CS2 et le dernier.
Le truc que ne comprennent pas ceux qui croit que le problème c'est d'être habitué à photoshop et de passer à gimp, c'est que ce que disent les personnes qui font état de leur expérience, même si forcément elles comparent avec ce qu'elles connaissent et donc parlent de psp, est surtout au sujet de gimp en lui même. Et le choc est grand.
Dans mon cas, ayant utilisé gimp, en passant à photoshop, non seulement j'ai tout trouvé tout de suite mais surtout les choses sont 10 fois plus rapides et simples. C'est pas que l'UI est super géniale ou sans défaut, mais elle est intuitive, allez, on va dire compréhensible et utilisable.
Un exemple, quand tu utilises un filtre, tu as pleins de fonctions (mais pleins) qui sont modifiables de façon aisée à la souris avec des visualisation rapides et qui ne s'affichent pas de façon obstructive. Et ça va vite.
Sous gimp, euh, disons que souvent quand tu fais quelque chose, tu as une popup qui se met entre toi et le dessin et il faut la bouger, 9 fois sur 10 tu n'as pas de visualisation, quand tu en as une, elle est minuscule, les options c'est des chiffres dans des champs, le file selector a des vignettes minuscules et des temps d'accés gigantesques, etc.
Le comble c'est comparer les performances de gimp en natif contre photoshop dans du virtualbox. Il se fait éclater.
Bon, je sais que pleins de choses sont en développement, par exemple pour les visualisations dont je parlais.
Mais dire à un pro dont le bifteack dépend de tout ça, "ben mon gars, allons, c'est juste une question d'habitude, tu vas t'y faire", ça revient à lui dire "faire tout 10 fois plus lentement avec 10 fois plus d'efforts tu vas t'y faire sinon c'est ta faute".
Ca ne marche pas.
Et j'ai pas parlé des pans de fonctionnalités entiers qui n'existent pas, genre le vectoriel. Avec psp tu peux en faire. Non, vraiment, à moins d'être d'une mauvaise fois sans borne, l'écart est énorme, et ce n'est pas toujours que parce que psp est bien.
Mais eh! L'écart est énorme dans l'autre sens aussi, le code de gimp est libre! C'est tout ce qui compte ...
[^] # Re: Chrome et Ubuntu
Posté par imr . En réponse à la dépêche En vrac, les autres navigateurs. Évalué à 2.
Clique droit sur la bordure, fais avance > pas de bordure, est ce que la bordure disparait?
[^] # Re: Rolling release
Posté par imr . En réponse au journal Chakra se sépare d'Arch. Évalué à 5.
Non, ils vont faire une base stable, c'est à dire une base pas du tout rolling, puisque rolling se traduit par instable/en développement quand on croit pas tout ce qui est écrit sur internet.
Elle sera aussi solide que arch l'est au moment où ils la figeront plus le travail qu'ils pourront fournir en fonction de leurs ressources moins le travail que va demander la mise au point de leurs outils moins le fait que ces outils vont avoir une phase de développement ou ils ne vont être ni solide ni stable, voire pire (genre "aaaaah ma bdd sqllite est corrompue, je peux plus installer ou désinstaller!!! keskejefait?").
Inutile de te dire que les probabilités que ce soit aussi stable ou solide qu'une des distros qui existent actuellement sont quasi nulles avant longtemps mais on peut espérer.
Enfin, pour des utilisateurs de arch, ça devrait pas leur faire peur, et ça ne peut qu'être plus stable.
avec une interface "cutting edge".
Oui, comme tout le monde qui a une distro, sauf qu'eux ils peuvent choisir en plus les paquets stables voire les paquets super stables supportés pendant x années.
Mais c'est génial \o/
Oui, ça s'appelle une distro! C'est fou!
Un truc de dingue qui est pas foutu en l'air quand xorg ou le kernel ou les drivers intel ou autres subissent une évolution. Et qui a aussi une version "rolling" pour les masochistes et les contributeurs qui s'appelle la version de développement!
C'est de la bombe, bébé!
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 4.
Quand tu es en mode "follow the mouse" et que tu as plusieurs images d'ouvertes, ce qui arrive tout le temps, quand tu travailles sur une image et que tu vas vers tes outils par exemple pour faire une opération sur les calques, , si tu passes au dessus d'une autre image sur le chemin ce qui arrive tout le temps, c'est elle qui est sélectionnée, et les opérations que tu effectueras auront lieu dans l'image intermédiaire mais pas dans celle d'origine. oups.
Donc tu passes ton temps à réorganiser tes fenetres pour éviter ça. Pleins de clics.
Ou alors tu désactives, la fonction focus follow mouse dans gimp. Ben oui, elle a été rajoutée dans GIMP pour qu'on puisse l'avoir dans gimp même en étant en "focus si click" dans le gestionnaire de fenêtre ( google chrome se fait crucifier pour beaucoup moins que ça question intégration).
Ah ben oui, mais là, la fenetre ne gagne plus le focus si tu cliques sur sa barre, il faut cliquer sur un menu ou sur l'image carrément. Donc si l'outil en cours c'est un pinceau, gros paté, si c'est le lasso, pleins de clics pour focus puis déselectionner.
Donc au final, tu finis par te servir des menus intégrés directement à la fenêtre pour éviter tout ça, et c'est pleins de clicks.
Ou alors tu utilises les raccourcis dynamiques pour attribuer des raccourcis aux fonctions monter ou descendre les calques par exemple; ce qui est au final la comportement idéal à utiliser avec gimp: clavier + souris.
Sauf que contrairement à blender qui est pensé dès le départ dans cette optique clavier et l'assume (ou l'assumait) dans un workflow efficcace, gimp est censé être pensé "fenêtre".
Mais entre le long héritage du passé, la volonté d'être original et le manque de développeurs, l'expérience utilisateur reste ce mélange de découverte des fonctions (faut la trouver l'option focus dans les préfs) et de contournement des problèmes, pour au final finir par passer par le clavier pour tout.
C'est ce genre de comportements qui font passer leur chemin aux débutants comme aux professionnels, et qui font dire que l'UI de gimp, c'est de la merde en boite. Sauf que c'est abusif et irrespectueux de parler comme ça d'un travail libre et bénévole.
Mais c'est tout autant abusif de dire des "t'as qu'à coder, connard" à des gens qui essaient de transmettre leur expérience et leur ressenti d'utilisateur; ou de leur dire sans réfléchir dans l'autre sens à la réalité des problèmes de l'UI de gimp et des utilisateurs qui le découvrent qu'il est trop génial et que tout va bien madame la marquise.
[^] # Re: Bien uzbl
Posté par imr . En réponse à la dépêche En vrac, les autres navigateurs. Évalué à 4.
[^] # Re: Rolling release
Posté par imr . En réponse au journal Chakra se sépare d'Arch. Évalué à 7.
Au final on obtient quelque chose qu'on peut avoir avec une distro normale, garder sa distro dans une version stable et mettre une source "instable" de KDE pour avoir un KDE backporté de la version suivante, ce qu'ils appellent "rolling". Perso, c'est ce que je fais, et je mets à jour mon KDE tous les jours sans soucis.
Par contre, la différence qui n'est pas évidente à première vue, c'est que le core lui est mis à jour tous les ans au lieu de 6 mois. Donc au final, il a la possiblité d'être plus stable que les distros "6 mois", à condition qu'on puisse le garder et qu'il soit maintenu au delà de ces 6 mois. Ce qui n'est pas évident vu l'esprit "rolling distro" arch et leurs ressources. On verra.
[15:37:47] ok, to start: i think at least some of you have noticed that arch linux is a fine platform for what we want to deliver, but there are some little "annoyances"
[15:37:50] mainly:
[15:37:59] -.so bumps every few weeks
[15:38:25] -the general "freshness"
[15:38:37] -a lot of manual interaction needed (sometimes)
[15:39:14] everyone can see these problems when looking at the forums, _most_ of them are related to updates
[15:40:57] in one sentence: to do what we really want to do, we need a stable platform.
[15:44:01] <drf__> exactly. boom1992, the problem funkyou is trying to address is not the fact that arch is breaking on us, but that the rolling release model of arch is not suitable for what we want to achieve
[15:44:20] drf__: so what do we wnat to archieve? :)
[15:44:26] <drf__> basically
[15:44:30] <drf__> a half-rolling release model
[15:44:53] <drf__> so, having as funkyou said, a stable platform, which would be a "freezed" core
[15:45:04] <drf__> and on the top of that, our packaged kde+dependencies
[15:45:08] <drf__> rolling
[15:45:49] <drf__> to provide a stable system to users, which is exactly what we miss now. updates are breaking stuff and some times you need to do manual intervention
[15:46:04] <drf__> and that's also why ras0ir is here I suppose :)
[15:46:16] <drf__> there is a project called archserver
[15:46:25] <drf__> which is doing almost exactly what I told you
[15:46:46] <drf__> for everyone: http://www.archserver.org/
[15:47:20] <drf__> yes, definitely ras0ir could explain everyone better what archserver is and what they are trying to achieve
[15:47:48] ok let me tell some about archserver
[15:48:20] as you know, a server needs more stable packages compared to the rolling releases
[15:48:57] so we've decided to create a stable one
[15:49:04] stable as in debian or centos etc.
[15:49:30] we are thinking of releasing new versions a periodic basis
[15:49:37] on a*
[15:49:53] until a new release, we only get security patches to packages
[15:50:10] ras0ir: are you taking pkgbuilds an building it or you just using the binaries from arch repos?
[15:50:35] jofko: taking pkgbuilds and build them
[15:50:46] we're not taking binaries from arch repos
[15:52:22] How often does this 'release cycle' happen ?
[15:53:50] djszapi: it's not decided yet, but it'll be one release per year
[15:54:49] we might need to add some newer libs etc if needed on top of that when kde needs it ...
[15:55:57] so far there are 2 ideas:
[15:56:01] do the same like the archserver guys = sync core/extra/etc from arch once in a time and apply only bug-/security-fixes
[15:56:41] or (a small variation): work together with the archserver guys on their [server-core] and use that combined with timed snapshots from arch [extra]
[15:57:53] second sounds better for me since they do it a little longer than we ;) and we can trade code and devs
[15:58:03] <drf__> I favor the second option
[15:58:25] <drf__> of course some packages will diverge (kernel for example) but we already do that
[15:58:40] here is the whole idea: http://chakra-project.org/temp/core.png
[16:00:15] 1. we can strip down the archserver core a little bit, i am down at 155 pkgbuilds for [core]
[16:00:38] 2. the dependencies needed for kde: ~300 packages
[16:01:04] (this is with gtk/wx/tk etc, i guess we can strip that down quite a lot)
[16:02:00] funkyou: we can't? as we're not in sync with arch anymore?
[16:02:26] boom1992: well, thats the main thing: it wont be arch anymore, everything will be at our repos
[16:03:12] <drf__> boom1992: it's much more feasible than what appears - "extra" packages out of kde stuff would be handled in a slightly different way
[16:03:24] <drf__> and it will also be possible to sync with arch binaries
[16:04:05] <drf__> we have a ~year of a stable platform (and with platform I mean kernel 'n stuff)
[16:04:15] <drf__> and on the top of that, everything else rolling
[16:05:03] and the "everything else" wont be much, we will do it for kde only, no gtk, no other gui stuff, just based on Qt
[16:05:16] so we stick for example with kernel 2.6.32 series when arch has 2.6.35 for example
[16:05:17] <drf__> it's really not much more than what we do now
[16:05:32] we just take real control over releases
[16:05:45] <drf__> and if you consider the manpower which gets lost in fixing stuff during updates, you have the exact manpower needed for performing the additional packaging
[16:05:48] and I don't have all the troubles I've now with live-cds
[16:08:52] <drf__> do not make stuff "rolling" for the sake of having it rolling
[16:09:00] <drf__> but make stuff roll if it's feasible
[16:09:12] <drf__> now, suppose for a moment there is a conflict in package xyz
[16:09:18] <drf__> or an update on that breaks the whole kde
[16:09:29] <drf__> simply we don't sync that package any longer
[16:09:36] like X or so
[16:09:40] <drf__> the good thing about kde is that we won't have problems with so versions
[16:09:54] it all boils down to what we want: kde on an all-purpose platform (like arch) or KDE on a platform made for KDE (what we would do)
[16:09:54] <drf__> since we can rely on backends that work with older software (take policykit for example)
[16:10:32] for example I need older aufs2 to get livecd working
[16:10:35] <drf__> of course the goal is to deliver a stable platform, and update whenever possible
[16:10:52] <drf__> and to tailor this for
[16:15:39] "Our goal with Chakra is to provide a operating system for desktops that is easy to use, but still has all the functionality, clarity, power and speediness of a KISS operating system. In the long term, we want to build an operating system based on Arch Linux that meets most requirements desktop users have today, like easy installation of software, graphical system administration, configuring power management on mobile devices or sharing an internet connection."
[16:25:18] <drf__> so basically what I want to tell you is an idea that appears bad and controversial, but I urge you to let me finish before any critics :)
[16:25:40] <drf__> to the point: arch's pacman is no longer suitable for us.
[16:25:45] <drf__> now to the explaination
[16:25:53] <drf__> I know pacman pretty well - I hacked the shit out of it
[16:26:25] <drf__> aqpm "kinda" works, but will never be perfect. The problem with it is that simply libalpm is created to be run on a terminal, in a single-threaded blocking program
[16:26:30] <drf__> not really our use case
[16:26:54] <drf__> however, there is one good thing in all of this: pacman is extremely simple, and creating a clone is a matter of nothing
[16:27:02] <drf__> so basically, what is the idea?
[16:27:12] <drf__> create a "pacman clone" in Qt, with some added goodness
[16:27:27] <drf__> like a real database
[16:27:34] <drf__> (sqlite)
[16:27:47] <drf__> hooks in addition to scriptlets, mimetype associations and stuff
[16:28:40] <drf__> now, after some talks with funkyou, we also found out some stuff about bootstrapping and dependencies
[16:28:44] <drf__> this is the main idea
[16:28:52] <drf__> having a 2-level package manager
[16:29:39] <drf__> a library handling transactions (install, remove, stuff), and one handling sync operations (download, etc). Both would be very small and I already have a somewhat working POC. Guess what, it's smaller than aqpm and it manages to handle arch's packages basically
[16:29:56] <drf__> so we're to the point where still remains the problem of third party software
[16:30:16] <drf__> boom1992 was right: if we want to distribute firefox, but we don't package gtk and gecko, what the hell?
[16:30:25] <drf__> I have a solution for this, and it's called bundle
[16:30:53] <drf__> I'm studying a bundle system (integrated with the package manager) which would also be able to take binaries from arch's packages
[16:31:19] <drf__> so basically we would have third party software handled in a single file representing a filesystem (more or less like mac os)
[16:31:40] <drf__> and handle everything "extragear" this way.
[16:32:07] <drf__> in the bundle system? There's no KISS, but your system stays extremely clean and simple
[16:32:22] <drf__> and I can assure you the code needed for all of this is extremely simple
[16:32:35] <drf__> implementing this stuff seems hard, but it's really not
[16:34:15] drf__: so we need to "unpack" a program every time we run it?
[16:34:28] boom1992: no, we just mount an image i guess :)
[16:34:39] every freakin run
[16:34:41] sucks...
[16:34:48] and remember performance...
[16:36:12] <drf__> boom1992: why? trust me, bundles are just as fast as anything else
[16:36:12] and deps as well
[16:36:22] <drf__> boom1992: no deps, it's a bundle because of that
[16:36:37] drf__: so we go back to windows way to have deps installed like hundreds of times...
[16:36:39] <drf__> it is completely self contained except from system libraries
[16:36:44] we have gtk installed 4 times or wut?
[16:36:45] all the deps goes in the bundle
[16:36:48] <drf__> exactly
[16:36:57] firefox will be one pkg with all needed in it.
[16:37:02] yes so we have gtk installed 4 times for 4 differeent gtk progs
[16:37:12] <drf__> what is -not- present in our repo will go into the bundle
[16:41:04] <drf__> boom1992: ah, and bundles also have a strong plus: security
[16:41:11] <drf__> because everything is sandboxed
[16:40:23] so basically our goal is to get from distrolet -> distro
[16:40:36] yes, for the sake of our mission :)
[17:04:39] <drf__> the whole point is that I'm not saying this things just because I like to reinvent the wheel, and you know it, given what I do in kde
[17:05:00] <drf__> it's just because - if we want to reach the goal we have, we have to do some brave decisions
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 3.
Oui, il faudrait que des graphistes rejoignent les développeurs.
Il ne suffit pas d'avoir du temps et des bras pour coder, faut il encore faire les bons choix.
Temps et bras qu'ils n'ont pas; mais ils ont du chocolat et du papier allu.
[^] # Re: roman graphique
Posté par imr . En réponse au journal Logicomix. Évalué à 2.
Trade paperback of Will Eisner's A Contract with God (1978), one of the first books marketed as a "graphic novel", although the concurrent hardcover edition did not carry that label.
Je parie pour le service marketing de la boite. Et encore, je parie pas beaucoup.
[^] # Re: roman graphique
Posté par imr . En réponse au journal Logicomix. Évalué à 3.
# roman graphique
Posté par imr . En réponse au journal Logicomix. Évalué à 8.
Ce terme vient des USA où il a été créé pour désigner les BDs d'inspirations européennes par rapport aux comics américains qui sortent en série de courts épisodes mais dont l'histoire générale ne finit souvent jamais.
Donc ce n'était pas infamant mais plutôt pour préciser une différence de nature. Un peu comme série/téléfilm pour la télé.
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 6.
Tu peux rejoindre les équipes de développement parce que le développement est ouvert. Si tu n'arrives pas avec tes gros sabots en leur expliquant la vie mais en regardant d'abord leurs modes de travail et leurs contraintes puis en leur donnant ton retour et tes suggestions depuis ton point de vue d'utilisateur avancé/pro, ça leur sera utile s'ils ne sont pas déjà au courant de ce que tu avances.
Malheureusement, l'autre point, dont je parlais au dessus, c'est que souvent ces types ne sont pas idiots, qu'ils sont au courant de pas mal de choses déjà, mais ils manquent de devs, ils manquent de temps, il faut écrire ou réécrire des pans entiers du bouzin pour implémenter ces idées.
Donc parce que quelque chose n'est pas dans gimp, ça ne veut pas dire qu'ils ne veulent pas le faire, et même si tu les convaincs d'ajouter quelque chose, ça peut prendre longtemps à être implémenté.
Maintenant, c'est certain que quand on voit gimp, on voit que le workflow d'un graphiste, c'est pas leur priorité. Insérer ici une longue "critique/plainte/gueulante/hululement désespéré" sur le file selector de merde.
[^] # Re: il n'y a pas que la vitesse, il y a la robustesse
Posté par imr . En réponse à la dépêche Mozilla continue d'avancer !. Évalué à 4.
Je suis resté à firefox parce qu'il est plus pratique à utiliser. Je m'étais fait une interface aussi épurée avec une ou deux extensions. J'ai rajouté les fonctionnalités qui me manquaient grace à des extensions, je peux facilement les gérer.
Je n'ai pas retrouvé cette facilité dans chrome, rien que vider la barre d'url est pénible, j'ai une mini icone pour ça dans ff.
Ce qui me manque dans ff, c'est pouvoir rajouter et utiliser puis enlever à la volée des extensions, parce que certaines sont consommatrices de perf. Je ne peux pas les laisser activées. Peut être que jetkit sera la solution.
Ce qui me fait peur avec ff, c'est le passage à des release tous les 6 mois et à vouloir rajouter des modifications importantes à chaque fois. J'ai peur qu'on tombe dans l'enfer des distros avec leurs régressions incessantes comme prix à payer pour les améliorations. C'est une peur seulement pour l'instant. L'architecture propre blahblah c'est bien si c'est releasé quand c'est prêt.
L'autre problème c'est que les développeurs d'extensions n'arrivent pas tous à suivre le rythme. Là aussi, peut être jetkit sera la solution.
[^] # Re: Krita != Gimp
Posté par imr . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 7.
D'un coté, le logiciel est tellement avancé et les ressources tellement maigres, que les modifications nécessaires à son amélioration ne sont pas triviales à implémenter et ne peuvent pas être implémentées rapidement malgré la bonne volonté des devs. Exemple, le support du 16 bits qu'on attend depuis des années.
De l'autre, les devs laissent s'installer une réputation détestable même si immérité qui ne va pas contribuer à amener des contributeurs ou des utilisateurs. Cette réputation vient en général de loin, peut être même d'une période ou les dévs actuels n'étaient pas là.
A comparer avec la naissance et le travail de la fondation blender.
[^] # Re: bénéfices != revenus
Posté par imr . En réponse au journal Modèle économique de la mode... transposable en informatique?. Évalué à 2.
Economiquement, universal music fait partie du groupe vivendi, qui pèse ~25 Milliards, et qui comprend aussi des télécoms et de la gestion d'eau.
Socialement, séparrer les vêtements d'un coté et la culture de l'autre n'a aucun sens, pareil pour la nourriture.
Tout ça, c'est de la culture. La différence, comme dans les bénéfices dont tu parles, est dans les moyens de production, de diffusion et d'utilisation, et c'est pour ça que les différents bizness modèles ne sont pas comparables ou exportables à d'autres secteurs.
[^] # Re: ça va déboiter!
Posté par imr . En réponse à la dépêche Sortie de MeeGo 1.0. Évalué à 4.
C'est d'autant plus dommage que les autres solutions à base de fbdev ne supportent pas sa résolution alors que là c'est un X donc ça aurait passé, enfin je crois.
Booter en X en quelques secondes, avoir une interface bien foutue, ça m'aurait intéressé.
Ben tant pis, ça m'apprendra à être un "early adopter", on finit toujours par se faire avoir.
# splendide le splendid
Posté par imr . En réponse à la dépêche Big Brother Awards 2010. Évalué à 4.
J'ai l'impression qu'il y a eu publicité mensongère, on te présente des bouffons, et tu te retrouve avec des auxiliaires de police.
Enfin, ils peuvent faire ce qu'ils veulent, ils arriveront jamais à contrebalancer coluche.
[^] # Re: Richard Stallman ?
Posté par imr . En réponse au journal Toi aussi aide le BSA. Évalué à 8.
Je le verrai plutôt en Robinson.