Discussion :

[bbeaulant]

Bonjour,

Je souhaiterais vous faire part d'un projet Open Source - Kuix (Kalmeo User Interface eXtensions). Comme son nom l'indique, c'est avant tout un framework d'interface pour applications mobiles sous Java ME.

Sa particularité est d'intégrer en natif nombre de composants utiles (boutons, listes, radios, scrollbar, transition, ...) qui seront mis en forme via XML et dont l'apparence sera assurée par des feuilles de style CSS.

De plus ce dernier se veut compatible avec un maximum de mobiles (CLDC 1.0 / MIDP 2.0)

Puisqu'une démo est plus parlante qu'un long discourt, je vous laisse consulter ce lien.

Le projet est accessible à cette page : http://www.kalmeo.org/projects/kuix.

[fetchy]

Outre le fait que le message précédent ressemble à une publicité bien plus qu'à une information, je ne crois pas que Kuix réussira à se faire une place au milieu des solutions existantes (j4me, lwuit, j2mepolish) pour plusieurs raisons :
- sa licence qui fera que celle-ci sera rejetée par la plupart des entreprises (tout les travaux dérivés doivent avoir des sources libres (GPL))
- son support et sa capacité à évoluer qui doivent être quasi-inexistants, kalmeo étant certainement une entreprise dont le nombre d'employés se comptent sur les doigts d'une main.
- l'arrivée de midp 3 qui risque de rendre obsolètes toutes ces solutions.

Donc, même si il y a de bonnes idées dans Kuix, je ne me formerai pas sur cet outil qui n'a à mon sens aucun avenir.

[nouknouk]

Outre le fait que le message précédent ressemble à une publicité bien plus qu'à une information

Moui. Faut pas exagérer non plus: c'est un message:
- posté sur le bon forum et qui peut donc potentiellement intéresser les gens qui le lisent
- qui propose une solution également en GPL, donc il n'est pas nécessaire de passer à la caisse pour l'utiliser.

Faut pas voir le mal partout non plus .

- sa licence qui fera que celle-ci sera rejetée par la plupart des entreprises (tout les travaux dérivés doivent avoir des sources libres (GPL))

Non, prends le temps de lire: il y a deux licenses (GPL & commerciale).
Regarde Qt son système de double license (GPL gratuite & Commerciale payante) : ça marche du tonnerre pour eux.

- son support et sa capacité à évoluer qui doivent être quasi-inexistants, kalmeo étant certainement une entreprise dont le nombre d'employés se comptent sur les doigts d'une main.

Non:
- si la license est en GPL et que le projet 'prend', une partie du support et les évolutions sont prises en charge par la communauté, et pas juste l'instigateur du projet.

- c'est effectivement moins intéressant pour les entreprises (qui recherchent en général un support commercial béton), mais:

1/ Au lieu de partir sur un à-priori négatif, on peut glaner des infos. On trouve pas grand chose, mais la (jeune) société a un capital social de 100 000 euros, ce qui laisse quelques garanties. On est déjà loin de la micro-entreprise avec juste un geek/dev/boutonneux au fond de son garage.

2/ il faut bien commencer un jour. La société date de septembre 2007. Comment Trolltech a-t-elle fait en son temps ?

3/ La politique tarifaire est tout de même relativement agressive par rapport à la concurrence. Pour une entreprise qui a des besoins simples, elle préférera peut-être se tourner vers quelque chose de plus léger pour payer moins cher.

l'arrivée de midp 3 qui risque de rendre obsolètes toutes ces solutions.

Oui, et l'arrivée de Windows Seven changera également beaucoup de choses
Ce que je veux dire par là c'est que: MIDP 3 n'est pas encore sorti. Alors:

- d'ici à ce qu'il y ait effectivement des mobiles en vente sur le marché qui l'exploitent, de l'eau coulera sous les ponts.

- d'ici à ce que la majorité des téléphones en circulation supportent MIDP 3, de la bière aura coulé sous les ponts

Donc, même si il y a de bonnes idées dans Kuix, je ne me formerai pas sur cet outil qui n'a à mon sens aucun avenir.

Peut-être que TU n'es pas intéressé (moi non plus d'ailleurs), mais - a mon humble avis - c'est pas une raison suffisante pour un post aussi radical.

[bbeaulant]

Outre le fait que le message précédent ressemble à une publicité bien plus qu'à une information, je ne crois pas que Kuix réussira à se faire une place au milieu des solutions existantes (j4me, lwuit, j2mepolish)

Certe, alors le message est clair, arrêtons de chercher, tout est déjà fait...
Désolé fetchy, mais sur le coup, je ne suis pas tout à fait d'accord.

1. La volonté de Kalmeo par rapport à la réalisation de ce projet est avant tout née d'un besoin interne qui ne trouvait PAS de solution dans l'écosystème existant, tant d'un point de vue philosophique qu'économique. Je ne veux pas par là dénigrer les autres solutions, mais la vision que nous avons de ce type de produit qui repose principalement sur le fait qu'il est indispensable de ne pas tout imposer au développeur, mais de savoir partager les compétences en fractionnant les tâches (logique de l'application, design d'interface, ergonomie).

2. Ne pas monter seul une solution. C'est pourquoi le choix a été fait de rendre ce projet "libre". Mais je suis désolé de te le dire, Kalmeo est une entreprise et on est pas là pour donner non plus. Donc le libre pour le libre, OUI. Sinon, il faudra ce tourner vers la solution commerciale qui est également proposée.

3. Donc, si je suis le concept, une jeune structure qui compte ses employés sur les doigts d'une main ne peut pas avoir les capacité de proposer de choses intéressantes. A mon sens, c'est une erreur de jugement. Nous n'avons certe pas toujours les capacités de réaction d'un grand groupe, mais nous n'en avons pas non plus les lourdeurs.

4. Merci à toi Nouknouk. Je suis vraiment touché par ton message !

5. Concrètement je suis bien conscient que Kuix n'intéressera pas tout les développeurs Java ME. Mais par simple curiosité, qui lui manque-t-il ou qu'a-t-il en trop pour répondre à vos besoins ?

[fetchy]

Alors désolé si mon message a choqué certaines personnes.
Néanmoins, pour rendre ce post intéressant, tu pourrais peut-être nous expliquer ce que Kuix apporte de plus que les autres fonctionnellement ou en gain en temps de développement (J2MEpolish utilise également les CSS), parce que pour l'instant je n'ai pas vu, mais ça m'intéresse! Bref, en quoi Kuix se différencie-t-il vraiment des autres!

Pour être moi-même passé dans des petites et très grosses entreprises, je ne dis pas que les plus petits ne proposent pas de choses intéressantes, bien au contraire, mais quid de la garantie de suivi (de survie?) de ton produit ?
Si on prend en comparaison un produit, très jeune également, comme LWUIT, les communautés ne sont pas comparables... (même si ça ne fait pas de LWUIT un bon produit!)

Maintenant, ce qu'on peut reconnaître, c'est la relative légèreté de Kuix.
Ce que j'attends de mon côté c'est:
- une réelle plus value visuelle (toutes les applis que je fais utilisent déjà les Canvas)
- la légéreté
- le support garanti sur un grand nombre de mobiles sans codage supplémentaire. Pourquoi est-il nécessaire de télécharger l'application de démo pour un mobile en particulier ? N'est-ce pas censé être la même pour tous les mobiles ?

Kuix a-t-il été testé sur tous les mobiles pour lesquels il est proposé au téléchargement ?
L'impact sur les performances ont-elles été comparées par rapport aux APIs MIDP (Form & Canvas) ?

[manitoba]

Kuix a-t-il été testé sur tous les mobiles pour lesquels il est proposé au téléchargement ?
L'impact sur les performances ont-elles été comparées par rapport aux APIs MIDP (Form & Canvas) ?

D'accord avec Fetchy.
Les points les plus critiques sont effectivement les performances et la portabilité.

[bbeaulant]

...tu pourrais peut-être nous expliquer ce que Kuix apporte de plus que les autres fonctionnellement ou en gain en temps de développement (J2MEpolish utilise également les CSS), parce que pour l'instant je n'ai pas vu, mais ça m'intéresse!

Bien entendu je ne cherche pas à annoncer que nous révolutionnons le secteur. Mais pour en revenir au apport dans le développement, je dirais que la principale caractéristique ce n'est pas d'offrir seulement le CSS, mais aussi une mise en forme par XML.
Pour être plus précis, ceci permet de répartir efficacement le développement au sein de l'équipe.
- Le développeur Java s'attache uniquement à la logique générale de l'application
- Le designer d'interface, intègre la créa graphique et peut choisir l'agencement ergonomique sans solliciter le développeur (XML / CSS).
Ainsi les tâches peuvent évoluer en parallèle, d'où le gain de productivité.

Pour en revenir à J2ME polish, l'utilisation du CSS, va certes permettre de donner le "look" souhaité à l'application, mais il ne répond pas pour autant à la philosophie précédente, puisque la disposition des composant est toujours décrite dans le code.

De là j'entends déjà les puristes qui vont pouvoir crier au scandale en apprenant que XML et CSS ne sont analysés qu'à l'exécution, mais c'est justement ce qui donne toute le souplesse au framework. Ne sommes nous pas d'une certaine façon proche des technologies Web ? et ne suffirait-il pas d'ajouter un language de script pour retrouver l'esprit Ajax ?

D'un point de vue portabilité, nous savons bien que les spécifications CLDC / MIDP ne sont pas respecté à la lettre par tous les constructeurs. Mais d'un point de vue théorique, Kuix se limite à MIDP 2.0 / CLDC 1.0, ce qui le rend à ce jour très portable et SANS compilation spécifique.
Quant au fait que le téléchargement de la démo soit proposée avec un découpage par modèle de mobiles n'est en place que pour orienter l'utilisateur. Pour dire vrai c'est toujours le même fichier qui sera téléchargé.

Kuix est testé sur une large partie des mobiles présent dans cette rubrique.

Pour ce qui est des performances, il est délicat de comparer l'incomparable. Je suis désoler de rappeler qu'avec les composants LCDUI, il n'est pas possible de faire grand choses. De ce point de vue Kuix va beaucoup plus loin tant dans la disposition, la forme ou l'estétique des composants.
Donc pour répondre à la question, les performances à contenu égale sont très similaires entre Kuix et LCDUI (List, Form, Textfield, ...).

De plus le rendu par "Layout" va permettre à l'application construite avec Kuix de savoir d'adapter à toutes les tailles d'écrans sans même avoir à s'en préoccuper.

Pour résumer, je dirais que les principaux points forts de Kuix sont :
- la séparation entre logique d'application et design d'interface.
- la portabilité KVM (CLDC 1.0 / MIDP 2.0) et taille d'écran (Layout)
- la légèreté (env 60ko)

[manitoba]

* interface rapide et propre
* plus évolué que J4ME (plus de possibilités)
* beaucoup moins lourd que LWUIT (mais le jar de demo fait quand même 150k)
* semble tourner sur pas mal de téléphone (a vérifier)
* licence commerciale abordable : 199€ / 1 appli.

C'est plutôt positif pour moi. Je l'envisagerais sans doute lors d'un prochain projet.

Question au CEO (puisque on la sous la main ) , quel effort a votre avis pour faire un player audio/vidéo avec kuix ?

[bbeaulant]

... quel effort a votre avis pour faire un player audio/vidéo avec kuix ?

L'effort sera minime. il vous suffira de constituer un nouveau composant en dérivant la class Widget. Cette dernière va vous donner accès à toutes les informations concernant sa taille et sa position, ainsi qu'une méthode paint(). Partant de là vous aurrez accès à tout ce qu'il vous faut pour utiliser les outils de rendu de vidéo de J2ME.

Pour créer son propre composant dans Kuix, je vous invite à consulter cette page.

[yodutouf]

Bonjour est ce que quelqu'un l'a utilisé pour un projet ?

Cordialement,

Olivier