Re: [E-devel] E SVN: kakaroto trunk/ecore/src/lib/ecore_sdl
On Mon, 12 Sep 2011 07:41:18 +0200 (CEST) Vincent Torri said: > > > On Sun, 11 Sep 2011, Enlightenment SVN wrote: > > > Log: > > Ecore-sdl: remove unused events and fix semicolon typo and docs > > this is an API break actually ecore_sdl was already broken - it had the extern ints defined but never backed them with real symbols - so anyone using those event id's would have had their code fail to link as it'd have never found symbols. so it's not an api break. it was already broken :( > Vincent > > > > > Author: kakaroto > > Date: 2011-09-11 20:43:46 -0700 (Sun, 11 Sep 2011) > > New Revision: 63338 > > Trac: http://trac.enlightenment.org/e/changeset/63338 > > > > Modified: > > trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h > > trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c > > > > Modified: trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h > > === > > --- trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h 2011-09-12 03:43:37 > > UTC (rev 63337) +++ trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h > > 2011-09-12 03:43:46 UTC (rev 63338) @@ -36,14 +36,8 @@ > > extern "C" { > > #endif > > > > -EAPI extern int ECORE_SDL_EVENT_KEY_DOWN; /**< SDL Key Down event */ > > -EAPI extern int ECORE_SDL_EVENT_KEY_UP; /**< SDL Key Up event */ > > -EAPI extern int ECORE_SDL_EVENT_MOUSE_BUTTON_DOWN; /**< SDL Mouse Down > > event */ -EAPI extern int ECORE_SDL_EVENT_MOUSE_BUTTON_UP; /**< SDL Mouse > > Up event */ -EAPI extern int ECORE_SDL_EVENT_MOUSE_MOVE; /**< SDL Mouse > > Move event */ -EAPI extern int ECORE_SDL_EVENT_MOUSE_WHEEL; /**< SDL Mouse > > Wheel event */ -EAPI extern int ECORE_SDL_EVENT_GOT_FOCUS; /**< SDL Mouse > > Wheel event */ -EAPI extern int ECORE_SDL_EVENT_LOST_FOCUS; /**< SDL Mouse > > Wheel event */ +EAPI extern int ECORE_SDL_EVENT_GOT_FOCUS; > > +EAPI extern int ECORE_SDL_EVENT_LOST_FOCUS; > > EAPI extern int ECORE_SDL_EVENT_RESIZE; > > EAPI extern int ECORE_SDL_EVENT_EXPOSE; > > > > > > Modified: trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c > > === > > --- trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c 2011-09-12 03:43:37 > > UTC (rev 63337) +++ trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c > > 2011-09-12 03:43:46 UTC (rev 63338) @@ -50,9 +50,9 @@ > > } > > > > /** > > - * @defgroup Ecore_Sdl_Library_Group Framebuffer Library Functions > > + * @defgroup Ecore_Sdl_Library_Group SDL Library Functions > > * > > - * Functions used to set up and shut down the Ecore_Framebuffer functions. > > + * Functions used to set up and shut down the Ecore_Sdl functions. > > */ > > > > /** > > @@ -96,8 +96,8 @@ > > EAPI int > > ecore_sdl_shutdown(void) > > { > > - if (--_ecore_sdl_init_count != 0); > > - return _ecore_sdl_init_count; > > + if (--_ecore_sdl_init_count != 0) > > + return _ecore_sdl_init_count; > > > >ecore_event_shutdown(); > >eina_log_domain_unregister(_ecore_sdl_log_dom); > > > > > > -- > > Doing More with Less: The Next Generation Virtual Desktop > > What are the key obstacles that have prevented many mid-market businesses > > from deploying virtual desktops? How do next-generation virtual desktops > > provide companies an easier-to-deploy, easier-to-manage and more affordable > > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > > ___ > > enlightenment-svn mailing list > > enlightenment-...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > > > > > -- > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists
Re: [E-devel] E SVN: discomfitor IN trunk/PROTO/azy/src: include lib tests/identi.ca tests/rss
On Sun, 11 Sep 2011 23:20:56 -0700 "Enlightenment SVN" wrote: > Log: > add AZY_EVENT_DOWNLOAD_STATUS, related type Azy_Event_Download_Status, docs, > and examples > > Author: discomfitor > Date: 2011-09-11 23:20:56 -0700 (Sun, 11 Sep 2011) > New Revision: 63343 > Trac: http://trac.enlightenment.org/e/changeset/63343 > > Modified: > trunk/PROTO/azy/src/include/Azy.h trunk/PROTO/azy/src/include/azy_private.h > trunk/PROTO/azy/src/lib/azy_client_events.c trunk/PROTO/azy/src/lib/azy_lib.c > trunk/PROTO/azy/src/tests/identi.ca/get.c trunk/PROTO/azy/src/tests/rss/rss.c > @[Rui] -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/ecore/src/lib/ecore_sdl
On Sun, 11 Sep 2011, Enlightenment SVN wrote: > Log: > Ecore-sdl: remove unused events and fix semicolon typo and docs this is an API break Vincent > > Author: kakaroto > Date: 2011-09-11 20:43:46 -0700 (Sun, 11 Sep 2011) > New Revision: 63338 > Trac: http://trac.enlightenment.org/e/changeset/63338 > > Modified: > trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h > trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c > > Modified: trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h > === > --- trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h 2011-09-12 03:43:37 UTC (rev > 63337) > +++ trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h 2011-09-12 03:43:46 UTC (rev > 63338) > @@ -36,14 +36,8 @@ > extern "C" { > #endif > > -EAPI extern int ECORE_SDL_EVENT_KEY_DOWN; /**< SDL Key Down event */ > -EAPI extern int ECORE_SDL_EVENT_KEY_UP; /**< SDL Key Up event */ > -EAPI extern int ECORE_SDL_EVENT_MOUSE_BUTTON_DOWN; /**< SDL Mouse Down event > */ > -EAPI extern int ECORE_SDL_EVENT_MOUSE_BUTTON_UP; /**< SDL Mouse Up event */ > -EAPI extern int ECORE_SDL_EVENT_MOUSE_MOVE; /**< SDL Mouse Move event */ > -EAPI extern int ECORE_SDL_EVENT_MOUSE_WHEEL; /**< SDL Mouse Wheel event */ > -EAPI extern int ECORE_SDL_EVENT_GOT_FOCUS; /**< SDL Mouse Wheel event */ > -EAPI extern int ECORE_SDL_EVENT_LOST_FOCUS; /**< SDL Mouse Wheel event */ > +EAPI extern int ECORE_SDL_EVENT_GOT_FOCUS; > +EAPI extern int ECORE_SDL_EVENT_LOST_FOCUS; > EAPI extern int ECORE_SDL_EVENT_RESIZE; > EAPI extern int ECORE_SDL_EVENT_EXPOSE; > > > Modified: trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c > === > --- trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c 2011-09-12 03:43:37 UTC (rev > 63337) > +++ trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c 2011-09-12 03:43:46 UTC (rev > 63338) > @@ -50,9 +50,9 @@ > } > > /** > - * @defgroup Ecore_Sdl_Library_Group Framebuffer Library Functions > + * @defgroup Ecore_Sdl_Library_Group SDL Library Functions > * > - * Functions used to set up and shut down the Ecore_Framebuffer functions. > + * Functions used to set up and shut down the Ecore_Sdl functions. > */ > > /** > @@ -96,8 +96,8 @@ > EAPI int > ecore_sdl_shutdown(void) > { > - if (--_ecore_sdl_init_count != 0); > - return _ecore_sdl_init_count; > + if (--_ecore_sdl_init_count != 0) > + return _ecore_sdl_init_count; > >ecore_event_shutdown(); >eina_log_domain_unregister(_ecore_sdl_log_dom); > > > -- > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] diskselector...
Hi, elm diskselector is unusable when finger size is very small. that's all. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore fd handler deletion.
On Sun, 11 Sep 2011 21:53:11 +1000 David Seikel wrote: > From my reading of the ecore fd handler code, returning > ECORE_CALLBACK_CANCEL from the handlers callback does the same as > ecore_main_fd_handler_del(), which is to mark the handler for > deletion, not actually do the deletion. The deletion actually > happens at some later point. So it seems to be safe to do both, or > to not have to do both. > > If this is true, I think it's important to document this subtlety. > Other callbacks might have the same property. While we are at it It looks as if epoll (as well as select and poll) are NOT to be used for ordinary files. Though this is not stated anywhere in their docs. They all just use the term "file descriptor", with no limitations mentioned. Epoll returns a fairly meaningless permissions error, and I hear that select and poll just degrade. I searched through SVN, and found no case of ecore_main_fd_handler_add() being used on ordinary files. I guess this is why. We should mention that in the ecore docs, it certainly lead me astray for along time scratching my head. Welcome to unix, where everything is a file, except actual files. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ofono in e17
Hello! I recently bought 3G/GPS modem (Ericsson F5521gw), which supported by ofono. I see modem via ofono test utils, can enable/disable, list networks and so on, but E17 module says "No modem available" Also, i see name of my GSM network in connman module. e_dbus_ofono_test http://paste.pocoo.org/show/473985/ e_dbus_connman_test http://paste.pocoo.org/show/474089/ I use connman module for wifi & bluetooth without any issues. If somebody have motivation in improving ofono on E17, i could test/debug. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] a bug fix for zoom-out in elm_map
Hello Yunhan, This is my test environment. Engines: Software Memory Buffer.: yes Software X11...: yes (Xlib: yes) (XCB: no) OpenGL X11.: yes (Xlib: yes) (XCB: no) (GLES: no) (SGX: no) (s3c6410: no) Software GDI...: no Software DirectDraw: no Direct3d...: no Software SDL...: no (primitive: no) OpenGL SDL.: no Software Framebuffer...: yes DirectFB...: no Software 8bit grayscale: no Software 16bit : no Software 16bit X11.: no Software 16bit Directdraw..: no Software 16bit WinCE...: no Software 16bit SDL.: no (primitive: no) I recorded a video for you. http://www.youtube.com/watch?v=nap6Qq9iGTg The black noise may be already there but we couldn't see before due to some reasons. I guess you're patch looks ok and nobody is interested in reviewing elm_map patch. I'll commit your code if nobody reviews in a couple of days. Thanks. Daniel Juyung Seo (SeoZ) On Fri, Sep 9, 2011 at 1:46 PM, Kim Yunhan wrote: > Hello, seoz. > > Wow, testing with valgrind is great idea! > I did test on my computer and my device. > But I couldn't see your mentioned symptom. > > I guess that evas_map is related with its back-end evas render engine. > So, I think your render is different with mine. > This is my testing environment on evas engine. > > Engines: > Software Memory Buffer.: yes > Software X11...: yes (Xlib: yes) (XCB: no) > OpenGL X11.: no (Xlib: no) (XCB: no) > Software GDI...: no > Software DirectDraw: no > Direct3d...: no > Software SDL...: no (primitive: no) > OpenGL SDL.: no > Software Framebuffer...: yes > DirectFB...: no > Software 8bit grayscale: no > Software 16bit : no > Software 16bit X11.: no > Software 16bit Directdraw..: no > Software 16bit WinCE...: no > Software 16bit SDL.: no (primitive: no) > > Could you tell me your environment? > Then I'll investigate some more. > > Regards, > Yunhan Kim > > > On Fri, Sep 9, 2011 at 10:30 AM, Daniel Juyung Seo > wrote: > >> Dear Kim Yunhan, >> Thanks for you patch. >> >> Watchwolf and gouache can review your patch well. But I think nobody >> are active now. >> I just applied your patch and ran elementary_test "Map". >> >> I GUESS broken tile on zooming out issue is fixed. (I'm not sure we're >> talking about the same issue.) >> But I got noise on zooming out. >> Please see this screenshot. >> http://www.flickr.com/photos/67308399@N05/6128438625/ >> >> Black noise didn't happen before. >> You can easily see this when you run elementary_test with valgrind. >> Because it makes things very slow :) >> >> Can you check this? >> Thanks in advance. >> >> Daniel Juyung Seo (SeoZ) >> >> >> On Thu, Sep 8, 2011 at 4:43 PM, Kim Yunhan wrote: >> > Is there anybody to review this patch? >> > :'-( >> > >> > On Tue, Sep 6, 2011 at 2:41 AM, Kim Yunhan wrote: >> > >> >> >> >> Hello. >> >> >> >> I wrote a patch that handles a bug while zooming-out in elm_map. >> >> When I try to zoom out, some tiles are broken. >> >> But it is hard to notice because broken frame disappears quickly. >> >> >> >> I investigated in a few days. >> >> And I realize that there are something wrong. >> >> When map is zoomed out, a tile is shrunk by evas_object_resize(). >> >> But evas_map handles its texture by just its origin image size not a >> shrunk >> >> size. >> >> If evas_object's width & height is shrunk, I have to handle for its >> >> texture. >> >> So, I added some code for patch. >> >> >> >> Please review this. >> >> Thanks! >> >> >> > >> -- >> > Doing More with Less: The Next Generation Virtual Desktop >> > What are the key obstacles that have prevented many mid-market businesses >> > from deploying virtual desktops? How do next-generation virtual >> desktops >> > provide companies an easier-to-deploy, easier-to-manage and more >> affordable >> > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ >> > ___ >> > enlightenment-devel mailing list >> > enlightenment-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> >> >> -- >> Why Cloud-Based Security and Archiving Make Sense >> Osterman Research conducted this study that outlines how and why cloud >> computing security and archiving is rapidly being adopted across the IT >> space for its ease of implementation, lower cost, and increased >> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge
Re: [E-devel] [PATCH] Document the existing gengrid "longpressed" signal
In SVN. Thanks! Daniel Juyung Seo (SeoZ) On Fri, Sep 9, 2011 at 4:18 PM, Benjamin Drucker wrote: > gengrid already emits "longpressed" signals, but it is not currently > documented nor demonstrated in the examples. See the attached patch, > please. > > -- > Why Cloud-Based Security and Archiving Make Sense > Osterman Research conducted this study that outlines how and why cloud > computing security and archiving is rapidly being adopted across the IT > space for its ease of implementation, lower cost, and increased > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore fd handler deletion.
From my reading of the ecore fd handler code, returning ECORE_CALLBACK_CANCEL from the handlers callback does the same as ecore_main_fd_handler_del(), which is to mark the handler for deletion, not actually do the deletion. The deletion actually happens at some later point. So it seems to be safe to do both, or to not have to do both. If this is true, I think it's important to document this subtlety. Other callbacks might have the same property. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore/evas key events
On Sun, 11 Sep 2011 04:25:57 -0400 Youness Alaoui wrote: > While I'm working on adding keyboard support to ecore/ecore-evas for > the ps3 engine, I noticed that there is no enum for the various keys, > they are strings instead. I do not understand *why* this is done this > way... first of all, doing strcmp is less efficient than a int > comparison, secondly, it produces uglier code, and most importantly, > it's prone to errors.. what if I compare with "up" instead of "Up" ? > and I don't see any list of what the strings should be.. is it > "Enter" or "Return".. The ps3 SDK also can give me either the raw > code or the utf-8 of the key code, do I need to put a huge list > associating each key code with the keyname ecore expects or can I > just use the utf-8 character? Why do I need to change "(" into > "parenleft" and why do I need to check if it's "2" or "at" symbol > when the ps3 SDK itself transforms it correctly for me depending on > the chosen layout and LED states? Are you forcing every ecore_* > module to have a copy of some list to associate keys with the > expected keyname ? and every library user to have a big if/else to > check the keys entered? Anyone (raster?) knows of any good reason for > this design? Yes, I thought that was ugly as well. In my framebuffer project, I also noticed that I'm being passed a strdup of those fixed strings. Which forces me to do lots of strcmps with MORE fixed strings in a big if/else tree. Eww Lucky this project of mine only needs a small subset of the keyboard supported. If I remember rightly it's only the QWERTY layout as well. shudder -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ecore/evas key events
Hi, While I'm working on adding keyboard support to ecore/ecore-evas for the ps3 engine, I noticed that there is no enum for the various keys, they are strings instead. I do not understand *why* this is done this way... first of all, doing strcmp is less efficient than a int comparison, secondly, it produces uglier code, and most importantly, it's prone to errors.. what if I compare with "up" instead of "Up" ? and I don't see any list of what the strings should be.. is it "Enter" or "Return".. The ps3 SDK also can give me either the raw code or the utf-8 of the key code, do I need to put a huge list associating each key code with the keyname ecore expects or can I just use the utf-8 character? Why do I need to change "(" into "parenleft" and why do I need to check if it's "2" or "at" symbol when the ps3 SDK itself transforms it correctly for me depending on the chosen layout and LED states? Are you forcing every ecore_* module to have a copy of some list to associate keys with the expected keyname ? and every library user to have a big if/else to check the keys entered? Anyone (raster?) knows of any good reason for this design? Thank you, KaKaRoTo -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] stringshare use in elementary
On 11/09/11 10:54, Mike Blumenkrantz wrote: > obviously, but when it's the case that your list is composed entirely of > strings that you will be reusing, it makes a lot more sense to stringshare. Only if you assure the strings passed are stringshares, i.e if you do "eina_stringshare_*REF*" on all the strings passed, and not stringshare_add, it makes sense. Otherwise, it's just slower. -- Tom. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] stringshare use in elementary
On Sun, 11 Sep 2011 09:51:15 +0300 Tom Hacohen wrote: > On 10/09/11 20:01, Mike Blumenkrantz wrote: > > too late! check out what I did in 61735 :D > > 61735? That's not recent, are you sure that's the one? It's hard to misremember a function name like elm_gengrid_item_tooltip_size_restrict_disabled_get > > Btw, also, malloc is faster than stringshare, I guess that's also a > reason why he opted for that (as I said, it's only a small number of > strings, only the visible ones). obviously, but when it's the case that your list is composed entirely of strings that you will be reusing, it makes a lot more sense to stringshare. > > -- > Tom. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel