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, Sunday 11 September 2011 à 17:07


Subscription date : 03 July 2010
Messages : 1081
Nouveau patch qui normalement termine la première partie en corrigeant le placement de l'axe horizontal, l'alignement du BAR en vertical, et du LINE et PLAIN pour s'aligner par rapport à l'axe.
Plus affichage du bon nombre de valeurs pour LINE et PLAIN pour aligner sur les pixel.
Ce patch supprime aussi l'axe vertical pour ces 3 modes.

Dans l'ordre BAR, LINE, PLAIN
http://uppix.net/e/7/1/4a172ce965863b2a7c427f90eefc4.png

#829
Graph : Fix display of BAR, LINE, PLAIN
-Remove left axis
-Draw horizontal axis on the pixel
-Align data to match axis position

matttbe, Monday 12 September 2011 à 09:07


Subscription date : 24 January 2009
Messages : 12573
Merci pour ce récapitulatif

@Fabounet: qu'en penses-tu? Je crois que tu étais en train d'y jeter un coup d'oeil le WE, p-ê que c'est déjà fait.

lylambda, Monday 12 September 2011 à 18:51


Subscription date : 06 September 2009
Messages : 1635
Sacré boulot ! Ton travail offre un grand plus au dock

SQP, Tuesday 13 September 2011 à 12:08


Subscription date : 03 July 2010
Messages : 1081
SQP :

2. Première tentative d'amélioration des graphs avec le réalignement du graph BAR sur les pixels #827:
-Affichage du bon nombre de valeurs (utilisation de n = fWidth = pRenderer->iWidth - 2*fMargin)
-Affichage sur le pixel et pas entre les entre deux (le petit décalage de 0.5px dont j'ai parlé plus haut)
-Affichage seulement si il y a une valeurs à afficher (le petit bonus sympa)

3. Changement du calcul des marges et du radius pour l'affichage du graph et de ses coins #828

fMargin est un entier (enfin à partir du 828) donc je n'ai pas de problèmes d'arrondis (à moins qu'on puisse avoir des tailles d'icones avec décimales)
Le floor j'en ai sur d'autres parties (genre les axes horizontaux), mais je l'ai réenlevé d'ici quand j'ai eu des marges entières.

Le 828 c'est juste une inversion du calcul. Au lieu de calculer le radius à partir de la marge, on se fixe une marge (que j'ai réduite par rapport à ce que j'avais imaginé), et on ajuste le radius en fonction. Il y a juste mon facteur 1.5 en plus pour l'ajustement de la taille (vu que l'arrondi n'est calculé que sur la moitié extérieure du trait) et que j'ai préféré documenter.


si t'as encore des question sur mes patchs hésite pas, parce que je suis pas sur que t'as bien compris ce que j'avais fait

fabounet, Tuesday 13 September 2011 à 14:22


Subscription date : 30 November 2007
Messages : 17118
j'ai intégré les patch 827 et 828, avec qques modifs:

827: j'ai borné par iMemorySize en plus de n, car sinon on risquait de sortir du tableau, je pense que c'est tout.

828: j'ai gardé l'esprit (réduire la marge), mais je préfère fixer le rayon, et en déduire la marge. en faisant qques tests, les 2 méthodes me semblent très proches.

829: j'ai regardé hier et j'avais trop sommeil pour comprendre je finirai ce soir (je passerai ptet sur IRC si j'ai des questions)

SQP, Tuesday 13 September 2011 à 22:24


Subscription date : 03 July 2010
Messages : 1081
827 : ya plus rien de mon patch.

828 : le but c'était aussi d'avoir des marges entières pour pouvoir aligner sur les pixels. A partir de la, c'est juste une question de savoir à quelle taille on change cette marge. Sachant qu'on la perd 2* en largeur, il ne faut pas monter trop vite. Et j'ai fait un peu plus que quelques tests...
0-31px : marge 0, perte 0
32-63px : marge 1, perte 2
64-95px : marge 2, perte 4
96-127px : marge 3, perte 6

829 : si on fait un translate et un dessin, ca fait 2 arrondis sur le calcul de la hauteur, et on se prend des décalages.
J'ai donc déplacé le translate dans la section des graphs ronds pour qu'elle reste inchangée, et je fais les calculs directement sans translate.
Je calcule l'affichage en décalant de i+1 graph, comme ca je suis aligné sur mon axe, et j'ai juste à soustraire la taille de ma barre.
(et remis les MIN au nb de valeurs affichées pour pas planter)

SQP, Monday 19 September 2011 à 01:22


Subscription date : 03 July 2010
Messages : 1081
1: Axe vertical : Je n'ai pas l'air d'être le seul à vouloir un graph sans l'axe vertical (matttbe et lylambda ont l'air intéréssé, et personne à part toi n'a voté contre), alors j'ai gardé la modif.

2: Calcul de la marge et du radius : Je persiste avec ma méthode pour définir une marge en fonction de la taille et utiliser la taille maximale disponible pour le radius en fonction de cette marge. Il n'y a aucun intérêt à montrer une progression en fonction de la taille ou à ne pas utiliser de la place qui pourrait être disponible pour un radius (les 2 seuls intérêts du calcul dans le sens radius -> marge).

3: Changement de ratio du Radius : Ensuite, sur ce radius, vu que le calcul du dessin de l'arrondi du rayon n'est calculé que sur l'extérieur du trait, c'est à dire la moitié de la largeur du rayon qu'on lui donne, il y a une marge sur lequel on peut jouer sur le dessin actuel laissant beaucoup d'espace entre l'arrondi du background et la position du coin du graph. J'ai essayé de réduire cette marge de moitié avec le * 1.5 sur le calcul du radius. Je suis sur que le commentaire que j'ai laissé à coté pour essayer de l'expliquer mérite une amélioration, mais je suis convaincu que c'est un changement bénéfique.

Voir juste en dessous les différences entre nos 2 méthodes actuellement. Par rapport à tes nouveaux calculs, j'accorde un poil plus d'espace au margin (par ex entre 32 et 47, et sur les valeurs plus hautes). Mais rien de choquant, mon dock à 36 avec 1 px de marge rend très bien et ce pixel est même bénéfique, et les hautes valeurs comme 160 peuvent très largement se permettre de perdre 10px sur les marges (5x2). Et on est très loin des valeurs qu'il y avait encore il y a qq semaines. Enfin j'ai un rayon cohérent avec la marge dispo.

Taille applet; Margin et Radius avec ma méthode; Margin et Radius avec les calculs actuels
10    0    0    0    0
12    0    0    0    1
14    0    0    0    1
16    0    0    0    1
18    0    0    0    1
20    0    0    0    1
22    0    0    0    1
24    0    0    0    2
26    0    0    0    2
28    0    0    0    2
30    0    0    0    2
32    1    5    0    2
34    1    5    0    2
36    1    5    0    3
38    1    5    0    3
40    1    5    0    3
42    1    5    0    3
44    1    5    0    3
46    1    5    0    3
48    1    5    1    4
50    1    5    1    4
52    1    5    1    4
54    1    5    1    4
56    1    5    1    4
58    1    5    1    4
60    1    5    1    5
62    1    5    1    5
64    2    10    1    5
66    2    10    1    5
68    2    10    1    5
70    2    10    1    5
72    2    10    1    6
74    2    10    1    6
76    2    10    1    6
78    2    10    1    6
80    2    10    1    6
82    2    10    1    6
84    2    10    2    7
86    2    10    2    7
88    2    10    2    7
90    2    10    2    7
92    2    10    2    7
94    2    10    2    7
96    3    15    2    8
98    3    15    2    8
100    3    15    2    8
102    3    15    2    8
104    3    15    2    8
106    3    15    2    8
108    3    15    2    9
110    3    15    2    9
112    3    15    2    9
114    3    15    2    9
116    3    15    2    9
118    3    15    2    9
120    3    15    2    10
122    3    15    2    10
124    3    15    2    10
126    3    15    2    10
128    4    20    2    10
130    4    20    2    10
132    4    20    3    11
134    4    20    3    11
136    4    20    3    11
138    4    20    3    11
140    4    20    3    11
142    4    20    3    11
144    4    20    3    12
146    4    20    3    12
148    4    20    3    12
150    4    20    3    12
152    4    20    3    12
154    4    20    3    12
156    4    20    3    13
158    4    20    3    13
160    5    25    3    13
162    5    25    3    13
164    5    25    3    13
166    5    25    3    13
168    5    25    4    14
170    5    25    4    14
172    5    25    4    14
174    5    25    4    14
176    5    25    4    14
178    5    25    4    14
180    5    25    4    15
182    5    25    4    15
184    5    25    4    15
186    5    25    4    15
188    5    25    4    15
190    5    25    4    15
192    6    30    4    16
194    6    30    4    16
196    6    30    4    16
198    6    30    4    16
200    6    30    4    16


3: Utilisation de la vraie hauteur dispo pour chaque graph : Je suis passé à un calcul qui se base sur la position de l'axe du graph précédent, et de l'axe du graph actuel pour être sur d'avoir une position et une taille de graph correcte. J'en ai profité pour positionner le translate pile sur le graph (en intégrant les margin) et simplifier les calculs. (et faire un patch cohérent, notamment en alignant le cairo_dock_create_graph_pattern)

4: Alignement sur les axes : J'ai essayer de corriger tous les petits problèmes d'alignement des graphs du mieux que je pouvais. Selon mes calculs et tests, avec ce patch, le BAR est parfait, et le LINE/PLAIN souffre juste d'un tout petit poil de non remplissage sur les coins de l'axe, mais ca se voit qu'avec un bon zoom.

J'utilise (et ai besoin) de graphs à 1, 2 et 4 valeurs et de tailles différentes, alors je teste bien les petits décalages qui surviennent sur config avancées.

PS : et c'est pas cool de faire un changement de structure inutile à ce moment (genre passage en switch) sur une zone sur lequel j'ai proposé des modifs et que tu refais les tiennes : il faut que je vérifie chaque ligne au pixel près pour chercher les changements.

#857
Graph: Fix non round display on pixel alignment and use the correct available size for all graphs

+ à edit : screens demain

matttbe, Friday 07 October 2011 à 16:13


Subscription date : 24 January 2009
Messages : 12573
Merged

Merci

matttbe, Saturday 08 October 2011 à 23:51


Subscription date : 24 January 2009
Messages : 12573
Avec ce patch (je ne pense pas avoir eu ce comportement avant), voici ce que j'ai par moments puis peu de temps après, je retrouve mes "pointes":
http://uppix.net/9/6/9/c146922148581d30f788f846e6e49.png


Netspeed est utilisé dans une vue panel qui a une taille réduite (Module Vue / Tableau de bord / 0.6), ça peut p-ê aider.

SQP, Sunday 09 October 2011 à 10:03


Subscription date : 03 July 2010
Messages : 1081
damn, un problème avec le remplissage.
Je vais tester ca ce soir. C'est quoi la taille de l'icone avant réduction ?

matttbe, Sunday 09 October 2011 à 11:30


Subscription date : 24 January 2009
Messages : 12573
Ok merci
c'est du 34x34.

SQP, Monday 10 October 2011 à 13:46


Subscription date : 03 July 2010
Messages : 1081
je crois qu'il va me falloir plus d'infos sur la config de ton graph :
c'est bien un plain ?
netspeed active 2 graphs mais il n'y en a qu'un sur le screen, tu les a mélangé ?

@fabounet : le truc de réduction du panel, j'imagine que c'est un zoom appliqué sur le dock ou ses icônes, donc qui n'a pas d'impact sur la qualité de ce qui est affiché dedans.

matttbe, Monday 10 October 2011 à 17:52


Subscription date : 24 January 2009
Messages : 12573
Voici ma config pour netspeed:
[Configuration]

#l+[Gauge;Graph] Choose the style of the display:
renderer=1

#X[Gauge;gtk-dialog-info]
frame_gauge=

#h+[/usr/share/cairo-dock/gauges;gauges;gauges3] Choose one of the available themes:/
theme=

#l+[No;With dock orientation;Yes] Rotate applet theme :
rotate theme=0

#X[Graph;gtk-dialog-info]
frame_graph=

#l+[Line;Plain;Bar;Circle;Plain Circle] Type of graphic :
graphic type=1

#c+ High value's colour :
#{It's the colour of the graphic for high rate values.}
high color=1;0;0;

#c+ Low value's colour :
#{Graph colour for low rate vaues:}
low color=1;1;0;

#C+ Background colour of the graphic :
bg color=0;0;0;0;

#b Show all values on same graph?
mix graph=true

#F[Parameters;gtk-dialog-info]
frame_param=

#s interface:
#{By default this will be 'eth0'.}
interface=wlan0

#i[1;30] Refresh time:
#{in seconds.}
delay=2

#e[0;1] Fluidity of the transition between 2 values :
#{You need OpenGL for this option. Set it to 0 to disable it, 1 means the transition is continue.}
smooth=0.33000000000000002

#l[No;On icon;On label] Display rate values :
info display=2
Ca n'arrive pas tout le temps. Généralement quand il y a un blanc puis un pic, etc.

fabounet, Monday 17 October 2011 à 13:55


Subscription date : 30 November 2007
Messages : 17118

@fabounet : le truc de réduction du panel, j'imagine que c'est un zoom appliqué sur le dock ou ses icônes, donc qui n'a pas d'impact sur la qualité de ce qui est affiché dedans.


oui c'est un zoom appliquée à l'icône au moment du dessin.

des fois cairo et opengl ne zoom pas très bien en petit, je ne sais pas si ça peut expliquer cela ou pas.

je pense que le mieux c'est de faire les tests dur des desklets de taille moyenne (genre 96x96) pour être sûr que les points tombent bien. après si un zoom rend le tout un peu flou, je pense pas qu'on y puisse grand chose.

matttbe, Monday 17 October 2011 à 15:00


Subscription date : 24 January 2009
Messages : 12573
Ne pas avoir de zoom? (surtout avec cette vue panel, c'est dommage de ne pas avoir la netteté alors qu'il n'y a pas de zoom lorsque la souris est dans le dock)
Et pourquoi pas un zoom uniquement entre la taille max lorsque la souris est dans le dock et la taille min lorsque la souris est hors du dock?

fabounet, Thursday 20 October 2011 à 16:04


Subscription date : 30 November 2007
Messages : 17118
pour ça il faudrait que la taille des icônes soit définie par-dock.
pour l'instant c'est pas possible, mais j'y songe

SQP, Saturday 22 October 2011 à 12:53


Subscription date : 03 July 2010
Messages : 1081
il suffit de pas mettre de zoom sur le panel et changer la taille des icones à la main sur un de tes 2 dock

pour ça il faudrait que la taille des icônes soit définie par-dock.
pour l'instant c'est pas possible, mais j'y songe


si tu songe à un truc comme ca, essaye d'y glisser un moyen pour avoir une taille dynamique en fonction du contenu.
Par exemple si je veux un monitoring des disques qui ajoute ou enlève un graph/gauge quand je (dé)branche un disque.
Ou sur le systray qui varie en fonction du nombre d'icônes.

Une option permettant de définir la taille d'un seul élément serait utile. Et que l'applet puisse demander un resize facilement quand il y a besoin.

Comme ca j'aurais pas à changer la taille de mes icônes quand je veux une partition de plus.

Pour en revenir au sujet initial, je n'ai pas vu de problème à l'affichage en mode mix graph=false, alors je vais me pencher sur le cas inverse

lylambda, Sunday 23 October 2011 à 00:00


Subscription date : 06 September 2009
Messages : 1635
essaye d'y glisser un moyen pour avoir une taille dynamique en fonction du contenu.[…]
Ou sur le systray qui varie en fonction du nombre d'icône
Oh oui ! Ce serait super

fabounet, Tuesday 25 October 2011 à 15:53


Subscription date : 30 November 2007
Messages : 17118
Ou sur le systray qui varie en fonction du nombre d'icône

si je ne m'abuse, le systray (nouveau) se redimensionne automatiquement si plus de 4 items.
je crois qu'il y'a même une option pour ça.

lylambda, Tuesday 25 October 2011 à 18:23


Subscription date : 06 September 2009
Messages : 1635
Étant sur Maverick, je dois encore utiliser le vieux systray… pas de redimensionnement pour moi (du moins, jusqu'à ce que je migre )

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.