Re: [E-devel] [Patch] Animation gif feature patch
On Wed, 10 Aug 2011 17:41:40 +0900 Jiyoun Park said: approved! only comments would be on the docs - english could be better, but, i won't deny the patch based on that! :) > Hello~~ > > > I add more comment related with documentation. > > Test_icon_animated.c have to be added to elementary/src/bin directory > Animated_logo.gif have to be added to elementary/data/images directory. > > I made simple animated file because of license problem. > If somebody have good animated image can be used test, plz tell me. > > t.c is test program for evas. > > thanks > -Original Message- > From: Carsten Haitzler (The Rasterman) [mailto:ras...@rasterman.com] > Sent: Monday, August 08, 2011 6:23 PM > To: Jiyoun Park > Cc: 'Daniel Juyung Seo'; 'ChunEon Park'; > enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] [Patch] > Animation gif feature patch > > On Sun, 07 Aug 2011 00:37:06 +0900 Jiyoun Park said: > > need: > > for elm: > > 1. docs: need more documentation with more description and details as well as > examples of how to use the api calls 2. should add a test to elm_test to show > off how it works and be able to test that it works. > > for evas: need more documentation with more description and details as well > as examples of how to use the api calls > > 1. docs: > > that's actually it! just docs and test for elm! :) > > > > I rename elementary API. > > > > Below is API names. > > > > > > Eina_Bool evas_object_image_animated_get (const Evas_Object *obj) int > > evas_object_image_animated_frame_count_get (const Evas_Object *obj) > > Evas_Image_Animated_Loop_Hint > > evas_object_image_animated_loop_type_get(const > > Evas_Object *obj) int evas_object_image_animated_loop_count_get (const > > Evas_Object *obj) double evas_object_image_animated_frame_duration_get > > (const Evas_Object *obj, int start_frame, int fram_num) void > > evas_object_image_animated_frame_set (Evas_Object *obj, int frame_num) > > > > > > Eina_Bool elm_icon_animated_available_get (const Evas_Object *obj) > > Void elm_icon_animated_set (Evas_Object *obj, Eina_Bool anim) > > Eina_Bool elm_icon_animated_get (const Evas_Object *obj) void > > elm_icon_animated_play_set (Evas_Object *obj, Eina_Bool play) > > Eina_Bool elm_icon_animated_play_get (const Evas_Object *obj) Todo 1. > > optimization > > > > > > > > 1. You are right. Document is really needed for application developer. > > I already have test application. Which file can I add to example code? > > 2. I modified evas_image_load_gif file. > > 3. I add null to generic, eet, psd, svg, and xpm > > > > Thanks. > > > > -Original Message- > > From: Carsten Haitzler (The Rasterman) [mailto:ras...@rasterman.com] > > Sent: Friday, July 29, 2011 8:12 PM > > To: Jiyoun Park > > Cc: 'Daniel Juyung Seo'; 'ChunEon Park'; > > enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] > > [Patch] Animation gif feature patch > > > > On Tue, 26 Jul 2011 16:25:45 +0900 Jiyoun Park > > said: > > > > i see chuneon's point. evas uses "animated" and elm "anim". so either > > use animated or anim in both - i'd choose animated. :) can you just > > rename the elm calls and resend the patches? > > > > i'll review them apart from the name thing here: > > > > 1. documentation - way too little WAY too little. provide > > examples of the functions and how to use them in a small app > > > > 2.static Eina_Bool _evas_image_... and static Eina_Bool > > _evas_image_load_frame_... and static Eina_Bool > > _evas_image_load_fram... why no newline between retyurn type and > > function name? the other functions have it static Eina_Bool > > evas_image_load_file_data... too > > > > 3. you missed adding NULL to the generic, eet, psd, svg, and xpm > > loader structs i believe. (like you did to the others). > > > > :) can you fix the naming and the above and re-send the patches? :) > > > > > 1. why do you think *_animated_* is not proper name? > > > long character or grammar problem (word class? Other reason?) ? > > > *_animated_* is familiar to me, and there is no place related with > > > this in evas , so I want to keep this name. But If this name is > > > wrong or not acceptable name generally , I will consider to change API > > > name. > > > 2. yes . I already have elm_icon_anim_available_get API 3. > > > elm_icon_anim_set means I will use animation mode currently or later. > > > Elm_icon_anim_play_set is for real play of image. > > > > > > Thanks. > > > > > > -Original Message- > > > From: Daniel Juyung Seo [mailto:seojuyu...@gmail.com] > > > Sent: Monday, July 25, 2011 11:43 PM > > > To: ChunEon Park > > > Cc: Jiyoun Park; enlightenment-devel@lists.sourceforge.net > > > Subject: Re: [E-devel] [Patch] Animation gif feature patch > > > > > > 1) > > > > Frankely, I don't like *_animated_* > > > Agreed. Choose either animation or anim and apply it to > > > evas_object_image and elm_icon. I prefer anim :)
[E-devel] eina_file...
Any reason why this is read-only instead of read-write? -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ethumb "exists" problems
On Tue, Aug 9, 2011 at 5:33 PM, Cedric BAIL wrote: > On Tue, Aug 9, 2011 at 2:22 PM, Gustavo Sverzut Barbieri > wrote: > > Hi all, particularly cedric. I was to do the bindings for the new > > ethumb_client_exists() API and got impressed by the number of > > problems. > > > > - inconsistent api: void* is the first callback parameter, see > > all EFL > > Agreed, but I followed previous callback format of Ethumb_Client, see > Ethumb_Client_Generate_Cb. I have no problem about breaking this and > follow the rest of the EFL API convention. In fact, I would really > like that solution as I think Ethumb API is a mess right now. typedef void (*Ethumb_Client_Generate_Cb)(void *data, Ethumb_Client *client, int id, const char *file, const char *key, const char *thumb_path, const char *thumb_key, Eina_Bool success); as I said, void*data is the first... What of Ethumb API is a mess now? Could you clarify? And are you talking about Ethumb or Ethumb_Client? > > - inconsistent api: missing ethumb_CLIENT prefix, like > > Ethumb_Exists should be Ethumb_Client_Exists > > The data type, right ? yes. > > - strange api: if I have an Ethumb_Exists handle why do I need > > all the other parameters? Because Ethumb_Exists is an internal > > thing exposed to user! You should return the > > Ethumb_Async_Exists_Cb structure (and remove Cb from it) > > Maybe I should reverse the logic, have all Cb pointing to the same > Ethumb_Async_Exists instance, that would solve the cancel parameter > things. keep them split, listen to me :-) > > - memory leak: in _ethumb_client_exists_end() you free the > > async->callbacks but nothing frees 'cb' nodes. > > Outch and not only there, but also in cancel. I see nothing wrong with cancel, actually it should call _end as well. > > - strange behavior: you can create lots of async requests, but > > if you cancel one, all of them is cancelled! > > Nop, only the callback is cancelled. It will wait to have no more > callback before cancelling the job. yeah, I failed to see it's just when the async->ref drops to zero... damn I hate those refcount macros... > > - race condition: thread may start and finish before you add the > > structure to the hash: > > async->thread = ecore_thread_run(...); > > eina_hash_direct_add(_exists_request, async->dup, async); > > Yup, should check ecore_thread_run returned value. I don't recall ecore_thread_run() behavior but I don't see how it would help. It could have gathered the structure to return and right before the function does the return the process can be preempted to run the thread, that may finish it's stuff before being preempted. At the end you return a dead thread. Like this: thread-1: ecore_thread_run(), allocates return, start thread thread-2: run and finishes thread-1: return a finished thread > > - strange behavior: provided cb is executed even when it was > > cancelled > > Yes, it was done that way as it's the only way to be sure that the > data are not used any more. But right now, if I reverse the loginc > with callback and async stuff, it should not be needed anymore as > callback will not be in the list anymore. > > > - bad API design: there is no free_cb for exists. If you cancel > > it you still get the main cb but this is not clear. This is > > bad for bindings. > > Agreed and unecessary now in fact, as the callback is removed from the > list, there is no chance to be called later. please add a free callback. It makes bindings (or anyone doing proper code) a mess to delete references to it and cleanup. > > In my opinion there should be no single-thread per ethumb_client > > thing. It's a micro optimization and is useless since most users will > > ask just one. > > I don't think so, fire elementary_test ethumb test and you will see > the difference directly. Grouping command are usefull when used by > gengrid as you can be very quickly asked to create one > thumbnail,destroy and asked again, or some times asked twice and > destroyed once. It was possible to see the difference in excessive > also. This is a problem with elementary's usage then. Although I really really fail to see this happening a lot in common cases. You rarely will have a thumb view with the same icon as we have in elementary_test, that's just nonsense... we happen to have it as we have few images to test, it's far from realistic. Seriously, make it right first, if people come to provide a real use case I can take a look at it myself. All in all if that turns to be a common case I'd rather cache the paths in elm_ethumb than to fix this the "optimization" we have now. It is similar to my complains of the "exists" being async, god damn, we're computing an MD5 of a path... this shouldn't be that much worse than computing the eina_hash to go into a thread! Just check how other parts of this process account and this part should be very minimal to deserve such handling... look how the code grown, and which problem
Re: [E-devel] E SVN: glima trunk/ecore/src/lib/ecore
On Wed, 10 Aug 2011 12:14:48 -0700 "Enlightenment SVN" wrote: > Log: > [ecore] Put order in header file, splitting function groups in contiguous > chunks. > Sorry for having to pratically rewrite the header, but the other way > to get docs right would be to put lots of @addtogroup around several > chunks of the file, which is ugly too and doesn't organize anything. > > I have tested ecore with that and it seems to be okay. > > > > Author: glima > Date: 2011-08-10 12:14:48 -0700 (Wed, 10 Aug 2011) > New Revision: 62307 > Trac: http://trac.enlightenment.org/e/changeset/62307 > > Modified: > trunk/ecore/src/lib/ecore/Ecore.h trunk/ecore/src/lib/ecore/ecore.c > trunk/ecore/src/lib/ecore/ecore_app.c > trunk/ecore/src/lib/ecore/ecore_events.c > trunk/ecore/src/lib/ecore/ecore_exe.c trunk/ecore/src/lib/ecore/ecore_glib.c > trunk/ecore/src/lib/ecore/ecore_idle_enterer.c > trunk/ecore/src/lib/ecore/ecore_idle_exiter.c > trunk/ecore/src/lib/ecore/ecore_idler.c trunk/ecore/src/lib/ecore/ecore_job.c > trunk/ecore/src/lib/ecore/ecore_main.c trunk/ecore/src/lib/ecore/ecore_pipe.c > trunk/ecore/src/lib/ecore/ecore_poll.c > trunk/ecore/src/lib/ecore/ecore_throttle.c > trunk/ecore/src/lib/ecore/ecore_time.c > trunk/ecore/src/lib/ecore/ecore_timer.c In the beginning Raster created the ecore source and the headers. Now the headers were docless and barren, darkness was over the surface of the header files, and the Spirit of Raster was cackling with trollish glee. And glima said, “Let there be comments,” and there were comments. glima saw that the comments were good, and he separated the comments from the darkness. glima called the comemnts “docs,” and the darkness he called code.” And there were typedefs, and there were functions—the first changes. And glima said, “Let there be a second asterisk after the first to separate comments from docs.” So glima made the second asterisk and separated the docs under the asterisk from the comments above it. And it was so. glima called the new comments “doxygen.” And there was /**, and there was */—the second changes. And glima said, “Let the comments above the asterisks be gathered to one place, and let large block docs appear.” And it was so. glima called the large block docs "groups,” and the gathered comments he called "copyright notices.” And glima saw that it was good. Then glima said, “Let the groups produce information: sentences and phrases in the large block docs that bear details and nuances in it, according to their various kinds.” And it was so. The groups produced information: sentences bearing details according to their kinds and phrases bearing nuances with questionable usefulness in it according to their kinds. And glima saw that it was good. And there was @defgroup, and there was @ingroup—the third changes. And glima said, “Let there be newlines in the space between */ and /** to separate the comments from the code, and let them serve as breaks to mark places to stop reading, and functions and typedefs, and let them be oases in the large doc blocks to give readability to the headers.” And it was so. glima made two great separators-the double newline to govern the separation of groups and the single newline to govern the separation of comments. He also made the single line comments. glima set them in the large doc blocks to give more readability to the headers, to govern the small bits of code and the large, and to separate comments from darkness. And glima saw that it was good. And there was \n, and there was \n\n—the fourth day. And glima said, “Let the docs teem with @ signs, and let coherency flow through the headers across the large doc blocks.” So glima created the great ascii 64 in the doxygen and every keyword with which the doxygen teems and that moves about in it, according to their kinds, and every word be placed appropriately so as to be coherent. And glima saw that it was good. glima blessed them and said, “Be fruitful and increase in number and fill the doxygen in the comments, and let the coherency increase in the headers.” And there were keywords, and there was occasional punctuation—the fifth changes. And glima said, “Let the large doc blocks produce enumeration of function attributes according to their prototypes: the @brief, the short details which can be used for tooltips, and the @params, each according to its kind.” And it was so. glima made the @brief according to their kinds, the @params according to their kinds, and all the @return according to their kinds. And glima saw that it was good. Then glima said, “Let us make further descriptions in our docs, in our comments, so that they may elaborate upon the doxygen keywords with coherency, over the @brief and the @params, and over all the @returns that exist in the headers.” So glima created descriptions in his own docs, in the comments of glima he created them; helpful and unhelpful he created them. glima blessed them an
Re: [E-devel] E SVN: cedric trunk/e/src/bin
hum this patch fixes nothing, and I have already fix this issues with the
default value in e.cfg.
2011/8/10 Enlightenment SVN
> Log:
> e: some people have been hurt by this default value.
>
>
> Author: cedric
> Date: 2011-08-10 06:02:09 -0700 (Wed, 10 Aug 2011)
> New Revision: 62294
> Trac: http://trac.enlightenment.org/e/changeset/62294
>
> Modified:
> trunk/e/src/bin/e_backlight.c
>
> Modified: trunk/e/src/bin/e_backlight.c
> ===
> --- trunk/e/src/bin/e_backlight.c 2011-08-10 12:45:10 UTC (rev 62293)
> +++ trunk/e/src/bin/e_backlight.c 2011-08-10 13:02:09 UTC (rev 62294)
> @@ -31,7 +31,7 @@
> e_backlight_init(void)
> {
>e_backlight_update();
> - e_backlight_level_set(NULL, 0.0, 0.0);
> + e_backlight_level_set(NULL, 1.0, 0.0);
>e_backlight_level_set(NULL, e_config->backlight.normal, 1.0);
>return 1;
> }
>
>
>
> --
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
Michaël Bouchaud
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth IN trunk/E-MODULES-EXTRA/everything-shotgun: . m4
On Wed, 10 Aug 2011 22:22:04 +0900 Daniel Juyung Seo wrote: > Thanks. It builds well. > But I have a segvs with shotgun not everything-shotgun. > zmike, fix it! What are you, a user? This is the worst bug report I've ever seen! > > Daniel Juyung Seo (SeoZ) > > On Wed, Aug 10, 2011 at 10:12 PM, Enlightenment SVN > wrote: > > Log: > > e-modules/evry-shotgun: add missing files -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth IN trunk/E-MODULES-EXTRA/everything-shotgun: . m4
Thanks. It builds well. But I have a segvs with shotgun not everything-shotgun. zmike, fix it! Daniel Juyung Seo (SeoZ) On Wed, Aug 10, 2011 at 10:12 PM, Enlightenment SVN wrote: > Log: > e-modules/evry-shotgun: add missing files > > > Author: jeffdameth > Date: 2011-08-10 06:12:30 -0700 (Wed, 10 Aug 2011) > New Revision: 62295 > Trac: http://trac.enlightenment.org/e/changeset/62295 > > Added: > trunk/E-MODULES-EXTRA/everything-shotgun/m4/ > trunk/E-MODULES-EXTRA/everything-shotgun/m4/ac_attribute.m4 > > > -- > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric IN branches: e_dbus-1.0 ecore-1.0 edje-1.0 eet-1.4 eeze-1.0 efreet-1.0 eina-1.0 evas-1.0
Hey some EFL have a README.in only for the version, the others have just a README. I think that this should be fixed. So having a README.in or a README. In case there is a README, the package manager must check that the version in the README file is correct. Btw, I prefer a README. Vincent On Wed, 10 Aug 2011, Enlightenment SVN wrote: > Log: > branches: the EFL in this branches are not BETA anymore. > > > Author: cedric > Date: 2011-08-10 05:45:10 -0700 (Wed, 10 Aug 2011) > New Revision: 62293 > Trac: http://trac.enlightenment.org/e/changeset/62293 > > Modified: > branches/e_dbus-1.0/README branches/ecore-1.0/README.in > branches/edje-1.0/README branches/eet-1.4/README.in branches/eeze-1.0/README > branches/efreet-1.0/README branches/eina-1.0/README > branches/evas-1.0/README.in > > Modified: branches/e_dbus-1.0/README > === > --- branches/e_dbus-1.0/README2011-08-10 10:59:31 UTC (rev 62292) > +++ branches/e_dbus-1.0/README2011-08-10 12:45:10 UTC (rev 62293) > @@ -1,4 +1,4 @@ > -E_dbus 1.0.0 BETA > +E_dbus 1.0.1 > > ** > > > Modified: branches/ecore-1.0/README.in > === > --- branches/ecore-1.0/README.in 2011-08-10 10:59:31 UTC (rev 62292) > +++ branches/ecore-1.0/README.in 2011-08-10 12:45:10 UTC (rev 62293) > @@ -1,4 +1,4 @@ > -Ecore @VERSION@ BETA > +Ecore @VERSION@ > > ** > > > Modified: branches/edje-1.0/README > === > --- branches/edje-1.0/README 2011-08-10 10:59:31 UTC (rev 62292) > +++ branches/edje-1.0/README 2011-08-10 12:45:10 UTC (rev 62293) > @@ -1,4 +1,4 @@ > -Edje 1.0.0 BETA > +Edje 1.0.1 > > ** > > > Modified: branches/eet-1.4/README.in > === > --- branches/eet-1.4/README.in2011-08-10 10:59:31 UTC (rev 62292) > +++ branches/eet-1.4/README.in2011-08-10 12:45:10 UTC (rev 62293) > @@ -1,4 +1,4 @@ > -Eet @VERSION@ BETA > +Eet @VERSION@ > > ** > > > Modified: branches/eeze-1.0/README > === > --- branches/eeze-1.0/README 2011-08-10 10:59:31 UTC (rev 62292) > +++ branches/eeze-1.0/README 2011-08-10 12:45:10 UTC (rev 62293) > @@ -1,4 +1,4 @@ > -Eeze 1.0.0 BETA > +Eeze 1.0.1 > > ** > > > Modified: branches/efreet-1.0/README > === > --- branches/efreet-1.0/README2011-08-10 10:59:31 UTC (rev 62292) > +++ branches/efreet-1.0/README2011-08-10 12:45:10 UTC (rev 62293) > @@ -1,4 +1,4 @@ > -Efreet 1.0.0 BETA > +Efreet 1.0.1 > > ** > > > Modified: branches/eina-1.0/README > === > --- branches/eina-1.0/README 2011-08-10 10:59:31 UTC (rev 62292) > +++ branches/eina-1.0/README 2011-08-10 12:45:10 UTC (rev 62293) > @@ -1,4 +1,4 @@ > -Eina 1.0.0 BETA > +Eina 1.0.1 > > ** > > > Modified: branches/evas-1.0/README.in > === > --- branches/evas-1.0/README.in 2011-08-10 10:59:31 UTC (rev 62292) > +++ branches/evas-1.0/README.in 2011-08-10 12:45:10 UTC (rev 62293) > @@ -1,4 +1,4 @@ > -Evas @VERSION@ BETA > +Evas @VERSION@ > > ** > > > > -- > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenme
Re: [E-devel] E SVN: jeffdameth IN trunk/E-MODULES-EXTRA/everything-shotgun: . images src
2011/8/10 Mike Blumenkrantz : > On Tue, 9 Aug 2011 18:05:22 -0700 > "Enlightenment SVN" wrote: > >> Log: >> e-modules/evry-shotgun: add default contact icon and filter contacts >> >> >> Author: jeffdameth >> Date: 2011-08-09 18:05:22 -0700 (Tue, 09 Aug 2011) >> New Revision: 62271 >> Trac: http://trac.enlightenment.org/e/changeset/62271 >> >> Added: >> trunk/E-MODULES-EXTRA/everything-shotgun/images/contact_icon.png >> Modified: >> trunk/E-MODULES-EXTRA/everything-shotgun/e-module.edc >> trunk/E-MODULES-EXTRA/everything-shotgun/src/e_mod_main.c >> > I need an icon designer! Stat! Yeah, better put it into shotgun, so it provides an icon. It needs a 'no avatar'-icon as well! > > -- > Mike Blumenkrantz > Zentific: Coding in binary since '10. > > -- > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Leif -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Big improvements on OSX
On Tue, 9 Aug 2011 20:47:33 -0700 Dave Ray said: i didn't do anything to try fix the shm thing... well other than handling -1 ptr returns that i added 5th of july... was your previous build before that? as for 10x speedup.. totally beats me! > I noticed some big improvements on OSX, compared to 2 weeks ago, which was > the last time I downloaded from SVN. > > The OSX crash-on-startup bug seems to be gone. I don't know why. There are > still some display problems during the first e17 launch after startup, but no > segv crashes. > > I can fix the display problems with the same work-around I was using for the > startup crash -- by disabling shm > in /evas/src/modules/engines/software_x11/evas_xlib_buffer.c. Still it would > be good to understand what I can do to make shm segments work better on OSX. > > Also, startup is 10x faster than before. There was always a 10 second delay > starting up e17. Today, it takes like 1-2 seconds. > > I'm very happy to see this after many months with the crash on startup and > slow launch! > > What changed? > > > > -- > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > ___ > 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 -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] where is entrance package
On Wed, 10 Aug 2011, Mark-Willem Jansen wrote: > > Entrance and estickies were removed by quaker. He wanted to rewrite them from > scratch. > > http://trac.enlightenment.org/e/changeset/46590/trunk > > As far as I can see Elsa is not made by quaker but yoz,. So quaker are you > still woking on your write of entrance? he has not coded a lot on the EFL the past few months, afaik. Instead of developping entrance, better improving Elsa. Elsa is quite well written, and smaller than the old entrance. about estickies, I don't know why he has removed it. Rewriting on a prog does not imply its removal. One can bump the major release, it's sufficient. regards Vincent -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm on Windows and elm_main
On Wed, 10 Aug 2011 08:24:41 +0200 (CEST) Vincent Torri
said:
>
>
> On Wed, 10 Aug 2011, Carsten Haitzler (The Rasterman) wrote:
>
> > On Wed, 10 Aug 2011 08:00:21 +0200 (CEST) Vincent Torri
> > said:
> >
> >>
> >>
> >> On Wed, 10 Aug 2011, Carsten Haitzler (The Rasterman) wrote:
> >>
> >>> On Tue, 9 Aug 2011 10:17:09 +0200 (CEST) Vincent Torri
> >>> said:
> >>>
> >>> hmm welll the EAPI was there so *IF* u build the app AS a .so (.dll) then
> >>> elementary quicklaunch can run it faster (skipping several link and setup
> >>> steps that are pre-done). thats why its EAPI. but if u build an executable
> >>> on linux the EAPI is harmless and doesnt hurt
> >>>
> >>> so what you are saying here is this:
> >>>
> >>> on linux we can put EAPI in binaries without harm
> >>> on windows putting EAPI in a binary will cause the compile to fail? (as
> >>> opposed to a dll)?
> >>
> >> I say that EAPI, in a binary that includes an EFL, is defined as
> >> __declspec(dllimport), that mean that the symbol is imported from a DLL.,
> >> so in a program using elm:
> >>
> >> #include
> >>
> >> // EAPI is __declspec(dllimport)
> >>
> >> EAPI int elm_main()
> >> { ***
> >> }
> >>
> >> so the linker searches for elm_main() into a DLL, which is obviously not
> >> the case, hence an error.
> >
> > ok - on linux EAPI simply is "this symbol is visible/exported and not
> > hidden".
> >
> > so we have a disagreement of usage. the idea is that with quicklaunch u
> > COMPILE as a dll and then elm_main is exported as a symbol. as a binary -
> > it is useless. in the case of building the dll - it should be what it is
> > now. in the case of a binary it should actually be "do nothing" here. ie
> > empty. maybe we need a new macro? like ELM_MAIN or such that does this? ie
> > ifdef windows ->
> > #define it to nothing, if anywherre else #define it to EAPI
>
> last time i tried, i didn't succeeded in making quicklaunch work on
> Windows. I remember of something specific to linux. But i can't remember
> exactly what.
>
> if it is possible to have quicklaunch on Windows, then EAPI must be
> __declspec(dllexport) so that the symbol is exported, otherwise (in non
> quicklaunch mode) EAPI must be nothing.
>
> ELM_MAIN is already used, that's why I proposed EAPI_MAIN. EAPI_ELM_MAIN
> could be used too. But yes, having such macro defined as nothing on
> Windows, and EAPI otherwise should be sufficient. And if, later,
> that macro must be tuned if quicklaunch works on Windows, then it will
> not modify the way elm_main() is declared, it will always be
>
> EAPI_MAIN int elm_main() { ** }
maybe EAPI_MAIN is best.
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] where is entrance package
Entrance and estickies were removed by quaker. He wanted to rewrite them from scratch. http://trac.enlightenment.org/e/changeset/46590/trunk As far as I can see Elsa is not made by quaker but yoz,. So quaker are you still woking on your write of entrance? -- Mark-Willem Jansen > From: jeffhoogl...@gmail.com > To: enlightenment-devel@lists.sourceforge.net > Date: Tue, 9 Aug 2011 16:05:10 -0500 > Subject: Re: [E-devel] where is entrance package > > Check the old section of the E SVN. Pretty sure that package is no loner > maintained. > -- > ~Jeff Hoogland > http://JeffHoogland.com > > On Tue Aug 9 2011 03:52:46 PM CDT, المسالم المسالمة > wrote: > > > hello developers > > > > where can i find entrance package i tried to find it at enlightenment > > site but i didnt find it there > > > > i have this version 0.16.999.57316 > > > > so is there any package for it or not > > -- > > uberSVN's rich system and user administration capabilities and model > > configuration take the hassle out of deploying and managing Subversion > > and the tools developers use with it. Learn more about uberSVN and get > > a free download at: http://p.sf.net/sfu/wandisco-dev2dev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
