Re: [E-devel] pulseaudio in e17
On Tue, Sep 27, 2011 at 23:22, David Seikel wrote: > On Tue, 27 Sep 2011 15:14:44 -0500 Jeff Hoogland > wrote: > >> I am the only one that has to cringe every time he hears the words >> "pulse audio"? > > I actually like it. :-P > > Definitely looks like you better get used to it though. Don't think > it's going away any time soon. Raster does not seem keen on doing a > new audio system again. OSSv4 works fine at least for me (Having software mixing for years, and no lock with flash or whatever, been able to change volume per application…). I don't care about pulseaudio, just don't make it mandatory. -- Boris Faure -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] bug with edje map rotation?
I have am using map rotation of images in my edje script. My image, which is a png with alpha, when rotated on the z-axis, looks like one or two pixel colums from the right are wrapped to the left and a couple of rows at the bottom are wrapped up to the top. Very odd. Check out my attached .edj file. Is this a bug? Is there a work-around? rot-test.edj Description: Binary data -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Wed, 28 Sep 2011 09:29:05 +0200 Boris Faure wrote: > On Tue, Sep 27, 2011 at 23:22, David Seikel wrote: > > On Tue, 27 Sep 2011 15:14:44 -0500 Jeff Hoogland > > wrote: > > > >> I am the only one that has to cringe every time he hears the words > >> "pulse audio"? > > > > I actually like it. :-P > > > > Definitely looks like you better get used to it though. Don't think > > it's going away any time soon. Raster does not seem keen on doing a > > new audio system again. > > OSSv4 works fine at least for me (Having software mixing for years, > and no lock with flash or whatever, been able to change volume per > application…). > I don't care about pulseaudio, just don't make it mandatory. > don't worry, I hate it far more than you do. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] About a "port" of fontconfig for Windows
Hey, I would like some advices about a font search "engine" for Evas on WIndows (it would be statically linked to Evas as it would be only used in that lib). Do you know which functions I should provide so that fonts are found ? Do you think that I should provide a cache system, based on eet, to store that cache ? Thanks, and I hope you're feeling better regards Vincent -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/E-MODULES-EXTRA/elfe/data/themes/default/images
Dear jeffdameth, This image is not used. It was described in 'images' tag but not used in any parts. So I just removed this image from 'images' tag before. Thanks. Daniel Juyung Seo (SeoZ) On Thu, Sep 22, 2011 at 11:19 AM, Enlightenment SVN wrote: > Log: > e-modules/elfe: add missing image > > > Author: jeffdameth > Date: 2011-09-21 19:19:16 -0700 (Wed, 21 Sep 2011) > New Revision: 63527 > Trac: http://trac.enlightenment.org/e/changeset/63527 > > Added: > trunk/E-MODULES-EXTRA/elfe/data/themes/default/images/engage_im0.png > > > Property changes on: > trunk/E-MODULES-EXTRA/elfe/data/themes/default/images/engage_im0.png > ___ > Added: svn:mime-type > + application/octet-stream > > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/E-MODULES-EXTRA/elfe/data/themes/default/images
thanks guys to fix my mess :-P 2011/9/28 Daniel Juyung Seo : > Dear jeffdameth, > This image is not used. > > It was described in 'images' tag but not used in any parts. > So I just removed this image from 'images' tag before. > > Thanks. > Daniel Juyung Seo (SeoZ) > > On Thu, Sep 22, 2011 at 11:19 AM, Enlightenment SVN > wrote: >> Log: >> e-modules/elfe: add missing image >> >> >> Author: jeffdameth >> Date: 2011-09-21 19:19:16 -0700 (Wed, 21 Sep 2011) >> New Revision: 63527 >> Trac: http://trac.enlightenment.org/e/changeset/63527 >> >> Added: >> trunk/E-MODULES-EXTRA/elfe/data/themes/default/images/engage_im0.png >> >> >> Property changes on: >> trunk/E-MODULES-EXTRA/elfe/data/themes/default/images/engage_im0.png >> ___ >> Added: svn:mime-type >> + application/octet-stream >> >> >> -- >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> ___ >> enlightenment-svn mailing list >> enlightenment-...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn >> > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Wed, Sep 28, 2011 at 03:07, Carsten Haitzler wrote: > On Tue, 27 Sep 2011 23:44:06 +0200 Thomas Gstädtner > said: > > if we take your view that the only thing that matters in a release is sitting > and waiting 6+ months for a distro to package it, then why do we care about > release at all? reality is this: > > we release as source tarballs "day 1" and there will be the first major > group of users that take this and use that and need it to work. that means it > must work TODAY. if it doesn't work today no devs can even test it. no PA 1.0 > here - no dbus API. if it wasn't for me testing it against an installed and > working "today" distro and changing and fixing code - the PA support wouldn't > work right. mike did some awesome work. he missed some critical small things > and some integration work. i CAN'T test and fix against a PA 1.0 today... and > mike can't because he doesn't have it either - that's WHY he "reverse > engineered" the PA protocol. looking at the number of other people working on > the e17 release todo list... actually getting things finished - well... those > DOING the work that call the shots. those DOING the code to support PA don't > have a dbus API... TODAY - when the code NEEDS TO BE DONE... and so... it > didn't get done and won't be worked on by those people. if others wish to step > up and work on the release todo - then maybe they can implement it if they > have > a dbus API available to test against. i'd welcome people stepping up and doing > things. but the voices of those who worked on it says "no dbus API here.. so > moot. not going to bother. what is there now works. what's the fuss?". > > if the issue is that "OMG!~ they may break internal protocol!!! use dbus!!! it > won't break". please tell me that the networkmanager dbus api never broke. or > connman... or... yeah right. i thought so. :) (it seems to me that people who > use dbus love to break api's much more as the effects are less drastic than a > c > api break - where u get crashes or simply apps not starting at all, but in > dbus > land features just stop working or malfunction, so the error state degredation > is less). > > so even if distros pick e up on 6+ months after release.. the PA code there > will still work. or should. i don't see that going away in a hurry. now even > after source tarballs we will have packages for fedora, ubuntu, debian etc. > that are made within weeks of src release (or days) and so are available via > extra repositories (or in debian testing/unstable which is what people > actually > use), so let's be realistic... e needs to work HERE. in this situation. we > can't just say "oh well it doesn't work for 90% of potential users today but > as > long as everyone upgrades their distribution the instant they come out from > distro vendors AND those distros ALL pick up PA 1.0 - sure over 3, 6, 9, 12 > months e may being to be usable... so we just will ignore the problem and > throw > out work already done so we can ensure we get a reputation for releasing stuff > that is not usable so maybe in 12 months 50% of possible users might have e > work right (with audio)". > > why 50%? u REALLY think people upgrade their distribution instantly? i don't > know what bizarre world you live in but they don't. they often lag behind the > actual release (in fact the majority do i'd say) by at least 3-6 months or > more. the majority of possible users may very conceivably be on a distro > released 6 or 12 months ago. reality is we have to work for them. so that > means > working with what is out TODAY (or even last year). > >> Ok, let's get realistic: >> _If_ e17 should go stable later this or early next year, it will take >> a while until distros include it in their trees at all, lat alone >> stabilize it (for the distros that maintain stable branches). >> So here's a list of the major distros including a) the current release >> with its PA version b) the first release e17 could be included in >> should it be release in the next 6 months c) the first release that >> will have PA with dbus support >> >> Debian >> a) stable/squeeze: PA 0.9.21 b) unstable/sid: PA 0.9.23 c) unkown >> (likely not before 7.0, but then again, e17 won't make it either.) >> >> Fedora >> a) f15: PA 0.9.22 b) f16: PA 0.9.23 c) unknown (probably fast-tracked >> to f16, more likely coming in f17) >> >> Gentoo >> a) current: PA 0.9.23 b) ~testing: PA 1.0 c) ~testing (PA 1.0 will be >> stable before EFL, let alone e17) >> >> OpenSuse >> a) 11.4: PA 0.9.22 b) 12.1: PA 0.99/1.0 c) 12.1 (next release will be >> early 2012 and include PA 1.0) >> >> Ubuntu >> a) 11.04: PA 0.9.22 b) 11.10: PA 0.99/1.0 c) 11.10 (upcoming release >> will include PA1.0) >> >> In conclusion: even if the e17 release happens very soon, it will not >> be included in any stable tree this year, and very likely not even >> next year. In the non-stable trees, of the major distros Ubuntu, >> OpenSuse, Gentoo all already have PA 1.0 (or a 0.99 prerelease)
Re: [E-devel] [Patch] Implement rotation decoding in evas jpeg loader
2011/9/28 Jiyoun Park > Hello. I'm Jiyou Park. > I implement evas_object_image_load_orientation_set API(This API already > exist in evas). > > Currently, this API only set load option's orientation value. > But I added code to jpeg loader, and this API can really work(only jpg file > type). > > In jpeg loader, > If object's load_option orientation flag is true, > 1. jpeg loader parse exif info from file and get orientation info. > 2. change load option's value according to rotation info. > 3. after decoding, change value according to rotation. > > And I modify elm photocam code to use > evas_object_image_load_orientation_set > API for rotation decoding. > > If there is any bug, plz let me know it. > Thanks. > -- > Jiyoun Park > > Mobile S/W Platform Lab > DMC R&D Center > SAMSUNG ELECTRONICS CO. ,LTD > > TEL: +82-31-279-0619 > Mobile: +82-10-9871-0703 > jy0703.p...@samsung.com > -- > > > > > > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > Ho great, I needed this features since longtime. I will test it with my long list of jpg photo -- Michaël Bouchaud -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/elementary: doc src/examples
This is beautiful. I bet manymanymanymanymany application programmers SHOULD read this. Thanks raster! Daniel Juyung Seo (SeoZ) On Wed, Sep 28, 2011 at 8:53 PM, Enlightenment SVN wrote: > Log: > Document how to use thread with EFL in nice detail for "beginners" who > know already how to use threads (pthread) and then how to use that > with EFL. > > > > Author: raster > Date: 2011-09-28 04:53:41 -0700 (Wed, 28 Sep 2011) > New Revision: 63641 > Trac: http://trac.enlightenment.org/e/changeset/63641 > > Added: > trunk/elementary/src/examples/efl_thread_1.c > trunk/elementary/src/examples/efl_thread_2.c > trunk/elementary/src/examples/efl_thread_3.c > trunk/elementary/src/examples/efl_thread_4.c > trunk/elementary/src/examples/efl_thread_5.c > trunk/elementary/src/examples/efl_thread_6.c > Modified: > trunk/elementary/doc/examples.dox trunk/elementary/doc/index.doxy > trunk/elementary/src/examples/Makefile.am > > Modified: trunk/elementary/doc/examples.dox > === > --- trunk/elementary/doc/examples.dox 2011-09-28 09:14:40 UTC (rev 63640) > +++ trunk/elementary/doc/examples.dox 2011-09-28 11:53:41 UTC (rev 63641) > @@ -92,6 +92,18 @@ > * @ref progressbar_example > * > * @ref slideshow_example > + * > + * @ref efl_thread_1 > + * > + * @ref efl_thread_2 > + * > + * @ref efl_thread_3 > + * > + * @ref efl_thread_4 > + * > + * @ref efl_thread_5 > + * > + * @ref efl_thread_6 > */ > > /** > @@ -5928,6 +5940,125 @@ > */ > > /** > + * @page efl_thread_1 EFL Threading example 1 > + * > + * You can use threads with Elementary (and EFL) but you need to be careful > + * to only use eina or eet calls inside a thread. Other libraries are not > + * totally threadsafe except for some specific ecore calls designed for > + * working from threads like the ecore_pipe_write() and ecore_thread calls. > + * > + * Below is an example of how to use EFL calls from a native thread you have > + * already created. You have to put the EFL calls inside the critical block > + * between ecore_thread_main_loop_begin() and ecore_thread_main_loop_end() > + * which ensure you gain a lock on the mainloop. Beware that this requires > + * that the thread WAIT to synchronize with the mainloop at the beginning of > + * the critical section. It is highly suggested you use as few of these > + * in your thread as possible and probably put just a single > + * ecore_thread_main_loop_begin() / ecore_thread_main_loop_end() section > + * at the end of the threads calculation or work when it is done and > + * would otherwise exit to sit idle. > + * > + * For a progression of examples that become more complex and show other > + * ways to use threading with EFL, please see: > + * > + * @ref efl_thread_2 > + * > + * @ref efl_thread_3 > + * > + * @ref efl_thread_4 > + * > + * @ref efl_thread_5 > + * > + * @ref efl_thread_6 > + * > + * @include efl_thread_1.c > + */ > + > +/** > + * @page efl_thread_2 EFL Threading example 2 > + * > + * You can also use ecore_main_loop_thread_safe_call_sync() to call a > + * specific function that needs to do EFL main loop operations. This call > + * will block and wait to synchronise to the mainloop just like > + * ecore_thread_main_loop_begin() / ecore_thread_main_loop_end() will, > + * but instead you simply provide it the function callback to call instead > + * of inlining your code. > + * > + * @ref efl_thread_3 > + * > + * @ref efl_thread_4 > + * > + * @ref efl_thread_5 > + * > + * @ref efl_thread_6 > + * > + * @include efl_thread_2.c > + */ > + > +/** > + * @page efl_thread_3 EFL Threading example 3 > + * > + * Like with ecore_main_loop_thread_safe_call_sync() you can provide a > + * callback to call inline in the mainloop, but this time with > + * ecore_main_loop_thread_safe_call_async() the callback is queued and > + * called asynchronously, without the thread blocking. The mainloop will > + * call this function when it comes around to its synchronisation point. This > + * acts as a "fire and forget" way of having the mainloop do some work > + * for a thread that has finished processing some data and is read to hand it > + * off to the mainloop and the thread wants to march on and do some more work > + * while the main loop deals with "displaying" the results of the previous > + * calculation. > + * > + * @ref efl_thread_4 > + * > + * @ref efl_thread_5 > + * > + * @ref efl_thread_6 > + * > + * @include efl_thread_3.c > + */ > + > +/** > + * @page efl_thread_4 EFL Threading example 4 > + * > + * Now when you want to have a thread do some work, send back results to > + * the mainloop and continue running but the mainloop controls when the > + * thread should stop working, you need some extra flags. This is an example > + * of how you might use ecore_main_loop_thread_safe_call_async() and pthreads > + * to do this. > + * > + * @ref efl_thread_5 > + * > + * @ref efl_thread_6 > + * > + * @include efl_thread_4.c > + */ > + >
Re: [E-devel] E SVN: raster IN trunk/elementary: doc src/examples
On Wed, 28 Sep 2011 22:40:25 +0900 Daniel Juyung Seo said: that was the whole point. i kept being sucked away from this - i started these examples weeks ago and everything else got in my way of finishing. it's now in the docs. they absolutely MUST read this *IF* they are to use threads with EFL *AT ALL*. they NEED to take the examples given and use the "design pattern" there. i.e. DONT do efl stuff in the threads (without moving the efl calls out of the thread via one of various mechanisms OR by using the lock-step mechanisms given in the first 2 examples). i still encourage people to avoid threads, and if they really need them, think carefully about the use and isolate the thread functions and data so it's almost like another process you IPC to/from. > This is beautiful. > I bet manymanymanymanymany application programmers SHOULD read this. > Thanks raster! > > Daniel Juyung Seo (SeoZ) > > On Wed, Sep 28, 2011 at 8:53 PM, Enlightenment SVN > wrote: > > Log: > > Document how to use thread with EFL in nice detail for "beginners" who > > know already how to use threads (pthread) and then how to use that > > with EFL. > > > > > > > > Author: raster > > Date: 2011-09-28 04:53:41 -0700 (Wed, 28 Sep 2011) > > New Revision: 63641 > > Trac: http://trac.enlightenment.org/e/changeset/63641 > > > > Added: > > trunk/elementary/src/examples/efl_thread_1.c > > trunk/elementary/src/examples/efl_thread_2.c > > trunk/elementary/src/examples/efl_thread_3.c > > trunk/elementary/src/examples/efl_thread_4.c > > trunk/elementary/src/examples/efl_thread_5.c > > trunk/elementary/src/examples/efl_thread_6.c Modified: > > trunk/elementary/doc/examples.dox trunk/elementary/doc/index.doxy > > trunk/elementary/src/examples/Makefile.am > > > > Modified: trunk/elementary/doc/examples.dox > > === > > --- trunk/elementary/doc/examples.dox 2011-09-28 09:14:40 UTC (rev 63640) > > +++ trunk/elementary/doc/examples.dox 2011-09-28 11:53:41 UTC (rev 63641) > > @@ -92,6 +92,18 @@ > > * @ref progressbar_example > > * > > * @ref slideshow_example > > + * > > + * @ref efl_thread_1 > > + * > > + * @ref efl_thread_2 > > + * > > + * @ref efl_thread_3 > > + * > > + * @ref efl_thread_4 > > + * > > + * @ref efl_thread_5 > > + * > > + * @ref efl_thread_6 > > */ > > > > /** > > @@ -5928,6 +5940,125 @@ > > */ > > > > /** > > + * @page efl_thread_1 EFL Threading example 1 > > + * > > + * You can use threads with Elementary (and EFL) but you need to be careful > > + * to only use eina or eet calls inside a thread. Other libraries are not > > + * totally threadsafe except for some specific ecore calls designed for > > + * working from threads like the ecore_pipe_write() and ecore_thread calls. > > + * > > + * Below is an example of how to use EFL calls from a native thread you > > have > > + * already created. You have to put the EFL calls inside the critical block > > + * between ecore_thread_main_loop_begin() and ecore_thread_main_loop_end() > > + * which ensure you gain a lock on the mainloop. Beware that this requires > > + * that the thread WAIT to synchronize with the mainloop at the beginning > > of > > + * the critical section. It is highly suggested you use as few of these > > + * in your thread as possible and probably put just a single > > + * ecore_thread_main_loop_begin() / ecore_thread_main_loop_end() section > > + * at the end of the threads calculation or work when it is done and > > + * would otherwise exit to sit idle. > > + * > > + * For a progression of examples that become more complex and show other > > + * ways to use threading with EFL, please see: > > + * > > + * @ref efl_thread_2 > > + * > > + * @ref efl_thread_3 > > + * > > + * @ref efl_thread_4 > > + * > > + * @ref efl_thread_5 > > + * > > + * @ref efl_thread_6 > > + * > > + * @include efl_thread_1.c > > + */ > > + > > +/** > > + * @page efl_thread_2 EFL Threading example 2 > > + * > > + * You can also use ecore_main_loop_thread_safe_call_sync() to call a > > + * specific function that needs to do EFL main loop operations. This call > > + * will block and wait to synchronise to the mainloop just like > > + * ecore_thread_main_loop_begin() / ecore_thread_main_loop_end() will, > > + * but instead you simply provide it the function callback to call instead > > + * of inlining your code. > > + * > > + * @ref efl_thread_3 > > + * > > + * @ref efl_thread_4 > > + * > > + * @ref efl_thread_5 > > + * > > + * @ref efl_thread_6 > > + * > > + * @include efl_thread_2.c > > + */ > > + > > +/** > > + * @page efl_thread_3 EFL Threading example 3 > > + * > > + * Like with ecore_main_loop_thread_safe_call_sync() you can provide a > > + * callback to call inline in the mainloop, but this time with > > + * ecore_main_loop_thread_safe_call_async() the callback is queued and > > + * called asynchronously, without the thread blocking. The mainloop will > > + * call this function when it comes around t
Re: [E-devel] E SVN: barbieri trunk/THEMES/detourious/bits
On Wed, 28 Sep 2011 16:57:30 -0700
"Enlightenment SVN" wrote:
> Log:
> THEMES/detorious: fix some missing programs, change 'menu' and 'default'
> focus out.
>* manage contents visibility, does not seem to affect runtime, but
> the preview looked weird.
>
>* 'menu' should not be colored on focus-out, likely it will not have
> any focus... same as 'popup'
>
>* 'standard' should have focus-out color, same as 'still' given that
> default and still do no wobble effect.
>
>
>
> Author: barbieri
> Date: 2011-09-28 16:57:30 -0700 (Wed, 28 Sep 2011)
> New Revision: 63646
> Trac: http://trac.enlightenment.org/e/changeset/63646
>
> Modified:
> trunk/THEMES/detourious/bits/comp.edc
>
> Modified: trunk/THEMES/detourious/bits/comp.edc
> ===
> --- trunk/THEMES/detourious/bits/comp.edc 2011-09-28 23:07:18 UTC (rev
> 63645) +++ trunk/THEMES/detourious/bits/comp.edc 2011-09-28 23:57:30
> UTC (rev 63646) @@ -269,27 +269,62 @@
> mouse_events: 1;
> description { state: "default" 0.0;
> }
> + description { state: "hidden" 0.0;
> + visible: 0;
> + }
> }
> }
> programs {
> program { name: "show1";
> signal: "e,state,visible,on";
> source: "e";
> + action: STATE_SET "default" 0.0;
> + target: "e.swallow.content";
> + after: "show2";
> + }
> + program { name: "show2";
> action: SIGNAL_EMIT "e,action,show,done" "e";
> }
> program { name: "hide1";
> signal: "e,state,visible,off";
> source: "e";
> + action: STATE_SET "hidden" 0.0;
> + target: "e.swallow.content";
> + after: "hide2";
> + }
> + program { name: "hide2";
> action: SIGNAL_EMIT "e,action,hide,done" "e";
> }
> }
> }
> //
> group { name: "e/comp/still";
> - alias: "e/comp/menu";
> + alias: "e/comp/default";
> parts {
> + part { name: "clipper";
> +type: RECT;
> +mouse_events: 0;
> +description { state: "default" 0.0;
> + visible: 0;
> + color: 255 255 255 0;
> + rel1 {
> + relative: -1.0 -1.0;
> + offset: - -;
> + }
> + rel2 {
> + relative: 2.0 2.0;
> + offset: ;
> + }
> +}
> +description { state: "visible" 0.0;
> + inherit: "default" 0.0;
> + visible: 1;
> + color: 255 255 255 255;
> +}
> + }
> part { name: "shadow";
> mouse_events: 0;
> + clip_to: "clipper";
> description { state: "default" 0.0;
> image {
> normal: "images/comp/comp-sh1.png";
> @@ -316,6 +351,7 @@
> part { name: "focus-clipper";
> type: RECT;
> mouse_events: 0;
> + clip_to: "clipper";
> description { state: "default" 0.0;
> color_class: "comp_focus-out_color";
> rel1 {
> @@ -357,11 +393,21 @@
> program { name: "show1";
> signal: "e,state,visible,on";
> source: "e";
> + action: STATE_SET "visible" 0.0;
> + target: "clipper";
> + after: "show2";
> + }
> + program { name: "show2";
> action: SIGNAL_EMIT "e,action,show,done" "e";
> }
> program { name: "hide1";
> signal: "e,state,visible,off";
> source: "e";
> + action: STATE_SET "default" 0.0;
> + target: "clipper";
> + after: "hide2";
> + }
> + program { name: "hide2";
> action: SIGNAL_EMIT "e,action,hide,done" "e";
> }
> program { name: "focus";
> @@ -381,8 +427,8 @@
> }
> }
> //
> -group { name: "e/comp/default";
> - alias: "e/comp/popup";
> +group { name: "e/comp/popup";
> + alias: "e/comp/menu";
> parts {
> part { name: "clipper";
> type: RECT;
>
>
> --
> All the dat
Re: [E-devel] E SVN: discomfitor trunk/elementary
yeah this is better than managing elm todo personally. great discomfitor! Daniel Juyung Seo (SeoZ) On Thu, Sep 29, 2011 at 9:29 AM, Enlightenment SVN wrote: > Log: > add a todo file for elm to start keeping track of issues > > > Author: discomfitor > Date: 2011-09-28 17:29:38 -0700 (Wed, 28 Sep 2011) > New Revision: 63647 > Trac: http://trac.enlightenment.org/e/changeset/63647 > > Added: > trunk/elementary/TODO > > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/THEMES/detourious/bits
Using his coding style, with tabs and all :-/
On Wednesday, September 28, 2011, Mike Blumenkrantz
wrote:
> On Wed, 28 Sep 2011 16:57:30 -0700
> "Enlightenment SVN" wrote:
>
>> Log:
>> THEMES/detorious: fix some missing programs, change 'menu' and 'default'
>> focus out.
>>* manage contents visibility, does not seem to affect runtime, but
>> the preview looked weird.
>>
>>* 'menu' should not be colored on focus-out, likely it will not have
>> any focus... same as 'popup'
>>
>>* 'standard' should have focus-out color, same as 'still' given that
>> default and still do no wobble effect.
>>
>>
>>
>> Author: barbieri
>> Date: 2011-09-28 16:57:30 -0700 (Wed, 28 Sep 2011)
>> New Revision: 63646
>> Trac: http://trac.enlightenment.org/e/changeset/63646
>>
>> Modified:
>> trunk/THEMES/detourious/bits/comp.edc
>>
>> Modified: trunk/THEMES/detourious/bits/comp.edc
>> ===
>> --- trunk/THEMES/detourious/bits/comp.edc 2011-09-28 23:07:18 UTC
(rev
>> 63645) +++ trunk/THEMES/detourious/bits/comp.edc 2011-09-28 23:57:30
>> UTC (rev 63646) @@ -269,27 +269,62 @@
>> mouse_events: 1;
>> description { state: "default" 0.0;
>> }
>> + description { state: "hidden" 0.0;
>> + visible: 0;
>> + }
>> }
>> }
>> programs {
>> program { name: "show1";
>> signal: "e,state,visible,on";
>> source: "e";
>> + action: STATE_SET "default" 0.0;
>> + target: "e.swallow.content";
>> + after: "show2";
>> + }
>> + program { name: "show2";
>> action: SIGNAL_EMIT "e,action,show,done" "e";
>> }
>> program { name: "hide1";
>> signal: "e,state,visible,off";
>> source: "e";
>> + action: STATE_SET "hidden" 0.0;
>> + target: "e.swallow.content";
>> + after: "hide2";
>> + }
>> + program { name: "hide2";
>> action: SIGNAL_EMIT "e,action,hide,done" "e";
>> }
>> }
>> }
>> //
>> group { name: "e/comp/still";
>> - alias: "e/comp/menu";
>> + alias: "e/comp/default";
>> parts {
>> + part { name: "clipper";
>> +type: RECT;
>> +mouse_events: 0;
>> +description { state: "default" 0.0;
>> + visible: 0;
> you seem to have only a vague understanding of formatting :P
>
> --
> Mike Blumenkrantz
> Zentific: Coding in binary since '10.
>
>
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] edje_cc : group_inherit feature
Here we go ! 2011/9/28 Jaehwan Kim : > 7. Do not increase the size of runtime structure, especially Edje_Part > and also Edje_program as much as possible. The reorder is maybe doable > when you find the keyword, that would avoid completly the reorder > structure inside Edje_Part. If I increase the size of runtime structure, previously built edj files may have a problem. You concerned about it, right? I didn't think about that. then how can I change the code? Do you have any idea? I saw the code you change in 62086. Should I change like that? >>> The issue is that with your change, we now have pointer that are not used at runtime, but are allocated. This is a waste of memory in my opinion. It will not break previous edje file, thanks to eet, but still that's not a good thing in my opinion. Maybe instead of adding this structure, you could try to put the part/program at the right place when you find the keyword that tell you where to put it. As for can_override, I think it should be part of a more generic infrastructure to detect when setting a value override an existing property. So lets forget about that one for the moment. You don't need to change the way you handle it in your patch. When we improve edje error, we could improve that at that time. >>> >>> I separated the structure of reorder from Edje_Part. And after reordering, >>> the structure is deleted. Becuase Edje_Part just has the reorder pointer, >>> I think there isn't the waste of the memory. >>> Please check attached patch file. >> >>> This change sounds good to me, just one question why didn't you put >>> the "can_override" member inside the reorder member ? >> >> "can_override" is not related to reorder feature. So I think it is not >> proper. >> And "can_override" is in three structure but reorder is just in _Edje_Part >> structure. I think it's not proper in unity aspect, too. > >> Yes, but can_override is a data only used by edje_cc. So puting it in >> Edje_Part make it increase the size of Edje at runtime. In fact, in my >> opinion, it would make sense to create an Edje_Part_Parser or >> something like that, that would hold this can_override and the reorder >> field to. > > I changed the structure of three struct (Edje_Program, Edje_Pack_Element, > Edje_Part) as you said. I made three struct (Edje_Program_Parser, > Edje_Pack_Element_Parser, Edje_Part_Parser). can_override and reorder > are used in that struct. So Edje_Program, Edje_Pack_Element and Edje_Part > are not changed. We don't worry about the increasing the size of Edje at > runtime. > I tested it and it works well. Please check my patch. I did just move the various _Parser structure inside edje_cc.h instead of edje_private.h and fixed some obvious source of bug. As the rest looked fine, I pushed it in svn, so every one can now try and use it. Thanks for your work. Have fun ! -- Cedric BAIL -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/THEMES/detourious/bits
On Wed, Sep 28, 2011 at 9:00 PM, Mike Blumenkrantz wrote:
> On Wed, 28 Sep 2011 16:57:30 -0700
> "Enlightenment SVN" wrote:
>
>> Log:
>> THEMES/detorious: fix some missing programs, change 'menu' and 'default'
>> focus out.
>> * manage contents visibility, does not seem to affect runtime, but
>> the preview looked weird.
>>
>> * 'menu' should not be colored on focus-out, likely it will not have
>> any focus... same as 'popup'
>>
>> * 'standard' should have focus-out color, same as 'still' given that
>> default and still do no wobble effect.
>>
>>
>>
>> Author: barbieri
>> Date: 2011-09-28 16:57:30 -0700 (Wed, 28 Sep 2011)
>> New Revision: 63646
>> Trac: http://trac.enlightenment.org/e/changeset/63646
>>
>> Modified:
>> trunk/THEMES/detourious/bits/comp.edc
>>
>> Modified: trunk/THEMES/detourious/bits/comp.edc
>> ===
>> --- trunk/THEMES/detourious/bits/comp.edc 2011-09-28 23:07:18 UTC (rev
>> 63645) +++ trunk/THEMES/detourious/bits/comp.edc 2011-09-28 23:57:30
>> UTC (rev 63646) @@ -269,27 +269,62 @@
>> mouse_events: 1;
>> description { state: "default" 0.0;
>> }
>> + description { state: "hidden" 0.0;
>> + visible: 0;
>> + }
>> }
>> }
>> programs {
>> program { name: "show1";
>> signal: "e,state,visible,on";
>> source: "e";
>> + action: STATE_SET "default" 0.0;
>> + target: "e.swallow.content";
>> + after: "show2";
>> + }
>> + program { name: "show2";
>> action: SIGNAL_EMIT "e,action,show,done" "e";
>> }
>> program { name: "hide1";
>> signal: "e,state,visible,off";
>> source: "e";
>> + action: STATE_SET "hidden" 0.0;
>> + target: "e.swallow.content";
>> + after: "hide2";
>> + }
>> + program { name: "hide2";
>> action: SIGNAL_EMIT "e,action,hide,done" "e";
>> }
>> }
>> }
>> //
>> group { name: "e/comp/still";
>> - alias: "e/comp/menu";
>> + alias: "e/comp/default";
>> parts {
>> + part { name: "clipper";
>> + type: RECT;
>> + mouse_events: 0;
>> + description { state: "default" 0.0;
>> + visible: 0;
>> + color: 255 255 255 0;
>> + rel1 {
>> + relative: -1.0 -1.0;
>> + offset: - -;
>> + }
>> + rel2 {
>> + relative: 2.0 2.0;
>> + offset: ;
>> + }
>> + }
>> + description { state: "visible" 0.0;
>> + inherit: "default" 0.0;
>> + visible: 1;
>> + color: 255 255 255 255;
>> + }
>> + }
>> part { name: "shadow";
>> mouse_events: 0;
>> + clip_to: "clipper";
>> description { state: "default" 0.0;
>> image {
>> normal: "images/comp/comp-sh1.png";
>> @@ -316,6 +351,7 @@
>> part { name: "focus-clipper";
>> type: RECT;
>> mouse_events: 0;
>> + clip_to: "clipper";
>> description { state: "default" 0.0;
>> color_class: "comp_focus-out_color";
>> rel1 {
>> @@ -357,11 +393,21 @@
>> program { name: "show1";
>> signal: "e,state,visible,on";
>> source: "e";
>> + action: STATE_SET "visible" 0.0;
>> + target: "clipper";
>> + after: "show2";
>> + }
>> + program { name: "show2";
>> action: SIGNAL_EMIT "e,action,show,done" "e";
>> }
>> program { name: "hide1";
>> signal: "e,state,visible,off";
>> source: "e";
>> + action: STATE_SET "default" 0.0;
>> + target: "clipper";
>> + after: "hide2";
>> + }
>> + program { name: "hide2";
>> action: SIGNAL_EMIT "e,action,hide,done" "e";
>> }
>> program { name: "focus";
>> @@ -381,8 +427,8 @@
>> }
>> }
>> //
>> -group { name: "e/comp/default";
>> - alias: "e/comp/popup";
>> +group { name: "e/comp/popup";
>> + alias: "e/comp/menu";
>>
[E-devel] Evas/Elm resolution management
Hi all, As you know, I'm doing the PS3 port of the EFL and I'm finding myself in a bit of a tricky situation, let me explain : The PS3 is a console that outputs to a TV... TVs can do different resolutions, 480, 720p or 1080p (as well as a few others). The SDK allows us to know what the TV screen supports, and we can choose to switch to whatever resolution we want that the TV supports. What I initially did in the evas engine was that I would take whatever size the application requested (evas_output_size_set) and set my buffer to it, then find the closest matching resolution (the smallest difference in area between that resolution and the resolutions supported by the TV), and set the TV to that res, then scale the output when I draw on screen. So basically, you'd resize your evas to 200x200 and it would be seen internally as 200x200 but the engine would scale it to 720x480 for the screen. The issue came when I ported elementary. Most (all?) elementary tests (from elementary_test app) would create the evas with resolution 1x1 then they would resize the window to whatever they want, but I never received that size change request and my buffer would stay at 1x1 and scale that up. The reason is that the ecore_evas_resize has a nice little check : if (ee->prop.fullscreen) return; so the resize would never work. I 'fixed' it by removing the fullscreen flag for the ps3 engine. Other issue I got was that when I scale, I lose the aspect ratio which might look great. so I'm thinking of adding a way to tell the engine if we want to keep the aspect ratio (then it would center the scaled image on screen) or stretch it completely. Is there a way to set this up natively with the API without having an engine specific option ? Raster said that fullscreen engines need to tell the screen resolution to the app, so what I did was to also add a call to the resize callback after we get resized, more precisely, you set your window to 200x200, you get a resize callback of your 200x200 then it will fetch the real current resolution (720x480) then send another resize callback with the full resolution. Question here, should I do it like that or should I only sent a single resize callback? Most importantly, what happens when the client didn't register his callback yet? for example, eskiss would do the ecore_evas_new with its 1280x768 resolution request, *then* do the callback_resize_set (but it's too late since the resize callback was 'called' during the new), and since it never calls the ecore_evas_resize afterwards, it never knows that the evas it's working on has been resized. What should be the fix for that? should the ecore_evas_callback_resize_set call the callback with the current resolution the first time it's called? Or should we workaround it by always creating 1x1 windows and then call the ecore_evas_resize after we set a callback (in which case it might cause the tv screen to switch resolutions twice for no reason)? Finally, my current biggest design issue, is how to decide whether or not to tell the application that it has been resized to fit the screen. In other words, what if someone wants the window to be 200x200 and get scaled and doesn't actually want to be rendering on 720x480? What if the window has a min/max size set to it? In the case of eskiss, I get a smooth 60fps on 1280x768, but when it tries to draw on any other resolution, its performance drops to 2 or 3 fps (I still have no idea what causes this performance loss), so for eskiss for example, I wouldn't want to have the resize callback called and evas_output_size_set called to resize evas to the screen resolution, I'd want it to stay at 1280x768 and have the engine scale that to whatever the screen wants (and even if we fixed that performance issue, if the TV only supports 480p SD resolutions, eskiss just won't work because the levels and menus, etc.. were not designed for anything less than 1280x768.. and they will not look good on 1920x1080 either). One thought I had was the fullscreen flag.. if the fullscreen flag is set, then I'd call the resize callback and resize evas to fit the screen resolution, if it's not set, then I would just scale. This brings up the issue of the ecore_evas_resize not working in fullscreen mode.. what if I want to change the screen resolution? I'd have to unset the fullscreen flag, then resize, then set it back again (imagine a game where you can choose the fullscreen resolution in the game's video options). That seems like an ugly hack. Maybe I should use the maximized flag instead in that case.. in which case, does any of these flags affect how evas/ecore_evas/elementary work? or is that only engine specific stuff ? Obviously the fullscreen flag affects ecore_evas (since it skips the resize command), will there be any other similar side effects if I make the window have the maximized flag or not? I feel like it would make sense to have the engine set the maximized and fullscreen flags, because that's how it really is, and i
Re: [E-devel] E SVN: cedric IN trunk/edje: . src/bin
On Wed, 28 Sep 2011 18:29:21 -0700 "Enlightenment SVN" wrote: > Log: > edje: add group inheritance. > > Patch by Jaehwan Kim > > > Author: cedric > Date: 2011-09-28 18:29:21 -0700 (Wed, 28 Sep 2011) > New Revision: 63648 > Trac: http://trac.enlightenment.org/e/changeset/63648 > > Modified: > trunk/edje/AUTHORS trunk/edje/ChangeLog trunk/edje/src/bin/edje_cc.c > trunk/edje/src/bin/edje_cc.h trunk/edje/src/bin/edje_cc_handlers.c > trunk/edje/src/bin/edje_cc_out.c > would be good to have some working examples committed with this as well... -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
