Home Forums Wiki Doc Install Extras Screenshots Source Code Projects Blog Users Groups Register
Glx-Dock / Cairo-Dock List of forums Ideas | Propositions [Graphs] Changement dans la configuration
The latest stable release is the *3.4.0* : How to install it here.
Note: We just switched from BZR to Git on Github! (only to host the code and your future pull requests)
Ideas | Propositions

Subjects Author Language Messages Last message
[Locked] [Graphs] Changement dans la configuration
Page : 1 2 3
SQP Français 59 lylambda [Read]
25 October 2011 à 18:23

SQP, Monday 25 July 2011 à 23:36


Subscription date : 03 July 2010
Messages : 1081
J'aimerais essayer de répondre à 2 besoins par un petit changement de la configuration des graphes :
  • Pouvoir avoir la même configuration facilement sur tous mes graphes
  • Pouvoir ajouter des options aux graphes (plein !)

Je propose donc une centralisation de la configuration des graphes dans une zone dédiée permettant d'éditer des thèmes de graphique en les nommant et de choisir leurs options.

Il ne resterait dans la zone de configuration de l'applet que le choix du thème et un bouton vers la fenêtre d'édition, plus les options spécifiques au module (genre le group all)

Si on se démerde bien, et que chaque thème nomme bien ses graphiques, ca pourrait permettre aussi d'importer facilement des configs différentes.

J'espère que mon idée est assez claire. Evidemment je peux essayer de faire un mockup si il y a du monde intéréssé.

Parmi les options en plus que j'aimerais ajouter :
  • utiliser une image comme background
  • choisir les réglages de marges et de radius (j'ai joué avec, et une partie de mon problème de graphs pas beaux vient de la)
  • placement, fontes et couleurs des textes pour les label et les "on icon" (les options de textes pourraient aussi être sympa regroupées de la même manière, et si quelqu'un pense à d'autres trucs, on pourrait avoir une fenêtre de thémage commune assez sympa)


(c'est ca ou faire des thèmes comme les jauges)

En passant, j'ai trouvé un bon bug qui me rendaient mes graphs tout moches parce que pas carrés et en mode vertical : le nombre de valeurs était basé sur la hauteur de mon graph.

Voici une tentative de correction sur System-Monitor. Si quelqu'un peut vérifier les cas : dock vertical, dock horizontal et entrée/sortie de desklet.

=== modified file 'System-Monitor/src/applet-init.c'
--- System-Monitor/src/applet-init.c    2011-04-07 00:04:36 +0000
+++ System-Monitor/src/applet-init.c    2011-07-25 19:52:31 +0000
@@ -74,7 +74,9 @@ static void _set_data_renderer (CairoDoc
        memset (&attr, 0, sizeof (CairoGraphAttribute));
        pRenderAttr = CAIRO_DATA_RENDERER_ATTRIBUTE (&attr);
        pRenderAttr->cModelName = "graph";
-        pRenderAttr->iMemorySize = (myIcon->fWidth > 1 ? myIcon->fWidth : 32); // fWidht peut etre <= 1 en mode desklet au chargement.
+        pRenderAttr->iMemorySize = (myApplet->pContainer->bIsHorizontal == CAIRO_DOCK_HORIZONTAL ? myIcon->fWidth : myIcon->fHeight);
+        if (pRenderAttr->iMemorySize < 1)
+         pRenderAttr->iMemorySize = 32; // fWidht peut etre <= 1 en mode desklet au chargement.
        //g_print ("pRenderAttr->iMemorySize : %d\n", pRenderAttr->iMemorySize);
        attr.iType = myConfig.iGraphType;
        attr.iRadius = 10;

fabounet, Wednesday 27 July 2011 à 12:47


Subscription date : 30 November 2007
Messages : 17118
le fix paraît bon, en effet l'orientation n'était pas prise en compte, merci

(c'est ca ou faire des thèmes comme les jauges)

en fait des thèmes pour les graphes ça pourrait être une bonne idée, le problème c'est que c'est pas user-friendly (mais c'est aussi le cas pour les jauges, donc on pourrait dire qu'osef).

SQP, Friday 29 July 2011 à 09:56


Subscription date : 03 July 2010
Messages : 1081
bah je pense qu'il y aura moins facilement des thèmes de graphes que de jauges, mais qu'une config centralisée ou tu te définis 1 ou 2 thèmes de graph, ça permettrait de leur mettre plus d'options assez facilement sans surcharger les applets (en les simplifiant même).

J'oubliais l'option la plus importante à ajouter : choisir l'image sur laquelle sera découpé le graphique. Au lieu d'un dégradé 2 couleurs, on peut se faire un svg un peu plus sophistiqué !! Ou sinon j'ai qq png sympa dans mon répertoire de thèmes gkrellm.

Tu serais partant pour essayer de mettre quelques variables dans le code des graphs ?

Pour le bug, je fais un patch pour tous les applets à graph ou t'as déjà prévu quelquechose ?

PS : si quelqu'un veut tester, mes graphs dans le dock ont une meilleure gueule avec ces simples valeurs entières :
(dans la fonction load de cairo-dock-graph.c)
    //~ pGraph->iRadius = MAX (pAttribute->iRadius, MIN (iWidth, iHeight)/3.);
    //~ pGraph->fMargin = pGraph->iRadius * (1. - sqrt(2)/2);
    
    pGraph->fMargin = 1.;
    pGraph->iRadius = 2;

de base, avec un dock assez large de 48px par exemple, on a un radius à 16 et un margin à 4,686291501.
On se retrouve donc avec une surface à afficher inférieure (à cause du radius) à 48 - 2 * 4,686291501 = 38,627416998px
on perd presque 10px rien que sur le margin, et en se retrouvant avec des valeurs de décalages et de taille non entier, qui va rendre l'affichage un peu flou : essayer d'afficher 48 valeurs sur une zone de 38,627...px

fabounet, Friday 29 July 2011 à 12:59


Subscription date : 30 November 2007
Messages : 17118
le radius étant un entier il devrait être arrondi
la marge par contre est un double, faudrait en faire un entier aussi pour voir si ça améliore.
la marge est calculé pour que le graphe ne mange pas sur le rayon du coin.
bon après c'est ptet pas très judicieux d'en avoir fait un attribut, et 1/3 de l'icône me semble aussi nettement trop grand.
peut-être 1/6 de min(iWidth, iHeight) ? ça ferait 8 de rayon et 2 de marge (en arrondissant).

pour les thèmes de graphes, si on en propose qques de base (rouge->orange, vert->bleu, noir->blanc et l'inverse), ça serait probablement déjà bien, et on aurait plus qu'une liste dans la config des applets.

aussi ça me gêne depuis le début d'avoir mélangé les jauges à aiguille des autres.
ça fait une liste à rallonge (qui sera encore plus grande avec les barres de progression) et chaque applet liste tous les thèmes (alors que pour le wifi, je vois pas l'intérêt du thème de batterie). et puis le code est si différent ...

SQP, Wednesday 03 August 2011 à 23:07


Subscription date : 03 July 2010
Messages : 1081
Comme je n'utilise pas les graph en desklet (normal vu que je n'utilise pas de desklet), il y a surement des choses à nuancer sur certains points pour cet affichage mais voici mon constat :

Mes jauges prennent tout l'espace qui leur est alloué. Mes autres icones ou applets ne se gènent pas non plus quand ce qu'il y a à dessiner est assez grand.

Et je me retrouve avec des graphs aux dimensions réduites pour des effets de styles qui ne m'interessent pas : les coins arrondis donnent un effet sympa, mais sont plutôt nuisibles à la lisibilité en raison de l'espace qu'ils font perdre. On se retrouve à vouloir agrandir le dock pour voir un peu mieux, mais ça a des conséquences sur tout le reste du dock.

J'ai pris l'exemple d'un dock à 48px, mais c'est un luxe que je ne peux pas trop me permettre : sur un dock vertical, 48px de large ca fait super classe pour les graphes et les jauges, mais 48px de hauteur pour chaque icone ça limite le nombre affichables à 25 en 1920x1200. Je n'ose pas imaginer sur de plus petits écrans.

A noter qu'à mon avis, il devrait y avoir une distinction entre les marges X et Y . Une marge vers la bordure du dock peut être pertinente pour l'effet, mais inutile entre les applets. Il y a déjà une marge à ce niveau la. (et toujours le problème de distinction du sens du dock)

De plus cette marge réduit aussi l'espace utile pour les textes. J'ai pu voir que les textes "in graph" n'étaient activés qu'à partir de cette taille de 48px. En dessous, on se retrouve avec l'affichage "on icon" standard. En utilisant ma valeur de 1 pour la marge, je peux avoir la même taille d'affichage interne disponible à partir de 41px (40,6)
J'aurais d'autres trucs à dire sur la taille allouée à ce texte, mais la marge joue beaucoup dessus quand même.

Vu qu'avec une possibilité de thèmes, je devrais pouvoir couvrir mes besoins, j'ai commencé à réfléchir à la question, et je me suis dit que si on fait une configuration de thèmes sur les graphs. Ensuite, il suffirait de faire ou d'utiliser un petit éditeur XML et quelques boutons de gestion (add/remove/copy...) pour avoir un truc modifiable par tout le monde.

les autres trucs sympa que je garde pour le moment, et que je vous encourage à tester (dans implementations/cairo-dock-graph.c)

Le label en blanc avec alpha 75% (ligne 356)
l'effet de flou ignoble sur les labels est du à une ombre gris très sombre autour d'un texte noir, il suffit donc de changer la couleur centrale
                pLabel->param.pColor[0] = 1.;
                pLabel->param.pColor[1] = 1.;
                pLabel->param.pColor[2] = 1.;
                pLabel->param.pColor[3] = .75;


Virer les axes sur la gauche (ligne 254) :
        //~ cairo_move_to (pCairoContext, fMargin, fMargin);
        //~ cairo_rel_line_to (pCairoContext, 0., fHeight - 2*fMargin);
        //~ cairo_stroke (pCairoContext);


Ne dessiner le trait que si la valeur est supérieure à 0
ajouter un test if (fValue > 0) autour des fonctions de dessin dans la fonction render

et le screen de ce que ca donne sur ma config : (à droite les graphs originaux)
J'ai juste élargi le dock à 48 px pour avoir les textes in graph, et changé le fond d'écran pour un plus adéquat
A noter en bas un retour de mon volume en jauge :), surement bientôt sur une branche quand j'aurais vérifié les changements de config et libérations mémoire.

http://uppix.net/3/c/4/26a9cbb578c609bd35264fbc2b5ca.png http://meuarrr.free.fr/images/temp/cairo-dock-mymonitoring.png

fabounet, Thursday 04 August 2011 à 13:27


Subscription date : 30 November 2007
Messages : 17118
ok pour utiliser le plus d'espace possible pour l'essentiel, c'est-à-dire la courbe elle-même.
par contre je pense à un truc, c'est qu'en fait on demande 48 valeurs à afficher, et que le graphe s'affiche sur ~ 40px
du coup il doit y'avoir un zoom qui est fait, et ça rend pas bien.
je me demande si en fait il suffirait pas de mieux préciser le nombre de valeurs que le renderer peut afficher (ou faire en sorte que les graphes ne puissent afficher que 40 valeurs si leur largeur est de 40, même si ils ont 48 valeurs en mémoire).

non pas que je tienne particulièrement à mes coins arrondis, mais juste pour être sûr d'avoir cerné le problème

SQP, Thursday 04 August 2011 à 21:42


Subscription date : 03 July 2010
Messages : 1081
je confirme pour le nb de valeurs à afficher, il faut soustraire margin * 2.
J'ai déjà modifié le mien comme ca, mais sans être sur de la qualité du résultat pour le moment (pas l'impression que mon graph soit net), c'est pour ca que j'avais pas encore abordé. J'approfondis avant de confirmer.

pour le moment, MemorySize est définit à l'init de l'applet, et margin dans le renderer. Ca laisse quelques valeurs en trop non affichées correspondant à cette marge

Pour les coins arrondis, c'est pas que je leur en veut, je trouvais que ca donnait un effet pas mal, mais c'est en me penchant sur le code que j'ai compris toute la place que ca me fait perdre.

En plus d'ajuster le nombre de valeurs à afficher pour bien avoir une seule valeur par pixel, il faudrait surement avoir une configuration différente pour le calcul du radius et margin suivant qu'on est en desklet ou pas. Comme je disais plus haut, avec radius=2 et margin=1, j'ai un truc qui me plait beaucoup plus dans le dock.

Le truc que je me demande, c'est si je suis le seul à utiliser des graph, ou du moins à utiliser des graph dans le dock, parce que j'aimerais voir d'autres exemples d'utilisation. Comment vous avez fait pour avoir un truc qui rende bien ?

Alors si des utilisateurs de graphs lisent ca, si vous pouviez poster des screens et quelques détails sur votre config.
Et vos appréciations et commentaires, sur ce qui vous plait ou pas sur ces graphs.

SQP, Friday 05 August 2011 à 14:18


Subscription date : 03 July 2010
Messages : 1081
comme il faut repasser sur tous les applets à graph pour corriger le bug d'orientation du dock (post #1), je propose d'en profiter pour essayer de factoriser la partie de création d'un renderer graph avec ces 2 fonctions (à rename ou améliorer autant que vous voulez)

static CairoGraphAttribute cairo_dock_create_graph_attribute (CairoDockModuleInstance *myApplet, int iGraphType, gboolean bMixGraph)
{
    CairoDataRendererAttribute *pRenderAttr = NULL; // les attributs generiques du data-renderer.
    CairoGraphAttribute attr; // les attributs du graphe.
    memset (&attr, 0, sizeof (CairoGraphAttribute));
    pRenderAttr = CAIRO_DATA_RENDERER_ATTRIBUTE (&attr);
    pRenderAttr->cModelName = "graph";
    pRenderAttr->iMemorySize = (myApplet->pContainer->bIsHorizontal == CAIRO_DOCK_HORIZONTAL ? myIcon->fWidth : myIcon->fHeight);
    if (pRenderAttr->iMemorySize < 1)
     pRenderAttr->iMemorySize = 32; // fWidht peut etre <= 1 en mode desklet au chargement.
    //g_print ("pRenderAttr->iMemorySize : %d\n", pRenderAttr->iMemorySize);
    attr.iRadius = 10;
    attr.iType = iGraphType;
    attr.bMixGraphs = bMixGraph;
    return attr;
}

static void cairo_dock_graph_set_colors (CairoGraphAttribute *attr, int iNbValues, const void* fHighcolor, const void* fLowColor, const void* fBgColor)
{
    int i;
    for (i = 0; i < iNbValues; i ++)
    {
        memcpy (&attr->fHighColor[3*i], fHighcolor, 3*sizeof (double));
        memcpy (&attr->fLowColor[3*i], fLowColor, 3*sizeof (double));
    }
    memcpy (attr->fBackGroundColor, fBgColor, 4*sizeof (double));
}


ce qui laisse un code plus simple dans l'applet (et surement perfectible encore) et plus centré sur l'essentiel : charger les valeurs de la config dans le renderer. Et vu que c'est un code qui va peut être subir des modifs (sur le set_colors), autant l'avoir aussi simple et factorisé que possible. (7 applets concernés, afaik)

    else if (myConfig.iDisplayType == CD_SYSMONITOR_GRAPH)
    {
        CairoGraphAttribute attr = cairo_dock_create_graph_attribute (myApplet, myConfig.iGraphType, myConfig.bMixGraph);
        double fHighColor[CD_SYSMONITOR_NB_MAX_VALUES*3];
        double fLowColor[CD_SYSMONITOR_NB_MAX_VALUES*3];
        attr.fHighColor = fHighColor;
        attr.fLowColor = fLowColor;
        cairo_dock_graph_set_colors (&attr, iNbValues, myConfig.fHigholor, myConfig.fLowColor, myConfig.fBgColor);
        pRenderAttr = CAIRO_DATA_RENDERER_ATTRIBUTE (&attr);
    }

fabounet, Friday 05 August 2011 à 14:31


Subscription date : 30 November 2007
Messages : 17118

En plus d'ajuster le nombre de valeurs à afficher pour bien avoir une seule valeur par pixel, il faudrait surement avoir une configuration différente pour le calcul du radius et margin suivant qu'on est en desklet ou pas. Comme je disais plus haut, avec radius=2 et margin=1, j'ai un truc qui me plait beaucoup plus dans le dock.

plutôt sur la taille de l'icône alors, le code doit rester générique
genre une valeur qui ferait 1px pour 48, 2 pour 64, 3 pour 96 (une simple fonction affine irait).
le rayon se déduit de la marge.


pour le moment, MemorySize est définit à l'init de l'applet, et margin dans le renderer. Ca laisse quelques valeurs en trop non affichées correspondant à cette marge

le renderer devrait tronquer lui-même s'il y'a trop de valeurs. l'applet dit juste combien de valeurs elle aimerait afficher.

au fait ça n'est pas trop lourd d'afficher autant de graphes/jauges ?

SQP, Sunday 07 August 2011 à 18:39


Subscription date : 03 July 2010
Messages : 1081
un commentaire sur la proposition de factorisation des 2 fonctions de creation de graph avant de déployer un fix sur les applets ?

fabounet :

plutôt sur la taille de l'icône alors, le code doit rester générique
genre une valeur qui ferait 1px pour 48, 2 pour 64, 3 pour 96 (une simple fonction affine irait).
le rayon se déduit de la marge.


un truc du genre iMargin = (int) ((MIN (iWidth, iHeight) - 16) / 16)
ca donnerait ca :
1 - 31 : 0
32 - 47 : 1
48 - 63 : 2
64 - 79 : 3
80 - 95 : 4
96 - 111 : 5
112 - 127 : 6
...


au fait ça n'est pas trop lourd d'afficher autant de graphes/jauges ?


non ca va, j'ai réglé les graphes à 3s refresh sans transitions, et les jauges à 30s refresh, ce qui suffit largement pour surveiller la mémoire ou les partitions. Au démarrage de la session, j'ai le cpu qui alterne entre 0 et 1,1% d'utilisation sur mon Atom D525

fabounet, Monday 08 August 2011 à 13:57


Subscription date : 30 November 2007
Messages : 17118
ça me parait bien

un commentaire sur la proposition de factorisation des 2 fonctions de creation de graph avant de déployer un fix sur les applets ?


pourquoi pas, mais pas dans le core alors, plutôt dans une petite lib statique dans les plug-ins (comme celle pour factoriser gvfs entre gnome-integration et xfce-integration)

SQP, Monday 08 August 2011 à 15:58


Subscription date : 03 July 2010
Messages : 1081
c'est toujours un plaisir d'essayer de proposer des trucs avec toi

fabounet, Monday 08 August 2011 à 17:22


Subscription date : 30 November 2007
Messages : 17118
ouais je suis pointilleux, mais je le suis aussi avec moi si ça peut te rassurer (le nombre de fois que je suis repassé sur mon code )

matttbe, Monday 08 August 2011 à 19:34


Subscription date : 24 January 2009
Messages : 12573
fabounet :
pourquoi pas, mais pas dans le core alors, plutôt dans une petite lib statique dans les plug-ins
Pourquoi pas dans le core?
Car ça simplifie un petit peu la création de graph pour les applets, ça peut être pratique.

SQP, Monday 08 August 2011 à 19:43


Subscription date : 03 July 2010
Messages : 1081
je le suis surement pas moins, mais avec les infos que tu me lâches à chaque fois, j'aurais jamais eu aucune chance d'arriver à mettre un truc à niveau.

Alors maintenant essaye de te mettre à la place de quelqu'un qui a envie de contribuer :

J'ai un problème de rendu, je cherche d'ou ca peut venir, je découvre un bug, je cherche un patch, je le teste, et le propose.
Une fois confirmé, je regarde pour déployer le fix, et j'arrive à 2 fonctions pour factoriser 15 lignes identiques (faute d'orthographe incluse) sur tous les applets à graph, et incluant mon correctif.

Réponse : non ca irait pas à gauche, mais à droite !

OK bah désolé d'avoir voulu aider

Mais il y a surement des très bonnes raisons (que je ne veux pas connaître) pour aller cacher le code de creation des graph, qui fait 20 lignes, ailleurs que dans le fichier cairo-dock-graph.[c/h] qui lui en fait 550, inutiles si on n'initialise pas le dit graph.

Maintenant, bah t'as l'idée et le bout de code pourri, t'en fais ce que tu veux.
Mon prochain post fera 2 lignes et 1 screen, et peut être un lien vers une branche si j'ai le courage, ou pas de post du tout, je gagnerais mon temps et le tien.

(moi mon coté pointilleux, il dit que si ya eu un copier-coller de code pour faire la même chose, c'est une erreur)

matttbe, Monday 08 August 2011 à 21:53


Subscription date : 24 January 2009
Messages : 12573
Merci pour cette franchise et pour insister sur ton patch qui me semble correct et utile (je peux me tromper mais moi j'aimerais bien savoir pourquoi )

Je suppose que Fab n'est pas dans cette partie du code et que du coup, il n'a peut-être pas compris l'avantage de son application... mais bon...

J'attends toujours l'avis de Fab concernant le sujet sur les nouveaux thèmes de jauges pour l'intégrer mais c'est des modifs dans le core, je préfère (et je dois) attendre cette review.
D'un autre côté, maintenant que le plus gros du script de compiz standalone est sorti, la review va peut-être bientôt arrivée

fabounet, Tuesday 09 August 2011 à 12:50


Subscription date : 30 November 2007
Messages : 17118
désolé je pensais que c'était évident, mais c'est vrai j'explique mal
la raison c'est que les graphes et jauges ne sont pas dans le core (gldi) mais sont des implémentations des data-renderer (donc concrètement il faut les voir comme des plug-ins mêmes si on les compile dans le core).
enfin bon, ce genre de détail technique, je peux fignoler ça moi-même, l'essentiel c'est le code, même si c'est un hack. le côté pointilleux c'est pour que le code (plus de 100000 lignes tout de même) soit gérable.

matttbe, Tuesday 09 August 2011 à 17:43


Subscription date : 24 January 2009
Messages : 12573
Merci pour l'explication

SQP, Tuesday 09 August 2011 à 23:37


Subscription date : 03 July 2010
Messages : 1081
ce qui troue le cul, c'est de pas savoir si il a été, ou sera audité. Un petit "ok je materais ca" peut suffire.

Je sais que c'est pas facile de bosser sur trop de sujets à la fois, mais je pense que vu leur rareté, les motivés désireux de contribuer, surtout avec des compétences en programmation, il vaut mieux les encourager.

Même si je sais que je ferais jamais assez de C pour être bon (j'aime pas ça, mais j'ai eu les bases), j'aimerais bien arriver à proposer des patchs du niveau requis, mais je peux pas le faire seul. Chaque section du code est très spécifique et différente des autres. Et il faut du temps pour en comprendre l'organisation et connaitre les fonctions utiles.
J'essaye déjà d'éliminer un gros nombre de mes interrogations avant de venir poser des questions, mais ensuite, généralement, j'essaye d'organiser un tir groupé de questions liées ou pas, mais qui vont me permettre d'aller plus loin. Et je prends le temps d'écrire des posts construits pour rassembler au mieux mes idées.

Si il y en a que la moitié de répondu, parfois, ca me permet d'avancer sur certains sujets, mais souvent je resté assez bloqué.

Exemple sur ce thread, vu les réponses, j'ai pu conserver les 2 bugs, qui bien que sur la route de mon sujet de départ, en sont assez éloigné.

Voila, c'était la fin de ma parenthèse pour fabounet pour dire que si tu veux plus de contributeurs, il faut aussi leur montrer de l'attention, et que c'est surement pas fréquent que le bug arrive avec son patch.
(et un énorme merci à matttbe pour sa réactivité de coté la, autant sur le forum que pour les merge, je crois que mes 4 patchs plugins, dont un nouvel applet, ont été vérifié, patché et intégré dans les 24h)

(et je le répète, moi aussi je suis un maniaque du rangement pour mon code une fois stabilisé)

Pour le détail du patch en lui même. A vrai dire, son emplacement ne me regarde même pas, tant que ca reste facile d'accès pour le plug-in. C'est ton projet et tu le ranges comme tu veux, je peux juste dire ce que j'en pense. Et à mon avis, autant du coté du code, pour avoir ensemble le code lié et utilisant les mêmes variables, que du coté execution, pour que ca soit chargé ensemble si besoin (à moins que ca soit complètement fragmenté et que le renderer charge la partie graph on use)
Et ca fait bcp de commentaires sur une simple facto de 20 lignes.

Retour au sujet initial :

Nouveau screenshot pour montrer que j'ai réussi à aligner les barres sur les pixels et que ca rend beaucoup mieux.
Apparemment avec cairo, pour dessiner un trait vertical de 1 px de largeur sur le pixel 1, il faut se placer à x=1.5, sinon il l’étale salement sur 2 px.

J'ai avancé sur le texte in graph aussi. Le meilleur résultat auquel je suis parvenu est avec un Monospace 8 sans zoom et en indent left légèrement décalé par rapport au coin bas gauche du graph.

Comme ca j'ai un texte net et dont les petites fleches ne bougent plus, ca me donne un aspect plus stable et lisible. (sur cpu, à moins d'un changement de value<10, j'ai le point et le % stables aussi)

J'arriverais presque à dire que je suis enfin satisfait du rendu de mes graphs
(plus que le label à afficher non zoomé pour virer le flou et le problème sur le up/down du netspeed)

http://uppix.net/9/b/c/aa19829804253846946ce7bce3072.pnghttp://meuarrr.free.fr/images/temp/cairo-dock-mymonitoring.png
A droite l'original. La différence est assez choquante, et je crois que je vais enfin pouvoir être fier de montrer mes screens

matttbe, Wednesday 10 August 2011 à 10:32


Subscription date : 24 January 2009
Messages : 12573
et un énorme merci à matttbe pour sa réactivité de coté la, autant sur le forum que pour les merge, je crois que mes 4 patchs plugins, dont un nouvel applet, ont été vérifié, patché et intégré dans les 24h
Avec plaisir mais bon, je n'ai absolument pas le même emploi du temps que Fab et, sur le core, je ne me permettrais pas d'intégrer de si grosses modif car le core a été bien optimisé, cache parfois certains trucs, et de tels modifs peuvent avoir de mauvaises répercutions.

J'espère que la discussion ne va pas plus s'envenimer (mais c'est pas ce que l'on a l'habitude de voir sur le forum ), mais je dois dire que j'ai un peu de mal à me positionner en vers cette situation : d'un côté, c'est vrai que je pense qu'ils manquent des devs sur le projet (p-ê aussi parce que l'on peut s'exprimer en français sur le forum ), que j'apprécie tes contributions et que je comprends tout a fait que ça peut être embêtant de ne pas avoir les réponses et attentes que l'on souhaite. Mais d'un autre côté, je comprends aussi un peu Fab qui a longtemps été seul à contribuer sur le core (pas pour les plug-ins) et que c'est difficile de se (re)mettre à un travail de groupe... et aussi que le core touche tellement à des outils divers que pour passer de l'un à l'autre, ce n'est pas tjs simple...
Je voudrais bien aider à résoudre ce problème mais je ne sais pas trop comment, désolé



Sinon j'approuve la modification, c'est bien clair!
D'un autre côté, je me demandais ceci: étant donné que dans toutes les autres vues on a un zoom, cette justesse ne sera visible que lors du zoom?
Maintenant, comme tu le dis, il manque encore la précision dans la police . Mais c'est plus hard je pense (ou alors l'utilisateur choisi la taille de la police et non la taille en pixels)

Comme ca j'ai un texte net et dont les petites fleches ne bougent plus, ca me donne un aspect plus stable et lisible. (sur cpu, à moins d'un changement de value<10, j'ai le point et le % stables aussi)
Intéressant aussi, c'est plus lisible lorsque ça bouge moins!
Bon boulot

Sinon, je trouve aussi très sympa ceci:
Virer les axes sur la gauche (ligne 254) :
        //~ cairo_move_to (pCairoContext, fMargin, fMargin);
        //~ cairo_rel_line_to (pCairoContext, 0., fHeight - 2*fMargin);
        //~ cairo_stroke (pCairoContext);

Ne dessiner le trait que si la valeur est supérieure à 0
Intégration facile et résultat plus propre!

Ideas | Propositions

Subjects Author Language Messages Last message
[Locked] [Graphs] Changement dans la configuration
Page : 1 2 3
SQP Français 59 lylambda [Read]
25 October 2011 à 18:23


Glx-Dock / Cairo-Dock List of forums Ideas | Propositions [Graphs] Changement dans la configuration Top

Online users :

Powered by ElementSpeak © 2007 Adrien Pilleboue, 2009-2013 Matthieu Baerts.
Dock based on CSS Dock Menu (Ndesign) with jQuery. Icons by zgegball
Cairo-Dock is a free software under GNU-GPL3 licence. First stable version created by Fabounet.
Many thanks to TuxFamily for the web Hosting and Mav for the domain name.