OpenXTalk Forums

Came across this whilst perusing Windows APIs on the MS Dev Site and thought "jeez that's a familiar concept"!

https://docs.microsoft.com/en-us/adapti ... a-renderer

EXAMPLE: This could be translated into a text field with the properties name="{name}", textStyle set to "Heavy"/Bold(er?) or htmlText <H#></H#>, texSize to some arbitrary "Medium" ...and the "AdaptiveCard" format has lots of other GUI control oriented properties available. It's already meant to be a GUI template system. XTCML <> AdaptiveCard ?

https://github.com/microsoft/adaptivecards-templates

MS has a lot planned with the introduction of Win11.

Even just the fact that it is planned to integrate android. (Even if the whole thing is to come with the autumn update 22)

As I have understood correctly in the insider program, the company plans to become cross-system, so that even some Linux apps in the future should also run on Win11.

For me it looks like it is the first steps in the direction and one has taken the card system of "Hypercard" (times used as a generic term) as a model.

If the syntax develops in this direction, we have as Hyper-Livecode-XTalk connoisseurs and users absolutely an advantage.

I would say, the whole times under observation hold...

At least it would be worth to consider an implementation of Adaptive cards

astu wrote: ↑Wed Dec 22, 2021 8:20 pm MS has a lot planned with the introduction of Win11.

Even just the fact that it is planned to integrate android. (Even if the whole thing is to come with the autumn update 22)

As I have understood correctly in the insider program, the company plans to become cross-system, so that even some Linux apps in the future should also run on Win11.

For me it looks like it is the first steps in the direction and one has taken the card system of "Hypercard" (times used as a generic term) as a model.

If the syntax develops in this direction, we have as Hyper-Livecode-XTalk connoisseurs and users absolutely an advantage.

I would say, the whole times under observation hold...

At least it would be worth to consider an implementation of Adaptive cards

Yeah I found it very interesting that MS has decided to integrate Android in Win 11 (somewhat of an admission of failure to launch on mobile devices?)...but it's the obvious choice. Android x86 ASOP is open-source. I've run it on laptops with varying success. Android is Linux at the core, the same way macOSX+ is BSD Unix at it's core. Windows has had a Linux subsystem option available for Win 10 for some time.

I find it more exciting that Phyton is available directly in WIN11. At least for this, OXT/LC will become interesting for GUIs.

Let's see how the further development progresses.

"Card" is also a UI element in the Android UI specs, and some web frameworks.

Same spelling, different uses.

xTalks live in a metaphor where they fill the window, with only one card is visible at a time.

Modern usage elsewhere has them as a thing inside the window, letting you spread them out within the window's content region.

Of course xTalks can be used to make such things. But making them in an xTalk would mean using a field or a group, rather than the classic xTalk-native card object.

Though the spelling is the same, and some use cases may overlap, modern card elements as implemented in other systems are a different beast.

One of the few nomenclature differences I liked in Toolbook was using "page" for what we call "card", a choice that turned out almost prescient once the web took over.

FourthWorld wrote: ↑Thu Dec 23, 2021 3:58 pm "Card" is also a UI element in the Android UI specs, and some web frameworks.

Same spelling, different uses.

xTalks live in a metaphor where they fill the window, with only one card is visible at a time.

Modern usage elsewhere has them as a thing inside the window, letting you spread them out within the window's content region.

Of course xTalks can be used to make such things. But making them in an xTalk would mean using a field or a group, rather than the classic xTalk-native card object.

Though the spelling is the same, and some use cases may overlap, modern card elements as implemented in other systems are a different beast.

One of the few nomenclature differences I liked in Toolbook was using "page" for what we call "card", a choice that turned out almost prescient once the web took over.

Is it really a different usage?
Technically a CARD IS a content view that gets rendered inside a Window, and with substacks, menustack, etc. it IS possible to have a Card inside another Card, which is the way that DataGrid works, although I do understand what you're saying about this being more like a <DIV> in HTML, which would make "ActiveCards" more like a GROUP Control than it is like a "Card" in our thing. But "Card" is NOT the same size as a Window, you can have a card that scrolls inside a stack window, you can have card controls in a stack that are outside of the viewable region of a Window. A "Stack" I think has more closely related usage to a window than card does. There is some, albeit limited, Window related syntax separate from the Card/Stack related syntax. Windows have their own ID#. Distilled to very basic terms, however we are talking about Cards that are content views or sub-views, that are made up of text/data, graphics and UI controls, and get rendered inside a window (depending on onscreen or offscreen positions).

My thinking on this encapsulated exchange format is more about abstraction, interoperability, and portability than it is about any direct conversion. If a "Card" becomes a Toolbook "Page", an NSView object, an HTML "<Div>", etc. that's all good with me.