Re: RE: [Tsp-devel] Bravo gdisp+

[Eric NOULARD]

Selon address@hidden:

> Bon on arrête là les louanges...
> J'attends plutôt mon PC 3 Ghz tout neuf...
> Private Joke...
>
> Pour l'autoscalling sur l'axe X, personnellement, il ne
> me plaits pas. Ne me plait pas non plus le look des axes
> fournis par le widget GtkRule de Gtk.
> Je voudrais bien ré-implémenter tout ça pour avoir des
> axes qui prennent moins de place. Faut voir ça ensemble.
>
> Pour l'instant, pouvez-vous me dire TRES PRECISEMENT ce
> qui ne va pas ?

0) Le problème le plus important [pour moi]
   est un déconnage APPARENT de l'autoscaling sur ma Mdk10
   ou visiblement tout autre distrib' utilisant la NPTL
   (j'ai testé chez un client sur RedHat et Gentoo)
    On obtient des traits discontinus hératiques pendant
    "un certain temps" avant que l'autoscaling 'accroche'
    et trace enfin une courbe???
   Je peux pas faire de screenshot car je suis pas sur mon PC
   dès que j'ai moyen d'en faire un je le fais.
   Yves à constaté le pb aussi.

1) L'autoscaling en Y est capable de faire le zoom OUT
   i.e. les valeurs en Y grandissent mais pas
   le zoom IN quand les valeurs en Y on rediminuées et
    que les dernières "grandes valeurs" ne sont plus dans
    le champs des abscisses visibles.

2) Tu as raisons pour l'autoscaling en X on doit clairement
   pouvoir CHOISIR:
    - choisir un range de X visible manuellement
    - choisir une "durée" de X quand on sait que X
      a le comportement d'une variable temporelle
      (strictement positive et croissante)
>
> Autre chose : adieu le "click & click" à la Gégé. Je ne pense
> pas l'implémenter tout de suite car il faut que je creuse beaucoup
> plus, la faute au plot text pour lequel je ne peux pas outrepasser
> la gestion du click. Click = sélection et c'est tout.
> Je pense que la sauvegarde XML est plus importante (Sorry Gégé, mais
> il ne le saura jamais).

   Ben si il le saura je vais lui dire :))
   Que tu as raison la sauvegarde est plus importante.

>
> Pour le Drop en cours de run, je suis surpris. Certes c'est plus robuste
> mais un nouveau symbole dans un plot ne sera tracé que si il l'est déjà
> dans un autre plot. Car je ne re-programme pas le flux entre le provider
> et gdisp+.
   Ben je suis tombé sur un cas qui marche :))
>
> Pour terminer, je commence ASAP la sauvegarde XML. D'abords l'implémentation
> dans le kernel et les plots. Dois-je attendre la spec d'Eric quant au
> format XML ?
   La sauvegarde XML toi s'appuyer sur une lib externe aux consumer.
   Genre la libpages (src/util/libpage/) de gdisp--.
   J'ai un WE calme donc je vais sortir un draft de spec rapidement.

   Par contre je pense que tu devrais commencer par utiliser
   la libpage ACTUELLE  pour une LECTURE de conf mono-provider
   ou alors LECTURE d'un fichier par provider.
   Comme ça tu auras un regard critique aiguisé sur la "spec" actuelle
   pour critiquer ACTIVEMENT celle qui viendra.
   Je dis LECTURE car je ne sais même pas si la libpage ACTUELLE permet
   la sauvegarde....

   L'objectif étant bien que même si tu utilises la libpage ACTUELLE
   ça te coutes pas beaucoup de changements [côté gdisp+] pour passer
   à une autre lib .
>
> Esteban.
>
> -------------
>
>
>
>
>
>
>
> 29/10/04 11:05:32, TSP <address@hidden> wrote:
>
> >La regression dont tu parles sur tsp_gdisp m'a l'air de venir depuis que
> >nous utilisons la MDK10.0
> >En effet Stephane n'a pas ce genre de problemes, mais je lui avait déja
> >relévé le bug de l'autoscrolling qui se décale au fur et à mesure vers la
> >droite.
> >Y++
> >
> >> -----Original Message-----
> >> From: NOULARD Eric [mailto:address@hidden
> >> Sent: Thursday, October 28, 2004 10:15 PM
> >> To: Devel TSP
> >> Subject: [Tsp-devel] Bravo gdisp+
> >>
> >>
> >>
> >> Je dois tirer mon chapeau à gdisp+ ce soir
> >> car je l'ai testé après un update -A
> >> et:
> >>
> >> 1) il est désormais robuste au drag&drop
> >>    en cours de run
> >>
> >> 2) le drag&drop est désormais super facile
> >>    grace au X et Y en surimpression
> >>
> >> 3) Je l'ai testé avec 2 providers locaux
> >>    et fait un tracé Y_provider1 = F(X_provider2)
> >>    et ça marche !!
> >>    Bon évidemment j'ai un peu triché car j'ai lancé
> >>    2 bb_provider de même fréquence qui attaque en fait
> >>    le même Blackboard!!!
> >>    [c'est pas trop prévu pour mais ça fonctionne
> >>     sauf que les 2 bb_provider se 'partagent'
> >>     la fréquence de production de la pseudo
> >>     simulation [bb_test -s] qui
> >>
> >> 4) Encore plus fort [débile] j'ai lancé 3 provider
> >>      2 bb_provider sur le même blackboard
> >>      1 stub_server
> >>    J'ai demander à gdisp+ de tracer
> >>       bb_provider1::bb_test_Toto[1]
> >>       bb_provider2::bb_test_Toto[2]
> >>       en fonction
> >>       de stub_server::t
> >>    Et ça marche!!
> >>    J'ai des escaliers car le stub est à 100Hz et
> >>    les bb_provider des 'pseudo' 2x32Hz (64/2)
> >>
> >> On va bientôt pouvoir faire une démo de tueur!!
> >> Je vais m'activer pour fournir une spec de fichier de conf
> >> pour les consumer et on aura bientôt un gdisp+ qui va
> >> en faire pleurer plus d'un.
> >>
> >> Toutefois gdisp+ souffre encore d'une lacune rédhibitoire qui
> >> est un [très] mauvais auto-scaling, courbe crénelée, saut etc...
> >> Est-ce qu'une bonne âme pourrait [aurait le temps]
> >> s'attaquer au problème?
> >> [perso c'est pas trop mon rayon]
> >>
> >> Eric
> >>
> >> --
> >> Eric NOULARD
> >> E-mail: address@hidden
> >>
> >>
> >>
> >> _______________________________________________
> >> Tsp-devel mailing list
> >> address@hidden
> >> http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >>
>
>
>
>


--
---
Erk