Color rules and native style Action buttons

[tashasummers]

Color rules won't change the background of a native style action button. The same rule will work on a classic style action button.

At NSLS2 we have example of these in pages that were created with 3.1.6 and the action button style defaults to native when we run these pages in 3.2.x. Maybe the default style could be set to classic?

[kasemir]

Hmm, problem. The 'native' button doesn't always support changes to the background color. Depends on the platform (Windows, OS X, Linux) because it's the system-specific native button. On the other hand, the Native button tends to look more 'natural' for the respective OS. It's also the one that would work better via the webopi. So I think that's why it was overall made the default.

Maybe one solution would be to make the 'default' button style a preference setting, so your site could select 'classic' as the default?

[berryma4]

I believe you can do this with the "Schema OPI", which is in CSS Applications->Display->BOY->OPI Editor. Just put your button as you like the defaults in this opi, thhen it will be the default for future screens.

Thank you! Eric

On Wed, Mar 5, 2014 at 9:41 PM, kasemir notifications@github.com wrote:

Hmm, problem. The 'native' button doesn't always support changes to the background color. Depends on the platform (Windows, OS X, Linux) because it's the system-specific native button. On the other hand, the Native button tends to look more 'natural' for the respective OS. It's also the one that would work better via the webopi. So I think that's why it was overall made the default.

Maybe one solution would be to make the 'default' button style a preference setting, so your site could select 'classic' as the default?

Reply to this email directly or view it on GitHubhttps://github.com/ControlSystemStudio/cs-studio/issues/413#issuecomment-36819483 .

[kasemir]

Correct for future screens, but won't affect loading existing screens.

For existing screens, there are two cases: 'current' existing screens which use the one 'button' widget and specify 'native (=SWT)' or 'classic (=Draw2d)' - You get what the *.opi requests.

Older existing screens that use the very old 'button', or medium-aged screens from the time when there were 2 different button widgets: They're translated into the new button, and that's where the logic for deciding if it should turn into 'native' or 'classic' could be modified.

[berryma4]

Maybe it makes sense to have an overall native or classic preference option? We probably should not allow mixing the two.

On Thu, Mar 6, 2014 at 10:23 AM, kasemir notifications@github.com wrote:

Correct for future screens, but won't affect loading existing screens.

For existing screens, there are two cases: 'current' existing screens which use the one 'button' widget and specify 'native (=SWT)' or 'classic (=Draw2d)' - You get what the *.opi requests.

Older existing screens that use the very old 'button', or medium-aged screens from the time when there were 2 different button widgets: They're translated into the new button, and that's where the logic for deciding if it should turn into 'native' or 'classic' could be modified.

Reply to this email directly or view it on GitHubhttps://github.com/ControlSystemStudio/cs-studio/issues/413#issuecomment-36898363 .

[mdavidsaver]

Maybe it makes sense to have an overall native or classic preference option? We probably should not allow mixing the two.

I would be in favor of this. The Native widget types have caused only confusion/problems for our users.

[kasemir]

The native widgets offer much better performance for the webopi, they support tabbing, "assistive" technologies and whatever else the OS offers for their widgets out of the box. But they may not allow background color changes. That's why there was a need for both.

[berryma4]

So, this sounds like an overall option would be best. RAP people would choose native, RCP people classic.

On Fri, Mar 7, 2014 at 11:32 AM, kasemir notifications@github.com wrote:

The native widgets offer much better performance for the webopi, they support tabbing, "assistive" technologies and whatever else the OS offers for their widgets out of the box. But they may not allow background color changes. That's why there was a need for both.

Reply to this email directly or view it on GitHubhttps://github.com/ControlSystemStudio/cs-studio/issues/413#issuecomment-37040820 .

[kasemir]

The code in ActionButtonModel looks quite straight forward. Should I add a preference for the Action button default style, native or classic, when loading older *.opi files? You'd have to test that at NSLS2, though.

[mdavidsaver]

Should I add a preference for the Action button default style, native or classic, when loading older *.opi files?

Apologies if I've mis-read some of the previous comments. Are we choosing the default used when placing new widgets in edit mode, or when loading a legecy .opi in run mode? I was thinking the former.

I thought we were discussing the default for new widgets, which I think would benefit from being configurable. IMO legacy .opi files (meaning before the Native/Classic split) should always be treated as Classic widgets.

[kasemir]

How about one preference for the Action button default style, native or classic, which applies to both newly created widgets and when loading older *.opi files that do not specify the style?

[mdavidsaver]

Having one preference for both would satisfy BNL users (we want Classic only).

However, I have to ask. Do you think anyone would want to take legacy .opi files, which were all designed with the Classic semantics, and run them with the Native semantics? This seems to me like a recipe for surprise (and bug reports).

[kasemir]

"At NSLS2 we have example of these in pages that were created with 3.1.6 and the action button style defaults to native when we run these pages in 3.2.x. Maybe the default style could be set to classic?"

Can you check those older *.opi files if they indeed included "<widget type .widgts.ActionButton>", or if they included a "<widget … widgets.Button"?

[kasemir]

Commit f7ec88c1fe2981e28ea0c363bbde1d38647e73ab on the bug413 branch adds that preference, using it for ActionButtons when creating new button or loading older *.opi files that do not specify the style. But the ActionButtonModel still includes this code:

    public void processVersionDifference(Version boyVersionOnFile) {
    ...
        if(boyVersionOnFile.compareTo(VERSION_BEFORE_STYLE)<0){         
            // convert native button widget to native style     
            if (getWidgetType().equals("Button")){ //$NON-NLS-N$
                setStyle(Style.NATIVE);
...

So older files that specifically used a "Button", i.e. a native button, stay as a native button. That's why I was wondering about the existing NSLS2 files and the exact widget that they used.

[mdavidsaver]

Can you check those older *.opi files if they indeed included "", or if they included a "<widget … widgets.Button"?

I'm a bit unclear on how to interpret this in the context of the actual content of a .opi file. For our existing .opi files I see the following:

<widget typeId="org.csstudio.opibuilder.widgets.ActionButton" version="1.0"> <widget_type>Action Button</widget_type>

[kasemir]

Then commit f7ec88c on the bug413 branch should fix your issue: Your existing *.opi files use <widget typeId="org.csstudio.opibuilder.widgets.ActionButton". Their default systole used to be "Native". Now it's a preference, predefined to use the classic style.

[berryma4]

Leaving open for validation