Re: [E-devel] EFL and subpixel antialiasing

[Stanislav Baiduzhyi]

On Mon, Dec 28, 2015 at 9:35 PM, Michal Suchanek  wrote:
>> That makes some sense. Pity, on still very popular 96 DPI monitor
>> readability of subpixeled font is one step higher.
> Popular in the sense you can easily pull a working one from the trash?

In a sense that around 60% of all monitors in the shops are still 23"
FullHD which is 96 DPI, and most of the large employers are providing
exact those monitors in the offices.

>> Also, I've noticed that font size is often configured in pixels and
>> not in points, why?
> It's stupid. On the other hand, X reports DPI as 96 always unless you
> take manual measures to correct it.
>
> There is also per-display DPI which you can infer from xrandr
> information which is also often bogus. And nobody probably bothers to
> read it anyway.

Yes, X is famously bad at detecting physical size of the display. But
minor modification to Xorg conf and you can have it reported properly,
since most of the toolkits are still calculating DPI from physical
size and resolution. As for pixels, if you have QHD+ laptop with 96
DPI external screen you're still screwed, no matter if you measure in
pixels or points. But at least they promise that Wayland will handle
it better than X, so pt is still more flexible.

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Ask opinion: size hint padding vs. margin

[The Rasterman]

On Mon, 28 Dec 2015 04:57:04 + Conrad Um  said:

> Dear all,
> 
> I'm seeking for an easier way to make a layout without edc, but only with
> code.
> I suggested a contianer having flexible padding for layouts like this.
> http://imgur.com/E1HfxJF
> 
> Now I want to ask opinion about size hint padding or margin.
> 
> The biggest difference between size hint padding and margin is whether the
> extent of paddings belongs to the area of the object or not. Let's see the
> next picture.
> http://imgur.com/7pFP0sG
> 
> Because of this difference, their behaviors become different between the
> object having size hint padding and margin.

sure. these are different. both belong to the object itself. one is implemented
by parent (padding) one by child (margin). ok.

> size hint padding https://phab.enlightenment.org/D3500
> 1. calculation: A litte complex. Calculation logic belongs to the container
> object like box or table. If the object having size hint padding is not
> packed into a container or the container doesn't have the logic handling
> child's size hint padding, size hint padding will not work at all. (It's
> easy to implement size hint padding on box or table, but seems not so easy
> for edje object. If swallowd object has margins, edje should consider those
> values while moving or resizing its children.)

actually edje objects can do it.. add padding to min size when calculating and
always move object in from swallow geom by pad left + pad top and resize it to
swallow size mind all the padding on each axis. margins can just be added ALSO
to min size too as above but the object isnt offset by margin or reduced by the
margin in side.

> 2. geometry: Intuitive. Because object and resize object are same,
> developer can get geometry of visible area directly.
> 3. scaling: Inconsistent. Elm.Box has its own calculation logic in
> els_box.c but elm_table depends on Evas.Table. Original Evas.Box or
> Evas.Table are not affected by scale, because scale factor belongs to
> Elementary. So applying scale to size hint padding is easy to Elm.Box, but
> hard on Elm.Table.

ok scaling is an issue. should padding or margin be multiplied by scale? hmmm.
i lean to "no". multiply by scale yourself when setting it... UNLESS we add a
boolean flag to hints to say "multiply by scale factor" ... we do have an evas
scale factor per object too... :)

> margin: https://phab.enlightenment.org/D3458
> 1. calculation: Easy. Calculation logic belongs to the object itself having
> margin, so margin can be applied to any container. (child object calculates
> its own min size including margins)
> 2. geometry: Not intuitive. Margins exist between object and its resize
> object, so the coordinates can be different between real object and visible
> area.
> 3. scaling: Very simple. Object's min size is determined by adding the min
> size of resize object and the scaled margins.
> 
> I prefer margin to size hint padding, because of easier implementation and
> consistency.
> Or, both of size hint padding and margin can be applied at the same time.
> If many of you think that size hint padding should be used for flexible
> spacing, please advise me about Scaling size hint padding in Elm.Table and
> Elm.Layout (Edje.Object).
> 
> I appreciate your taking the time to read this long email.

i think they can be applied at the same time - for different purposes. one
adds "empty padding" around the object. the parent does this. the other EXPANDS
the minimum size of an object by the margin. the object should be resized by
the parent of course.

should these be scaled? good q. 

> Best regards,
> Jee-Yong Um (conr2d)
> --
> ___
> 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


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] C++ bindings

[Andreas Volz]

Hello,

I just like to take a decision about eflxx (C++ binding)

https://git.enlightenment.org/bindings/cxx/eflxx.git/

I put many work based on this and have at least one application based
on it that I never really published to the community.

https://github.com/andreas-volz/stateval

Based on this I developed a infotainment car system. Also on github
available. (oilm, oicf, oisp, oiui). I didn't work that much on it in
the last year, but now like to continue the work.

Now I looked in current state of the E development and see the C++
wrapper direct in the EFL libs. Didn't yet try it so far. How mature
and stable is the C++ API? 

I'm really a little sad about throwing eflxx away if I decide for
this, because of the many time I invested in it. :-( But on the good
side I could put all time I save to maintain eflxx into my
application. :-)

Is someone else using eflxx or am I the only user? Does it really help
to have two different C++ APIs available?

The only comment while just browsing five minutes around the new C++
headers is that I like the EFLxx API a little more. It looks more C++
like and uses more C++ like designs. But I may be wrong. Please correct
me here.

So I'm very interested in your comments!

regards
  Andreas


BTW: for some reasons my developer GIT account is again not working. 

> git clone git+ssh://g...@git.enlightenment.org/bindings/cxx/eflxx.git
Cloning into 'eflxx'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I checked ssh key and this one is correct:
https://git.enlightenment.org/admin/devs.git/tree/developers/andreas/id_dsa_thor.pub

-- 
Technical Blog 

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Enlightenment DR 0.20.2 Release

[Mike Blumenkrantz]

This bugfix release improves on the 0.20.1 release and resolves a number of
issues.

TICKETS ADDRESSED
https://phab.enlightenment.org/T2906
https://phab.enlightenment.org/T2942
https://phab.enlightenment.org/T2950

SHA256SUM + DOWNLOAD
3de99a7f09ccedf3039482794882002b1025df9fa8b3ab7b60c1ae6bb10c41f7
http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.20.2.tar.gz

441009a5cbe19861bc1f1404ce4361184ace27208ce429a51c23344c8f9f5d39
http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.20.2.tar.xz


Bonus release:
68166cb57e3fdf0a78b7a405bb93b22b0a3a8b6ab7b993b2169209c06471fcd2
http://download.enlightenment.org/rel/apps/enlightenment/desksanity-1.1.0.tar.gz

c3ab8e851100bb6db948ab45b8aaab25ead11ec0a6660d25d918fc162d6be57e
http://download.enlightenment.org/rel/apps/enlightenment/desksanity-1.1.0.tar.xz

See the full announcement for more details:
https://phab.enlightenment.org/phame/live/3/post/e20_2_release/
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[Mike Blumenkrantz]

Changing the option only affects users of git, so it's not the highest
priority for many people to look at immediately after it has been changed.
Given that the removal of sleep is guaranteed to work for all stable
releases (since configure options don't change during this time) it means
that the only ones being penalized here are users of git directly.

It has indeed been some time since the option was last changed, but I don't
think changing it more frequently is the answer; this will only cause
people who maintain ebuilds to begin updating them more frequently since it
will become a "routine change". This is assuming that they don't just read
the configure script and disable the check for the option entirely--far
easier for them to do than to continually update some option which is known
to be volatile.

Any solution with configure flags really just results in more work for you
on the development side as well as more hassle for every other non-Gentoo
user of git who changes a default option while knowing what they are doing.

On Thu, Dec 24, 2015 at 9:04 PM Carsten Haitzler 
wrote:

> On Thu, 24 Dec 2015 19:11:28 + Mike Blumenkrantz
>  said:
>
> > As further proof of how unsuccessful this has been, here's the downstream
> > patch that Gentoo's core repo ebuilds use:
> >
> >
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=422cf597b84d3553eac42dd8b1faa8257af5941f
> >
> > It removes the sleep entirely, making the entire thing (and all future
> > attempts at "getting attention") a complete waste of time for everyone.
>
> that specifically isn't going to change anything as in my experience no
> gentoo
> "user" reads build output. they pastebin it and have someone else read it
> for
> them. so a sleep is being patched out only to "make the build faster".
>
> changing the "i know what i am doing" option stops the build entirely and
> such
> patches are not a workaround for that.
>
> we havent changed that option for maybe 2 years. ok - checking log. last
> change
> was 1.5 years ago - july 2014. so perhaps the "its not working" is a
> result of
> not changing it often enough? the builds settle in and then dont change?
>
> > On Thu, Dec 24, 2015 at 12:22 PM Mike Blumenkrantz <
> > michael.blumenkra...@gmail.com> wrote:
> >
> > > After having read these mails, as well as the past mails on this topic,
> > > I'm beginning to see a pattern.
> > >
> > > This option was originally implemented because a Gentoo user came into
> #e
> > > last year asking why something in Enlightenment didn't work (possibly
> mouse
> > > cursors, since the eet image loader is/was optional). It was determined
> > > that changing any "default" configure option would require this flag so
> > > that Gentoo users would then come to #e to ask why their ebuild was
> broken
> > > instead of lacking features in their applications.
> > >
> > > Having seen the flag at work for almost two years, I can only say
> that, in
> > > my opinion, the objective has not been met. Trying to filter Gentoo
> users
> > > (since yes, it was directed specifically at blocking them from toggling
> > > features) in this way is, in a word, impossible. To understand why,
> it's
> > > necessary to examine the state of Enlightenment packaging in Gentoo.
> > > Currently, Gentoo "provides" Enlightenment. Looking at the available
> > > packages (https://packages.gentoo.org/packages/x11-wm/enlightenment
> > > https://packages.gentoo.org/packages/dev-libs/efl), it's easy to see
> that
> > > updates are not frequent since none of the packages are even close to
> > > up-to-date. Users can easily figure out what the latest version of
> > > available software is, and they will typically want to use it, even
> more so
> > > on Gentoo. So how do Gentoo users usually install Enlightenment to get
> > > these latest versions? They use third party repositories.
> > > Checking the list of (public) repositories for Enlightenment packages
> > > yields significantly more results (
> > > http://gpo.zugaina.org/x11-wm/enlightenment
> > > http://gpo.zugaina.org/dev-libs/efl). These repositories are
> maintained
> > > by users (anyone), and are updated MUCH more frequently than the core
> > > repository, typically by someone who is more in-tune with upstream
> > > development. According to the overlays listed, none have yet updated
> to the
> > > flag's name change, but I'd guess this is more likely related to lack
> of
> > > time due to holidays/end of year than not having noticed the change or
> > > having been notified of it. Regardless, once they update, and they
> will,
> > > breaking this option will have been a waste of time for everyone,
> including
> > > the time that I spent writing this mail.
> > >
> > > Furthermore, I'd like to address what may be an oversight from the
> > > statement that "it's to try and force whoever is maintaing the build to
> > > sit and think for a bit about what they are doing and possibly
> > 

Re: [E-devel] Enlightenment DR 0.20.2 Release

[Bruno Prémont]

On Mon, 28 December 2015 Mike Blumenkrantz  
wrote:
> 
> See the full announcement for more details:
> https://phab.enlightenment.org/phame/live/3/post/e20_2_release/
> --

Whoever is on change of this part of phab, please check the logo 
tag generated in there. It is rendered as follows:
16:
17:  
18:
19:  http://www.enlightenment.org;>
20:http://www.enlightenment.org/lib/tpl/e/images/logo.png; border=0>
21:  
22:

The http:// src on a https page causes at least Firefox to complain.
As www.enlightenment.org is https capable the src attribute should be
//www.enlightenment.org/... or https://www.enlightenment.org/...

Thanks for fixing,
Bruno


pgpihXOOrz9PG.pgp
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL and subpixel antialiasing

[Stanislav Baiduzhyi]

On Sun, Dec 27, 2015 at 11:27 PM, Carsten Haitzler  wrote:
> 100% intended. there is no way we are doing that insanely bad sub-pixel rgb
> stuff n efl. an explicit decision to not support it. why?

That makes some sense. Pity, on still very popular 96 DPI monitor
readability of subpixeled font is one step higher. But yes,
considering development resource constraints it's already too late to
start implementing something like this.

Also, I've noticed that font size is often configured in pixels and
not in points, why?

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL and subpixel antialiasing

[Michal Suchanek]

On 27 December 2015 at 23:27, Carsten Haitzler  wrote:
> On Sun, 27 Dec 2015 16:59:33 +0100 Stanislav Baiduzhyi
>  said:
>
>> I've noticed that fonts in EFL-based apps are not as good as in Qt
>> apps, and digging into source it looks like LCD rendering is not
>> supported, render mode is hardcoded to FT_RENDER_MODE_NORMAL. Is that
>> intentional or just not yet implemented feature?
>
> 100% intended. there is no way we are doing that insanely bad sub-pixel rgb
> stuff n efl. an explicit decision to not support it. why?
>
> 1. 3x the storage needed at least for fonts
> 2. slower rendering
> 3. adds colorization/swimming artifacts so it's not "better" just it gains 
> some
> percieved resolution and loses color fidelity in the process (eg you willfind
> the outline of a char may swim between reddish and blueish as it goes down a
> diagonal).
> 4. this requires metadata (the exact rgb pixel layout) that you can't always
> accurately get and in the end needs to be manually provided
> 5. in additon this falls down horribly when the rgb layout is wrong for your
> screen - eg if its a pentile amoled or its bgr, or gbr, or perhaps there are
> not 3 ditinct rgb triplets side by side - maybe its vertical or a projector
> where there literally are not side-by-side elements byt they layer on top in 3
> display passes (r, g then b).

That's unfortunate that displays do not include this information in
EDID or such. Still there are ways to specify the correct order, even
ones that don't require the user to be a rocket scientist. eg windows
have a wizard which basically renders the text with every setting
available and lets the user pick whatever looks the best. You have to
do that for every display in multi-display configurations, though.

> 6. this totally falls over once you do transforms - eg you rotate an object 90
> degrees  or any angle for that matter or stretch etc. - eg via proxies or map
> as well as entire window or screen rotation where your rgb layout is basically
> changing on the fly. you have to recompute all your font sub-rendering every
> time for the full 90 degree rotations and anything else is basically undoable
> so you have to turn it off.

And since compositing is becoming popular this antialiasing (subpixel
or otherwise) should be done in the compositor. Unfortunately, the
compositor does not have the subpixel information because the window
is usually rendered pixel for pixel. So if you really wanted subpixel
rendering that badly you can probably add an experimental feature to
your compositor so it reports the DPI larger to applications (eg 3x or
9x) and then scales down the rendered window bitmaps using any hacks
you like. You might need special hacks for single pixel lines, though.

> 7. historically such "hacks" have limited lifespans as display technology
> keeps changing, i've lived through many such hacks across 8/6 and 32bit
> machines over the decades. i've seen hacks come and go. thus code invested in
> this even with the above issues will have a limited lifespan and add cost to
> maintain.

Indeed, with higher res displays antialiasing in general and subpixel
rendering in particular is losing its sheen.


On 28 December 2015 at 20:39, Stanislav Baiduzhyi
 wrote:
> On Sun, Dec 27, 2015 at 11:27 PM, Carsten Haitzler  
> wrote:
>> 100% intended. there is no way we are doing that insanely bad sub-pixel rgb
>> stuff n efl. an explicit decision to not support it. why?
>
> That makes some sense. Pity, on still very popular 96 DPI monitor
> readability of subpixeled font is one step higher.

Popular in the sense you can easily pull a working one from the trash?

>
> Also, I've noticed that font size is often configured in pixels and
> not in points, why?
>


It's stupid. On the other hand, X reports DPI as 96 always unless you
take manual measures to correct it.

There is also per-display DPI which you can infer from xrandr
information which is also often bogus. And nobody probably bothers to
read it anyway.


Thanks


Michal

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove unnecessary layer set for elm_win.

[Daniel Juyung Seo]

+Jaehyun

OK let's stop guessing by ourselves and just ask Jaehyun and Raster.
Daniel Juyung Seo (SeoZ)


On Tue, Dec 29, 2015 at 9:41 AM, Hermet Park  wrote:
> i'm sure he already asked.
>
> Regards, Hermet
>
> -Original Message-
> From: "Daniel Juyung Seo"
> To: "Enlightenment developer list";
> Cc: "Carsten Haitzler";
> Sent: 2015-12-28 (월) 15:58:15
> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove 
> unnecessary layer set for elm_win.
>
> This code was there for years and it could impact the behavior.
> I think there must be a good reason for this code but I also have a
> doubt on this code.
>
> One thing I am sure is that if someone would like to change the code
> like this(been there for ages and could give an impact), it should be
> discussed with the original author(in this case, Raster) first as far
> as he/she is reachable. Do not just remove the code just because you
> don't know why.
>
> Of course, this could be a workaround code and needs to be removed but
> anyways ask raster first. I think there must be a reason.
>
> Thanks,
> Daniel Juyung Seo (SeoZ)
>
>
> On Mon, Dec 28, 2015 at 2:44 PM, Hermet  wrote:
>> If it doesn't cause any critical side effects/compatibility issues, I can't 
>> see any reasons to keep it in.
>>
>> No one expects window layer value is 50.
>> But I'd rather ask why 50? why it should have layer 50?
>>
>> Specifically, evas_object_layer_set() API has been exposed,
>> which means the layer setting is up to users, even window object can be 
>> dealt with the API by users.
>>
>> Additionally, window object was special one so it have been deal with event 
>> stuff differently.
>>
>>
>> Regards, Hermet
>>
>> -Original Message-
>> From: "Amitesh Singh"
>> To: "Enlightenment developer 
>> list";
>> Cc: "Carsten Haitzler";
>> Sent: 2015-12-25 (금) 16:05:50
>> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: 
>> Remove unnecessary layer set for elm_win.
>>
>> Hello
>>
>> On Dec 18, 2015 3:54 PM, "Jaehyun Cho"  wrote:
>>>
>>> jaehyun pushed a commit to branch master.
>>>
>>>
>> http://git.enlightenment.org/core/elementary.git/commit/?id=a9be1d488daf74d11181909fb6c454991272fe1e
>>>
>>> commit a9be1d488daf74d11181909fb6c454991272fe1e
>>> Author: Jaehyun Cho 
>>> Date:   Fri Dec 18 19:18:51 2015 +0900
>>>
>>> elm_win: Remove unnecessary layer set for elm_win.
>>> ---
>>>  src/lib/elm_win.c  1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
>>> index b1a05ae..f509f95 100644
>>> --- a/src/lib/elm_win.c
>>> +++ b/src/lib/elm_win.c
>>> @@ -3830,7 +3830,6 @@ _elm_win_finalize_internal(Eo *obj, Elm_Win_Data
>> *sd, const char *name, Elm_Win_
>>> evas_object_color_set(obj, 0, 0, 0, 0);
>>> evas_object_move(obj, 0, 0);
>>> evas_object_resize(obj, 1, 1);
>>> -   evas_object_layer_set(obj, 50);
>>
>> I wonder why it was removed.  As far as I know,  elm win is a fake ecore
>> evas object. Basically it's just a wrapper of ecore evas and since elm win
>> does not contain any object so I think it's better to put it at layer 50.
>> After this change,  there could be a case when it does not receive any
>> events as it might go at lowest at layer 0. This could result into some
>> side effects. Please consider this.
>>> evas_object_pass_events_set(obj, EINA_TRUE);
>>>
>>> if (type == ELM_WIN_INLINED_IMAGE)
>>>
>>> --
>>>
>>>
>> --
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> --
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
___
enlightenment-devel mailing list

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove unnecessary layer set for elm_win.

[The Rasterman]

On Tue, 29 Dec 2015 15:00:40 +0900 Daniel Juyung Seo 
said:

> +Jaehyun
> 
> OK let's stop guessing by ourselves and just ask Jaehyun and Raster.
> Daniel Juyung Seo (SeoZ)

i did tell jaehyun that i have no idea why that is there and it likely shouldnt
be. its too long ago as to remember why its there as it was there in the
initial elm win code.

> On Tue, Dec 29, 2015 at 9:41 AM, Hermet Park  wrote:
> > i'm sure he already asked.
> >
> > Regards, Hermet
> >
> > -Original Message-
> > From: "Daniel Juyung Seo"
> > To: "Enlightenment developer
> > list"; Cc: "Carsten
> > Haitzler"; Sent: 2015-12-28 (월) 15:58:15
> > Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win:
> > Remove unnecessary layer set for elm_win.
> >
> > This code was there for years and it could impact the behavior.
> > I think there must be a good reason for this code but I also have a
> > doubt on this code.
> >
> > One thing I am sure is that if someone would like to change the code
> > like this(been there for ages and could give an impact), it should be
> > discussed with the original author(in this case, Raster) first as far
> > as he/she is reachable. Do not just remove the code just because you
> > don't know why.
> >
> > Of course, this could be a workaround code and needs to be removed but
> > anyways ask raster first. I think there must be a reason.
> >
> > Thanks,
> > Daniel Juyung Seo (SeoZ)
> >
> >
> > On Mon, Dec 28, 2015 at 2:44 PM, Hermet  wrote:
> >> If it doesn't cause any critical side effects/compatibility issues, I
> >> can't see any reasons to keep it in.
> >>
> >> No one expects window layer value is 50.
> >> But I'd rather ask why 50? why it should have layer 50?
> >>
> >> Specifically, evas_object_layer_set() API has been exposed,
> >> which means the layer setting is up to users, even window object can be
> >> dealt with the API by users.
> >>
> >> Additionally, window object was special one so it have been deal with
> >> event stuff differently.
> >>
> >>
> >> Regards, Hermet
> >>
> >> -Original Message-
> >> From: "Amitesh Singh"
> >> To: "Enlightenment developer
> >> list"; Cc: "Carsten
> >> Haitzler"; Sent: 2015-12-25 (금) 16:05:50
> >> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win:
> >> Remove unnecessary layer set for elm_win.
> >>
> >> Hello
> >>
> >> On Dec 18, 2015 3:54 PM, "Jaehyun Cho"  wrote:
> >>>
> >>> jaehyun pushed a commit to branch master.
> >>>
> >>>
> >> http://git.enlightenment.org/core/elementary.git/commit/?id=a9be1d488daf74d11181909fb6c454991272fe1e
> >>>
> >>> commit a9be1d488daf74d11181909fb6c454991272fe1e
> >>> Author: Jaehyun Cho 
> >>> Date:   Fri Dec 18 19:18:51 2015 +0900
> >>>
> >>> elm_win: Remove unnecessary layer set for elm_win.
> >>> ---
> >>>  src/lib/elm_win.c  1 -
> >>>  1 file changed, 1 deletion(-)
> >>>
> >>> diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
> >>> index b1a05ae..f509f95 100644
> >>> --- a/src/lib/elm_win.c
> >>> +++ b/src/lib/elm_win.c
> >>> @@ -3830,7 +3830,6 @@ _elm_win_finalize_internal(Eo *obj, Elm_Win_Data
> >> *sd, const char *name, Elm_Win_
> >>> evas_object_color_set(obj, 0, 0, 0, 0);
> >>> evas_object_move(obj, 0, 0);
> >>> evas_object_resize(obj, 1, 1);
> >>> -   evas_object_layer_set(obj, 50);
> >>
> >> I wonder why it was removed.  As far as I know,  elm win is a fake ecore
> >> evas object. Basically it's just a wrapper of ecore evas and since elm win
> >> does not contain any object so I think it's better to put it at layer 50.
> >> After this change,  there could be a case when it does not receive any
> >> events as it might go at lowest at layer 0. This could result into some
> >> side effects. Please consider this.
> >>> evas_object_pass_events_set(obj, EINA_TRUE);
> >>>
> >>> if (type == ELM_WIN_INLINED_IMAGE)
> >>>
> >>> --
> >>>
> >>>
> >> --
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> --
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> > --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > 

Re: [E-devel] EFL and subpixel antialiasing

[The Rasterman]

On Mon, 28 Dec 2015 20:39:16 +0100 Stanislav Baiduzhyi
 said:

> On Sun, Dec 27, 2015 at 11:27 PM, Carsten Haitzler 
> wrote:
> > 100% intended. there is no way we are doing that insanely bad sub-pixel rgb
> > stuff n efl. an explicit decision to not support it. why?
> 
> That makes some sense. Pity, on still very popular 96 DPI monitor
> readability of subpixeled font is one step higher. But yes,
> considering development resource constraints it's already too late to
> start implementing something like this.
> 
> Also, I've noticed that font size is often configured in pixels and
> not in points, why?

because evas itself doesnt know or care about dpi. it generates/cares about
pixels. it's very much divorced from the screen itself other than it being a
big grid of pixel values.

the scaling is done elsewhere. thats what scale factor is for. this simply
multiples pixel sizes by this factor. this is what people ACTUALLY want. you
hear people all day long saying "set your dpi to xxx". no. wrong. you dont SET
dpi. the dpi is a fuxed value for that display. the problem is either:

1. your eyesight is horrible at the normal viewing distance, so you just "need
stuff bigger" thus - make scale bigger (or smaller for those with excellent
eyesight to avoid scrolling as much)
  or
2. you are using a screen at a different distance. eg - the tv across the other
side of the living room. dpi is not useful at anything other than an EXACT
viewing distance that is "expecteD" with an "expected" level of eyesight. with
the tv across the room you certainly want to increase sizes -> thus increase
scale factor.

so thats why we have a scale factor setting in e (and elm) and this just sizes
stuff up - not JUST fonts, but many many many things. it's the "make it bigger
- i can't see that" option which is what people ACTUALLY want.

for evas - it just gets given a bigger pixel size then by higher layers of code
that handle the scaling (actually you can set scale ON a specific object and
evas will multiple the font size by the scale factor anyway)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL and subpixel antialiasing

[The Rasterman]

On Mon, 28 Dec 2015 21:35:11 +0100 Michal Suchanek  said:

> On 27 December 2015 at 23:27, Carsten Haitzler  wrote:
> > On Sun, 27 Dec 2015 16:59:33 +0100 Stanislav Baiduzhyi
> >  said:
> >
> >> I've noticed that fonts in EFL-based apps are not as good as in Qt
> >> apps, and digging into source it looks like LCD rendering is not
> >> supported, render mode is hardcoded to FT_RENDER_MODE_NORMAL. Is that
> >> intentional or just not yet implemented feature?
> >
> > 100% intended. there is no way we are doing that insanely bad sub-pixel rgb
> > stuff n efl. an explicit decision to not support it. why?
> >
> > 1. 3x the storage needed at least for fonts
> > 2. slower rendering
> > 3. adds colorization/swimming artifacts so it's not "better" just it gains
> > some percieved resolution and loses color fidelity in the process (eg you
> > willfind the outline of a char may swim between reddish and blueish as it
> > goes down a diagonal).
> > 4. this requires metadata (the exact rgb pixel layout) that you can't always
> > accurately get and in the end needs to be manually provided
> > 5. in additon this falls down horribly when the rgb layout is wrong for your
> > screen - eg if its a pentile amoled or its bgr, or gbr, or perhaps there are
> > not 3 ditinct rgb triplets side by side - maybe its vertical or a projector
> > where there literally are not side-by-side elements byt they layer on top
> > in 3 display passes (r, g then b).
> 
> That's unfortunate that displays do not include this information in
> EDID or such. Still there are ways to specify the correct order, even

you can get RGB, BGR etc. in edid - this is not always correct, and when it's
not - boom. stuff is not happy. evas itself is unaware of edid info or screen
info like dpi etc. - its higher layers that deal with this.

> ones that don't require the user to be a rocket scientist. eg windows
> have a wizard which basically renders the text with every setting
> available and lets the user pick whatever looks the best. You have to
> do that for every display in multi-display configurations, though.

yup. have 2 monitors with different layouts. boom. :( that was my point - this
falls apart way to quickly and when it does the results are staggeringly
horrible,

> > 6. this totally falls over once you do transforms - eg you rotate an object
> > 90 degrees  or any angle for that matter or stretch etc. - eg via proxies
> > or map as well as entire window or screen rotation where your rgb layout is
> > basically changing on the fly. you have to recompute all your font
> > sub-rendering every time for the full 90 degree rotations and anything else
> > is basically undoable so you have to turn it off.
> 
> And since compositing is becoming popular this antialiasing (subpixel
> or otherwise) should be done in the compositor. Unfortunately, the
> compositor does not have the subpixel information because the window
> is usually rendered pixel for pixel. So if you really wanted subpixel
> rendering that badly you can probably add an experimental feature to
> your compositor so it reports the DPI larger to applications (eg 3x or
> 9x) and then scales down the rendered window bitmaps using any hacks
> you like. You might need special hacks for single pixel lines, though.

that is more sensible than rendering the font itself with rgb anti-aliasing.
then it applies to all content equally AND means that if you move a window from
a normal to a hi dpi screen... it can actually seamlessly "look good".

of course there is an issue here - then you spend either 2x2, 3x3 or 4x4 etc.
the cost in rendering (it is NOT cheap) as well as in memory footprint. (4
times, 9 times or 16 times the memory needed and the bandiwdht and the
rendering horsepower)

> > 7. historically such "hacks" have limited lifespans as display technology
> > keeps changing, i've lived through many such hacks across 8/6 and 32bit
> > machines over the decades. i've seen hacks come and go. thus code invested
> > in this even with the above issues will have a limited lifespan and add
> > cost to maintain.
> 
> Indeed, with higher res displays antialiasing in general and subpixel
> rendering in particular is losing its sheen.

yup. thats a big reason to just say no today. with high dpi becoming
increasingly common (still not common but on its way) it isn't worth it. given
all the downsides it isnt even worth considering imho. :(

> On 28 December 2015 at 20:39, Stanislav Baiduzhyi
>  wrote:
> > On Sun, Dec 27, 2015 at 11:27 PM, Carsten Haitzler 
> > wrote:
> >> 100% intended. there is no way we are doing that insanely bad sub-pixel rgb
> >> stuff n efl. an explicit decision to not support it. why?
> >
> > That makes some sense. Pity, on still very popular 96 DPI monitor
> > readability of subpixeled font is one step higher.
> 
> Popular in the sense you can easily pull a working one from 

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention

[The Rasterman]

On Mon, 28 Dec 2015 19:36:53 + Mike Blumenkrantz
 said:

> Changing the option only affects users of git, so it's not the highest

it affects users of git until the next release,, then it affects those building
a release too. changing it every release is probably what should be happening
to make it effective.

> priority for many people to look at immediately after it has been changed.
> Given that the removal of sleep is guaranteed to work for all stable
> releases (since configure options don't change during this time) it means
> that the only ones being penalized here are users of git directly.
> 
> It has indeed been some time since the option was last changed, but I don't
> think changing it more frequently is the answer; this will only cause
> people who maintain ebuilds to begin updating them more frequently since it
> will become a "routine change". This is assuming that they don't just read
> the configure script and disable the check for the option entirely--far
> easier for them to do than to continually update some option which is known
> to be volatile.

actually to do that they have to patch, and the patch to disable it depends on
the option itself, so a new patch has to be generated every time it is changed.
it's less work to just change the option to configure itself. again - as i
said. for builds that build stable sw this needs changing to encode sw version
anyway. every release they have to update from 1.16 to 1.17 to 1.18 - there is
a routine change needed anyway for any packaging of a stable release. for a git
build where you don't care about version then yes - these break and need
maintenance.

> Any solution with configure flags really just results in more work for you
> on the development side as well as more hassle for every other non-Gentoo
> user of git who changes a default option while knowing what they are doing.

i will go back to my original example. ecore-x in xcb code is not complete.
certain things will not work. for example xinput2 is not supported. this will
mean things like touch may not work or work properly when you build with xcb.
if you are ok with this, then fine - use xcb, BUT you must be fully aware of it
and the tradeoffs you are making.

if you disable pulse support you break audio support and users reading that
"this sound happens when i click this" then have no sound and wonder why the
app or efl is broken... at least have an ability to have been warned of it.

the reason isn't build breaks only but also functionality changes. these
choices ad build time affect functionality and a user may not be aware of those
tradeoffs and thus the point is to encourage them to think carefully on their
choices that stray from what is "known to be safe". at least we can do this at
compile time and warn the person making the choices (the one providing the
configure options).

the alternative is we just remove options so people cant create a "broken
builds" and let people actually patch efl code and build files to try and get
their broken builds back. that or just live with people who have broken systems
and go around all day saying "e is broken., it sucks" probably because they
shot themselves in the foot by choosing to have it be broken (they or whoever
decided on the packaging/builds of efl).

> On Thu, Dec 24, 2015 at 9:04 PM Carsten Haitzler 
> wrote:
> 
> > On Thu, 24 Dec 2015 19:11:28 + Mike Blumenkrantz
> >  said:
> >
> > > As further proof of how unsuccessful this has been, here's the downstream
> > > patch that Gentoo's core repo ebuilds use:
> > >
> > >
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=422cf597b84d3553eac42dd8b1faa8257af5941f
> > >
> > > It removes the sleep entirely, making the entire thing (and all future
> > > attempts at "getting attention") a complete waste of time for everyone.
> >
> > that specifically isn't going to change anything as in my experience no
> > gentoo
> > "user" reads build output. they pastebin it and have someone else read it
> > for
> > them. so a sleep is being patched out only to "make the build faster".
> >
> > changing the "i know what i am doing" option stops the build entirely and
> > such
> > patches are not a workaround for that.
> >
> > we havent changed that option for maybe 2 years. ok - checking log. last
> > change
> > was 1.5 years ago - july 2014. so perhaps the "its not working" is a
> > result of
> > not changing it often enough? the builds settle in and then dont change?
> >
> > > On Thu, Dec 24, 2015 at 12:22 PM Mike Blumenkrantz <
> > > michael.blumenkra...@gmail.com> wrote:
> > >
> > > > After having read these mails, as well as the past mails on this topic,
> > > > I'm beginning to see a pattern.
> > > >
> > > > This option was originally implemented because a Gentoo user came into
> > #e
> > > > last year asking why something in Enlightenment didn't work (possibly
> > mouse
> > > > cursors, since the 

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove unnecessary layer set for elm_win.

[Hermet Park]

i'm sure he already asked.
 
Regards, Hermet
 
-Original Message-
From: "Daniel Juyung Seo" 
To: "Enlightenment developer list"; 
Cc: "Carsten Haitzler"; 
Sent: 2015-12-28 (월) 15:58:15
Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove 
unnecessary layer set for elm_win.
 
This code was there for years and it could impact the behavior.
I think there must be a good reason for this code but I also have a
doubt on this code.

One thing I am sure is that if someone would like to change the code
like this(been there for ages and could give an impact), it should be
discussed with the original author(in this case, Raster) first as far
as he/she is reachable. Do not just remove the code just because you
don't know why.

Of course, this could be a workaround code and needs to be removed but
anyways ask raster first. I think there must be a reason.

Thanks,
Daniel Juyung Seo (SeoZ)


On Mon, Dec 28, 2015 at 2:44 PM, Hermet  wrote:
> If it doesn't cause any critical side effects/compatibility issues, I can't 
> see any reasons to keep it in.
>
> No one expects window layer value is 50.
> But I'd rather ask why 50? why it should have layer 50?
>
> Specifically, evas_object_layer_set() API has been exposed,
> which means the layer setting is up to users, even window object can be dealt 
> with the API by users.
>
> Additionally, window object was special one so it have been deal with event 
> stuff differently.
>
>
> Regards, Hermet
>
> -Original Message-
> From: "Amitesh Singh"
> To: "Enlightenment developer list";
> Cc: "Carsten Haitzler";
> Sent: 2015-12-25 (금) 16:05:50
> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove 
> unnecessary layer set for elm_win.
>
> Hello
>
> On Dec 18, 2015 3:54 PM, "Jaehyun Cho"  wrote:
>>
>> jaehyun pushed a commit to branch master.
>>
>>
> http://git.enlightenment.org/core/elementary.git/commit/?id=a9be1d488daf74d11181909fb6c454991272fe1e
>>
>> commit a9be1d488daf74d11181909fb6c454991272fe1e
>> Author: Jaehyun Cho 
>> Date:   Fri Dec 18 19:18:51 2015 +0900
>>
>> elm_win: Remove unnecessary layer set for elm_win.
>> ---
>>  src/lib/elm_win.c  1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
>> index b1a05ae..f509f95 100644
>> --- a/src/lib/elm_win.c
>> +++ b/src/lib/elm_win.c
>> @@ -3830,7 +3830,6 @@ _elm_win_finalize_internal(Eo *obj, Elm_Win_Data
> *sd, const char *name, Elm_Win_
>> evas_object_color_set(obj, 0, 0, 0, 0);
>> evas_object_move(obj, 0, 0);
>> evas_object_resize(obj, 1, 1);
>> -   evas_object_layer_set(obj, 50);
>
> I wonder why it was removed.  As far as I know,  elm win is a fake ecore
> evas object. Basically it's just a wrapper of ecore evas and since elm win
> does not contain any object so I think it's better to put it at layer 50.
> After this change,  there could be a case when it does not receive any
> events as it might go at lowest at layer 0. This could result into some
> side effects. Please consider this.
>> evas_object_pass_events_set(obj, EINA_TRUE);
>>
>> if (type == ELM_WIN_INLINED_IMAGE)
>>
>> --
>>
>>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL and subpixel antialiasing

[Stanislav Baiduzhyi]

On Tue, Dec 29, 2015 at 1:00 AM, Carsten Haitzler  wrote:
> so thats why we have a scale factor setting in e (and elm) and this just sizes
> stuff up - not JUST fonts, but many many many things. it's the "make it bigger
> - i can't see that" option which is what people ACTUALLY want.
>
> for evas - it just gets given a bigger pixel size then by higher layers of 
> code
> that handle the scaling (actually you can set scale ON a specific object and
> evas will multiple the font size by the scale factor anyway)

Could you please clarify that with example? Having scaling factor 1.5
for example and having 12px fonts on labels for example, will evas
create a bitmap for 12px and then it will be scaled to 18px or will
that size be scaled before reaching evas and evas will create a 18px
bitmap?

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL and subpixel antialiasing

[The Rasterman]

On Tue, 29 Dec 2015 08:16:55 +0100 Stanislav Baiduzhyi
 said:

> On Tue, Dec 29, 2015 at 1:00 AM, Carsten Haitzler 
> wrote:
> > so thats why we have a scale factor setting in e (and elm) and this just
> > sizes stuff up - not JUST fonts, but many many many things. it's the "make
> > it bigger
> > - i can't see that" option which is what people ACTUALLY want.
> >
> > for evas - it just gets given a bigger pixel size then by higher layers of
> > code that handle the scaling (actually you can set scale ON a specific
> > object and evas will multiple the font size by the scale factor anyway)
> 
> Could you please clarify that with example? Having scaling factor 1.5
> for example and having 12px fonts on labels for example, will evas
> create a bitmap for 12px and then it will be scaled to 18px or will
> that size be scaled before reaching evas and evas will create a 18px
> bitmap?

the latter.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove unnecessary layer set for elm_win.

[Hermet Park]

I'm sorry but i have no idea about your point here Seoz.
I didn't guess anything here nor agree both jaehyun and amitesh.
But the code in win looked strange to me. 
 
But now, the point i want argue you here is,
just leaving those risky code without any reasons doesn't make sense to me 
either. 
In point of my view, if the code is incorrect and it disturbs improvement then 
we definitely try to improve it. 
 
 
Here the point is,  
jaehyun needs prove that patch doesn't cause any side effects. otherwise, the 
patch seems be good to efl. 
 
  
Regards, Hermet
  
-Original Message-
From: "Daniel Juyung Seo"seojuyu...@gmail.com 
To: "Carsten Haitzler"ras...@rasterman.com; "Amitesh 
Singh"singh.amit...@gmail.com; 
Cc: "Enlightenment developer 
list"enlightenment-devel@lists.sourceforge.net; 
jae_hyun@samsung.com; 
Sent: 2015-12-29 (화) 15:28:41
Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove 
unnecessary layer set for elm_win.
 
+Amitesh

Thanks raster.
Problem solved.

Daniel Juyung Seo (SeoZ)


On Tue, Dec 29, 2015 at 3:17 PM, Carsten Haitzler ras...@rasterman.com 
wrote:
 On Tue, 29 Dec 2015 15:00:40 +0900 Daniel Juyung Seo 
seojuyu...@gmail.com
 said:

 +Jaehyun

 OK let's stop guessing by ourselves and just ask Jaehyun and Raster.
 Daniel Juyung Seo (SeoZ)

 i did tell jaehyun that i have no idea why that is there and it likely 
shouldnt
 be. its too long ago as to remember why its there as it was there in the
 initial elm win code.

 On Tue, Dec 29, 2015 at 9:41 AM, Hermet Park her...@naver.com 
wrote:
  i'm sure he already asked.
 
  Regards, Hermet
 
  -Original Message-
  From: "Daniel Juyung Seo"seojuyu...@gmail.com
  To: "Enlightenment developer
  list"enlightenment-devel@lists.sourceforge.net; Cc: 
"Carsten
  Haitzler"ras...@rasterman.com; Sent: 2015-12-28 (월) 
15:58:15
  Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: 
elm_win:
  Remove unnecessary layer set for elm_win.
 
  This code was there for years and it could impact the behavior.
  I think there must be a good reason for this code but I also have 
a
  doubt on this code.
 
  One thing I am sure is that if someone would like to change the 
code
  like this(been there for ages and could give an impact), it 
should be
  discussed with the original author(in this case, Raster) first as 
far
  as he/she is reachable. Do not just remove the code just because 
you
  don't know why.
 
  Of course, this could be a workaround code and needs to be 
removed but
  anyways ask raster first. I think there must be a reason.
 
  Thanks,
  Daniel Juyung Seo (SeoZ)
 
 
  On Mon, Dec 28, 2015 at 2:44 PM, Hermet her...@naver.com 
wrote:
  If it doesn't cause any critical side effects/compatibility 
issues, I
  can't see any reasons to keep it in.
 
  No one expects window layer value is 50.
  But I'd rather ask why 50? why it should have layer 50?
 
  Specifically, evas_object_layer_set() API has been exposed,
  which means the layer setting is up to users, even window 
object can be
  dealt with the API by users.
 
  Additionally, window object was special one so it have been 
deal with
  event stuff differently.
 
 
  Regards, Hermet
 
  -Original Message-
  From: "Amitesh Singh"singh.amit...@gmail.com
  To: "Enlightenment developer
  list"enlightenment-devel@lists.sourceforge.net; Cc: 
"Carsten
  Haitzler"ras...@rasterman.com; Sent: 2015-12-25 (금) 
16:05:50
  Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: 
elm_win:
  Remove unnecessary layer set for elm_win.
 
  Hello
 
  On Dec 18, 2015 3:54 PM, "Jaehyun Cho" 
jae_hyun@samsung.com wrote:
 
  jaehyun pushed a commit to branch master.
 
 
  
http://git.enlightenment.org/core/elementary.git/commit/?id=a9be1d488daf74d11181909fb6c454991272fe1e
 
  commit a9be1d488daf74d11181909fb6c454991272fe1e
  Author: Jaehyun Cho jae_hyun@samsung.com
  Date:   Fri Dec 18 19:18:51 2015 +0900
 
  elm_win: Remove unnecessary layer set for elm_win.
  ---
   src/lib/elm_win.c  1 -
   1 file changed, 1 deletion(-)
 
  diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
  index b1a05ae..f509f95 100644
  --- a/src/lib/elm_win.c
  +++ b/src/lib/elm_win.c
  @@ -3830,7 +3830,6 @@ _elm_win_finalize_internal(Eo *obj, 
Elm_Win_Data
  *sd, const char *name, Elm_Win_
  evas_object_color_set(obj, 0, 0, 0, 0);
  evas_object_move(obj, 0, 0);
  evas_object_resize(obj, 1, 1);
  -   evas_object_layer_set(obj, 50);
 
  I wonder why it was removed.  As far as I know,  elm win is a 
fake ecore
  evas object. Basically it's just a wrapper of ecore evas and 
since elm win
  does not contain any object so I think it's better to put it 
at layer 50.
  After this change,  there could be a case when it does not 
receive any
  events as it might go at lowest at layer 0. This could result 
into some
  side effects. Please consider this.
  evas_object_pass_events_set(obj, EINA_TRUE);
 
  if (type == ELM_WIN_INLINED_IMAGE)
 
  --
 
 
  

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win: Remove unnecessary layer set for elm_win.

[Daniel Juyung Seo]

+Amitesh

Thanks raster.
Problem solved.

Daniel Juyung Seo (SeoZ)


On Tue, Dec 29, 2015 at 3:17 PM, Carsten Haitzler  wrote:
> On Tue, 29 Dec 2015 15:00:40 +0900 Daniel Juyung Seo 
> said:
>
>> +Jaehyun
>>
>> OK let's stop guessing by ourselves and just ask Jaehyun and Raster.
>> Daniel Juyung Seo (SeoZ)
>
> i did tell jaehyun that i have no idea why that is there and it likely 
> shouldnt
> be. its too long ago as to remember why its there as it was there in the
> initial elm win code.
>
>> On Tue, Dec 29, 2015 at 9:41 AM, Hermet Park  wrote:
>> > i'm sure he already asked.
>> >
>> > Regards, Hermet
>> >
>> > -Original Message-
>> > From: "Daniel Juyung Seo"
>> > To: "Enlightenment developer
>> > list"; Cc: "Carsten
>> > Haitzler"; Sent: 2015-12-28 (월) 15:58:15
>> > Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win:
>> > Remove unnecessary layer set for elm_win.
>> >
>> > This code was there for years and it could impact the behavior.
>> > I think there must be a good reason for this code but I also have a
>> > doubt on this code.
>> >
>> > One thing I am sure is that if someone would like to change the code
>> > like this(been there for ages and could give an impact), it should be
>> > discussed with the original author(in this case, Raster) first as far
>> > as he/she is reachable. Do not just remove the code just because you
>> > don't know why.
>> >
>> > Of course, this could be a workaround code and needs to be removed but
>> > anyways ask raster first. I think there must be a reason.
>> >
>> > Thanks,
>> > Daniel Juyung Seo (SeoZ)
>> >
>> >
>> > On Mon, Dec 28, 2015 at 2:44 PM, Hermet  wrote:
>> >> If it doesn't cause any critical side effects/compatibility issues, I
>> >> can't see any reasons to keep it in.
>> >>
>> >> No one expects window layer value is 50.
>> >> But I'd rather ask why 50? why it should have layer 50?
>> >>
>> >> Specifically, evas_object_layer_set() API has been exposed,
>> >> which means the layer setting is up to users, even window object can be
>> >> dealt with the API by users.
>> >>
>> >> Additionally, window object was special one so it have been deal with
>> >> event stuff differently.
>> >>
>> >>
>> >> Regards, Hermet
>> >>
>> >> -Original Message-
>> >> From: "Amitesh Singh"
>> >> To: "Enlightenment developer
>> >> list"; Cc: "Carsten
>> >> Haitzler"; Sent: 2015-12-25 (금) 16:05:50
>> >> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_win:
>> >> Remove unnecessary layer set for elm_win.
>> >>
>> >> Hello
>> >>
>> >> On Dec 18, 2015 3:54 PM, "Jaehyun Cho"  wrote:
>> >>>
>> >>> jaehyun pushed a commit to branch master.
>> >>>
>> >>>
>> >> http://git.enlightenment.org/core/elementary.git/commit/?id=a9be1d488daf74d11181909fb6c454991272fe1e
>> >>>
>> >>> commit a9be1d488daf74d11181909fb6c454991272fe1e
>> >>> Author: Jaehyun Cho 
>> >>> Date:   Fri Dec 18 19:18:51 2015 +0900
>> >>>
>> >>> elm_win: Remove unnecessary layer set for elm_win.
>> >>> ---
>> >>>  src/lib/elm_win.c  1 -
>> >>>  1 file changed, 1 deletion(-)
>> >>>
>> >>> diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
>> >>> index b1a05ae..f509f95 100644
>> >>> --- a/src/lib/elm_win.c
>> >>> +++ b/src/lib/elm_win.c
>> >>> @@ -3830,7 +3830,6 @@ _elm_win_finalize_internal(Eo *obj, Elm_Win_Data
>> >> *sd, const char *name, Elm_Win_
>> >>> evas_object_color_set(obj, 0, 0, 0, 0);
>> >>> evas_object_move(obj, 0, 0);
>> >>> evas_object_resize(obj, 1, 1);
>> >>> -   evas_object_layer_set(obj, 50);
>> >>
>> >> I wonder why it was removed.  As far as I know,  elm win is a fake ecore
>> >> evas object. Basically it's just a wrapper of ecore evas and since elm win
>> >> does not contain any object so I think it's better to put it at layer 50.
>> >> After this change,  there could be a case when it does not receive any
>> >> events as it might go at lowest at layer 0. This could result into some
>> >> side effects. Please consider this.
>> >>> evas_object_pass_events_set(obj, EINA_TRUE);
>> >>>
>> >>> if (type == ELM_WIN_INLINED_IMAGE)
>> >>>
>> >>> --
>> >>>
>> >>>
>> >> --
>> >> ___
>> >> enlightenment-devel mailing list
>> >> enlightenment-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> >> --
>> >> ___
>> >> enlightenment-devel mailing list
>> >> enlightenment-devel@lists.sourceforge.net
>> >>