https://bugs.kde.org/show_bug.cgi?id=442675
--- Comment #6 from doncb...@gmail.com --- (In reply to Michail Vourlakos from comment #4) Upon further consideration, I believe a more traditional option may be present, but it would require drastic changes to how Latte currently allows configuration. I have added a screenshot to demonstrate this. The dark gray rectangle represents available space on the dock and the light gray rectangle represents the drawn dock. Green represents padding or 'thickness,' perhaps. With the new method there are "border margins" and "border padding." "A" shows small border margins, though I am unsure if zero should be the size of the items or be around 50% of their size. Essentially, "A" has all corners (at least) inside the dock's space. "B" shows 1x border margins and content is always inside, regardless of dock roundness. "C" shows "border padding" which adds space around the dock's rectangle. I see this as an extension of the Thickness control where it affects both the sides and the top and bottom. Or, it could have both top/bottom and left/right controls. What limitations do you see to this method over the present one? i.e. do you think this can support all current use cases, even if it might be less user-friendly? > My initial thoughts were to let all indicators to set two options: > a) Painted Area Thickness Margin (the painted area is considered centered > always so the thickness margin is used both for bottom and top margins) > b) Painted Area Roundness (the painted area is considered always a > centered rectangle but the indicator can specify the painted area roundness) > > Benefits: > - with [a+b] Latte could possibly define what is the best positioning of > panel background in order to feel right and it could also use some clipping > method > - [a+b] can be user-specified if that is what the indicator creator wants > at per dock/panel basis > - [a+b] could also be indicator auto-adjusted based on each indicators > settings and requirements > > On the other hand, the calculations for [a+b] could break in many ways so > this can not be a v0.10.x branch solution. I am not sure I follow this. Does it look anything like the diagram I uploaded? I cannot quite imagine where this would break. Unless the user was pursuing a style like in No. 4 of the previous screenshot. > What can be done at this point is to introduce in the Indicators API (at > v0.10.3 or v0.10.4) a new option probably called: "Corner Margin" that could > take values between 0 - 100% . Each Indicator will take the responsibility > to provide it or not for the user to alter. Latte and Plasma indicators > could possibly introduce it after the Indicators API has been extended by > default. That option default value will be 100% and that would mean the > current behavior, 50% would mean half distance from background edge and 0% > would mean almost touching it. This satisfies my use case. With respect to the proposal in the new screenshot, I say also consider negative ~25-50% as the minimum, like in the previous screenshot's No. 4. Something like allowing the end of a floating dock to be centered under an icon the edge of a list of tasks. -- You are receiving this mail because: You are watching all bug changes.
