Directement à partir du dock, je sais pas mais ouvrir ton logiciel de calendrier et créer un évènement ça ne doit pas prendre tellement de temps.
Oh non, c'est sûr. Ouvrir un accès à une base de données. Balancer une requête d'écriture. Garder en mémoire le moment fatidique. Quand le moment fatidique approche, le rappeler à l'utilisateur.
Facile.
Bon, derrière, ça implique de choisir un moteur de base de données. D'architecturer correctement la-dite base, en fonction de l'ensemble des fonctionnalités désirées (présentes et futures, hein, pas juste celles que l'on imagine au moment exact ou l'on imagine le logiciel). Et tant qu'à faire il faut un mécanisme d'IPC pour dialoguer avec l'outil qui signalera à l'utilisateur l'arrivée du moment fatidique. Audio ou visuel, d'ailleurs, le signal?
La complexité, c'est une affaire de code, mais aussi de choix technique. Admettons qu'on prenne un SGBDR, solution de facilité (bien sûr qu'on peut simplement utiliser un fichier plat, voire peut-être même jouer avec des outils standard style at et cron, mais je doute que ce serait la solution retenue par la majorité des développeurs). Ben, ça implique d'avoir potentiellement un nouveau daemon qui tourne non-stop, les SGBDR sont des outils avec un fort coût mémoire et CPU. Je ne parle même pas du problème de configuration, en général ces outils protègent leurs bases avec des couples login/password (oui, je suis au courant pour sqlite, j'ai dit: en général).
Ensuite, le mécanisme d'IPC, y'a un truc relativement standard de nos jours. Dbus qu'il s'appelle. Encore une dépendance à un daemon.
Bref, pour une fonctionnalité qui ne sera peut-être pas utilisée par la majorité des utilisateurs, on ajoute quand même pas mal de dépendances, de risques de bugs et de failles, de lourdeur.
Alors, est-ce vraiment si simple de faire le choix d'implémenter cette fonctionnalité?
Bon, pour le reste, je suis plutôt d'accord... avec vous deux:
nos systèmes sont composés d'un patchwork de programmes développés par tout un chacun, mais ça n'empêche pas que ça marche très bien, bien mieux que Windows la dernière fois que j'ai eu à l'utiliser. Ça n'empêche qu'en terme d'ergonomie, Windows est battu à plate couture aussi: moi, je n'alterne pas constamment entre la souris et le clavier quand je suis sur ma machine, privilège inconnu des utilisateurs de Windows. Ah, certes, ce n'est peut-être pas hyper joli... mais en fait, l'esthétique, c'est une notion purement subjective, et mon i3 sans décoration de fenêtre, transparence et coins arrondis, je le trouve joli, moi. J'ai des goûts de chiotte, je sais :)
oui, les projets libres ont besoin de plus de ressources, tant financières qu'humaines, et je doute aussi que si je faisais un compte paypal ou je ne sais quoi, le fisc viendrait m'emmerder parce que j'ai reçu 10€ de mes utilisateurs. Bien entendu, à l'échelle d'entreprises ou d'associations, cette dernière assertion change, mais la majorité des logiciels que j'utilise ne me semble pas développée par des associations (au sens légal du terme) ou entreprises.
[^] # Re: éternel problème de la contribution
Posté par freem . En réponse au journal Ce que Linux aurait du devenir ces 15 dernières années.... Évalué à 5.
Oh non, c'est sûr. Ouvrir un accès à une base de données. Balancer une requête d'écriture. Garder en mémoire le moment fatidique. Quand le moment fatidique approche, le rappeler à l'utilisateur.
Facile.
Bon, derrière, ça implique de choisir un moteur de base de données. D'architecturer correctement la-dite base, en fonction de l'ensemble des fonctionnalités désirées (présentes et futures, hein, pas juste celles que l'on imagine au moment exact ou l'on imagine le logiciel). Et tant qu'à faire il faut un mécanisme d'IPC pour dialoguer avec l'outil qui signalera à l'utilisateur l'arrivée du moment fatidique. Audio ou visuel, d'ailleurs, le signal?
La complexité, c'est une affaire de code, mais aussi de choix technique. Admettons qu'on prenne un SGBDR, solution de facilité (bien sûr qu'on peut simplement utiliser un fichier plat, voire peut-être même jouer avec des outils standard style
atetcron, mais je doute que ce serait la solution retenue par la majorité des développeurs). Ben, ça implique d'avoir potentiellement un nouveau daemon qui tourne non-stop, les SGBDR sont des outils avec un fort coût mémoire et CPU. Je ne parle même pas du problème de configuration, en général ces outils protègent leurs bases avec des couples login/password (oui, je suis au courant pour sqlite, j'ai dit: en général).Ensuite, le mécanisme d'IPC, y'a un truc relativement standard de nos jours. Dbus qu'il s'appelle. Encore une dépendance à un daemon.
Bref, pour une fonctionnalité qui ne sera peut-être pas utilisée par la majorité des utilisateurs, on ajoute quand même pas mal de dépendances, de risques de bugs et de failles, de lourdeur.
Alors, est-ce vraiment si simple de faire le choix d'implémenter cette fonctionnalité?
Bon, pour le reste, je suis plutôt d'accord... avec vous deux: