BOY: editing a file for a small change seem to change all the fonts everywhere

[gcarcassi]

If you look at:

ControlSystemStudio/opi-regression-tests@a3b4caf

That change was generated just by changing the word lable->label. It has also changed all the fonts in the file.

[xihui]

This is because the Default font of the system changed. The font is only
used as a backup if there is no "Default" font macro is defined. The
"Default" font macro (which is a BOY predefined font macro) is always
available, so the font part will never be used.

On Thu, Mar 13, 2014 at 2:04 PM, Gabriele Carcassi <notifications@github.com

wrote:

If you look at:

ControlSystemStudio/opi-regression-tests@a3b4cafhttps://github.com/ControlSystemStudio/opi-regression-tests/commit/a3b4caf2c57126dc9cf15dc4a7768684b05481df

That change was generated just by changing the word lable->label. It has
also changed all the fonts in the file.

Reply to this email directly or view it on GitHubhttps://github.com//issues/431
.

[kasemir]

I agree that this is a "doesn't matter" type of difference in the *.opi files.

Still, to understand what's going on: Does the system default font change ("Sans" vs. "Segoe UI") result from

• A change in the Eclipse target platform, i.e. SWT changed the default system font
• A change to the opibuilder source code, i.e. some default inside BOY
• Running CSS on Windows vs. Linux, since SWT uses fonts offered by the OS
  ?

[berryma4]

This just happened to me too.
ControlSystemStudio/opi-regression-tests@88183c7
I would say this is not a desired behavior.

[kasemir]

I think we have two issues here.
One is a general re-ordering of properties that Eric shows in his regression test.
The other is the font name changes which originally started this issue:

<opifont.name fontName="Ubuntu" ...>Default</opifont.name>

vs.

 <opifont.name fontName="Segoe UI" ...>Default</opifont.name>

First the fonts: It's good that color and font properties list the macro name, so hopefully that's defined and thus used, but also include an (the) actual value. With EDM, you often can't use displays created elsewhere because you don't have their macros defined. With *.opi files, it looks correct because it includes the actual fonts & colors, but then you can define the macros to change its look.

Still, having changes in the edited *.opi just because of different fallback values is a bother, and I still wonder why it's happening:

• SWT? When we go through major SWT updates (rare), or once edit with SWT-on-Windows, then SWT-on-Linux (all the time), the font fallback values change -> Not sure if we can do anything about that. Just update all examples to one platform, then perform automated tests on that platform?
• Is it because the default was changed in the opibuilder source code? -> Write all example *.opi files with the current version, and then we simply don't change it again.
• Can it change for other reasons, for example computers A and B are both Windows 7, but one has Microsoft Office, the other Open Office, and the different available fonts result in such changes for the font fallback values?

The other issue is general ordering of properties. Way back when we started BOY, we looked at the SDS files. The SDS files were basically auto-generated by some model library, and looked like this:

<property name="x" type="java.lang.Integer" value="14"/>

I didn't like that for two reasons: It's quite verbose, and you have no control over the actual format.
The verbosity is a problem because sooner or later you do want to create some displays with perl/python/.. scripts, or do text replacement to globally change some setting, which is easier with a format like this:

<x>14</x>

The control over the actual format is exactly what we see here: New properties might be added as widgets "grow" in future versions, but the order of existing properties should not change, so you can at least to some extend compare the *.opi files as text files.
Looks like the order isn't really preserved, maybe because options are simply dumped from a map.
Should we dump them in alphabetical order? Or sort first by category, then alphabetically within category? Those would be somewhat simple to implement and predictable. Or add some manual ordering to for example always have location x, y and size widths, height right next to each other in the *.opi file?