UI Skinning

Hi,

I am running 7.10 on OSX 10.9. When loading the all-new skinned UI it  
applies the default look instead of the OSX-native skin. How can I switch  
to the native skin? (Albeit, I like the new default look.)

Regards, Steffen
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I don't know about OS-X. On Windows: load the UISkinning parcel. Go to Settings, select the "User Interface Look" as "Skinned". Then select the "Skin" as you like. Don't forget to press the Apply button. Maybe I am pointing out the obvious though.

Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Steffen Märcker
Gesendet: Dienstag, 26. November 2013 17:22
An: vwnc
Betreff: [vwnc] UI Skinning

Hi,

I am running 7.10 on OSX 10.9. When loading the all-new skinned UI it applies the default look instead of the OSX-native skin. How can I switch to the native skin? (Albeit, I like the new default look.)

Regards, Steffen
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi,

From what I've seen OSX 10.9 fall back to the default skin because it is
not supported yet. See #skinOrNil class method from AbstractMacOSXSkin.
You can try to return MacOSX108Skin new instead of nil in the ifAbsent
block of this method or simply subclass MacOSX108Skin with a
MacOSX109Skin class. As I don't have OS X 10.9 I haven't tried, but it
should work...

Christophe


Le 26/11/2013 19:59, Nowak, Helge a écrit :

--
Diazol <http://www.diazol.com> Christophe Gouyen
[hidden email] <mailto:[hidden email]>
DIAZOL Tél : +33 (0)2 98 33 61 04

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

That's an interesting and somewhat worrying challenge for UISkinning. In previous VW UIs, when a new OS UI came out, and before Cincom updated VW with a new look and feel, there was always the fallback to the previous OS UI - e.g. on Windows XP you'd see the Windows 98 look. This was similar to the behaviour across many other non-VW applications: it takes a while for all apps to update themselves to use the latest OS UI look.

The report below seems to indicate that if a new OS version updates the UI, VW doesn't know how to use it. Instead of falling back to the previous supported version of that OS, it falls right back to the default skin - significantly more surprising to customers. It may be just that VW doesn't know the new OS version (in which case falling back to the previous one may be possible, so not a big problem), but presumably it's also possible that the new UI stores its graphics elements in a different file or format, in which case VW will have no option but to fall back to the default skin (or worse, give an error or crash trying to display the error).

So, what's the story with forward compatibility over OS versions in UISkinning? Obviously you can't predict the future, but how would things have panned out if you built the mechanism to find OS UI graphic elements based on Windows 98, and then XP, Vista, 7 or 8 came along? Would they have required different mechanisms? In the old VW things would have worked fine, and the app would have looked the same as it always had to its users (except for maybe fonts and background colours read from the user's preferences). Can we get the same kind of relatively graceful degradation and "growing older" with UISkinning? (I know in development we can move to a newer VW version, once that supports the new OS version; I'm thinking more about the behaviour of deployed apps.)

Cheers,
Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi,

thanks for the hint. Unfortunately it does not work out - all the windows  
become unresponsive after altering the method and changing the skin from  
default to native.

Regards,
Steffen

Am 27.11.2013, 10:04 Uhr, schrieb Christophe Gouyen  
<[hidden email]>:


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 27 Nov 2013, at 8:14 pm, Steven Kelly <[hidden email]> wrote:

> That's an interesting and somewhat worrying challenge for UISkinning. In previous VW UIs, when a new OS UI came out, and before Cincom updated VW with a new look and feel, there was always the fallback to the previous OS UI - e.g. on Windows XP you'd see the Windows 98 look. This was similar to the behaviour across many other non-VW applications: it takes a while for all apps to update themselves to use the latest OS UI look.
>
> The report below seems to indicate that if a new OS version updates the UI, VW doesn't know how to use it. Instead of falling back to the previous supported version of that OS, it falls right back to the default skin - significantly more surprising to customers. It may be just that VW doesn't know the new OS version (in which case falling back to the previous one may be possible, so not a big problem), but presumably it's also possible that the new UI stores its graphics elements in a different file or format, in which case VW will have no option but to fall back to the default skin (or worse, give an error or crash trying to display the error).
>
> So, what's the story with forward compatibility over OS versions in UISkinning? Obviously you can't predict the future, but how would things have panned out if you built the mechanism to find OS UI graphic elements based on Windows 98, and then XP, Vista, 7 or 8 came along? Would they have required different mechanisms? In the old VW things would have worked fine, and the app would have looked the same as it always had to its users (except for maybe fonts and background colours read from the user's preferences). Can we get the same kind of relatively graceful degradation and "growing older" with UISkinning? (I know in development we can move to a newer VW version, once that supports the new OS version; I'm thinking more about the behaviour of deployed apps.)

I have to answer this in the context of the vw-dev NDA, so you should check there for information.

Antony Blakey
--------------------------
Ph: +61 438 840 787

The fact that an opinion has been widely held is no evidence whatever that it is not utterly absurd.
 -- Bertrand Russell




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 27 Nov 2013, at 7:34 pm, Christophe Gouyen <[hidden email]> wrote:

> From what I've seen OSX 10.9 fall back to the default skin because it is
> not supported yet. See #skinOrNil class method from AbstractMacOSXSkin.
> You can try to return MacOSX108Skin new instead of nil in the ifAbsent
> block of this method or simply subclass MacOSX108Skin with a
> MacOSX109Skin class. As I don't have OS X 10.9 I haven't tried, but it
> should work...

More recent versions provide a MacOSX109Skin class that is an empty subclass of MacOSX108Skin. No method changes are required to #skinOrNil.

That's not the only change in 10.9 - they also have a new system font ".Lucida Grande UI"

Antony Blakey
--------------------------
Ph: +61 438 840 787

It's amazing that the one side of the conversation that survived is "I don't know art, but I know what I like". The reply from the artist was "Madam, so does a cow".
  -- Carl Kirkendall




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Update: I subclassed MacOSX108Skin instead of changing #skinOrNil and it  
works fine so far.

Cheers, Steffen

Am 27.11.2013, 11:05 Uhr, schrieb Steffen Märcker <[hidden email]>:
<---Schnitt--->
>>
>>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The main problem is with pre-reqs, and a custom pre-req policy (easy enough to create; it was done at my last job) can handle that.  You do need to start using naming patterns for your packages (we did something like "7.9.1 - ...." - i.e., prefixing with the version number).  You also need to publish <everything>, and use the naming convention with that.  If Cincom simply shipped the entire release in a SQLLite db, with some kind of known naming scheme, this would be a lot easier.

>> So it's not unusual to require updates when the OS is upgraded.
>
> The burden on developers is huge, because, considering the frequency of OS updates today, they need to maintain a long history of past software releases (that is: make sure to be able to deploy new builds of previous releases at any time). This may work with conventional dev environments. With VW and Store, this is hell.

James Robertson
http://www.jarober.com
[hidden email]




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Well, loading the right packages into a base image is only half the deployment story. That's a very Smalltalk-centric point of view.

Building a cross-platform product involves a lot more, from compiling dependent and associated parts of the product, assembling platform-specific executables and their resources, up to the configuration and packaging of native installers, applying copy protection, digital signing, etc. Countless external tools and files are involved.

As products evolve, this build environment also changes. It can be hard to patch very old releases to still build fine in the current environment.

The only solution that worked for me is to keep dedicated Store DBs and isolated Macs and PCs (virtual hardware where possible) around to ensure there are no unwanted side affects across different releases. This way I can be sure all possible dependencies with compilers, shell scripts, resource folders and system tools are left unchanged over a long period of time.

I do not really want to keep more if this around than absolutely necessary. Therefore forward compatibilty is a must for deployed products.

Andre

--
> The main problem is with pre-reqs, and a custom pre-req policy (easy enough to create; it was done at my last job) can handle that.  You do need to start using naming patterns for your packages (we did something like "7.9.1 - ...." - i.e., prefixing with the version number).  You also need to publish <everything>, and use the naming convention with that.  If Cincom simply shipped the entire release in a SQLLite db, with some kind of known naming scheme, this would be a lot easier.
>
>>> So it's not unusual to require updates when the OS is upgraded.
>>
>> The burden on developers is huge, because, considering the frequency of OS updates today, they need to maintain a long history of past software releases (that is: make sure to be able to deploy new builds of previous releases at any time). This may work with conventional dev environments. With VW and Store, this is hell.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Well, once the topic shifted to build strategies, I didn't think it was particularly on-topic for "things in current dev builds" that vw-dev is focused on.  

On Dec 3, 2013, at 2:35 PM, Antony Blakey <[hidden email]> wrote:

James Robertson
http://www.jarober.com
[hidden email]




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc