Re: [Tsp-devel] GDisp+ sous Gtk+ 2.6

[Eric NOULARD]

Je remets le mail d'Yves sur le tapis
de tsp-devel car je crois qu'il n'as pas atteind la liste
à cause d'un reply simple.

J'y ajoute mes commentaires :))

Le lundi 31 octobre 2005 à 20:57 +0100, dufy a écrit :
> Salut les TSPistes.
> 
> Bon c'est vrai que je suis pénible, mais je voulais faire juste une
> piqure de rappel.
> On est resté en gtk 1.2.10, car quand le même Euhcequidi a voulu
> tester le GTK2.0 sur nos bonnes vielles SUN, il a du tirer une
> quantité de libs faramineuses liés à PANGO et ses copains du genre
> "fontes lissées".

Le problème du tirage de nombreuses libs tient à l'architecture
de la lib GTK qui s'est enrichie et donc au lieu d'avoir "un"
poid lourd il y a plusieurs poid moyen ou léger interdépendant.
Comme GTK est (vue ma compréhension) la lib de plus haut niveau
du lot ben c'est elle qui tire le plus de dépendance.
Je ne connais pas l'archi. de GTK et ses amis mais c'est peut-être
inévitable?

Le vrai pb est que sur des "vieilles" machines/systèmes ces libs ne sont
pas installées mais est-ce une "bonne" façon de se contraindre?

> Je suis pour suivre l'évolution, mais quasiment certain de ne pas
> arriver à compiler tsp_gdisp++ en GTK2.x sur nos SUN. Alors que faire
> sachant que je dois garder Solaris 2.6 et OSF/Dec:

http://www.sun.com/software/solaris/releases.xml
nous dit:

Solaris 2.6 Operating Environment

      * Releases prior to the Solaris 7 OE did not have updates, but
        rather had occasional hardware-specific platform releases.
      * The last hardware platform release was Solaris 2.6: HW 5/98
      * The Solaris 2.6 OE stopped shipping on July 23rd, 2001 and is
        currently at the "Vintage Phase II" support level.
      * End-of-support will be July 23, 2006.
      * 

Donc il suffit d'attendre Juillet 2006 :))

Concernant la situation pour DEC-OSF je pense que c'est ... pire.
Sauf erreur de ma part DEC a été racheté par Compaq qui a lui
même été racheté par HP.
Aujourd'hui HP incite ses clients à la transition vers un
HP-UX 11i qui intégrerat toute les fonctionnalité
du Tru64 Unix et HP-UX avec un statut un peu flou pour OpenVMS:
http://www.hp.com/products1/evolution/alpha_retaintrust/transition_guide.html

quoiqu'il en soit je n'ai même pas trouvé trace de DEC-OSF :((

Donc 'vu de ma fenêtre' ce que tu dis c'est 
il faut "GARDER" DEC-OSF et Solaris 2.6, alors oui mais en FIGEANT
les versions des logiciels qui fonctionnent ACTUELLEMENT dessus
quitte à créer (et la je parle de TSP ou de tout autre logiciel
dont vous disposez des sources) une branche de maintenance.

> - Mettre TSP que sur les nouvelles archis linux & consorts ?
> - Trouver un moyen de compiler gdisp+ à la fois en 1.2 et 2.6 ?

Non, sérieusement, on pourrait par exemple dire:

tsp_gdisp  --> GTK 1.2
tsp_gdisp+ --> GTK 2.x

Car vu ce que décrit Steph' un code GTK 1.2 + GTK 2.x == 2 codes
différents.

Mon point de vu simpliste est aussi.
Si vos station "d'observation" sont obsolètes ca vous coutera moins
cher de les remplacer par des PCs que de maintenir du code IHM
qui fonctionne dessus.

TSP (hors IHM, Gtk x.y et IHM Java z.w) fonctionnera encore un moment 
en Solaris 2.6.

En tous les cas mon avis "global" est que ce n'est pas "raisonnable"
pour nous (TSP dev team) de vouloir supporter des systèmes dont
les fournisseurs eux-mêmes annonce l'arrêt non?

Et je dis pas ça pour provoquer ou pour nier les pb d'obsolescence
et de maintenance.

Pour en discuter bien-entendu.
Eric

> Y++
> 
> 
> Le 30/10/05, Eric NOULARD<address@hidden> a écrit :
> > Le dimanche 30 octobre 2005 à 10:49 +0100, Stéphane a écrit :
> > > Salut à tous, chers TSP-Men.
> > >
> > > Bon, suite à la demande d'Eric, je viens de jeter un coup
> > > d'oeil à Gtk+ 2.6 afin d'évaluer l'effort de portage à faire.
> > > Pour mémoire, nous sommes en 1.2.
> > >
> > > Et ben, c'est pas gagné...
> >
> > Bah tu te sous-estimes :))
> > >
> > > Donc, il n'y a plus qu'à ... mais pas de suite car j'ai pas mal de
> > > truc sur le feu.
> >
> > Pas de pb fini donc tranquillement ce que tu as en cours
> > Gtk+ 2.0 viendra en son temps...
> > >
> > > Eric, je vois venir la question suivante : quelqu'un d'autre peut-il
> > > le faire en parallèle ? la réponse est non, car je ne suis pas 100%
> > > compliant avec le concept modèle/vue/controlleur. Et changer pas mal
> > > de widgets oblige à faire évoluer le traitement sur certaines données.
> >
> > Pas de pb, vu de ma fenêtre gtk+ 2.0 n'est pas urgentissime.
> > Ma précédente remarque je voulais juste tirer la sonnette
> > car c'est pas bien bon d'utiliser des libs dont les versions
> > récentes sont (probablement à juste titre) incompatibles
> > avec les anciennes... :))
> > >
> > > Je sais, c'est pas bien, mais bon.
> > > Really sorry.
> >
> > Meuh non même pas grave.
> >
> > De plus après TSP 0.7.0 (qui ne saurait tarder)
> > je m'attaquerai sérieusement poser une API propre
> > et commune au consumer ET provider
> > (c'est l'objectif de src/core/common
> > pour manipuler:
> >
> > TSP_request_xxxx
> > TSP_sample_symbol
> > et autres TSP_xxxx_list_t etc...
> >
> > C'est très pénibles tous ses types différents
> > entre provider et consumer et types rpc...
> >
> > Donc à ce moment là ben ce sera l'occasion de
> > retravailler sensiblement les consumers :)))
> > (côtés provider c'est souvent plus simple car
> >  il n'y a que les fonctions GLU et elles utilisent
> >  peu de type TSP)
> >
> > Eric
> >
> >
> >
> >
> > _______________________________________________
> > Tsp-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >
>