1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
CURRENT
=======
vertice / vertice_text visibility will be broken
need to implement it in the edje object and send signals
* BUG: show nodes labels does not show old nodes labels
reproduce: do not show labels, add edges, show label, add edges
* BUG: layer stacking is wrong, edges end up on top of nodes, despite
eg->split_vertice_edge
* BUG: vertices / vertices text fight for being on top. use evas layers ?
add 500 edges to reproduce, and watch the nodes
TODO
====
* missing function declaration for static _color_int_to_rgb()
* reorder static funcs
* BUG: sometimes when you add nodes during layouting, the graph is broken
a new edge attaches to the wrong new vertice
it seems to be always the same node numbers that gets this wrong edge
* BUG: EGRAPH_LAYOUT_FRUCHTERMANREINGOLD is broken when adding many edges
* zoom
10:16 < glouglou> i want to implement zooming with mouse scroll, do you have some ideas about that ?
10:16 < zmike> that should be trivial
10:16 < zmike> just hook mouse wheel and use efx_zoom
10:18 < glouglou> does efx_zoom resize the objects ?
10:18 < glouglou> all the graph is one evas smart object
10:18 < zmike> it does not resize, it just maps
10:18 < glouglou> that clips everything
10:18 < zmike> it should work, you can see the elm test is working, and that uses smart objects
10:18 < glouglou> yeah i want to update the coordinates i guess, not really "zoom"
10:19 < zmike> hm there's no efx_scale yet, but you could use efx_resize I would think
10:19 < glouglou> i would prefer to resize / update the coords
10:19 < glouglou> scale yes, that would be it
10:19 < glouglou> ok
10:19 < zmike> just calculate the size you want and use efx_resize
10:20 < zmike> it will animate the resizing
* blobs
05:17 < glouglou> cedric: t'as vu dans ma demo les packets qui vont d'une node a l'autre quand les nodes bougent et ben les paquets arrivent a l'ancien endroit
05:17 < glouglou> j'ai regarde un peu dans efx mais j'ai pas trouve de bon moyen
05:18 < glouglou> il faudrait que les paquets ne puissent pas sortir de l'edge (le trait) entre les 2 nodes
05:18 < glouglou> si tu as une idee ...
05:22 -!- Munto [~frugal@2a01:e35:139d:91e0:221:85ff:fee1:5c3c] has quit [Read error: Connection reset by peer]
05:33 -!- sharinganex [~sharingan@233.208.85.79.rev.sfr.net] has joined #e.fr
06:22 <@cedric> glouglou: oui, swallow un smart objet
06:22 <@cedric> qui n'a qu'une seule tache faire bouger des paquets de haut en bas et de bas en haut
06:22 <@cedric> parcontre ca a un probleme, la taille des objets de tes paquets est limite par la taille de ton objet edje parent
06:40 < glouglou> cedric: mais un smart object dans un edje object qui est ensuite mappe, juste pour faire un trait, ca va etre un peu lourd non ?
06:40 < glouglou> et complexe
06:40 < glouglou> mais c'est vrai que ca resous mon probleme
06:41 <@cedric> bah, de toute facon, tu vas avoir une surface cree pour mettre ton edje dans ta map
06:41 <@cedric> dc ca reviendra au meme voir tu fairas l'economie d'une surface
06:49 < glouglou> cedric: donc quand tu swallow un evas smart object dans un edje object, les coordonnes pour le smart object sont relatifs a la part swallow ?
06:50 < glouglou> genre si je fais un geometry_get dans mon smart obj, le 0x0 sera en fait en haut a gauche de ma part swallow edje ?
06:52 <@cedric> oui
06:52 < glouglou> mais c'est magnifique
06:52 < glouglou> et splendide a fois
06:53 < glouglou> merci :D
TODO LATER
==========
* find a better storage type for vertices
quick access O(1) -> table
possibility to foreach and remove at the same time
* possible future API: no edges no vertices for the user
struct Egraph_Vertice {
const char *name;
int vertice_id;
Evas_Object *o;
void *data;
}
egraph_vertice_add(Egraph *eg, const char *name, void *data);
egraph_edge_add(Egraph *eg,
const char *a, const char *b, void *data);
* speed: draw directly to a surface and map to evas via invisible polygons
see elementary/src/bin/test_gesture_layer3.c
04:45 < glouglou> i would like to draw directly in a surface and then give it to evas, but i want in the future to have user interaction with the nodes of my
graph, like click click reaction, so i guess i cannot escape from creating one evas object for each node and edge
04:46 <@raster> trick:
04:47 <@raster> u can just create invisible rects
04:47 < glouglou> (i can imagine crazy mapping of the clicks on my surface that triggers evas callbacks, but i'm not that crazy)
04:47 <@raster> and overlay them on your image
04:47 <@raster> use them for event stuff
04:47 < glouglou> lol
04:47 <@raster> or polygons tyoo
04:47 <@raster> thats about the only use of polygons
04:47 <@raster> as u can do exact inside/outside poly checks for events
04:48 < glouglou> i think you are talking about the crazy things i don't want to do :p
04:48 <@raster> one of the elm demos does this
04:48 <@raster> for soming/rotating with little photos
04:48 <@raster> multitouch test stuff
* speed: from Thanatermesis :
the Core library (https://github.com/acaudwell/Core)
renders to OpenGL directly
used by :
http://code.google.com/p/logstalgia/
https://github.com/acaudwell/Gource (http://code.google.com/p/gource/)
OLD
===
* speed: evas_object_rectangles
04:40 <@raster> they add clipoouts
04:41 <@raster> make them just a bit translucent
04:41 <@raster> and it'll be faster
|
