Multiple Appearance Schemes

[Stagg54]

I'm curious if anyone has ever run into this before and how they deal with it.

Here's my problem:

I have 1 program that depending on which location/setting it is used in ( currently only 3 options here) it has a different front panel appearance (ie. BGcolor, text colors, boolean colors, plot colors, line styles, etc.) My world would be much easier if everyone could just agree, but that's not going to happen (which is good in a way because it keeps me employed.) Oh and also for each of these locations, when the user prints the screen I have to change all the controls to another appearance.

I'm weighing a few options:

As far as actually updating the control properties

1. I could do the brute force method and have a case structure in the init stage of every VI that is displayed and use proprty nodes to set every control/indicator based on which location/setting I am in. Not elegant at all but it works. Not exactly very expandable either. Everything is pretty much hardcoded unless maybe I read it in from an .ini file. Also a lot of duplicated code. If I have a particular graph that appears on 3 screens and is handled the same way, I have to repeat the code 3 times. Maybe I make a subvi - who knows.

2. I looked at xcontrols and having a method for each xcontrol something like set color scheme, but from what I can figure replacing all of the controls with xcontrols would be a complete waste of time.

3. The most promising appears to be using vi server because we have a splash screen that loads all of the VIs so when I load each one I can set the properties of each control using property nodes and references.

4. There has to be some way to incorporate classes and dynamic dispatching into method #3.

As far as managing the different schemes:

1. I could read all the info from an ini file - seems straightforward

2. If I classes perhaps I could create a child class for each location and one for the print settings for each location.

If anyone has any thoughts or ideas it would be nice. This seems like a pretty overwhelming problem and I'm just trying to wrap my brain around it. I figure no matter what it's going to take a lot of effort, but I figure any planning I can do ahead of time will really pay off in the end. Of course I'd like to come up with somehting that is readable, scalable, and maintainable. Knowing the people that I'm dealing with their liable to change their minds 20 times yet today about what colors they want and what line types, etc.

[Cat]

I have 1 program that depending on which location/setting it is used in ( currently only 3 options here) it has a different front panel appearance (ie. BGcolor, text colors, boolean colors, plot colors, line styles, etc.) My world would be much easier if everyone could just agree, but that's not going to happen (which is good in a way because it keeps me employed.) Oh and also for each of these locations, when the user prints the screen I have to change all the controls to another appearance.

I had to do something that sounds similar with a very graph-intensive piece of code. I was tasked with making 1 "uniform" interface for 3 groups that had their own completely different products. So even tho the basic layout was the same, some wanted a black background, some wanted white, some were very picky about what order the colors were for different plots, etc. This problem was compunded by the fact that User X could be running the code and User Y, with very different aesthetic requirements could be using it 5 minutes later.

I ended up building a GUI where each user could go in, mess around with all possible settings, and save their preferences to their own ini file. The users were all a-gaga about it for quite some time and had fun playing around with it. I've noticed lately, tho, that after a year, most of them have migrated to just using the default settings.

Cat

[Yair]

Another option is having a GUI VI which doesn't have any code or has very limited code. The actual logic VI registers for events in the GUI VI dynamically and does the update using VI server. Then you can have several GUI VIs, but I don't think this scheme will work for what you want.

From your description, it sounds to me like you want to have the same FP, just with different colors and styles. For that, the method of going through the controls by reference and changing them sounds better to me. I think that you want two clusters - one for the references and one for the colors (or you could do it using a lookup table) and then you can easily do the updating in a subVI. Building the cluster of reference is easy if you use this JKI RCF plugin. The cluster or array of colors can be saved and loaded to an INI file (or several, as Cat suggests) using the OpenG or MGI saving VIs or you could do it as a class, as you suggested.

One thing which may help you save some time is Kshif's property saver. I haven't used it myself, so I can't comment, but it's free, so you shouldn't have any problems with trying it out.

In any case, if you're using the control updating way, be sure to set the Defer Panel Updates on the panel to T before starting and to F at the end.

[Stagg54]

Thanks for your responses. I will take all of that into consideration.

[jzoller]

There are a couple of social solutions as well.

Saying no to multiple interfaces is sometimes valid. Or, deliver an "initial version" with only a single interface, and see if they really want multiple interfaces.

Of course, if they're paying hourly, then you may not want to argue...

Joe Z.

[ShaunR]

It'd be nice if LV supported skinning.

Speaking of which.....Anyone know what the "IsSkinned" node is for?

[crelf]

It'd be nice if LV supported skinning. Speaking of which.....Anyone know what the "IsSkinned" node is for?

Yep - it's because LabVIEW has supported skinning for many versions

It's a little known feature that kinda hidden - right click on the horizontal scroll bar of your FP, select "Properties" and you'll get a dialog that allows you to select from some predefined background or choose your own. I'm pretty sure you'd be able to access this property dynamically.

I'm pretty sure you'd be able to access this property dynamically.

Yep

[Gary Rubin]

right click on the horizontal scroll bar of your FP

Of course! That makes perfect sense!

Maybe if I want to see if LabVIEW has a built-in thesaurus, I should try right-clicking on the pi constant.

Incidentally, we're missing a "sarcasm" emoticon.

[Gary Rubin]

It's a little known feature that kinda hidden - right click on the horizontal scroll bar of your FP, select "Properties" and you'll get a dialog that allows you to select from some predefined background or choose your own. I'm pretty sure you'd be able to access this property dynamically.

Interesting... I just tried this, and found that disabled controls are semi-transparent. I hadn't realized that.

[crelf]

Incidentally, we're missing a "sarcasm" emoticon.

[Gary Rubin]

I'm staring at that trying to figure out what makes it "sarcasm"

[Cat]

I'm staring at that trying to figure out what makes it "sarcasm"

It's looks more like "You're an idiot."

[jzoller]

Changing a background isn't even close to skinning.

[asbo]

It's looks more like "You're an idiot."

I reckon it's a poor assumption that crelf was trying to demonstrate a sarcastic emoticon.

ps. Don't look at the filename, it ruins my quip.

[ShaunR]

Changing a background isn't even close to skinning.

Amen

I have known about background wallpaper, although not sure at what point it was introduced. And I would add to Crelfs elegant descitipion that if you use splitters you can also have different wallpapers for each pane by right clicking on the splitters left/right pane properties.

But skninning goes way beyond that enabling choosing of control images, titlebar, borders......well anything visual thats represented by an image.

I'm staring at that trying to figure out what makes it "sarcasm"

Its more like a "I've got wind" emoticom

Edited November 6, 2009 by ShaunR

[crelf]

Changing a background isn't even close to skinning.

I don't think that's fair. Changing a background *is* close to skinning - it's a common component of skinning. Sure, it's not changing a whole theme, but it's definately better than nothing. Besides, in the industries that LabVIEW is used, I think that the ability to skin is pretty limited. A nice to have maybe, but I wouldn't suggest that the LabVIEW R&D spend too much time on it.

[PaulG.]

... Incidentally, we're missing a "sarcasm" emoticon.

I thought this was sarcasm. "Excuuuuuuse Meeeeeee!!! "

Edited November 6, 2009 by PaulG.

[ShaunR]

I don't think that's fair. Changing a background *is* close to skinning - it's a common component of skinning. Sure, it's not changing a whole theme, but it's definately better than nothing.

Actually it isn't better than nothing since you can easily end up with unreadable interfaces if you can't change the controls skin as well..

Besides, in the industries that LabVIEW is used, I think that the ability to skin is pretty limited. A nice to have maybe, but I wouldn't suggest that the LabVIEW R&D spend too much time on it.

And there was me thinking that NI was promoting LV as a "general" programming language

If you look at any other languages, skinning isn't actually a support of the language. It stems from the fact that all control properties are exposed and therfore modifyable (Think about the recent C++ poster trying to inherit from a boolean). The fact that LV R&D decide what you can and can't have access to limits this. If (for exampe) they exposed a booleans images properties (True, False, True>False, False>true) you could. LV user interface cpabilities has been pretty much unchaged since its inception. But it could be worse. Look at Labwindows....lol.

[crelf]

But skninning goes way beyond that enabling choosing of control images, titlebar, borders......well anything visual thats represented by an image.

Right, and to get back on track, I'd suggest that you have different UIs for each "skin" that you want to show. That's the most elegant method that I can think of in LabVIEW. As was already mentioned, you can communicate with FP elements using VI Server or the like, so it's actually not that difficult to set up.

[Gary Rubin]

...and to get back on track...

What?! That must be a first! I don't think I can recall a discussion ever coming back on-topic after meandering off into the philosophies of LabVIEW.

[crelf]

Actually it isn't better than nothing since you can easily end up with unreadable interfaces if you can't change the controls skin as well..

So you're saying that there's never a valid reason to change the background of a FP unless you can change the appearance of all the controls and indicators?!

And there was me thinking that NI was promoting LV as a "general" programming language

I can't say I've ever heard that from someone at NI.

If you look at any other languages, skinning isn't actually a support of the language. It stems from the fact that all control properties are exposed and therfore modifyable... The fact that LV R&D decide what you can and can't have access to limits this. If (for exampe) they exposed a booleans images properties (True, False, True>False, False>true) you could.

I think you mean that *more* control properties are exposed, not *all*, right?

LV user interface cpabilities has been pretty much unchaged since its inception.

I don't want to look like I'm itching for a fight, because I'm not, but I don't seem to be able to agree with anything you've written in this thread The controls palette underwent a pretty big change a few major versions ago - just take a look at the differences between the default and classic palettes.

Anyway, I, for one, am glad that NI's spending the time on new controls and indicators (take a look at the new graphs available in LabVIEW 2009) and not spending that time on adding skin capabilities. Sure, it's a nice to have, but it's of very little value to me.

[asbo]

So are we only considering skinning a viable exercise if it's feasible at run-time? Don't custom controls constitute skinning (or at least the capacity to)?

In any event, I (tentatively) agree with crelf - skinning could be handy, but LV really isn't geared for pretty interfaces and many of the industries it's used in don't care what the thing looks like as long as it Just Works Right.

[ShaunR]

So you're saying that there's never a valid reason to change the background of a FP unless you can change the appearance of all the controls and indicators?!

Don't remember saying that, but then again I've never written an app that has a bitmap background. Ours tend to be solid black. But I've written loads in other languages that do and am just aware of the pitfalls. In fact, if its visually intensive, I wouldn't do it in LV in the first place.

I think you mean that *more* control properties are exposed, not *all*, right?

Why not all? Let me decide what is appropriate for my application.

I don't want to look like I'm itching for a fight, because I'm not, but I don't seem to be able to agree with anything you've written in this thread

Nothing new there then

The controls palette underwent a pretty big change a few major versions ago - just take a look at the differences between the default and classic palettes.

I wouldn't say putting a few 3d borders was a major change. And even if you do, thats once in 20+ years and it still "looks" like LV.

Anyway, I, for one, am glad that NI's spending the time on new controls and indicators (take a look at the new graphs available in LabVIEW 2009) and not spending that time on adding skin capabilities. Sure, it's a nice to have, but it's of very little value to me.

Aha. Something we agree on. Nice to have! The new graphs I can live without and have been for ages.

So are we only considering skinning a viable exercise if it's feasible at run-time? Don't custom controls constitute skinning (or at least the capacity to)?

Well. For me yes. You can change most of the bitmaps at design time as it stands (well booleans at least). But skinning is meant to allow a user to choose a visually appealing interface so it really needs to be at run-time. As for custom controls, try changing a cluster

[jzoller]

I don't think that's fair. Changing a background *is* close to skinning - it's a common component of skinning. Sure, it's not changing a whole theme, but it's definately better than nothing. Besides, in the industries that LabVIEW is used, I think that the ability to skin is pretty limited. A nice to have maybe, but I wouldn't suggest that the LabVIEW R&D spend too much time on it.

Skinning at least implies an intermediate layer of architecture that abstracts the UI (as in Model-View-Control). Changing a background is just an environment change.

I think skinning capability is a user-land responsibility, but, as the original topic shows, LV makes it painful.

Joe Z.

Edit: oh, one more solution. Use a picture control to imitate the appearance of buttons, and swap images on it.

Edited November 6, 2009 by jzoller

[crelf]

In any event, I (tentatively) agree with crelf - skinning could be handy, but LV really isn't geared for pretty interfaces and many of the industries it's used in don't care what the thing looks like as long as it Just Works Right.

Thanks for the quasi backup, but I'm not sure that whole industries have any particular attitude - as most engineers have a lot of exposure to UIs across a broad range of apps, they're exposed to intuative and not-so-intuative UIs. Just because it's easy to dump a handful of controls and indicators on a FP and call it done because it "Just Works Right", doesn't mean that you should. Sure, I'd agree that a functional program with a crappy UI is better than a non-functional program with a gorgeous UI, but we should be finding a balance - that's why UI design is important, irrespective of what industry you're designing/writing for. Industries may have an average way of doing things, but that doesn't mean that we can't (sometimes very slowly) make things more intuative. That said, keeping things the same is also a method of increasing intuativity (by association), and sometimes that makes more sense. Think of the UI changes from Windows 3.11 to Windows 95 - most of the gross UI updates were for the new users - but that made the existing users bitter, because it actually put them backwards.

Changing a background *is* close to skinning - it's a common component of skinning. Sure, it's not changing a whole theme, but it's definately better than nothing.

Actually it isn't better than nothing since you can easily end up with unreadable interfaces if you can't change the controls skin as well..

So you're saying that there's never a valid reason to change the background of a FP unless you can change the appearance of all the controls and indicators?!

Don't remember saying that...

You said that changing the background "isn't better than nothing... if you can't change the controls skin as well"

Why not all? Let me decide what is appropriate for my application.

I'm not completely familiar with a lot of other languages, but I don't think that you can define "all". You only get access to the attributes of a control that the developer of that control exposes to you. In this case, the attributes exposed in LabVIEW are less than other languages. In other languages, you don't get absolutely everything without getting into the very low level of the control itself, in which case you might as well write your own.

I wouldn't say putting a few 3d borders was a major change. And even if you do, thats once in 20+ years and it still "looks" like LV.

Compare the LV1 palette with the LV 2009 palette. I'm not saying that there has been an explosion of changes in the last 20 years, but I think it's totally unfair to take the extremist view that nothing has changed. Please: credit where it's due. There's a difference between saying that not a lot has been done and insinuating that nothing has been done.

Aha. Something we agree on. Nice to have! The new graphs I can live without and have been for ages.

If you've got ideas, get off your arse and suggest them over on the Ideas Exchange. And don't just say "we need newer controls" - list specific stuff that you want, and go into details of how you want it.