On Thu, 12 Jan 2017 20:02:35 +0000 Mike Blumenkrantz <michael.blumenkra...@gmail.com> said:
> The crux of your argument seems to be "you didn't word your commit log > perfectly so nothing you say now matters", to which I would suggest that you didn't word your commit log to indicate there was any alternative at all. if you revert something make sure your explanation is complete enough. maybe you don't think it's necessary to explain a revert fully, but i do. continued below... > the content of said commit--as well as multiple clarifying mails that I've > sent on the subject--should be sufficient to prove that this is not the > case. I make mistakes just like anyone else, but I'm trying to focus on the > functional changes and not simply nitpick at text semantics. and focusing on function changes, adding a data item simply adds work and doesn't address what your commit log was saying is the justification for a revert. adding this data item then allows what your commit log clearly does not want to allow. so you contradict yourself. you do not expect me to focus on this when we're down to playing revert wars? but let's say you want to allow it - having a data item to enable it is no more secure or better than not having one and only creates more work for a theme. > Your claim that this is a pointless extra hurdle is problematic to me for > the same reason that you cited previously: desklocks never used > transparency prior to this. As a result, consider that it's possible there > are themes which have unintentional transparency which would never have > been revealed due to the presence of opaque rectangles behind the theme > objects. there wouldn't be any. it'd be using transparency on top of black which is pretty useless. in fact prior to e18 it'd actually create visual garbage as the window for desklock would not have had alpha at all and would have thus rendered on top of garbage memory and thus have been a bug. the vast majority of themes that might exist (and now lo longer work) would have been pre e18. find me one where this is an issue. > Again, regardless of what you may have read in an incompletely-worded > commit message, this is not supposed to prevent people from making lock > screens which use or contain transparency, it's so that anyone making a > theme has to knowingly opt-in to having transparency, preventing > unintentional footguns. find me that example. where someone relied on transparency for a desklock theme (transparency on top of black... or on garbage in e17 and below) > I've stated my position as clearly as is possible, and there is nothing to > gain from continuing to argue about it. If you really feel this strongly > about the issue on a technical level, feel free to revert all my related > commits since they no longer have any functional value. > > On Wed, Jan 11, 2017 at 4:04 PM Carsten Haitzler <ras...@rasterman.com> > wrote: > > > On Wed, 11 Jan 2017 19:05:31 +0000 Mike Blumenkrantz > > <michael.blumenkra...@gmail.com> said: > > > > > Instead of looking at ways to prove me wrong, perhaps it might be better > > to > > > see what I've done and determine whether it fits the needs you have > > > described. > > > > > > If you want transparency and a blur filter, does what I've done prevent > > > that? No, it does not. If you define the data.item in your theme, you can > > > have transparency for as long as you want since I decided not to put a > > > fixed timeout on show animations which would force opacity. > > > > > > If a theme wants to be translucent, it can do this. The only requirement > > is > > > that the theme author has to knowingly decide to do this and then set a > > > flag which informs the compositor that this is intentional and not by > > > accident. > > > > > > "By default, however, this will be opaque" meant exactly what I said: > > > desklocks will be opaque by default and then it is up to the theme > > designer > > > to determine whether they need transparency. > > > > you reverted on the argument that desklock is to be opaque by definition. > > let > > me directly quote you word for word from your log: > > > > revert desklock block_rect opacity change > > > > block rects are for blocking view of the desktop. they exist for > > security, > > preventing the desktop from being visible if a transparent lockscreen > > is > > in use. > > > > also split block_rects into per-zone rects for later use > > > > so i repeat - your argument for a revert is invalid. there is no need to > > add > > data items at all to allow for transparency. just simply start using it. > > desklocks never used transparency because it had absolutely no use or > > value as > > it was always on top of black and transparency was thus pointless. you add > > such > > data items when you may need to enable something that earlier themes > > couldn't > > do or support and now you can/do support it and the theme advertises that > > via > > the item. in this case there is no point. it's a pointless extra hurdle to > > jump > > over that just raises the bar of effort that tiny little bit. additionally > > your > > own words totally contradict your follow-up here. > > > > so first, perhaps, you should word your reverts properly, secondly you > > should > > remember your own log messages if you want to pick and argument. > > > > > On Tue, Jan 10, 2017 at 6:36 PM Carsten Haitzler <ras...@rasterman.com> > > > wrote: > > > > > > > On Tue, 10 Jan 2017 19:22:46 +0000 Mike Blumenkrantz > > > > <michael.blumenkra...@gmail.com> said: > > > > > > > > > I already added functionality for this in the theme by setting > > > > > 'show_signal' as a data.item when transparency is desired. By > > default, > > > > > however, this will be opaque. > > > > > > > > your entire argument is invalid. If a theme wants to desklock by using > > > > transparency and eg a huge blur filter - then WHY NOT? if your > > argument is > > > > "well security" yet the theme can just never emit the show done signal > > ... > > > > your > > > > argument is invalid. > > > > > > > > if a theme wishes to be translucent - let it be. let users complain to > > the > > > > theme author that it breaks their privacy. > > > > > > > > > I plan to revert this later in the week if you don't get to it before > > > > then. > > > > > > > > > > On Sat, Jan 7, 2017 at 12:23 AM Carsten Haitzler < > > ras...@rasterman.com> > > > > > wrote: > > > > > > > > > > > raster pushed a commit to branch master. > > > > > > > > > > > > > > > > > > > > > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=0b0b6e6fd9b53e717037e404445716a67cbfe15e > > > > > > > > > > > > commit 0b0b6e6fd9b53e717037e404445716a67cbfe15e > > > > > > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> > > > > > > Date: Sat Jan 7 14:19:18 2017 +0900 > > > > > > > > > > > > desklock - make blocker transparent again - a theme issue not > > code > > > > > > > > > > > > if "theme is transparent" and this is an issue - dont use that > > > > theme. > > > > > > very simple. the theme for a desk LOCK should be solid. it > > should > > > > hide > > > > > > what is underneath. that is the POINT is can have transition > > > > effects > > > > > > and that is why we shouldnt hide what is under it to allow > > that to > > > > > > happen otherwise if you do have such an effect (eg a fade in) > > you > > > > just > > > > > > get a black screen instantly on ctrl+alt+l for lock for example > > > > THEN > > > > > > it fades in which is not how things SHOULD look. > > > > > > > > > > > > yes - there is an issue on locking on screen lock where you > > get an > > > > > > initial fade in effect for example as desklock is shown LATER > > like > > > > > > when screen "unsuspends" from blank rather thanbefore this > > point. > > > > that > > > > > > is orthogonal. this rect should block events... not pixels. > > don't > > > > use > > > > > > non-solid themes or images if you dont want to see through... > > > > > > --- > > > > > > src/bin/e_desklock.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/src/bin/e_desklock.c b/src/bin/e_desklock.c > > > > > > index 8ec9234..664b921 100644 > > > > > > --- a/src/bin/e_desklock.c > > > > > > +++ b/src/bin/e_desklock.c > > > > > > @@ -300,7 +300,7 @@ e_desklock_show(Eina_Bool suspend) > > > > > > } > > > > > > o = evas_object_rectangle_add(e_comp->evas); > > > > > > block_rects[zone->num] = o; > > > > > > - evas_object_color_set(o, 0, 0, 0, 255); > > > > > > + evas_object_color_set(o, 0, 0, 0, 0); > > > > > > evas_object_geometry_set(o, zone->x, zone->y, zone->w, > > > > zone->h); > > > > > > evas_object_layer_set(o, E_LAYER_DESKLOCK); > > > > > > if (!block_zone[zone->num]) > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > Developer Access Program for Intel Xeon Phi Processors > > > > > Access to Intel Xeon Phi processor-based developer platforms. > > > > > With one year of Intel Parallel Studio XE. > > > > > Training and support from Colfax. > > > > > Order your platform today. http://sdm.link/xeonphi > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > 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 ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
