810

En réponse à : [Résolu] SMBFS sous MorphOS

#71786

– Est-il possible d’avoir un autre nom que SMBFS en nom de montage ? Car j’aimerais monter plusieurs répertoires avec des noms differents.

Cela se spécifie avec le Keyword DEVICE (ou DEVICENAME,VOLUME ou encore VOLUMENAME, tous équivalent) dans la ligne de commande de SMBFS (cf , la doc )

Par exemple :

Run
(ou qqchose d’approchant)

– C’est normal qu’un Icone correspondant au montage n’apparaisse pas sur le bureau ? Il n’apparait pas non plus en tant que Nom de volume dans « Volumes ».

Lorsque je le faisais chez moi (sur AmigaOS3.9) cela marchait il me semble.

Cela m’étonne qu’il n’apparaisse pas dans les « Assigns » dans le lister Devices:// .. au pire, tu peux faire un assign à la main dessus. (ok, ça ne règle pas ton problème, mais une fois qu’il apparait dans la liste des assigns, tu peux le « sortir » sur le bureau)

– Je n’arrive pas à écrire dessus (« Object in use »)

Je pense qu’il faut déjà vérifier que le ‘compte’ avec lequel tu te log a les droits d’écriture.

PS: Oups je vais me faire gronder par batteman, j’ai cassé la mise en page d’ai..

Topic: [Résolu] SMBFS sous MorphOS

dans le forum Général

J’ai installé SMBFS sous MOS, je lance ma ligne de commande via un le shell, il me créé bien un montage SMBFS: pointant vers un repertoire sur mon PC. Je peux naviguer sur mon PC via le shell…

Mes questions :

– Est-il possible d’avoir un autre nom que SMBFS en nom de montage ? Car j’aimerais monter plusieurs répertoires avec des noms differents.

– C’est normal qu’un Icone correspondant au montage n’apparaisse pas sur le bureau ? Il n’apparait pas non plus en tant que Nom de volume dans « Volumes ».

– Je n’arrive pas à écrire dessus (« Object in use »)

Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !

En réponse à : Alchimie 6, premières impressions … (utiliser ce topic)

#71417

Hello à tous !

Enfin un petit moment pour poster mon humble contibution :

Alchimie 2006

Moi qui était venue car on m’avait dit qu’il y aurait de la soupe aux potirons géniale, hé bien croyez moi où pas, j’ai rencontré pleins de gens sympas qui parlaient Amiga Normale après tout, c’est là ou les potes irons.

J’ai enfin pu voir Morphos de mes yeux, ce truc est assez incroyable.

L’organisation était impressionnante, bravo à ceux qui s’y collent et bravo aux participants/exposants qui font vivre notre petit monde bien sympa.

Amitoo pas déçu

A500+ / A1200 / CD32 et... Jaguar

[Admin]

En réponse à : Démos : scénario ou technique

#69350

bLa :  Exact ! Oo était synchro et franchement, ça change tout. De plus, c’était une démo originale qui ne reprenait rien d’une ancienne démo. Par contre, tu nous a bien eu, la musique est en P61 qui ne passe pas sous MorphOS/Peg ! Rahlala ! D’ailleurs, y’a pas moyen de mettre les « ancres » pour le son sur du dbm ou c’est uniquement dispo avec le P61, avec Karate évidemment ?

—

/me ne s’est pas penché sur la question.

Only Amiga makes it possible !

En réponse à : MUI Morphos et C++

#71521

Corto,

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

En réponse à : MUI Morphos et C++

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

En réponse à : MUI Morphos et C++

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

En réponse à : MUI Morphos et C++

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

En réponse à : MUI Morphos et C++

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

En réponse à : MUI Morphos et C++

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

En réponse à : MUI Morphos et C++

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

En réponse à : MUI Morphos et C++

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

En réponse à : MUI Morphos et C++

#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

En réponse à : MUI Morphos et C++

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

En réponse à : MUI Morphos et C++

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