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