MUI Morphos et C++

12 sujets de 1 à 12 (sur un total de 12)

Vince
25 octobre 2006 à 22h16 #4013
Salut, je voudrais me lancer dans un Dev C++ pour Mui Mos. Il sera éventuellement portable. Je voudrais utiliser les custom class pour éviter d’avoir une boucle événement sans fin mais je ne sais pas quels include utilisée.

J’ai vu les macros d’Ambient, les SDI ou les API MUI et j’aimerai votre avis.

Merci.
Fab1
26 octobre 2006 à 0h19 #71511
Je suis certainement influencé, mais je dois dire que les macros de vapor utilisées (et étendues) dans Ambient sont vraiment très pratiques.

Les macros vapor permettent de compiler pour gcc 68k/ppc et pour sas/c. Pour OS4, il faudrait adapter.

J’avais déjà jeté un oeil à SDI et dans mes souvenirs, c’était moins focalisé sur MUI.

Enfin, API MUI semble tout à fait similaire à ce que fait Ambient et supporte plus d’architectures.

Après, si tu fais du C++, j’imagine que tu pourras encapsuler ça dans une définition standard de classe, mais il faudra se méfier, car le C++ n’est pas toujours conciliant avec les macros à arguments multiples utilisées dans MUI, par exemple.

Maintenant, un petit exemple d’une classe avec la « méthode ambient » :

Les macros sont pour la plupart définies dans includes/macros/vapor.h

Pour la déclaration et création des classes (classes.h/c)

DEFCLASS(maclasse);

CLASSENT(maclasse);

Pour l’implémentation d’une classe :

// données membres

struct Data

{

blah blah perso

};

// constructeur

DEFNEW

{

APTR obj = DoSuperNew(cl, obj, TAG_DONE);

if(obj)

{

GETDATA;

// initialisation blah blah

doset( obj, data, INITTAGS );

}

return obj;

}

// destructeur

DEFDISP

{

GETDATA;

// nettoyage des ressources allouées

return (DOSUPER);

}

// accesseurs

DEFGET

{

GETDATA;

switch (msg->opg_AttrID)

{

case Attribut_n:

// blah blah

*msg->opg_Storage = blah;

return (TRUE);

}

return DOSUPER;

}

static void doset(APTR obj, struct Data *data, struct TagItem *tags)

{

FORTAG(tags)

{

case Attribut_n:

data->truc = tag->ti_Data;

break;

}

NEXTTAG

}

DEFSET

{

GETDATA;

doset(obj, data, INITTAGS);

return DOSUPER;

}

// Méthodes

DEFSMETHOD(MaMethode)

{

GETDATA;

blahblah

}

// Table des méthodes

BEGINMTABLE

DECNEW

DECDISP

DECSET

DECGET

DECSMETHOD(MaMethode)

ENDMTABLE

DECSUBCLASS_NC(classe_mui_dont_on_hérite, nom_de_ma_classe)
Yomgui
26 octobre 2006 à 9h53 #71512
Fab: a peine influence cette reponse….

Bon sinon, n’oubliez jamais ce que font ces macros!

C’est un peu comme les IDE. On n’oublie vite souvent ce que l’on fait.

En faite toutes les methodes sont bonnes pour faire du MUI.

Aucune n’est plus rapide que l’autre… elles ne jouent que sur la vitesse de frappe, la lisibilite et la portabilite, pas sur le resultat.

[PUB]Mon module MUI-Python avance bien [/PUB]
Polymere
26 octobre 2006 à 11h31 #71513
Les macros citées sont très bien mais dans mon cas cela me casse les c****** car le système de « sections » de GoldED AIX n’affiche que des « DEFTMETHOD » « DEFSMETHOD » et autres qui ne sont pas nominatif.

Donc pas d’accés rapide à la methode que l’on checher.

Quand on a plus de 25 methodes dans une classe ce n’est pas un luxe.

Et comme le dis Yomgui, comme les macros cachent le code,

il arrive tôt ou tard un cas particulier où il faut fouttre le nez dans les macros car il y a des erreur de compilations. (je pense en particulier aux tonnes de macro MUI qui peuvent vite devenir un cauchemard quand il y a beaucoup de groupes empilés).

Un autre conseil, utilise toujours la même identation avec décalage pour la conseption des GUI.

/me qui bosse sur PolyGlot et ca avance
Vince
26 octobre 2006 à 23h27 #71514
Fab1 a écrit :

Je suis certainement influencé, mais je dois dire que les macros de vapor utilisées (et étendues) dans Ambient sont vraiment très pratiques.

Les macros vapor permettent de compiler pour gcc 68k/ppc et pour sas/c. Pour OS4, il faudrait adapter.

Merci des infos mais dis moi, peux tu me conseiller la lecture d’un source d’Ambient pouvant m’aider à comprendre le fonctionnement de ces macros ?

J’avoue ne pas connaitre le fonctionnement des SUBCLASS et leur utilisations sous MUI. Aussi, je cherche tous sources simples qui pourrais m’aider à comprendre. Par exemple, je ne sais pas si une SUBCLASS peut être une fenêtre autonome ou s’il elle doit être contenue dans un CHILD d’une window MUI ?

Bon, je vais déjà essayer de regarder si je trouve.

Merci.
Vince
26 octobre 2006 à 23h51 #71515
Polymere a écrit :

Donc pas d’accés rapide à la methode que l’on checher.

Quand on a plus de 25 methodes dans une classe ce n’est pas un luxe.

tu parle de méthode, tu travaille en C++ ?

Un autre conseil, utilise toujours la même identation avec décalage pour la conseption des GUI.

c’est en terme de lisibilité du code ou pour autre chose ?

/me qui bosse sur PolyGlot et ca avance

il en faut qui bosse

Merci.
Fab1
26 octobre 2006 à 23h55 #71516
Si tu connais la programmation objet, tu sais ce qu’est l’héritage. C’est exactement ce dont il s’agit avec MUI.

Le modèle de base de MUI est le suivant : toutes les classes héritent d’une classe racine (boopsi). MUIC_Notify (qui implémente des mécanismes de notifications) en hérite. MUIC_Application, MUIC_Window, MUIC_Area héritent de MUIC_Notify. Et tous les gadgets/groups héritent de MUIC_Area, etc… MUIDev.guide montre tout ça très clairement.

Quand tu as besoin de redéfinir un comportement d’une classe, tu la dérives (sous-classes), définis/ajoutes ce dont tu as besoin, et il suffit ensuite d’instancier cette classe et de l’utiliser comme n’importe quelle autre classe.

Par exemple, dans la classe liste (sous mui4), tu peux (à moins d’utiliser des hooks), définir les méthodes d’affichage, de construction et destruction des éléments à insérer. En pratique, tu crées donc une classe qui dérive de MUIC_List, et tu implémentes MUIM_List_Display, MUIM_List_Construct/Destruct.

Dans ambient, tu peux regarder tous les fichiers *class.c qui sont des sous-classes des classes de base de mui.

Et par rapport à ton autre question, oui, une sous-classe de MUIC_*Group peut avoir des objets composites, évidemment, puisqu’elle ne fait qu’étendre le comportement d’une classe groupe normal.
Vince
26 octobre 2006 à 23h56 #71517
Yomgui a écrit :

Fab: a peine influence cette reponse….

Bon sinon, n’oubliez jamais ce que font ces macros!

C’est un peu comme les IDE. On n’oublie vite souvent ce que l’on fait.

En faite toutes les methodes sont bonnes pour faire du MUI.

Aucune n’est plus rapide que l’autre… elles ne jouent que sur la vitesse de frappe, la lisibilite et la portabilite, pas sur le resultat.

[PUB]Mon module MUI-Python avance bien [/PUB]

C’est vrai que j’aime pas trop les macros très complexes qui rende certainement service mais qui ne facilitent pas toujours la compréhention du code par quelqu’un qui n’en est pas l’auteur.
Polymere
27 octobre 2006 à 7h29 #71518
Salut Vince,

Comme le dis si bien Fab, MUI utilise un consept objet mais dans un environnement de développement C.

Finalement je trouve cela plus clair que le C++.

On a le contrôle total de ce que l’on veux faire.

Quand on programme une classe par .c avec des static pour chaque fonction, seuls les Tags MUIM/MUIA et les structures MUIP sont accessible donc cela force a utiliser uniquement les methodes que l’on a déclaré.

Dans la pratique cela demande beaucoup de réfléxion pour assurer un coerance globale de l’application.

(je parle en connaissance de cause je me suis déjà planté et cela force a recoder beaucoup de choses).

Une classe bien codée peux être réutilisée dans plusieurs programmes si le squelette est le même.

A+
Yomgui
27 octobre 2006 à 11h08 #71519
Sinon y a un truc bien, elegant, simple et OO…

… le module MUI pour Python, dont je viens tout juste dans fournir un premier essais (comme par hasard )

un premier saut ici ?

Bon sinon Vince, il te reste aussi a galerer a compiler du C++ avec MUI si tu veux…

Enfin moi je dis ca.. je dis rien quoi… je veux pas faire de la pub…
corto
28 octobre 2006 à 10h51 #71520
Vince a écrit :

J’avoue ne pas connaitre le fonctionnement des SUBCLASS et leur utilisations sous MUI. Aussi, je cherche tous sources simples qui pourrais m’aider à comprendre. Par exemple, je ne sais pas si une SUBCLASS peut être une fenêtre autonome ou s’il elle doit être contenue dans un CHILD d’une window MUI ?

Si ça peut t’aider, j’avais écrit un tutoriel MUI avec 7 articles et exemples, allant d’un programme simple à l’héritage de classe. A télécharger : tutoriel MUI DisKo sur Aminet

Fab : Les macros ça peut être bien (j’utilise d’ailleurs les macros SDI) mais je trouve que celles que tu indiques portent des noms trop génériques (tout comme par exemple la macro ENTRY des SDI_headers).
Fab1
28 octobre 2006 à 14h20 #71521
Corto,

si tu trouves ça choquant il suffit d’ajouter un MUI_ devant, mais bon…