Pixel32 pour Morphos

15 sujets de 16 à 30 (sur un total de 55)

LorD
9 janvier 2005 à 17h26 #29126
http://www.ck-koukal.sk/dn/pixel_mos4.png

Il s’est amusé à bricoler un skin à partir d’un skin de MOS .

Edit :

Et mince il a changer le grab par un autre
anonyme
9 janvier 2005 à 17h26 #29127
Rien du tout?

erm erm ca serait un autre type de soft je dirais rien mais

là…enfin bon c’est déjà ça de pris
LorD
9 janvier 2005 à 17h28 #29128
@lugduweb:

Pourquoi dommage ? Au contraire, le fait qu’il soit payé est une

motivation pour son auteur, ça fait des années qu’il y travaille

dessus et il le poursuit dans l’optique de la version qui coutera en

effet 100$, mais permettra d’avoir un soft performant et très pro sur

de nombreuses plateforme (dont de nombreuses peut soutenues) et ce à

un prix raisonnable.
corto
9 janvier 2005 à 17h41 #29129
hybrid a écrit :

Et dans le cas du grab de Pixel32, c’est carrément toute l’interface qui fait une croix sur l’intégration dans MOS, on croirait le voir tourner sous Windows, au premier coup d’oeil, ça fait vraiment fake d’amateur.

Alors, ok, c’est une skin qu’on peut changer mais il n’empêche que tout est contraint à une seule fenêtre, même le menu n’est pas un menu standard de l’OS, etc etc …

Il me plaisait beaucoup ce grab et ne me faisait pas penser à Windows. C’est marrant parce que ce que tu dis illustre parfaitement ce qu’on disait justement dans un autre thread. Ce qui est important dans un premier temps, c’est que des applis reconnues soient portées sur nos systèmes, même si c’est avec les défauts que tu soulèves. Ca apporte toujours une certaine crédibilité.

Ensuite, il faudrait dans l’idéal que ces logiciels soient améliorés avec les spécificités du système pour mettre en avant les qualités du système. Sans pour autant qu’il n’y ait que des portages, sinon on risque de perdre notre identité.

Encore une fois : il faut jouer serré et maîtriser tout ça. C’est pas facile mais on peut en tirer partie.
anonyme
9 janvier 2005 à 17h55 #29130
Pour que les portages aient un look plus adapté, il faudrait faire des wrappers pitètre.

Mais je suis 100% d’accord avec Corto, priorité au portage, optimisation et relookage après

Je note quand même que quasi tous les logiciels sortent en version 68k. Je ne m’en plains pas car je remonte mon 1200 mais c’est hallucinant!!! Est ce que les développeurs ne se brident pas niveau innovations pour assurer la rétro compatibilité?
Daff
9 janvier 2005 à 21h06 #29131
@Mahen : Les trois personnes que j’ai cité sont à l’origine de ce portage : Relec (revendeur suisse), RMS (agence de communication suisse dirigée par Christoph P. et qui utilise des Pegasos/MorphOS) ainsi que Denis Gauthier (un utilisateur de Pegasos/MorphOS).

Il faut donc les remercier chaleureusement d’avoir eu cette idée et d’avoir tout mis en oeuvre pour que cela aboutisse.

Merci les gars !
corto
9 janvier 2005 à 21h47 #29132
tetuzo a écrit :

Je note quand même que quasi tous les logiciels sortent en version 68k. Je ne m’en plains pas car je remonte mon 1200 mais c’est hallucinant!!! Est ce que les développeurs ne se brident pas niveau innovations pour assurer la rétro compatibilité?

Je ne sais pas à quels portages tu penses mais il y a pas mal de logiciels qui ne sortent qu’en PPC ou qui ne sont exploitables que sur ces machines.

C’est clair que pour les développeurs, ça rajoute du travail et des galères de supporter le 68k. L’API Amiga ne change pas mais entre les différents jeux d’includes, les différents comportements des datatypes suivants leurs versions et leur provenance, etc. ça ne facilite rien.
hybrid
10 janvier 2005 à 0h17 #29133
@tetuzo @corto :

Je pense que vous n’êtes pas tout à fait dans le vrai tous les 2 mais pour des raisons différentes …

A votre avis, pourquoi les softs portés apparaissent d’abord sur Classic en 68k ?

Simple en fait, c’est pour pouvoir brasser large.

Aujourd’hui, avec la scission MOS/AOS4, WinUAE, Amithlon, quelle est la seule plateforme commune qui marche vraiment partout ?

Bin ce sont les softs codés proprement pour Classic en 68k, grâce à l’émulation, c’est le seul moyen de s’assurer que ça marchera aussi bien sur AmigaOS 3.x, 4.0, MOS, UAE et Amithlon.

Alors, l’inconvénient, c’est que ça ne permet pas de tirer parti des nouveautés introduites par les nouveaux OS (c’est un peu comme un mauvais portage finalement …) mais de toute façon, entre un OS 3.9, 4.0 et MOS, les différences sont finalement mineures.

Alors, comme pas mal d’autres codeurs, pour le moment, je me contente de me faire la main sur du dev en MUI sur Amiga Classic en 68k, comme ça je peux le développer sur UAE avec mon portable ce que je ne peux pas faire avec n’importe quel autre “Amiga” jusqu’au jour où on y verra un peu plus clair et qu’une solution prenne un réel ascendant.

Ca a au moins le mérite de ne pas laisser les utilisateurs de Classic sur le bord de la route et de faire plaisir aux utilisateurs d’UAE ou d’Amithlon mais par contre, c’est clair, ça n’incite pas tellement les gens à se presser de passer sur MOS ou AOS4 … en gros, c’est le serpent qui se mord la queue :

plus il y’aura de softs pour Classic, moins les gens seront pressés de passer au PPC et tant qu’il n’y a pasd beaucoup d’utilisateurs de PPC, il n’y aura pas de solution dominante et donc, les développeurs craindront de développer pour ces plateformes et préfèreront jouer la sécurité avec des devs pour Classic … la boucle est bouclée.
Yomgui
10 janvier 2005 à 11h28 #29134
En regardant de près les grabs de Pixel32 j’ai l’impression que le gars a créé sa porpre GUI (direct dans le framebuffer de la fenêtre), par contre je me demande alors comment il crée des menus dans ce cas… (une fenêtre sans bord ? où tjrs dans le framebuffer de la fenêtre top ?)

En tout cas il est sûr que cette solution permet d’avoir des portages et support sur tous les OS. Mais cette GUI n’est pas standard…

Par contre Blender utilise cette technique puiqu’il se base sur OpenGL. (D’ailleur pourquoi pas basé Pixel32 sur OpenGL tiens )

/me repart dans ses idées…
LorD
10 janvier 2005 à 17h11 #29135
@Yomgui :

Oui, il a fait son propre système de GUI appelé eLiquide qui est skinnable (il fournira la doc pour faire ses propres skin qui est basée sur un fichier texte et des images).
Lanza
10 janvier 2005 à 17h39 #29136
LorD a écrit :

@Yomgui :

Oui, il a fait son propre système de GUI appelé eLiquide qui est skinnable (il fournira la doc pour faire ses propres skin qui est basée sur un fichier texte et des images).

Eurk.

/me est d’accord avec Hybrid sur ce coup-là. MOS a déjà un système de skin…
Yomgui
10 janvier 2005 à 18h16 #29137
Bah avoir sa propre GUI ça a ses + et ses – … ensuite vaut juste que le/les developpeur(s) en soi(en)t bien conscient(s)…

J’avais commencé à refléchir sur une bibliothéque de fonctions pour créer une GUI mais avec des éléments standarisés et ainsi créer des applis en décrivant le contenus mais pas le contenant.

C’est un peut le principe de MUI mais en plus générique…. il n’y a pas de dépendances sur le système utilisé. Ainsi un même programme peut proposer à l’utilisateur différents moteur de rendu de GUI. Un même programme utilise la lib pour créer son interface de façon générique. Ensuite la lib utilise telle ou telle lib (suivant prefs utilisateur) pour savoir si elle rend en MUI/Reaction/Intuition-Gadgtools/Tk/GTK+/OpenGL/…
Lanza
10 janvier 2005 à 18h35 #29138
Oui mais sur nos différents amiga, on a été plus ou moins habitués à ce qu’un réglage de préférence affecte toutes les applis. Je change de langue, les applis suivent. Je change de skin, les applis suivent. J’ajoute un datatype, les applis reconnaissent un nouveau format (bon les datatypes trainent un certain nombre de défauts, il est vrai, mais quand bien même).

Personnellement je peste dès qu’un soft réinvente la roue et du coup fait tout pas bô au milieu de mon système.

Je peux en comprendre les raisons (l’absence de standard chez nos amis unixiens, par exemple), mais ça m’agace, parce que nous avons des mécanismes relativement efficaces (qui rendent notre système si différent et attachant), et que les applis ne les utilisent pas.
Yomgui
10 janvier 2005 à 18h53 #29139
Lanza :

d’où mon système… tu choisiras comme moteur de rendu par défaut MUI par exemple et toutes les appli basé sur cette lib utiliserons MUI (et donc les préférences globals de MUI comme d’hab). Cela sera totalement transparent.

Tu veux autre chose pour tel ou tel programme ? tu le configure dans le prog lui-même avec au choix le moteur par défaut ou un autre… Le moteur par défaut étant simplement donné par une variable d’environnement par exemple.

/me qui crée des concepts à la minute
Anonyme
10 janvier 2005 à 19h17 #29140
Vous vous plaignez, mais ce portage n’aurait pas eu lieu s’il n’avait pas utilisé son propre système de GUI.