Kimono!!

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

sinisrus
22 décembre 2004 à 14h34 #1126
Au sujet de KIMONO l’interface graphique qui rend plus facile l’utilisation de karaté ça en est ou?
krabob
22 décembre 2004 à 15h23 #27588
…pour ma part je n’en sais rien. J’ai vu slob et vinz à l’alchimie, c’était trés impressionnant d’autant plus que tout est en rxmui. Ils utilisent leurs propres base qui crééent des script à la volé lancé par karate ensuite.

je n’ai pas fait les dev. que j’avais prévu en décembre. je les reporte en janvier. ( LWS présentable , interaction, application )

Je pense ces temps-ci à un possible karate 2.0 avec modifs majeures, pour pouvoir enabler l’édition de la base en RT et permettre une GUI ou autre chose.
sinisrus
22 décembre 2004 à 16h29 #27589
Pour ma part j’attend une gui pour pouvoir me mettre à faire des demo!
krabob
22 décembre 2004 à 17h01 #27590
Si ça branche quelqu’un pour bosser avec moi sur karate, il y a facilement la place pour un autre developpeur. Mais il y a un « ménage à faire » avant de pouvoir ouvrir le éveloppement d’une GUI.

-1 Je dois mettre en place un meilleur mécanisme de » dépendance » entre objet (si A utilise B, que fait A quand B est détruit: je compare actuellement les avantages de 3 politiques possible pour gérer ça, c’est mon seul « probléme ». )

-2 Je dois finir de séparer le parser et la lib de management des objets: seule les création de part et de script sont à refaire. (le parser est juste une sérialisation en entrée)

-3 Je dois faire rationnaliser par une « liste de type » ce qui est passé aux constructeur de chaque classe: pour l’instant une chaine abstraite et passé comme description des constructeur et interprété comme bon lui semble. (se systeme existe déjà pour les effets.)

Les points 1 et 2 sont juste des trucs pas fini mais necessaire pour ensuite faire une interface temps réel.

Seul le point 3 m’oblige à changer mon interface de plugin, (mais personne n’a éprouvé le désir de l’utiliser) et permettra de faire en sorte que pour une nouvelle classe ajouté par plugins, on est pas a coder un « panel de contruction spécifique ») L’interface de création d’un objet sera « implicite » de par sa liste de parametre « constructeur ». niark niark niark.

Pour le reste, le « moteur karate » gére une base de façon indépendante dans une lib statique, l’interface lui demandera des constructeurs et des description des objet, de dessiner des frames, mais sera indépendante. En fait un simple menu permettra de réaliser 90% des actions graphiques.
slobman
22 décembre 2004 à 17h19 #27591
Hip !!

Kimono est un peu en stand-by pour l’instant, en fait (du au fait qu’un blaireau est monté à la capitale avec le peg de dev). Mais ça devrait rebouger d’ici peu.

@Krabob: en parlant de séparer le parser, envisagerais-tu de refaire le parseur en te basant sur du xml plus tricte ?

Mais dans ce cas, il faudra peut être modifier certains aspect du langage.

Quant à l’interface de plugin, si j’ai eu une idée de plugin (très simple pour commencer), mais pas eu le temps de me plonger dedans.

!! qiH

/me qui doit toujours fignoler la version finale de la colorblind, présentée à l’alchimie4
WickedVinz
22 décembre 2004 à 17h33 #27592
Hip !!

Et bien, pour l’instant ça stagne un peu… je viens tout juste de récupérer les sources qui étaient parties avec le peg à Paris chez slobman, et je ne me suis pas encore replongé dedans…

Qui plus est, je compte passer à plus ou moins court terme à une version en C (donc, le parser ça m’intéresse bien.. je l’ai fait en Rexx mais ct facile ). Comme j’ai prévu pas mal de chose, bin, j’ai pas mal de taf en fait

Pour etre précis: pour l’instant, de fonctionnel on a :

– un editeur qui permet de lancer directement depuis l’interface le script

– un editeur de KScript en WYSIWIG, mais qui n’applique pas encore totalement les résultats… j’ai 2-3 chose à fixer pour les , ce qui fait que je suis passé à une phase à peine plus importante : la gestion complète du projet : création simplifié du projet qui crée l’arborescence du répertoire, le fichier de démarrage, etc.. (à terme, ça devrait meme permettre d’optimiser l’espace disque en retirant les .fx non nécessaire )

Pour info, là, je prépare un « Kyoshin » (assistant en langage de Karateka) pour créer un nouveau projet type Wizard à la w!nd0ze.

À coté de ça : j’ai pas mal d’étude papier pour:

– l’editeur de KPart WYSIWIG (pour insérer les FX, etc) avec des icone et tout pour savoir un peu c quoi les FXs

– un editeur de KTable (avec la possiblité d’éditer en parallèle plusieurs KTable: pratique pour la synchro)

– un editeur/browser d’objet

– un editeur de Scrolltext (et dieu sait que c plutot sympa ça pour faire un sinus scroll en Karate, y a pas mal de copier coller.. là ça serait automatisé)

– et alors là c pour plus tard : un editeur de K3dWorld et un editeur de Mesh3d…

Et juste pour en discuter (paskeu ça n’interessera pas gd monde): j’ai prévu de parser le fichier de diagnostic (Karate c) pour optenir la liste des FX et objects buildable.

Si ça intéresse vraiment du monde, je verrai pour placer une alpha alpha version sur http://lightourfire.free.fr (et surtout pour mettre à jour les grabs )

!! qiH

PS: si qq1 à une peg2 qui traine, je peux l’en débarrasser
krabob
22 décembre 2004 à 17h40 #27593
parseur en te basant sur du xml plus tricte ?

Mais dans ce cas, il faudra peut être modifier certains aspect du langage.

je ne modifierais pas la syntaxe du parser pseudo-XML actuel, bien sympa puisque léger et adapté pour. par contre aprés les modif dércite au dessus, il sera possible de faire des classes d’import/export vers n’importe quel format (ce format décrivant la base de donnée d’une maniére ou d’une autre). Donc je pense à un format binaire et/ou XML pour une GUI.