diff options
Diffstat (limited to 'egraph/doc/TODO.txt')
| -rw-r--r-- | egraph/doc/TODO.txt | 118 |
1 files changed, 118 insertions, 0 deletions
diff --git a/egraph/doc/TODO.txt b/egraph/doc/TODO.txt new file mode 100644 index 0000000..beed508 --- /dev/null +++ b/egraph/doc/TODO.txt @@ -0,0 +1,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 + |