Setting text style of disabled controls

[jacque]

My goal would be a design that automatically adapts -- I know that this is impossible -- has the same behavior for all similar components, can change a theme "on the fly"

That's what LC profiles are meant to do. I haven't used them much, but the idea is to set custom properties on each control and then you can change the profile so that it loads automatically on startup or openstack or wherever you decide. Check out "profiles" in the User Guide.

I have created Android apps that follow Material Design (I do like Material very much) but since my app was only built for Android, I didn't need to use profiles. In the case of disabled buttons (and others) I actually used Bogs' suggestion and created graphics that were used as buttons. The script of those graphics checked the foregroundColor and if it was the disabled color, it exited the mouseUp without doing anything. This could be implemented as a behavior if you have many controls that need it.

I stored the enabled color and the disabled color as constants in the behavior script. This would be easy to adjust for use on any OS. Instead of a constant, store the color values in script locals and assign values as needed to match the OS you are targeting.

BTW, while my original handler apparently doesn't work on Windows, it may stilll work on Android. Try it on a real device and see.

[FourthWorld]

Now, also Material Design has certain themes and gives guidelines about behavior and visual appearance. While we can at least do a subset, we currently will have problems implementing the full scale of such design framework.

Ah, I see. Thanks. Yes, LC has quite a ways to go to make mobile conform to the HIGs as well as their desktop controls do.

My goal would be a design that automatically adapts -- I know that this is impossible -- has the same behavior for all similar components, can change a theme "on the fly" and builds on a UX that other designers and developers have created elsewhere spending thousands of hours and offer this work for free. Then any new application would already inherit such design and behavior and the biggest part of work is already done.

Profiles were supposed to do some of that, and then that got shifted over to themes, which wound up being more limited than originally hoped.

I've been playing with the properties array, exploring options for using very lightweight plain-text to describe styles, somewhat akin to CSS. If I get it to a state I like I'll post it and maybe some of it may help with what you're working on.

[golife]

Richard wrote:

I've been playing with the properties array, exploring options for using very lightweight plain-text to describe styles, somewhat akin to CSS. If I get it to a state I like I'll post it and maybe some of it may help with what you're working on.

That would be great. And not only to me but to many users would appreciate. Your insight and experience here are by far exceeding all of us. I also had once thought about trying to use CSS style sheets and somehow converting them to properties and property sets in LiveCode. But I am not sure of being qualified enough to understand the implications.

Also, maybe I did not fully understand the usage of custom property sets. I view them as just a help to group custom properties. Is this a correct view? Maybe I should look more into what they offer. Is anybody using them?

What I have been doing is setting custom "cStyle" properties for objects such as buttons and fields. If there are any changes to the style, these changes reflect in the appearance and behavior of the object. Styles are of course arrays. Such property arrays are then grouped into themes (or groups of properties) -- which are also arrays.

Additionally, "styles" must contain properties that allow handling dynamic behavior, such as the states of buttons/fields... So, there are substyles to styles reflecting the changing nature of objects in time.

The principles are the same as we know them from CSS and style sheets in Word, InDesign, Adobe Muse.

- Styles are sets of properties of objects and stored in array format containing property arrays. So, there are arrays within arrays.
- Themes are named groups of styles. They are also stored as arrays containing the style arrays.

Changing individual properties of a style will reflect on all objects of the same custom style property. Changing a theme will change all styles assigned to objects and therefore all properties.

This is how I see it. Naming things correctly is very important.

[FourthWorld]

GMTA. What you describe is more or less where I was headed.

[golife]

Richard:

GMTA. What you describe is more or less where I was headed.

I would very much like to continue the discussion on UX, Material Design, CSS, ... and how it could relate to LiveCode.

Maybe, Richard, you could suggest which Forum would be suited and possibly move the discussion there. To me, and I believe strongly to ALL clients and end users, UX is what they see, touch and do, and I know, for serious development, we spend more time working on the UI than coding logic and data sources.

As a vision, ideally, we could use CSS in LiveCode almost 1:1. It is the language about HOW things should appear and it is also best practice to keep it separate from the logic of the application and data storage. The "viewport" is the card of our stack.

[FourthWorld]

To be clear, nothing I'm doing is directly related to CSS. My reference to it was merely for its name-value syntax, which is so useful for style info, and that it relates to styles.

A separate library in designing is for simplifying layout by providing a row-based logic that brings some of the benefits of HTML's layout autoflow to building UIs in LC.

Given the constraints on my current schedule, I expect a long process between making a form of them suitable for my own deadlines, and I've that would be useful for others.

It would be great to see something like CSS in LC, but I don't see that anywhere near the horizon, at least not as an engine feature. Perhaps toolkits could be made by the community.

With that in mind, if the goal in to share his open source perhaps a thread in the Community Projects section may be useful.

[FourthWorld]

Material Design and other platform-specific UI specs are a deeper subject. It would certainly benefit every LC dev to have a rich variety of controls for that, and the recommended solution for crafting those is LC Builder. Hopefully we'll see more along those lines, but personally I'm more interested in broader UI concerns that benefit both platforms. There's enough common to both that it would seem worth investing in.

For example, most apps have some sort of menu, usually flying out from the left after tapping an icon. Right now these need to be entirely hand-crafted. Back in the old MetaCard days we use to have to hand-craft menus for desktop as well. Very tedious. If we can simplify that common UI element the desktop, it should be possible to do so for mobile as well.

While that would be great in the engine, consistent with the current menu handling, only the company loses by not having it built in with the install; experienced devs could find and use a third-party widget if it were sufficiently complete (think DataGrid, as opposed to the Tree Viewer widget, in terms of meeting expectations for usable completeness).

More daunting are transitions. Even desktop apps incorporate various degrees of animation during state transition.

Many of LC's transitions are old-looking, and too limited to use (consider the value of the iris and zoom effects of only we could specify an origin point, and how seldom they make sense without that).

But the bigger problem with LC transitions is that they're primarily card-based, and designed for an older desktop world before gestures where everything was done with simple clicks.

Today even the desktop has things like swipe, and that's a central part of mobile interaction. Except in LC.

To do true swipes in LC requires us to write quite a bit of carefully-honed code to handle the gesture and what happens when the gesture is not completed. And for the layouts being navigated among, we can't use cards; instead we have to build large horizontal groups to swipe between, which runs against the grain of how LC is made and is cumbersome enough to nearly wipe out why development productivity advantage LC offers in other areas.

Indeed, this has never a tell for LC apps: they're the ones that don't swipe. It's so cumbersome to pull off well few bother.

So if it were up to me, I'd put engine support for card swipes as a top priority, with mobile menus a second.

After those two things are in place, I'd be able to relax enough to sort out which UI elements make sense in the product and which could be done just as well by the community.

[golife]

Mentioning Material Design ist just mentioning one example of a well structured and platform-independent design school or "framework" given for free and developed for years.

LiveCode promises to develop once and deploy everywhere. This in itself is actually huge. Now, what about UX/UI in this case?

In my opinion, UI/UX (with all elements readily available) is such an important subject for new and current developers that I could not stress enough that UX/UI elements and templates and UX-frameworks with all the behaviors would probably "hit" the market more than just Live-Coding with those basic UI elements LiveCode gives and leaving it up to the developer to do what he wants. But I doubt that developers often enough know what they are doing when it comes to professional development and especially when it comes to UX/UI.

The success of development is the success of LiveCode. It sounds trivial, but there is more to it under the hood. I hope, it is not the end of the discussion. )