 So, let's see, I'll be giving a talk on API design and QML, so let's see. In this presentation, I'm going to go over what I consider to be the main type of QML APIs, the digital component APIs, the non-digital APIs that you can build with QML, as well as the general API guidelines for QML, and the design process that I personally use and an example that we use in that design process to build an API, so, whoop, hold on, let's see, hold on a second, so let's see, let's see if you're watching this presentation, I hope that you already know what QML is like, so you have the basic declarative syntax where you specify an object and you specify its properties and functions on it as well as the signals to react to other things, so, let's see, like QML is generally like about the exchange of data between the declarative QML site and the imperative C++ site or if you're using another language like a Python or a Go, your imperative site of the code can also be built with that, so, I generally consider there to be two main types of QML APIs, let's see, the first is what I would like to term by elements, which are the visual components that you can see in QD Quick applications, and then let's see, there is also what I would like to term by processors or utility data processing components or anything else that doesn't show anything visible on the screen, so, let's see, hold on a second, let's see, let's see, so there are generally two main types of visual components, so let's see, the first type is what I would like to call it, leaves or, these are generally the end nodes and the tree of items in your QML programs, you generally don't put other elements inside these elements, these are your controls like buttons, checkboxes and etc., let's see, you also have the branches that are components that are generally used for putting other components in, such as the layouts and other miscellaneous components like the Kirigami page pool and let's see, so, first I'll cover some specific considerations for deciding leaves, like, since the leaves in your public QML APIs are most likely going to be controls, let's see, like, it's generally a good practice to either inherit from the control type found in QT Quick components too or the abstract button type if your element is for clicking, so, let's see, let's see, use the controls expect that, controls should have appropriate sizing set automatically based on the input of the properties that you use in the APIs, so, let's see, like, sizing is generally exposed to the implicit and width and height properties, let's see, like, like, what you do not want to do when creating a digital control is exposed by a pseudo, well, width and height properties as the layouts often change these, let's see, as the width and height are often changed by external layouts, let's see, the content and its padding should dictate the implicit width and height of the control, like, in 99% of cases the background of control should be a subservient to its site and shouldn't really affect the site of the control, let's see, let's see, your control should be able to handle whatever developer throws at it without looking broken, even if it does look a little bit weird, you should also be mindful of options that inheriting from another type ring to the public API, for example, if you inherit from the abstract button type, your control should be able to handle all the clicking and the checkable types of the button, let's see, and then on the other side of things you have what I call the branch controls, these are generally APIs that are used for managing other components like the layouts which is the column layout which arranges items in the column or components that manage construction and destructions of other components like repeaters or the curiculum page holder, let's see, branch components can also make use of attached properties for exposing additional APIs, like for example, layouts use the layout attached property to expose stuff like a preferred height and width, as well as whether you want to fill height or width or not, let's see, for layouts it's expected that you set a sensible default property so that the user of your API can simply put the items inside the parent item in their program source code instead of using explicitly specify a channel property, let's see, like, if you're building a layout and the layout has a special default such as a header or header, you should generally expose these as their own properties, let's see, for specific purpose APIs where you're building both the components and where you're building both a parent component and the components that go inside them, you should generally take care to make sure that these components look like they are made together, let's see, like, generally this means like, these things should be named similarly and let's see, and things that look, and things that affect each other should look like they affect each other, let's see, you can also use attached properties to communicate information between the children items and the parent items, let's see, and that's all I have to say about the visual APIs, but there's also a lot more besides the visual APIs in the QML world, let's see, hold on a second, let's see, on the other side of the API is that you can build with QML or the non-visual ones, let's see, like, for example, this is the QBS build system on this line here, let's see, like, when you're building a non-visual API, it's generally extremely important to know your target audience more so than when you're building, like, a BI with visual components where QT quacks, so, let's see, like, like, talking about QBS, like, QBS, like, while having a purely declutative build system would be nice, it's pretty impractical for real world usage, like, this knowledge of the target audience is why QBS abandons the QBS build system, abandons the purely declutative site of QML and gives the JavaScript engine a lot more tools than the QML engine and QT quick does, such as exposing the required statement and expanding the JavaScript parameters, supporting useful and build systems, such as convenient methods on the array and string prototypes, let's see, let's see, not commonly in QT quick, but used fairly permanently in QBS, that's what I would like to call the annotation pattern, the annotation pattern is an extension of how a task properties are used in QT quick, but it allows it to be more specific and encode more information used in the hierarchy, let's see, this pattern lets individual elements take two forms, a plain unannotated form and a larger annotated form by moving out to its own item, the unannotated form of an item has a sensible default, while the annotated form of an item allows to use and specify more information about an element, such as flagging it with tags or making this application on other parts of the script depend on the condition, let's see, the annotation pattern also includes using attached properties on a larger form items to provide extra information, let's see, besides that, there's not much else specific to non-digital QML APIs it's mostly the same concepts that you see in general API design and speaking of that, there's this one quote that I really like to keep in mind when designing APIs, and it's, let's see, this quote is from Rob Pike, decide the architecture, name the components and document the details, let's see, what, hold on a second, let's see, when designing the high-level architecture of your API, you want to think about the big picture of your API, what do you want the end result to look like, think about how the parent components and your API interact with their child components and advice their set, what actions are the parent components are going to take on the children components, what are the children going to tell the parent about, let's see, what do you want to expose the developers using your API, and then after you've designed your high-level API, you want to think about what you want to name your things, what, when you're browsing a foreign code base, the names of items and properties are going to tell the reader how everything in the program fits together, if your names are obscure and hard to understand, readers of programs that use your API are going to have a hard time understanding how everything fits together and developers using your APIs are going to have trouble recalling what elements they should use to fix their problems, like components should have short names, but not names so short that it expires some reading, and on the other end, long names are cumbersome to type out and remember when they're writing code, a good name and convention to follow is either a single nail, such as a button, or spinner, or input, let's see, or you can do like a note and a verb, for example, let's see, the page router manages pages by routing them, or you can use two nouns together to form your component names, such as the Curie Gummi page pool or the tool button, let's see, for components with variants, for example, list items using a single initiative is often used to distinguish between them, let's say like, for example, you'd have a baseline list item, and then if you want a list item to be expandable, you would have that be an expandable list item, and so on, it's like a common mistake is given the base component of an adjective, such as basic or simple, this is redundant information that makes the name less concise, and it makes it hard to notice which components are subtypes of other components, let's see. Let's see, and finally, like, no good API is complete without the documentation, while a good architecture and names are important for developers to be able to intuit your API, they're not subtypes for documentation, like documentation should, first, give a description of every type, and then after you've filled out a description for every type, you want to describe their methods, properties, signals, and other things, then after you've written the explanations of everything, you should generally add small concise examples that show specific parts of your API. Let's see, let's see. When writing documentation, do not forget that comments are also documentation, nobody likes to read dense 1000 line files with an area of comment to help them, let's see. Let's see, that's all the talk, but it's time to explain how I applied this to designing something, so let's see. Every tool generally has a purpose and it aims to solve a problem, let's see, for the Curriculum API Trouter API that I designed, let's see, like, the main reason why I built this was because I noticed that a state management and page navigation is like all over the place, so, let's see, like, our most complex applications navigation wise tend to hold our own solutions for navigation, for example, I discovered uses a JavaScript file with custom navigation functions for all of its needs, like even simpler applications, like Alisa tend to do a custom stuff in regards to navigation, and especially in communicating data between different parts of the application, like simplifying this navigation and state management is like the problem that I wanted the page trouter API to sign to fix, so, let's see, like, before getting into designing the API, I first wanted to see what approaches other UI frameworks used to building navigation and routing part, or it is extremely important in making sure that you design something recognizable and not totally formed to developers after browsing through and poking with a lot of UI frameworks, I found I liked React and Flutter's navigation API so best, so I took most inspiration from them as well as combining them with QML specific items, like attached properties and the ability to develop domain-specific language as APIs. This is where the first step of API design comes in, deciding the architecture. Let's see, for a page trouter, I wanted to avoid applications having to avoid their own custom navigation solution and having to manually move exposed variables up the tree, so, like, this influenced the main architecture of the API, the controller object responsible for navigation, managing pages, moving data between them. Let's see, attached properties are used a lot in the page trouter's API to move data between them and between deeply nested trees, a component, and then after I designed a high-level approach of the API, let's see, I needed to name the component since Kirigami already has components like the page and the page pool, I named the components after them. The manager object here is called the page trouter and the specification for a page is called a page trout. Let's see, additionally, I named the navigation functions like as a bit of a mix of a stack base, such as like an array and browser navigation, such as navigating to a specific link, so, the methods are named such as push route, push route from here, pop route, navigate to route, et cetera, let's see, I chose this naming to make sure that it was apparent what the components do and what their interactions with each other were resulting in the application, and then after I designed and implemented the architecture and desk components, let's see, documentation was the last thing to do. Let's see, since the page trouter is pretty different from how navigation is usually handled, I emphasized, explained the high-level, how the high-level architecture works before explaining the individual details, I provided diagrams and documentation to help developers visualize how things are arranged and applications when they're using the page trouter API. Let's see, and that's the process that I used for designing the page trouter API, I hope that was enlightening. Let's see, do we have any questions that need answering? Let's see.