Does Qt need a modern C++ GUI API?
-
I voted with Yes. I do indeed like QML for creating neat UIs, but I think it's not the best approach to introduce a new design language for that task - or at least not in a C++ centered application framework. I would appreciate a possibility to access the advantages of QML from within a pure C++ framework without much coding overhead...
-
1: Since C++ cannot possibly be a viable replacement for a declarative language (like XML, HTML, JS/JSON et al), how is this "100% native" approach going to be solved - by publishing all private API's and possibly remove all the QML code?
2: Assuming this is what is called for, what is "modern" about making and emerging and unfinished C++ API public? Since this mistake has been repeated since the dawn of C/C++, wouldn't this rather make this proposal "old fashioned" and "unguided" instead?
Why not just use the private API's (or publish them at your own liking)? This is after all an open source project.
-
[quote author="minimoog77" date="1334961907"]If anyone believes that with C++ you can write modern GUI, so be it.
Wrong tool.[/quote]
What??? :):):)
Every serious software is written in C++, even the QML and JavaScript interpreter too.
A lot of (if not all...) high-level programming language compiler is written also in C++. The very new Win8 is written native C++ too. The Android and the iOS are written also C/C++.
An so on... -
C++ cannot describe UI in a declarative, structured way, nobody claims that, with C++ the developer must structure the design himself, BUT it is not that hard AT ALL, and it allows you to skip two extra languages, glue code between them and C++, and the CPU cycles and memory needed for interpreting and running a VM.
bq. #1 C++ will always be a core language for Qt (I love C++ and can’t imagine it being anyother way)
#2 Most of the time QML actually improves your software architecture by drawing more solid lines between the front-end and the back-end.
#3 It’s not like C++ support has been dropped or anything.1 - the problem is that "core" turns out to be low level logic. Let me give you an example - with QtGui everything you can do in the designer or with XML you can always do in C++, with QtQuick you no longer have that option, and unlike using the designer or XML, QML comes with a solid dose of various overheads
2 - I guess what you actually wanted to say is something like "draws more solid lines between GUI structure and application logic" - but not more so than for example HTML5, where you separate an application even further, you have structure, styling and logic, which is even more flexible. I hope you do realize the more a frontend is separated from its backend, the more overhead is induced? There is nothing faster and more efficient than using a C++ backend through its native C++ frontend. Even language bindings induce some overhead, not to mention the QML approach.
3 - C++ support on the low level has not been dropped, but C++ support for developing GUI applications is pretty much done, there is absolutely no indication Qt will dedicate any significant efforts into improving the outdated QtGui or change it for a better native GUI API@capisce - what would be the point of stating the obvious, I am quite sure you as well as others know the cost of running a VM and interpreting code, as well as being isolated from C++ and only be able to access it through gluing and exporting stuff explicitly. I never claimed the performance overhead of using QML is dramatic, just that IT IS THERE and there should be an option to avoid it. I am sure there must be some kind of moral gratification from people using what you designed and working in the way you intended them to work, but the wheel has already been invented, and inventing other shape wheels may not always be the best idea, sure it may work for some, but I for one would like the option to keep it native, and it looks like I am not alone in this.
bq. If anyone believes that with C++ you can write modern GUI, so be it.
Wrong tool.C++ may not be designed from the ground up to write modern GUI, heck it is a GENERAL PURPOSE LANGUAGE, so while it is not THE BEST tool to write GUI, it COMPLETELY SUFFICES to express any type of structure, be that of a UI or anything else. What people seem to fail to realize is QML is not code that gets executed, it is data that gets parsed by an interpreter which builds the structure entirely in the C++ way, the way I and many others want to be able to use Qt Quick.
If you think C++ is the wrong tool for you to write GUI, then by all means, DO NOT USE IT, but C++ IS THE RIGHT TOOL if you want to keep your application compiled to native binary, including the GUI, that is totally doable in C++. To you it may seem it is a tremendous difference between QML and C++, but whether you will inline an element into the body of another element to parent it in QML or whether you will create the element and pass a reference to another object in the constructor to parent it - it is not all that different, two different ways for doing exactly the same.
As I said in another thread, for people that are not used to C++ structure QML is easy since it allows you to describe the structure in code and have the interpreter build it for you. But many developers don't really need that tool to build structure. You DON'T DO PROGRAMMING IN QML, just because it is tailored to look like JS it is not a programming language, stating you program in QML is just like stating you program in XML, in both QML and XML you write data structure which some program will then read and do something with it.
So in the end it boils down to this - some of us appear to want the option of doing GUI programming rather than GUI describing. For describing GUI we already have tools that go beyond QML and are enjoying amazing worldwide adoption. It would have actually been better if Qt chose a HTML+CSS like approach instead of QML which mimics a programming language syntax but is a data structure language, which is a little backwards, and as I already said, HTML+CSS offers even more flexibility since you can separate structure from design. I honestly don't see enough benefits in QML to chose it instead of HTML5 for rudimentary app development. It has the benefit of being extendible through C++ but HTML+CSS+JS has many other benefits QML simply cannot offer like for example running on Android and iOS which totally dominate the booming mobile market, while with Qt the "running everywhere" is currently just an empty slogan that has little to do with the reality of the market.
Come on now, we don't even ask of Qt to be perfect, only to not be worse than MS and Apple, who do offer the option of keeping it native. Since when is it too much asking to be a tiny bit better than the world's greediest, monopolistic enforcers of proprietary technologies?
-
[quote author="broadpeak" date="1334990942"]
[quote author="minimoog77" date="1334961907"]If anyone believes that with C++ you can write modern GUI, so be it.Wrong tool.[/quote]
What??? :):):)
Every serious software is written in C++, even the QML and JavaScript interpreter too.
A lot of (if not all...) high-level programming language compiler is written also in C++. The very new Win8 is written native C++ too. The Android and the iOS are written also C/C++.
An so on...[/quote]The thing here is that C++ is a great language for all the heavy lifting that should be performed in the back-end. And QML is great to develop fluid and visually attractive front-ends.
So I my self have to agree that QML is a far better tool for the GUI, witch does not prevent you from performing most of the core operations using C++. That's actually a more modern and maintainable way of writing software if you ask me.
I think I shouldn't have to convince anyone that having your code neatly separated into a portable back-end and possibly multiple easy maintainable front-ends is a good thing.
Don't get me wrong I love C++, but some times having your entire application written purely in C++ is like firing a cannonball at a fly. Sure if you aim it properly you'll get to hit the fly and it's going to be spectacular, but than aiming it at a different fly will take far to much time and effort to be effective. (I know this is very exaggerated) (does “CODE LESS DEPLOY EVERYWEHERE “ ring a bell)
@temp you are wasting far to much energy on this (and sorry I have far better things to do than read your ... long posts write a blog or sth.) And IMHO Qt + QML is way better than what WP7 has to offer, so you're wrong when requesting Qt to be "a tiny bit better" when it's a hell of a lot better. Also if you think Qt is missing something no one is stopping you from contributing (IT'S OPEN SOURCE).
-
@temp: Have you even given the C++ API a try by using the private headers in QtQuick? Sure, for a couple of Rectangle and Text elements in a hierarchy you can do that easily from C++, but once you want to define custom behaviors, states, animations, and bindings it's just so much more convenient in QML that I believe many of the people who are asking for the C++ API would end up using QML in the end after all.
bq. with QtGui everything you can do in the designer or with XML you can always do in C++
The difference from XML and HTML 5 is that QML is very readable and pleasant to use even from a stand-alone text editor. Noone is forcing you to use Creator.
-
@kkrzewniak - as a tool, dedicated to GUI structure and design description, QML is the easier to use tool, there is no arguing here. The same applies to training wheels, it is surely easier to drive a bicycle with training wheels if you are new to it, but if you can drive a bicycle without training wheels already, then those become a limitation instead of а facilitation.
@capisce - No, I haven't, I don't know the internals of Qt Quick. If you don't mind, please do get a little more technical concerning techniques that will not be possible to do in C++, I am honestly curious. Property binding - I don't see an issue here, attaching states and animations - it depends on how is this actually implemented in the backend, something you could tell me perhaps, since finding out myself will require quite a lot of digging through a not exactly easy to read API. If it is done in the spirit of Qt, then I don't think it is that hard creating a state instance, attaching it to a parent, setting up and pointing it to the properties it needs to modify and connecting some signals and slots. No rocket science at all. Maybe a little harder than doing it with QML, but potentially a little easier (for programmers) since some of the work can be done in the very constructors of objects.
It all depends on how would an eventual C++ frontend will be designed. If out of spite for being forced to do it, your team decides to make a half ass job just to get it back at us, then sure, it has a very good chance of being too tedious to work with, and achieve a purpose it was designed with - to convince us QML is better. But I can also imagine an elegant way to do it, one that will make QML pointless for many people, which I don't think your managers are too keen on.
Surely, making it nicely fit with a C++ frontend MIGHT require some reworking, but it is your fault for not building Qt Quick with the idea of native usage from the ground up. Seriously, who writes an API in C++ without considering the most obvious option of using it natively? Someone, looking to enforce their own "language" for sure, but who else?
I cannot do a C++ frontend to Qt Quick myself, but I am willing to contribute to it whatever I can, and since I notice you as well as other people claim some stuff is not doable, perhaps I will be able to offer a workaround for those cases? Just post a QML snippet, accompanied by eventual backend catches that would make it hard to do natively, if there are such, and I will do my best to propose an elegant solution.
///
So what you want to tell me the main purpose behind the invention of QML instead of using already established and widely used standards is so that you can use Notepad for programming? Heck, there is a ton of text editors that support XML/HTML syntax highlighting and structuring out of the box or through a few clicks away downloadable extension, and I don't buy it that QML is any more readable than HTML, maybe to you, a person who has extensively used and potentially designed QML and may not have used HTML that much at all, but objectively it is about the same... Sorry but I am totally giving the edge to HTML+CSS, it is much more flexible, it is much more widespread and supported virtually everywhere.
I chose Qt for its ability to deliver applications in native code, and it makes sense I want that feature being improved on rather than being left just for compatibility purposes. If I wanted to lean on something like QML, I'd never bother with Qt, I already know HTML and JS, so I am good to go with trivial apps that will be supported on every major platform out there.
-
Qt has a had a C++ API for animations and states for some time, see http://doc.qt.nokia.com/4.8/qabstractanimation.html and http://qt-project.org/doc/qt-4.8/qstate.html
Behaviors in QML is simply an easy way to bind an animation to property changes: http://doc.qt.nokia.com/4.8/qml-behaviors-and-states.html
As for the QtQuick internals, see src/quick/items/qquicktext_p.h, qquickrectangle_p.h, qquicklistview_p.h etc. There's your C++ API, and you're free to use it as long as you accept that it's private API and thus offers no source or binary compatibility guarantees. I guess it could in theory be polished and made public if there is enough interest, but for that to happen it might be useful if people give it a try and offer feedback. I haven't tried to use these existing items from C++ myself, but I have made custom C++ QQuickItems for use with QML. I don't think the reason for not offering a C++ API from the start is malice, but rather a lack of resources and (until now) request.
An XML-based syntax was initially considered for QML, but dropped in favor of the more readable JSON-like syntax. HTML has a lot of legacy cruft, and no good support for animations and transitions without using WebKit specific extensions and such, and from what little I've seen the syntax is not ideal. I think most people using QML would not prefer to use HTML.
-
[quote author="cincirin" date="1334963428"]Nobody said that QML is not perfectly suited for it. Question is why Qt not follow the successful Apple native sdk policy. Or ... are Apple "iOS Graphics and Animation":https://developer.apple.com/technologies/ios/graphics-and-animation.html or "Mac OS X Graphics and Animation":https://developer.apple.com/technologies/mac/graphics-and-animation.html perfect native development kit ?[/quote]
What is the definition of native? For example is Angry Birds native? But if somebody told you that Angry Birds is using Lua for scripting then maybe it isn't? :)
Anyway, I am looking at this QML scaaaary thing like this:
You have a 2D/3D rendering engine which is optimizing the rendering on the GPU (scene graph). Written in C++. You can also add your own nodes (rendering yourself) if you want.
On top of that you have some kind of scripting language which defines the 'scene'.
Heh, it's like any modern game engine. :)
Also, you have easy (not perfect) access from scripting language to 'native' C++ objects and vice versa. Nice. So you don't need to write IDL. :)
-
[quote author="temp" date="1334993354"]C++ cannot describe UI in a declarative, structured way, nobody claims that, ...[/quote]
(just pulled the last quote regarding C++ and UIs, not replying to that post)
C++ is very capable of creating UIs in a declarative way, it is just that QWidgets are not implemented with that kind of API. One could create an API that would allow this to be a valid C++ code:
@window (
name = "winMain",
button (
name = "buttonBig",
size = parent.size,
title = "Click me!",
onClicked = something
)
)@--
p.s. If a "modern GUI" can be done in HTML+JS, it can be done in anything :) -
@capisce - I have really grown tired of hearing all the same clichéd arguments over and over again, having to explain what is wrong with them over and over again, especially since the people who present those know DAMN WELL what's wrong and needs improvement.
Point of the matter is - you can all read numbers, this poll started at a 2-to-1 ratio and despite being dug down in a place with plenty of Qt community members and their inevitable, even if unintentional bias, the poll is steadily moving towards a 3-to-1 ratio. Since you are a programmer, I assume you are good with numbers, and it does seem to appear it is not a minority but a majority of people who call for an improved, native C++ GUI API that meets today's standards. And with all that bragging about Qt's community, I think it is only natural for you to pay some attention to what your developer base wants instead of convincing everyone in the opposite.
@minimoog77 - no one is scared of QML, just for lots of people it is not needed, and having to use something you don't really need to use just so you can get access to an improved GUI backend is..., well, just stupid. The word stupid might not mean a lot to someone, whose idea of a shining example of an application is Angry Birds, but again, looking at the poll results so far it would appear over 2/3 of Qt users share my opinion. We cannot all be impressed by Angry Birds, no matter how successful it may be for a wide range of very sad reasons.
-
[quote author="temp" date="1335005392"]@kkrzewniak - as a tool, dedicated to GUI structure and design description, QML is the easier to use tool, there is no arguing here. The same applies to training wheels, it is surely easier to drive a bicycle with training wheels if you are new to it, but if you can drive a bicycle without training wheels already, then those become a limitation instead of а facilitation. [/quote]
No QML is not like training wheels, you use training wheels while learning how to ride a bike. By stating this you imply that QML is used by people that do not have the skills needed to code up a GUI using pure C++, when it's clearly not true. It's widely used because it greatly reduced the apps "time to market".
Don't get me wrong I do understand that there are use cases that require code written purely in C++. But to me you just sound like one of those guys going on about how Assembler is so much better than C/C++ and every real programmer should only code in Assembler.
And again Qt's code does not come into being by it's self it's a fruit of the Trolls hard and on going work (pleas respect that), and even Trolls aren't supper heroes and their man power is limited. The thing that gets me the most is that you go on about how it's all bad and yet fail to see that you could redirect some of that energy into actually contributing something to Qt.
Granted you're very good at making noise.
-
No, I don't think assembler is better, yes it is faster, but it is different for every platform and it is not applicable unless you are writing something really low level like a compiler or a short performance critical routine.
You just took the training wheels analogy too literally, I didn't use it in full parallel to QML, even thou people that are new to programming can use QML and achieve some eye candy which will not be possible for them with C++ right away, I do realize experienced developers might also want to use QML for time saving and such. I still think with the right native frontend, coding a Qt Quick application could end up faster for various reason besides not needing to design with the limitations of QML in mind and glue custom C++ objects.
I do respect the work of trolltech, that is part of the reason I feel so bad about the direction Nokia is pushing things ever since the acquisition. Me being critical has nothing to do with disrespect. I am just the type of person who cannot force himself to praise with admiration actions that I don't find adequate.
-
[quote author="temp" date="1335011895"]
@minimoog77 - no one is scared of QML, just for lots of people it is not needed, and having to use something you don't really need to use just so you can get access to an improved GUI backend is..., well, just stupid. [/quote]
No it's not. If you want static UI, QWidgets is enough for you. But once you start animating, it's not. Then you go to QGraphicsScene, but you will end with lot of micromanagement.QWidgets will stay. QGraphicsScene will stay.
You have you choice. Nobody forcing is you to use QML.
[quote]
The word stupid might not mean a lot to someone, whose idea of a shining example of an application is Angry Birds, but again, looking at the poll results so far it would appear over 2/3 of Qt users share my opinion. We cannot all be impressed by Angry Birds, no matter how successful it may be for a wide range of very sad reasons. [/quote]
Angry Birds it's just an a example of using C++ with combination scripting language. It's natural thing to do. -
QML is a cool way to write simple UIs, but it just doesn't fit every developer needs.
- it has an overhead
- It just doesn't scale up well, would you really port a complex interface using QML, for example blender?
- It doesn't report common mistake that compilers usually reports (especially clang is making huge improvements in this field)
- You can't do any static analisis (which is really useful and it's improving)
- It's LIMITED, you can't do a lot of stuff using QML (for performance reasons), you need to create a plugin for each "strange thing" you want to do which lengthen times A LOT
- It's not portable, as many developers reported, HTML+CSS is much more portable and easier (for web designer too)
As i see it, QML is NOT USEFUL(it's replaced by HTML+CSS/json), the only context i can think of is Symbian and few simple applications.
As a project manager i won't use ever use QML, as i see it now, it's just a toy. -
I appreciate the work done by Qml developers. They have done very well what they have been told to do. And I don't have anything against Qml. But I have voted for a purely c++ UI api, because I'am a c++ developer and it is more comfortable for me to do things the C++ way.
For people who think c++ is not the right tool for fluid GUIs, on the iPhone we do all the UI stuff in plain Objective-C. So why not C++. So any argument that a declarative language is needed for fluid and flashy UI is simply not true. And not all mobile apps need a flashy UI. Qt developers are C++ developers. A vast majority of them have no experience in html / css / Javascript. I was surprised that instead of enhancing the existing QWidget api which the c++ devs are familiar with, a new declarative language was developed. This along with some heavy promotion of Qml on the blogs are responsible for some misunderstanding regarding Qt support for C++ in Qt 5.0
Comments like ' It is expected that entire applications would be written in js / Qml without c++ ' only helps to create confusion. If I can write my the entire logic in JS, I would prefer HTML5 for UI. Again on some other blogs there are some people who have created applications using Qt quick and what they highlight as the important point is that they don't use c++. We can't blame people, if, after seeing all these, they doubt Qt's commitment to C++.
-
Before going further, I should first qualify my experience. I have not used QML for anything "real". I have only gone through the tutorials and examples provided in the QT documentation. Based on what I saw, I did not feel the need or desire to learn the QML/QtQuick way of doing things.
From what I understand based upon this minimal experience, I am puzzled why the choice was made to move forward with a different language solution first before first establishing a proper use model and conceptual API in C++ first.
From reading various posts on numerous threads, my understanding is that the primary guiding reasons to create QtQuick1, QtQuick2, and QML were:
- The "procedural"/imperitive paradigm of the QWidget painter architecture was not scalable to hardware acceleration. Thus the need for a way to "declaratively" describe a UI so that the underlying implementation could optimally map it into availabel graphics hardware resources
- There are various visual effects that are difficult or infeasible to do in the QWidget architecture
- QWidget and QGraphicsItems sometimes had performance problems that were intractable without moving to a different architecture
- There was the perceived need to more rapidly create UI's using a specialized textual language that was somehow better suited to this task than C++ code using QWidgets/QGraphicsItems. It was felt that such a textual description would be more usable by "designers".
- There was the perceived need to be able to use an interpreted description in order to provide fast iteration of changes in the UI. In addition to this, some also felt that this architecture would allow for network transparency.
- There was a perceived need to be able to avoid making binary compatibility guarentees.
I hope the above list is mostly inclusive of the true reasons. Perhaps, someone with more knowledge can help us understand other reasons that went into the decision process.
Items 1-3 seem to be performance and/or architecture related and have little to do with the exact method used to formulate the description of the UI. Items 4-5 are mostly related to how to describe the composition and behavior of the UI to the underlying graphics system. Item 6 is more related to logistics of providing a complex framework to a wide variety of users.
I don't believe there is any argument by user "temp" and others that Items 1-3 are important and need to be addressed in some way to keep QT up-to-date and modern.
Regarding the choice to create QML to address Items 4-5, as user "temp" has talked about in this thread as well as several others, there appears to be little that a special purpose language (QML) can provide that a properly structured C++ API could not. If you look at the currently available documentation on all the QML elements, the documentation looks remarkably similar to what you could/would provide for a C++ based implementation of the same elements. There is a list of "properties" and a list of "methods". Obviously, C++ classes can easily support "properties" and "methods". Embedded JavaScript provides procedural functionality that can just as easily be provided by C++ statements. Slot handling could be handled in a straightforward way by function objects or lambda functions (a C++11 feature admittedly). A properly working "make" system could quickly build a new C++ based UI in a few seconds or less, so the interpreted language argument is not convincing. Even network-transparency would appear to be a solvable problem using a serialized version of the resulting data structures.
(continued on next post)
-
(continued from an earlier post)
In addition to providing duplicate functionality to what C++ could provide, creating and supporting QML has some significant downsides. These include:
- The requirement to learn a new syntax (QML)
- The user requirement to learn a new set of QML elements. Not that this wouldn't need to be done for an equivalent C++ implementation, except that C++ versions of these elements would probably closely mirror the QWidget versions.
- The requirement for a new parser for QML
- The requirement for a Javascript interpreter (apparently V8 in Qt5) with the concommittant requirement of porting and support. Moreoever, it appears that using V8 could preclude Qt's use in iOS - maybe this has changed, but I had heard this somewhere not too long ago.
- The runtime and memory overhead of the QML interpreter. Some may argue that this is very little. Some would argue that it is significant. I haven't seen concrete data one way or the other. In any case, there's no question that the runtime and memory overhead are > 0.
- A more complex build environment that can understand QML files and their inter-relationships and dependencies.
- A larger and more complex QT distribution which is harder for the open-source community to understand and contribute to.
- The opportunity cost of developing all the QML infrastructure. That is, the engineers who did all the QML specific development were not available to improve other areas of QT.
The best argument that I've seen to date about the utility of QML is that it allows the QT developers more freedom to change the underlying implementation (in C++ of course) without incurring the binary compatibility problems that can come up with C++ API's. But even here, it would seem there are several alternatives. One is that a high-level C++ API could be provided along the same lines as the currently available QML elements. These high-level API's could use the same compatibility mechanisms as have been successfully used in Qt4.X for many years. There could also be a statement to the effect that if you want to use the mid and low-level API's (scene-graph and GL stuff) that these might change and there will be no guarentees of source or binary compatibility until some future time.
Somewhere in this thread or one of the others, temp/Dian made a "challenge" to the community at large to come up with specific use-cases of QML that they perceived provided significant benefits that C++ implementation of the same could not provide. I believe this is a valid challenge that the architects of QML and others who are highly "pro-QML" should attempt to do, if for no other reason, than to satisfy themselves that QML really is providing significant benefits above and beyond what a straightforward C++ implementation could provide. temp/Dian also volunteered to help define a streamlined C++ way of doing things, if only he were provided examples of things where QML was perceived to provide value. And these sorts of examples would go a long way to quieting the growing contingent that appears to be unconvinced of QML's utility.
All in all, my current opinion, as controversial as it may be, is that the management of QT made a serious mistake at least in the order in which they developed/released the new GUI functionality. They should have first defined/developed a C++ version of the GUI API. Then, once that had been developed and at least some experience developed with it, then QML could have been developed to address the other segments of the user-base which still deemed QML to be important.
-
Because question is asked as is I voted for: "No ..." .
I know that QML is slower but it is more elastic and UI can be done faster in it.
I don't know Apple graphics something ... framework which was mentioned few times here, so I don't have whole view on the issue, but for my needs QML is enough.However I find reloading of a table, containing many many elements, done this way a little bit "slow". Off course "slow" is as always relative to user experience and expectation.. :)
@
Grid {
id: measTableGrid
rows: tableViewModel.tableModelData.tableRowsCount
columns: tableViewModel.tableModelData.tableColumnsCount
Repeater {
model: tableViewModel.tableModelData
delegate: MeasTableDelegate {
width: isFirstColumn ? 2*UI.FONT_SIZE : tableViewModel.tableModelData.standardWidth
model: tableViewModel.tableModelData
}
}
}
@ -
I think there are probably a number of people who would be willing to contribute to the C++ API if only there were a bit more documentation or examples available.
For example, perhaps, some set of people might be interested in putting together C++ classes that mirror the currently published QML elements. The problem is that at least for some of these, it is difficult to know where to even start. If one of the current developers could perhaps create an example of what a C++ API class could look like and an explanation of how it interfaces to the lower level API's then some volunteers could get started looking at this example and actually make some progress.
As it is now, the code base is simply too intimidating for anybody outside of the main developers to really do much with. Can any of the developers comment on whether any sort of examples (at a minimum) could be made available?