There are security problems, visual problems, input\/”feel” problems, compatibility\/driver problems, deployment\/packaging problems etc. to deal with when designing a system like this. But it’s important to remember that none of these matter unless the desktop system is fast enough to run apps.<\/p>\n\n\n\n
The desktop system doesn’t have any particularly crazy design constraints and isn’t intended to prove any new models of interaction. Just basic desktop computing stuff first, plenty of time to worry about more interesting innovations later.<\/p>\n\n\n\n
The desktop system is designed networking-first, this helps both to test networking functionality and enables more opportunities for supercomputing applications in the future.<\/p>\n\n\n\n
This doesn’t mean the protocol is perfectly designed, just that the system is definitely designed for network operation and that this isn’t an unsupported mode of operation.<\/p>\n\n\n\n
My desktop experiments in the past have been inspired by old computer systems and I originally tried to design towards a particular style to match the level of consistency in older operating systems.<\/p>\n\n\n\n
I eventually realised that focusing on consistent look-and-feel would hold the platform back and would limit the usefulness of ported software and of any other people’s experiments on my platform. After all the interface you might want for a heavy duty CAD program or game might not overlap at all with the interface you’d want for a text editor or a file manager, and something inbetween like an office suite would probably need some other balance of standard & customised features.<\/p>\n\n\n\n
So with this in mind the design will be a little more similar to X11 than I originally intended, and should gradually allow more and more customised desktop environments as well as very diverse kinds of apps.<\/p>\n\n\n\n
Some GUI systems do all the layout & rendering stuff within the application (client-side widgets) while others defer more of it to the GUI backend (server-side widgets).<\/p>\n\n\n\n
Neither of these approaches are good enough for every use case, sometimes one or the other method may be faster depending on the kind of app or the mode of operation, and both have pitfalls.<\/p>\n\n\n\n
So the only real solution is to have some basic facilities like simple font rendering built-in and to have other things like more advanced font systems controlled fully on the application side. This allows simple apps to avoid wasting space or reinventing wheels while also supporting more advanced apps that might have unusual methods of interaction.<\/p>\n\n\n\n
The system should eventually be useful for all kinds of programs, but should generally be optimised to ensure that the simplest visual apps like administration tools and wireframe\/stick-figure\/CAD-style rendering work reliably over a network connection.<\/p>\n\n\n\n
The desktop system is intended to help prototype real apps for my OS and also to be useful in ad-hoc supercomputer setups, this means that both in the short term as well as the long term it’s very important to try and allow running the desktop system on other platforms either for testing in-progress apps or for interoperability in real-world use.<\/p>\n\n\n\n
These techniques are pretty easy to demonstrate but can take a little while to optimise properly, so I want to avoid any unnecessary tinkering until I have a reliable system together. For now the rendering functions are intentionally kept simple at the cost of not looking as pretty as a full-featured version, while I focus on more critical features like stability & input management.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Performance-First There are security problems, visual problems, input\/”feel” problems, compatibility\/driver problems, deployment\/packaging problems etc. to deal with when designing a system like this. But it’s important to remember that none of these matter unless the desktop system is fast enough to run apps. Traditional Design The desktop system doesn’t have any particularly crazy design constraints […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-984","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/posts\/984","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/comments?post=984"}],"version-history":[{"count":4,"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/posts\/984\/revisions"}],"predecessor-version":[{"id":988,"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/posts\/984\/revisions\/988"}],"wp:attachment":[{"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/media?parent=984"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/categories?post=984"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/securelang.net\/cms\/wp-json\/wp\/v2\/tags?post=984"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}