Le theme, en l'état, est pas mal buggué (en tout cas sur chrome
/ubuntu). Mais il me semble avoir vu un jour une démo avec la
version debuggué (finalisé), je sais de qui mais mais j'ai pas
obtenu les corrections.
Le 12/09/2012 13:04, Juanjo Menent a écrit :
Et porqui pas adapter a 3.2 et utiliser le theme Amarok?
El mié, 12-09-2012 a las 12:01 +0200, Laurent Destailleur (eldy)
escribió:
Le 12/09/2012 11:39, Cyrille de Lambert a
écrit :
Bonjour,
Pour les interfaces et le thème, Emmanuel propose de décliner
en plusieurs couleurs ce qu'il a fais en orange.
Si c'est jute le changement de couleur, je ne suis pas sur que
cela soit utile.
Mieux vaut une variable ou l'utilisateur choisit sa couleur avec
un theme dynamique, que n themes à maintenir.
(exemple: Ceci est opérationnel avec le module skineditor et le
theme edly. Cela pourrait etre décliné sur les autres themes).
La difficulté est qu'il ne faut plus utilisé d'images mais
uniquement du css pour faire les dégradés sans quoi cela n'est
pas déclinable par couleur.
Cyrille
Le 12/09/2012 11:12, Régis Houssin a
écrit :
je suis d'accord avec toi sur le fait
de ne pas surcharger l'application avec des fonctionnalités
superflues et trop de codes à gérer.
reste à déterminer ce qui est superflu et ce qui est utile
pour 99% des cas
exemple mon module Milestone, il s'avère que ce type de
fonctionnalité est utilisée par beaucoup et c'est pour cela
que j'ai décidé de l'intégrer aussi.
en ce qui concerne les champs personnalisés, ceci est aussi
très utile.
reste à voir si ce module est user friendly et pas trop
tourné geek
j'ai moi même créé un module de champs personnalisés, que je
laisse en module externe pour le moment.
un onglet module expérimental serait le bienvenu, au lieu de
les disperser dans les différents onglets.
je propose aussi de créer une section pour stocker toutes
les constantes cachées, déjà pour éviter de les chercher à
droite à gauche, et pour se souvenir si oui ou non elles
sont activées.
(petit aparté) tu as fusionner des menus systèmes, c'est un
peu brouillon, il faudrait des menus/sous-menus en plus.
maintenant Laurent je suis ok pour une application simple,
mais il faut aussi prendre en compte les remarques de la
majorité des utilisateurs afin de coller au plus grand
nombre et à la demande du marché.
j'ai souvent des remarques de personnes qui découvre
Dolibarr et me demande si c'est fait uniquement pour les TPE
ou association. Ils n'ont pas confiance !
Je penses qu'il faut changer de discours et ne plus se
restreindre dans les capacités de Dolibarr.
PS: et revoir l'interface et les thèmes car pour certains
nous sommes obsolète au possible...
Le 12/09/12 10:42, Laurent
Destailleur (eldy) a écrit :
Pour info
Le 10/09/2012 13:46, Stephen
LARROQUE a écrit :
Bonjour Laurent,
Je te remercie d'avoir étudié ma
proposition avec sérieux.
Je vais ici répondre point par
point à tes interrogations:
- Au sujet de la licence, aucun
soucis, j'avais indiqué dans un mail précédent que je
suis tout à fait d'accord de mettre le module en licence
GPLv2+ comme Dolibarr.
- Je suis aussi tout à fait
d'accord avec le fait que le module devrait être
committé en experimental en premier lieu.
- J'ai déjà étudié la solution de
mettre le module sur Dolistore et n'ai pas retenu cette
solution.
- Le module n'est destiné à la
fois à l'utilisateur lambda et à l'intégrateur (mais
surtout à l'intégrateur) et aussi au développeur: il y a
des niveaux de fonctionnalités et de complexité pour
chacun. Pour l'utilisateur lambda, il n'y a aucune
notion nécessaire, ils peuvent créer leurs champs
simplement dans l'interface et les utiliser dans leur
modèles ODT sans aucune connaissance technique. Les
fonctionnalités avancées sont réservées à ceux que
veulent plus d'options et sont décrites dans le wiki.
Certes, mais le seul fait de "voir"
des fonctons avancées avec des notions non comprises
(comme clé étrnagère, ou requete sql), suffit our ne pas
etre compris par l'utilisateur, meme si c'est optionnel,
c'et genant.
- Au sujet de rajouter des écrans
d'information, effectivement j'ai anticipé et ai déjà
rajouté un petit encart en haut de l'interface
d'administration, qui indique les actions basiques et
pointe vers le wiki pour plus d'informations sur les
fonctionnalités avancées. Si tu as d'autres idées
d'aides à rajouter, je me ferai une joie de les
implémenter car je souhaite que le module soit bien
documenté et le plus facile possible à utiliser.
- Le module peut également être
mis dans la page "complémentaire" si souhaité.
- Quant au fait que "le module
n'apporte qu'une plus-value faible par rapport à la
fonction déjà existante en standard" pour l'utilisateur
lambda, je ne suis pas de cet avis: CustomFields
supporte déjà la quasi-totalité des modules de Dolibarr,
permet d'utiliser un plus grand nombre de types de
champs, gère les champs contraints (ex: lié à une autre
table Dolibarr comme llx_user)
Ceci n'interesse pas l'utilisateur
lambda, il ne sait pas ce qu'est un lien.
et gère l'intégration dans les
templates ODT et PDF;
ceci sera aussi dispo avec le
module standard
sans compter les fonctionnalités
de customization avancées pour l'intégrateur et le
développeur.
Ceci n'interesse pas non plus
l'utilisateur lambda
C'est d'ailleurs pour cette
raison que je me permet de proposer à l'équipe de
l'intégrer.
Et je t'en remercie.
Toutefois, il faut comprendre la stratégie. La cible est
la suivante :
* Ne mettre dans Dolibarr que les fonctions qui assure les
besoins types standard
* Ne pas mettre de fonctions en doublons sur les
fonctionnalité basiques, si la plus value ne concerne pas
les utilisateurs lambda.
* Ne mettre dans Dolibarr que des fonctions
compréhensibles par un utilisateur lambda. Même si une
fonction qui n'est pas pour lui est optionnelle, si on
peut ne pas la faire apparaitre pour ne pas lui faire
peur, il vaut mieux.
* Et pour pouvoir malgré cela offrir un logiciel riche et
puissant et donc garder un compromis entre simplicité et
richesse, ce qui est hors de ce cadre doit être fourni en
module complémentaire (si possible).
Bon, c'et la base, dans la pratique, c'est dur de trouver
le bon compromis. Mais c'et justement la la supériorité
reconnue de dolibarr ar rapport au autres.
N'hésites pas à me dire ce que
toi et l'équipe en pensez, et si vous souhaitez toujours
intégrer CustomFields à Dolibarr.
On pourrait en effet, ajouter des
tas de modules aux fonctions avancées ou aux options
variantes, mais cela grossit dangereusement le code à
maintenir. Hors la politique est de le réduire pour rendre
les choses plus modulaires et externaliser les fonctions.
C'est certes un choix uniquement "tactique", et qui peut
etre discutable, mais dans la mesure ou les concurrents
prennent le chemin inverse (grossir leur coeur pour avoir
plein de fonctions), c'est une maniere de se démarquer et
d'être seul sur un segment abandonnée. C'était aussi
l'engagement pris quand l'auteur du projet m'a demandé de
reprendre son projet.
Ce choix de laisser et rendre encore plus simple (tout en
permettant une utilisation avancée mais sans forcément
avoir ces fonctions avancée maintenu par l'équipe
principale) est donc un choix sur le long terme (car comme
toute stratégie, cela n'a d'effet que sur le long terme),
et seul l'avenir sera capable de dire si il était bon.
D'autant qu'il n'y a pas qu'une seule bonne stratégie, il
peut y en avoir plusieurs. Mais pour un projet donnée, une
seule ne peut etre appliquée à la fois pour avoir un sens.
Aussi il en faut bien une, et l'évolution de popularité et
l'agrandissement de la communauté ces dernières mois avec
les dernieres versions, montre que meme si il y en a
d'autres, de bonnes stratégie, celle n'a semble faire
partie des payantes, même si c'est l'une des plus dur à
suivre (la facilité étant d'integrer chaque commit de
chaque besoin de chacun).
Ce que je propose, c'est que, comme ton modules est non
intrusif, son ajout mais aussi suppression pouvant se
faire sans risque, c'est de le mettre en experimental.
Je vais l'intégrer aussi dans une nouvelle section dont je
n'ai pas encore trouvé de nom pour signaler que le module
évoque des concepts techniques, a moins que je ne fasse
une rubrique "experimental" pour y mettre les modules
experimental plutot que dans leur rubrique dédiée. Hum, y
aura surement des retours à mon mail pour me faire
trancher.
Je te dirais quand c'est commité (j'espere faire cela
cette semaine).
On verra apres comment cela évolu.
J'ai mis le bureau en copie, car pour une fois que
j'explique certais letimotiv, cela ne peut pas faire de
mal.
Cordialement,
--
Un cordial saludo.
Juanjo Menent
2Byte.es
Soluciones
Informáticas S.L.
http://www.2byte.es
C/ San Ramón, 5 46702
Gandía - Valencia (España) Telf. 985 675 996
Grupo
aire[re]creativo.com Factoría de Ideas
address@hidden |http://www.airerecreativo.com
Antes de imprimir este
correo electrónico piense bien si es necesario
hacerlo: El medio ambiente es cosa de todos.
INFORMACIÓN SOBRE
PROTECCIÓN Y TRATAMIENTO DE DATOS PERSONALES: Este
mensaje y los archivos adjuntos son confidenciales y
se dirigen exclusivamente a su destinatario. Si no es
usted el destinatario indicado, queda notificado de
que la utilización, divulgación y/o copia sin
autorización está prohibida en virtud de la
legislación vigente. Si usted ha recibido este correo
por error, por favor avísenos inmediatamente a través
de correo electrónico o por teléfono, descritos en
la parte superior, y tenga la amabilidad de eliminarlo
de su sistema.
En cumplimiento de lo
establecido en la Ley Orgánica 15/1999, de 13 de
Diciembre, de Protección de Datos de carácter Personal
le informamos que sus datos personales quedarán
incorporados en los ficheros de la empresa, con el fin
de poderle prestar y ofrecer nuestros
servicios además de noticias relacionadas con
nuestra actividad. Así mismo, le
informamos de la posibilidad de que ejerza los
derechos de acceso, rectificación, cancelación y
oposición de sus datos de carácter personal siendo el
responsable del fichero la propia empresa, cuya
dirección figura en la parte superior.
|
--
Eldy (Laurent Destailleur).
EMail: address@hidden
Web: http://www.destailleur.fr
Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: address@hidden
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: address@hidden
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
|