Inverting Buttons

[stam]

Indeed, Jacque and Stam both; and thank you for your suggestions.

However I should like to alter the colours of buttons and their icons in a
NON-DESTRUCTIVE fashion, so that "with the flick of a switch" on could
flip back and forth between 2 colour states.

And, when push comes to shove, all I am really looking
for is a way to INVERT all colours of an object.

Not sure i understand what non-destructive alteration of colours means... do you mean you want to be able to toggle the highlighted state instead of clicking?

If so, again universal button will help you out, just set it's isToggle property to true (in code of via property inspector)'
If not, please explain...

Or do you mean you want to treat a button as an image and invert it's RGB values? (in which case why not just use a graphic as a button and do that?)

[stam]

As an example, below is a universal button and 2 variants below.
The button at the top is the 'normal' state
The one on the bottom left is just toggled (ie each time you click it once, it will switch between normal and highlighted state and stay that way until next click)
The one on the bottom right is toggled and also set to a different icon for its hilighted state (filled instead of outline).

The colouring is just the default hiliteColor, but you could select this using the tinyColor library if you wanted something more specific, or use Bernd's code to invert the background colour.
Notably, the 'normal' background colour is unaffected (perhaps that's what you mean by 'non-destructive' Richmond?) and all you do is set the hiliteColor.

[richmond62]

By 'non-destructive' I mean NOT replacing images or buttons, but using inks, overlays or somesuch.

[stam]

By 'non-destructive' I mean NOT replacing images or buttons, but using inks, overlays or somesuch.

This is exactly what the hilighting does in universal button (the bottom left image above).

U certainly can “invert the colour” by estimating the inverse of the background colour in a mouseDown handler and assigning this to the universal button’s hiliteColor. But automatically assigning an inverse colour can produce results that may be undesirable and a predefined hiliteColor would probably work better.

And for the record, changing icons in universal button as on the other version (bottom right) is “non-destructive” in the sense that both icons are set in the widget - you don’t “destroy” anything but swap the two predefined widget states.

Have you tried this and if so what exactly doesn’t work for you? Or is the objection a theoretical one?



However, although I may be very wrong, I get the sense this isn’t what you want to hear.
I’m getting the sense you don’t want to use vector icons for your buttons but some arbitrary bitmap and are hoping there’s a magic way to both invert the state of a standard button and the colours of the bitmap you are using for an icon but without actually working on inverting the RBG values of either, and hence trying to explore inks and overlays that can automagically do this for you.

If you want to do what achieve what I speculate above you may be better served by using a graphic that behaves as a button, and overt it’s RGB values to highlight it. But that seems like a huge amount of work for what is likely to be little value.

Is a mental exercise for the sake of it or actually something needed for a project?

[richmond62]

Most of my exercises are "mental".

I want to invert the revMenuBar buttons.

[stam]

I want to invert the revMenuBar buttons.

That's a non-trivial task which really wasn't apparent from your OP or subsequent posts...

in the msgBox,

Code: Select all

put the filename of stack "revMenuBar"

resolves to /Applications/LiveCode 9.6.6.app/Contents/Tools/Toolset/palettes/menubar/revmenubar.livecodescript on MacOS.

A quick look at this suggests you may need to do quite a lot of work for this to happen as it's a script-only stack with over 3200 lines of code.

If you have that expertise that should be doable
OTOH it might just be easier to design a toolbar from scratch that does what you want... you can even draw upon the png and svg toolbar images in /Applications/LiveCode 9.6.6.app/Contents/Tools/Toolset/palettes/menubar/ to make it look identical.

I very much doubt there is an automagical solution to your query though...

[FourthWorld]

Algorithmic inversion was a popular way to indicate highlights on monochrome systems, such as the Mac models available when HyperCard premiered.

Monochrome displays allow a pixel to be only black or white, so inverting one to the other is straightforward.

Full-color display systems use more complex information to determine a pixel's color, most commonly using three components, red, green and blue.

While inversion on a monochrome system simply inverts the on to off or vice versa, what should inversion do with three values, each a range from 0 to 255?

The XOR ink in LC does a precise algorithmic inversion, turning black pixels white, white pixels black, and values in between to their opposite corollary within the given range.

But you may have noticed that since the advent of color systems few if any professional software uses simple inversion to render a "down" state. When you consider the effect of flipping each of the RGB components to their XOR value and then combining them to render the color, the unattractiveness of that approach becomes clear. You can see this most easily by using an XOR ink on any full-color object.

Skuemorphic inversion is creating the illusion of a 3D object with bevels, shading, and other effects to make an object appear physically inverted in its position on the Z axis, away from the user, such as one sees when pressing an physical button on devices in the real world. That usually requires human judgement to create the illusion, and when done algorithmically it involves several steps.

Another way to indicate "down" state is to change the background color of an object when it's pressed. LC supports this easily enough with the backgroundColor property, though of course if the background becomes too dark you may also want to change the foreColor of the object to something lighter during the "down" state to maintain readability.

There are others ways to indicate "down" state to the user, but the main point here is that simply flipping pixel components such as with an ink effect probably can't produce a satisfying result on modern RGB systems.

[richmond62]

Re the revMenuBar stack:

as it's a script-only stack

then why, forbye, when one has a look at the revMenuBar stack in the Application Overview stack does it show
images and buttons that CAN be modified at least for the time the IDE is open?
-

[jacque]

That image looks like the toolbar, not the menubar.

[richmond62]

That image looks like the toolbar, not the menubar.

But it isn't, and I cannot understand why this:

Code: Select all

set the colorOverlay["color"] of control "Inspector" of card id 1002 of stack "revMenuBar" to 255,255,255
         set the colorOverlay["opacity"] of control "Inspector" of card id 1002 of stack "revMenuBar" to 255

does not work, when, if the button is copied onto a new stack it does work.

[jacque]

The menubar has no images or icons. The toolbar does (we're not talking about the tool palette at the side of the screen.) On non-Mac machines the two are combined, on Macs the menubar is moved into the system menu.

If you see a File button then you're looking at the menubar.

[FourthWorld]

The menubar has no images or icons. The toolbar does (we're not talking about the tool palette at the side of the screen.) On non-Mac machines the two are combined, on Macs the menubar is moved into the system menu.

If you see a File button then you're looking at the menubar.

Are they not the same stack?

[richmond62]

Obviously I should stop believing in what I see:
-

[jacque]

Are they not the same stack?

I've always thought they were different but I'm always on a Mac. Now that I'm at the computer I see they are the same, so ignore me.