GNOME Bugzilla – Bug 502644
Option to turn off black outlines in desktop environment.
Last modified: 2020-11-07 12:36:50 UTC
Hello. I have opened this request, because i found several good rationals for subject. Minimize animation maybe becomes better somewhere but this black borders always will look very ugly. It also concerns switchers (Alt+Tab; Alt+Ctrl+Tab) when appears border at that element which is chosen at current moment. Really this borders is a big blot on beautiful face of GNOME. There's a lot of people which dislike the minimize effect but find it useful to see the window content during move, because wareframe is look not very pretty (about Gconf key "reduce_resources"). There's a lot people whom don't like black borders of windows or areas at switch Alt+Tab or Alt+Ctrl+Tab correspondingly. Why we should look at these ugly borders, when we know what will happen, we have window of switcher, after all... And on http://bugzilla.gnome.org/show_bug.cgi?id=166080 branch a man told following "...however, when I click on the minimize I already know what happened and is going on to the window. Without the effect gnome is cleaner and metacity is also much more lean and clean." I well understand you, why you don't want micromanage every effect (increase complexity of code). But you might provide Gconf key allowing to turn off these unfortunate black lines everywhere in desktop environment. This thing will appreciate those users who doesn't matter as look their favorite GNOME... in other words most of people.
P.S. Sorry for my really bad English, and I hope, that you have understood me how I wanted
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 92867 ***
I don't told about disabling animation. I told about turning off of black borders, when window is minimizing AND turning off of black borders of window when using Window Switcher. In other words I told about option to only turn off black borders everywhere in Gnome. I'll repeat. These ugly lines is a big blot on nice face of desktop environment.
In other words you want a setting to turn off both wireframe alt-Tab AND wireframe minimise. But wireframe alt-Tab can already be toggled using reduced_resources, so I think Elijah was correct in making this a duplicate of bug 92867. Am I misunderstanding?
(In reply to comment #4) > ... so I think Elijah was correct in making this a duplicate of > bug 92867. Am I misunderstanding? Reduced_resources turn off also useful options, i.e. useful (and just nice) to see the window content during move. Is it possible to include deleting uglies borders in Gnome tree code? I personally can patch source, but downloading this code from Internet is very expensive and long for me (I can use only GPRS-connection). However I can to try download source and in the upshot patch them, but for another people this is very hard problem (many of them are not programmers). I think that majority of people agrees with me: code for better improvement of appearance of Gnome should be natively in source... Many of people also as I can use free software only from e-shops (ordering CD's/DVD) or from particularized magazines, but it is there precompiled. We install distro with Gnome and look at these unfortunate black wireframes and nothing do with them... These ugly lines is very bad for us, if we turn on Reduced_resources then we look wireframe of window by draging them... and it is even more worse...
(In reply to comment #5) > (In reply to comment #4) > > ... so I think Elijah was correct in making this a duplicate of > > bug 92867. Am I misunderstanding? > > Reduced_resources turn off also useful options, i.e. useful (and just nice) to > see the window content during move. Is it possible to include deleting uglies > borders in Gnome tree code? Okay, so there are three cases where we show wireframes ("borders") at present, if I'm not mistaken: 1) Minimise and unminimise. 2) Dragging. 3) Alt-tab and alt-escape. Option 1 is covered already by bug 92867, so we don't need to talk about it any more here. Options 2 and 3, as of this moment, are both turned on and off together by reduced_resources. You are asking, if I understand correctly, to decouple this, giving us a way to turn off borders for 3 but not for 2. A couple of years ago someone wanted to decouple 1 and 2, which led to bug 166080 (which you yourself cited). Can you, then, explain to me how the reasons given for marking that bug WONTFIX don't apply to this request? In particular, have you read http://ometer.com/features.html and can you give us a rationale for your new feature accordingly? > I personally can patch source, but downloading this code from Internet is very > expensive and long for me (I can use only GPRS-connection). However I can to > try download source and in the upshot patch them, but for another people this > is very hard problem (many of them are not programmers). I think that majority > of people agrees with me: code for better improvement of appearance of Gnome > should be natively in source... Many of people also as I can use free software > only from e-shops (ordering CD's/DVD) or from particularized magazines, but it > is there precompiled. We install distro with Gnome and look at these > unfortunate black wireframes and nothing do with them... These ugly lines is > very bad for us, if we turn on Reduced_resources then we look wireframe of > window by draging them... and it is even more worse... This is rather irrelevant. Obviously most people think that (all other things being equal) code that makes GNOME look nice should be in trunk. But you have not shown a very convincing case that the changes you are suggesting do in fact make GNOME sufficiently nicer-looking in the estimation of a sufficiently large number of people that it's worth actually maintaining the new code. And the argument * I don't like this and nor do my friends * It is hard for some people who don't like it to patch the software * Therefore we should make changes to working code based only on my assertion. is one which we could apply to just about any suggested new feature. Separately, will having a working compositor solve your problem?
The compositor is the key. The right fix for this is to use a non-ugly effect. The fix for "this effect sucks" is not "have a way to turn the effect off," it's "fix the effect" So, we need volunteers to work on fixing it.
*** Bug 463395 has been marked as a duplicate of this bug. ***
I want to repeat again: With "reduced_resources" on, when you drag a window title-bar and move the window, the system still consume some percentage of CPU. However, in Windows XP, if you set the window contents not to be shown, the CPU usage is very low when dragging and moving a window.
(In reply to comment #6) Note i talk about of version, which I'm using in present 2.18.1 >You are asking, if I understand correctly, to decouple this, giving us a way to turn off borders for 3 but not for 2. >But wireframe alt-Tab can already be toggled using reduced_resources I told not about it. I forgot to say about it in preceding comment. As far as is known that there aren't a ways of turning off of wireframe of Alt-Tab. I want to detail your words. Are you talking about dividing into parts of setting reduce_resources?
(In reply to comment #6) >Okay, so there are three cases where we show wireframes ("borders") at present, >if I'm not mistaken: >1) Minimise and unminimise. >2) Dragging. >3) Alt-tab and alt-escape. >Options 2 and 3, as of this moment, are both turned on and off together by >reduced_resources. You are asking, if I understand correctly, to decouple this, >giving us a way to turn off borders for 3 but not for 2. Black borders show up in process of minimization, but not else, but it doesn't matter. I want to have an chance to turn off these borders in all cases, having said earlier, (sic) of one option, but it isn't so, as you may have thought. I told earlier about that black borders in process of moving of windows is bad thing. There is a radical solution to delete this unnecessary code from tree of development of GNOME, but you won't want to do this, I understand the reasons. Supposing it, I beforehand requested only key in the Gconf.
(In reply to comment #6) (next part) >In particular, >have you read http://ometer.com/features.html and can you give us a rationale >for your new feature accordingly? Thanks for the links, but I have already read this note of Havoc. Return to the question. Isn't rationale, what GNOME will look cleaner and neatly? Don't talk that it is only my whim. Designers of seriously software is using such effect only for secondary purposes (e.g. for helping in setting of interface of program). But minimization, Alt-Tab is frequently used functions of desktop environment. Absolutely everyone user begins yourself estimation with look that it is seeing, and then of the rest. Are you really believing that blackness is very pretty? If this is so then... excuse me. P.S. Sorry for my dividing post. I have trouble with posting big comments...
(In reply to comment #7) > The compositor is the key. The right fix for this is to use a non-ugly effect. > The fix for "this effect sucks" is not "have a way to turn the effect off," > it's "fix the effect" > I agree with you, compositor is the key. And is it meaning, what the metacity never will to improve then? Say me please how many years you "fix the effect"? This effect is never will pretty, IMO. May be already may to give chance to users yourself fix this effect (e.g using corresponding Gconf key)? > So, we need volunteers to work on fixing it. > I think that this effect won't look better. See my posts above...
The gconf key is not a fix, it's at best a workaround that keeps anyone from working on the fix.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.