Forum général.général Nouveau framework "EWOL" multi-OS (Linux/Mac/Windows/Android/IOs) recherche collaborat(eurs/rices)

Posté par . Licence CC by-sa.
-1
28
oct.
2016

Bonjour,

je sais pas ou il faut faire cette demande donc je la fais ici …

Ca fait un certain temps que je programme dans mon coin un framework et que je repousse sans cesse la demande d’aide d’autre développeur fou qui cherches des projets auquel s'accrocher …
Donc j’ai une collection de lib qui font le café et même plus … Il y en a qui sont industrialisable, et d’autre qui sont des prototype d’apprentissage (ce dernier c’est le café..)

Donc voila la liste des librairies (tout est sur github…)

  • http://github.com/atria-soft/elog : Une interface de log générique.
  • http://github.com/atria-soft/etk : une tool-box (une poubelle) il y a dedans un accès au fichier "asset", un wrapper sur lec vec2 (vector 2D) et vec3 (vector3D) qui wrap automatiquement la bullet-lib quand elle est présente ⇒ evite les conversion et …)
  • http://github.com/atria-soft/ewol : Une interface graphique en widget (il y a les composant de base, rien de très inivant, il faudrait en ajouter un certain nombre)
  • http://github.com/atria-soft/gale : Interface VIDEO multi-platform pour (Linux/Windows/MacOs/IOs/Android) (presque comme la SDL)
  • http://github.com/atria-soft/earchive : Access de fichier zip (sur Android On accède au fichier a l'aide du package apk (zip file))
  • http://github.com/atria-soft/egami : accès généric au fichier image (SVG, BMP, png) il faudrait ajouter un accès au jpeg et d’autre format quand les lib sont compatible en licenses)
  • http://github.com/atria-soft/esvg : génération de svg avec le CPU (il n’y en existant pas en apache-2 ou BSD)
  • http://github.com/atria-soft/ejson : JSON “dom” lib (même fonctionnement que exml)
  • http://github.com/atria-soft/exml : XML “dom” lib (même fonctionnement que ejson)
  • https://github.com/musicdsp/audio : Audio format (définition des formats basiques comme le 16bit sur du 32 bits…)
  • https://github.com/musicdsp/audio-orchestra : Interface AUDIO multi-platform pour (Linux/Windows/MacOs/IOs/Android) (lié au système de build et un peu a gale)
  • https://github.com/musicdsp/audio-drain : Simple pipeline de process audio (1 flow)
  • https://github.com/musicdsp/audio-river : Abstraction haut niveau audio (N connexion application (music, effect, voice … vers 1 sortis audio (ça fait le mix et la magie), transformation des format (ex: float -> int16) … un AEC très simple ET SURTOUT une bonne gestion de volume basé sur des tags et en dB)
  • https://github.com/musicdsp/audio-ess : Simple sound-set manager (jouer une music a la fois, et avoir plein de son précharger prêt à la lecture…)
  • http://github.com/atria-soft/ege : Ewol Game engine (prototype +/- abandonné) je dit pas qu’il est a jeter .. mais il n’avance pas vite … j’ai un jeu en cours basé dessus, mais ça avance vraiment très lentement)
  • http://github.com/atria-soft/zeus : RPC over websocket over http ⇒ j’ai voulus comprendre comment fonctionnais un RPC en C++, et du coup ça fonctionne pas trop mal … le projet de base était de faire une framework pour remplace facebook, tweeter, hangout, picasa, musicPlayer … avec un protocol interconnectable et sécurisé dot chaque personne pourrait avoir ces données chez lui… ⇒ il est en pause, il y a des problème sur un concept fondamental (comment crypter les donné et garder les clefs de la façon la plus sécurisé possible …)
  • http://github.com/atria-soft/enet : socket wrapper (interface HTTP, TCP, websocket) à besoin encore d’un peu de développement… pour être complètement stable.

Les documentations doxygen sont sur les github.io respectifs aux projets ex: http://atria-soft.github.io/ewol

Donc je suis partis de plusieurs postulats:

  • Les licence de beaucoup de lib ne permette pas de faire de la compilation pour IOS (link en .a) en propriétaire, donc j’ai limité toutes les lib aux licences: APACHE-2/BSD*/PNG/MIT/zlib et surtout pas : (L-GPL* ou GPL*)
  • cmake ne correspond pas à mes problématique de worktree (j’ai donc créé lutin) le worktree est dynamique…
  • Un livrable contient tout ce dont il a besoins (comme les .apk de Android ou les .app de Mac)
  • En dehors du worktree les livrables ne devraient dépendre que de lib C/C++
  • Use as possible all std-lib (limit at compliant with all platform [Linux/Windows[mingw]/MacOs/IOs/Android])

Toutes les lib sont accessible sur 2 group github:

Pour l’utiliser: la base de ewol:

Un programme (éditeur de code) je l’utilise tout les jour, c’est une bonne pratique pour découvrir des bug provenant d’un framework):

Le builder (c’est du python):

Je suis donc a la recherche de:

  • Critique positive (si c’est juste pour dire c’est d'la merde… sans explication, c’est sous-productif… [même si c’est vrai…])
  • De personnes qui ont juste envie de réutiliser des partis du code chez eux (merci de retourner les bugs)
  • De personnes qui ont envie d'être actif dans un projet récent, et qui cherche un point d'accroche.
  • De personne qui aime les interface graphique jolie IL Y A DU TRAVAIL
  • Toutes contribution sera la bienvenue …

un petit schéma fait à l’arrache …

overview framework

Merci d’avance de vos réponses/aides/critiques ….

  • # CMake et worktree

    Posté par (page perso) . Évalué à 1.

    Salut, tout d'abord, la masse de travail est énorme !

    As tu développé tout ça tout seul ?
    Bravo.

    Sinon, je ne comprends pas trop ce que signifie worktree. Tu as écris :

    cmake ne correspond pas à mes problématique de worktree […]
    le worktree est dynamique…

    • Peux-tu nous en dire un peu plus sur ce qu'est le worktree ?
    • C'est quoi un worktree dynamique ?
    • Quel est l'avantage de Lutin par rapport à CMake dans ce contexte ?
    • Que faire CMake pour gérer ton worktree dynamique ?

    Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

    • [^] # Re: CMake et worktree

      Posté par . Évalué à 3.

      bonjour,

      oui, j'ai développer ca tout seul depuis 2009 … donc oui c'est devenus trop gros pour continuer a évoluer en solo…

      un worktree c'est :

      • workspace
        • application
        • application_1
        • application_2
        • framework
        • library_1
        • library_N

      Donc à ce point je ne peut pas prédire quels vont être le nombre de lib, leur position dans les sous dossiers (chaque utilisateur organisant sont arbre comme il le désire. C'est le coté dynamique)

      Il y a déjà des projets (basé sur CMake) qui font ca: catkin ou encore qibuild. Le problème est connus…

      L'autre point, Lutin est un builder, pas un générateur de builder comme cmake (back-end Make/Ninja …)
      La résolution des dépendance est faite a chaque fois, et est aussi rapide qu'un build (cmake sans l'étape de config)

      Lutin propose une compilation de base pour Windows(mingw), Mac, Windows, IOs, Android

      Il propose aussi sous linux (pas encore le temps sur les autre platforme) une compilation isolé qui permet d'évité les problèmes d'inclusion implicite…

      Et comme tous système il a quelques bug…

      Et argument qui ne sert a rien : je l'avais commencé il y a 4 ans sans connaitre cmake… c'est un projet que j'aime bien …

      j'espère avoir répondu a un certain nombre de vos questions…

      PS: Il est en réflexion de faire de version pré-compiler qui permettra de faire du cmake/ps (utilisateur)

      • [^] # Re: CMake et worktree

        Posté par (page perso) . Évalué à 1.

        Merci pour tes réponses.
        Je n'ai pas bien compris le lien entre l'aspect dynamique du worktree et la limitation de CMake.
        J'aime bien CMake malgré sa rétrocompatibilité avec un long passé (et j'aimerai mieux comprendre ses limitations).
        Je vais regarder les projets catkin et qibuild pour essayer de comprendre cette limitation…
        J'ai moi aussi trop de projet à gérer en parallèle (bien que je n'ai produit à peine 1% de ce que tu as fais) et je ne pourrai pas t'aider… sauf à porter ton système sur CMake ;-)
        Bon courage

        Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.