Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#100 closed enhancement (wontfix)

TWEAKS - shifted selected state for button frames

Reported by: Mikhail Malyshev Owned by:
Priority: normal Milestone:
Component: Area.mui Version:
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:


Since we have killed the buggy xen style frame with shifting…

Add a TWEAKS option, shift selected button TEXT and IMAGES option

This should not be a problem, since you only have to add a case condition when the flag is set, to draw the contents of the button in pressed/selected state shifted X+1, Y+1

Since this is more of interest for double pxl border frames, there is no problem to shift the contents even if we need to overwrite 1 pxl of internal frame.

For single pxl frames, the contents of the button can be cut by 1 pxl in order to fit the frame, and in most cases this pxl lines are empty anyway.

A good example of how it works is ReqAttack.

Hopefully MUI internally is not limited and this can be implemented correctly (unlike the original, where the mouse area was shifted)

Change History (2)

comment:1 Changed 6 years ago by Thore Böckelmann

Component: undefinedArea.mui
Priority: undecidednormal
Resolution: wontfix
Status: newclosed

There is no need to push this topic any further. You have been told in #64 that you are very close to a ban. Rising the topic again gets you another step closer.

I will not (re)implement something that cannot work within MUI's way to handle things. Like it, hate it or leave it. This kind of change needs to work with any frame and not just for a single one. A shift of the frame and the object's contents as you suggest it would result in forcing MUI to draw outside the object's area which can cause undesired artifacts to remain under certain conditions, because the visual area of neighboured object is overdrawn. Honestly, you have no idea how MUI really works internally and you should not make any assumptions about that. The spacing between objects is not fixed but can be modified by any application to zero, even if the global default spacing would leave enough space for a possible shift. Things must work correct in every situation, not just in most situations.
You have been told why the coordinate shift done by MUI 3.8 was a bug and why it has been fixed. Accept this decision or stay with MUI 3.8. I will not argue about this anymore. And finally a possible "Tweaks" page is no place to reintroduce bugs, no matter how "cool" they may look. Bugs are bugs and there is no need to keep them. My time is too valuable to spend hours on looking at pressed buttons and watch how their imagery is shifted compared to the unpressed state and notice how "cool" this might look. If you want to do that then do it with MUI 3.8.

There is no official standard named "XEN" which defines how buttons according to this "standard" are required to behave. Furthermore there is no frame setting in MUI named "XEN" which could be bound to behave compatible to this non-existing standard.

To make it short: either stick with MUI 3.8 if you cannot live without this buggy effect or accept the change we made. But in any case stop discussing this topic any further.

comment:2 Changed 6 years ago by Mikhail Malyshev

You have misunderstood it again. We are not talking about implementing bugs.
We talking about a new feature. How it can be implemented is another thing.
And not many know how MUI works internally, its a big secret.
You are a good coder, so it should be a doodle to do for you if you decide it someday.

eg. When a flag is set, all text and image button frames can get an extra pxl of internal area if required, then the shifting effect will not corrupt anything.
We are not shifting frames, we are shifting the contents (text or image).

PS: XEN was one of default preset styles in MUI and some extra images and clssses created by a friend of Stuntz

Note: See TracTickets for help on using tickets.