Retourner aux forums || Retourner au forum Programmation.autre
Programmation.autre : Gtk, TreeModel et base de données
Posté par Bouil (Jabber id, page perso, ) le 15 juin 2005J'aimerai implémenter un GtkTreeModel qui prends ses données depuis une base de donnée. En effet, le TreeStore ou le ListStore m'obligent a charger toutes les données dans le modèle, et j'ai peur que ça rame beaucoup puisque j'ai plusieurs milliers d'enregistrement à afficher.
J'ai déjà utilisé quelque chose de similaire en Java ( http://www.bouil.org/index.php/ResultSetTableModel(...) ), mais je ne sais pas trop comment faire avec Gtk.
Je suppose qu'il faut également hériter de http://www.gtk.org/api/2.6/gtk/GtkTreeModel.html(...) afin d'implémenter les bonnes méthodes.
Si quelqu'un à déjà fait cela, ou a quelque pistes, dans n'importe quel langage, j'adapterai (mais c'est pour faire en Ada).
Merci
« La clé d'une langue commune, perdue dans la Tour de Babel, peut être seulement construite par l'usage de l'Espéranto. » Jules Verne.
Construction dynamique
Au début tu crées ton arbre plié et vide et quand quelqu'un déplie une branche, tu fais la requête pour remplir cette branche.
-
[^]Re: Construction dynamique
Posté par Bouil (Jabber id, page perso, ) le 15/06/2005 à 09:56. (lien). Évalué à 2.Le problème, c'est que ce ne sera pas une structure d'arbre, mais bien un listing. Il n'y aura, a priori, aucun dépliage à faire, juste une liste avec quelques colonnes.
Merci quand même :-)--
« La clé d'une langue commune, perdue dans la Tour de Babel, peut être seulement construite par l'usage de l'Espéranto. » Jules Verne.-
[^]Re: Construction dynamique
Posté par TImaniac (page perso, ) le 15/06/2005 à 10:04. (lien). Évalué à 2.Rempli ta liste dans un thread, ca sera plus simple que de t'amuser à implémenter les 10000 méthodes de GTKTreeModel.
-
[^]Re: Construction dynamique
Posté par Bouil (Jabber id, page perso, ) le 15/06/2005 à 10:19. (lien). Évalué à 2.Au delà du temps que ça peut prendre pour charger les données, c'est aussi l'utilisation de la mémoire qui me préoccupe...
Et si le Gtk TreeModel est pas trop mal foutu, il ne devrait pas y avoir trop de méthode a implémenter... si ? :-(--
« La clé d'une langue commune, perdue dans la Tour de Babel, peut être seulement construite par l'usage de l'Espéranto. » Jules Verne.-
[^]Re: Construction dynamique
Posté par TImaniac (page perso, ) le 15/06/2005 à 11:59. (lien). Évalué à 2.De toute façon à un endroit ou autre il va te falloir un tampon pour stocker la valeur à afficher dans le treeview, alors que tu t'amuses à le gérer toi même ou que tu laisses le TreeModel dispo ne changera pas grand chose question mémoire. J'ai peur que tu veuilles te prendre la tête pour pas grand chose.
De plus cela oblige ton code métier à implémenter une interface spécifique à un toolkit graphique, c'est vraiment douteux d'un point de vu méthodologique.-
[^]Re: Construction dynamique
Posté par Bouil (Jabber id, page perso, ) le 15/06/2005 à 12:52. (lien). Évalué à 2.De toute façon à un endroit ou autre il va te falloir un tampon pour stocker la valeur à afficher dans le treeview, alors que tu t'amuses à le gérer toi même ou que tu laisses le TreeModel dispo ne changera pas grand chose question mémoire. J'ai peur que tu veuilles te prendre la tête pour pas grand chose.
L'avantage de piocher dans un recordset, c'est que lui fait un tampon transparent vers la base de donnée, en l'interogant si nécessaire. Donc toutes les infos ne seront pas forcement en mémoire.
De plus cela oblige ton code métier à implémenter une interface spécifique à un toolkit graphique, c'est vraiment douteux d'un point de vu méthodologique.
Mon modèle retournera un RecordSet, que ma vue doit afficher en utilisant Gtk. Je vois pas bien le probleme de créer un nouveau widget à ce niveau.
Ceci dit, je vais quand meme essayer avec le GtkListStore. On verra bien ce que ça donne.--
« La clé d'une langue commune, perdue dans la Tour de Babel, peut être seulement construite par l'usage de l'Espéranto. » Jules Verne.-
[^]Re: Construction dynamique
Posté par TImaniac (page perso, ) le 15/06/2005 à 13:07. (lien). Évalué à 2.L'avantage de piocher dans un recordset, c'est que lui fait un tampon transparent vers la base de donnée, en l'interogant si nécessaire. Donc toutes les infos ne seront pas forcement en mémoire.
Sauf qu'à priori le TreeView va chercher à charger toutes les données, bref il va demander toutes les items et ton recordset sera plein. D'autant plus pleins qu'il y aura dedans pleins d'informations peut être inutile qui ne sont aps afficher. Avec une méthode sans recordset le tampon est uniquement constitué d'une chaîne de caractère.
Je vois pas bien le probleme de créer un nouveau widget à ce niveau.
Qui va implémenter l'interface GtkTreeModel ?-
[^]Re: Construction dynamique
Posté par Bouil (Jabber id, page perso, ) le 15/06/2005 à 13:44. (lien). Évalué à 2.à priori le TreeView va chercher à charger toutes les données, bref il va demander toutes les items
J'ose espérer qu'il ne fait pas ça, ça serait completement stupide. Imagine un modèle qui contient plusieurs millions de lignes... L'utisation du TreeModel de Java est très facile et le TreeView ne va pas interoger le modele pour obtenir les lignes qu'il n'a pas besoin.
Je vois pas bien le probleme de créer un nouveau widget à ce niveau.
Qui va implémenter l'interface GtkTreeModel ?
Oui, mais j'ai dit widget par erreur. C'est juste l'interface GtkTreeModel.
Enfin bref, je verrai bien ce que ça donne avec le ListStore.--
« La clé d'une langue commune, perdue dans la Tour de Babel, peut être seulement construite par l'usage de l'Espéranto. » Jules Verne.-
[^]Re: Construction dynamique
Posté par TImaniac (page perso, ) le 15/06/2005 à 13:53. (lien). Évalué à 2.J'ose espérer qu'il ne fait pas ça, ça serait completement stupide.
Même s'il ne le fait pas en une fois, tôt ou tard l'utilisateur va chercher à scroller et le nombre de requête à ta bdd risque d'augmenter assez rapidement.
Enfin imagine par exemple que ta bdd réponde en 1 seconde (charge réseau, table énorme à fouiller, etc.), t'imagine le joli freeze ?
Thread je te dis, thread :)
-
-
-
[^]Re: Construction dynamique
Posté par TImaniac (page perso, ) le 15/06/2005 à 13:09. (lien). Évalué à 2.Ah oui et je t'explique pas le raaaamage si jamais la requête à la bdd est de l'ordre du 10ème de seconde : pour chaque node que le treeview va chercher à afficher il va interroger ton implémentation, et donc ton dataset, et donc ta bdd... ouch !
Le remplissage depuis un thread t'évitera tous ces problèmes, et tu auras forcement besoin d'un tampon, le ListStore sert à ca.
-
-
-
-
-
[^]Re: Construction dynamique
Posté par Pascal Terjan (Jabber id, page perso, ) le 15/06/2005 à 10:36. (lien). Évalué à 2.Si tu veux que la liste soit affichée, il faut que les données y soient, non ? Tu voudrais que ca les cherches dans la base de données à chaque fois que tu scrolles ?
-
[^]Re: Construction dynamique
Posté par Bouil (Jabber id, page perso, ) le 15/06/2005 à 11:23. (lien). Évalué à 2.Oui, c'est tout a fait ce que fait le code Java donné en exemple. Bien sûr, cela est relativement facile car effectué depuis un RecordSet.
On récupere juste les données demandées depuis le recordset, et le nombre de lignes suffisent pour afficher l'ascenceur correctement.
J'ai trouvé un ou deux trucs dans Rhythmbox ( http://cvs.gnome.org/viewcvs/rhythmbox/rhythmdb/DESIGN?rev=1.4(...) ) qui pourront peut etre m'aider, faut voir, faut que je fouille dans le source...
Sinon, faut que je regarde dans gnome-db, mais bon, j'aimerai quelque chose en gtk, pour que ce soit portable sous Windows.--
« La clé d'une langue commune, perdue dans la Tour de Babel, peut être seulement construite par l'usage de l'Espéranto. » Jules Verne.
-
-
Revenir en haut de page || Retourner aux forums || Retourner au forum Programmation.autre
Cette page a été générée par Templeet en 0.0837s (dont 0.0058 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.