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

[stef . vnrq]

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 ?

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).

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+.

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 ?

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
>>