3 ms·
I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't wan
by sametmax 9y ago
I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be.
My OS has UI semantics. I want most of the apps to work the same everywhere. Your app is not special. Stop reinventing a "visual identity". Give me congruency and features.
- jerf 9y ago"I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be." Actually, I'm not referring to things like colors or fonts. What I'm referring to is the fact that had the web-browser style layout algorithms not been already invented by web browsers, they would have been invented by the inexorable progression of the pressures and features in desktop toolkits by now. If the people using web toolkits want to be able to lay things out without having to laboriously bundle things into horizontal and vertical scaling groups and specify flexing ratios and all the other crappy layout mechanisms used in desktop toolkits since they first came out, but to use a simple (to use, not implement), powerful HTML-esque layout mechanism, you're going to pay for that on the resource consumption. And the people writing these programs want that, and will use toolkits that offer that, and if that's bothering you, well, spend some time writing this stuff yourself and you'll stop being bothered, you'll happily spend 100MB of the user's RAM to make the pain end. As neat as it is in some ways, and as much as it has been made to sing and dance over the last 50 years, that style of layout really stinks to use.
- mwcampbell 9y ago> you'll happily spend 100MB of the user's RAM to make the pain end. And users, at least the savvy ones who hang out here, are saying that this RAM isn't ours to spend. Is there no way that we could spend more resources on our dev machines instead, at build time, to take a piece of code that was pleasant to write and convert it into something that's frugal with resources on the user's machine? C++ and Rust promise abstractions with zero runtime cost compared to the best that you could hand-code. I wonder if the same can be applied to multi-platform GUI toolkits, perhaps through compile-time metaprogramming.