JolieBulle ⇒ Demande de fonctionnalités [Sujet unique]

[314r]

C'est mieux le bandeau d'infos principales en haut je trouve. Par contre le volume total et l'efficacité ont disparu, dommage.

Ah ah, j'ai eu une pensée émue pour toi et tes petits yeux qui saignaient devant le précédent design
Le volume et l'efficacité vont revenir, ça fait partie des trucs que j'ai bridé pour cette pré-version simplement parce que je bosse dessus et que c'est tout cassé.

Il y a toujours le réglage du ratio qu'il serait pas mal de baisser au dixième.

Oui,c'est bien noté.

Ca a l'air bien pratique le Time Travel ! Juste un truc, j'ai ajouté " test" au nom, et ça créé 5 entrées "name changed", une par lettre. Si tu peux essayer de regrouper ça serait pratique.

Oui voilà, d'une part il va falloir que je sélectionne les actions à enregistrer (typiquement, le changement de nom de recettes je ne pense pas que ça vaille le coup), et d'autre part que je parvienne à une implémentation plus propre.

[efdé]

Mes petits yeux meurtris d'alpha-testeur te remercient
a+

[314r]

Il y a quelques temps sur le fil de Brewy, on évoquait les difficultés liées au Beerxml.
Je rencontre un problème concret : il n'y a pas de balise pour dire si un ingredient fermentable doit être empâté ou non. Jusque là je jouais avec la balise "add_after_boil", mais c'est une mauvaise approximation et j'aimerai faire différemment pour la version à venir.
J'ai regardé ce que faisaient les collègues qui proposent dans leur logiciel de choisir le moment d'utilisation du grain.

Beersmith n'exporte rien dans le Beerxml, l'information est perdue.

Brewtarget ajoute une balise IS_MASHED, qui n'existe donc pas dans le "standard" (avec des énormes guillemets).

Je pense m'aligner sur la proposition de Brewtarget, qui n'est pas idéale mais qui a le mérite de ne pas tout casser et surtout d'être déjà implémentée par des camarades qui jouent encore le jeu d'un format commun.

Est-ce que quelqu'un y voit un inconvénient ?

[Aza-]

Ça ne me pose évidemment aucun problème. C'est très bien si on trouve une solution unique adaptée à tous. Je regarderai pour ajouter ce champ.
Tu as regardé ce que fait brewersfriend ? Ils aiment bien ajouter des champs aussi. Tu vas bien rire en voyant ce qu'ils ont fait avec l'efficacité

[314r]

Du coup je suis allé jeter un oeil sur l'export de Brewersfriend.
L'éditeur propose une option mashed/non mashed sur les fermentables, mais je ne vois rien dans le xml. Ils ont d'ailleurs une façon très contre-intuitive de traiter les ajouts non mashed, pour lesquels le rendement du brassage ne s'applique pas et qui font donc exploser la DI (comme un ajout de sucre...). C'est totalement wtf non ?

[Aza-]

Je viens de regarder et je confirme. Bon, je suis cantonné sur mobile, donc c'est dur d'y voir clair, mais c'est effectivement très bizarre. Ils ne renseignent rien dans le XML à ce propos et effectivement ces ajouts non mashed sont ajoutés comme des sucres purs (100% de rendement, 100% efficacité).
J'essaierai de faire plus de tests la semaine prochaine.
A propos de l'efficacité dont je te parlais, c'est la dropdown Target tout en haut. Si tu choisis kettle, le champ efficiency du XML représente l'efficacité de brassage (contrairement au standard). Si tu choisis Fermentor, c'est bien l'efficacité brasserie. Du coup, ils ajoutent le champ

Code : Tout sélectionner

<BATCH_SIZE_MODE>k</BATCH_SIZE_MODE>

pour dire quel type d'efficacité ils utilisent.
Je l'ai pas encore pris en compte dans Brewy.

[314r]

Ah oui c'est... particulier.
Ceci dit il va falloir aussi que j'affine la gestion de l'efficacité dans joliebulle, pour le moment c'est rustique.

[Aza-]

Oui, sur ce point là, je pense que j'ai dépassé JolieBulle grâce notamment à la prise en compte de l'équipement etc. Du coup, je peux sortir l'efficacité brassage, l’efficacité brasserie en ayant un résultat similaire à celui de BeerSmith.

Je viens de regarder comment Brewy se comportait avec un fermentable en non mashed sur un XML pris de chez eux. Comme je le pensais, je tombe sur la densité comme s'il était mashed. Donc leur solution est... bancale.

Tant que j'y pense et que tu es en plein (re)développement de JolieBulle, je ne sais pas comment tu gères ton XML, mais ce qui serait super ce serait que JolieBulle ne supprime pas les nodes qu'il ne touche pas.
Un exemple : Brewy gère les styles (avec tous les sous nodes) contrairement à JolieBulle qui ne gère que le titre. Si j'exporte avec Brewy en ayant mis un style complet, que je réimporte avec JolieBulle et fais une modif puis renvoie vers Brewy, les infos complémentaires du style sont écrasées.

[314r]

Oui, sur ce point là, je pense que j'ai dépassé JolieBulle

Ça me fend le coeur.

Tant que j'y pense et que tu es en plein (re)développement de JolieBulle, je ne sais pas comment tu gères ton XML, mais ce qui serait super ce serait que JolieBulle ne supprime pas les nodes qu'il ne touche pas.

Pas simple je pense.
Pour parser le xml j'utilise un module tiers (pixl-xml) qui me renvoit un objet complet, donc il n'y a pas de perte d'information à ce stade. Pour l'export en revanche j'utilise un module maison qui est plus selectif et qui n'écrira pas des éléments arbitraires. Par contre dans le cas concret du style, je ne vois pas d'obstacle à faire passer les données extraites dans le document final... faut juste que je l'implémente, ce qui est une bonne idée.

[Aza-]

Ça me fend le coeur.

J'espère que je me suis pas mal exprimé. Ce n'était en aucun cas une marque de compétition entre nos deux applications. Je ne me place pas sur ce terrain ^^
Et de toute façon, JolieBulle fait beaucoup de choses que Brewy ne fait pas, comme le fait de pouvoir composer des recettes par exemple

Pas simple je pense.
Pour parser le xml j'utilise un module tiers (pixl-xml) qui me renvoit un objet complet, donc il n'y a pas de perte d'information à ce stade. Pour l'export en revanche j'utilise un module maison qui est plus selectif et qui n'écrira pas des éléments arbitraires. Par contre dans le cas concret du style, je ne vois pas d'obstacle à faire passer les données extraites dans le document final... faut juste que je l'implémente, ce qui est une bonne idée.

Je m'en doutais, mais il fallait que je demande
En terme technique, Brewy utilise la lib simple-xml. Elle parse de manière extensive le XML en objets kotlin qui couvrent l'intégralité de la spec. Du coup, quand je réexporte en XML, tous les champs existant en entrée, ressortent en sortie.