@grd I need some precisions to understand fully your opinion. > That is why we today need to live with C++ and C, and Windows, and the WWW > and you name it.
What's the problem with it ? They might all seem old technologies WWW being very different from an the OS Windows, and the two languages. They evolve and we are still making great software with it. > After you compiled clang, or the Linux kernel a couple of times you maybe > realize what I mean. I said "maybe". This formulation is kinda irritating. Precise your point rather than expecting us to derive it from little hints and understand it. If you think those are bloated software, that takes a lot of time to compile, because they try to pack too much stuff, is it related to our GUI development ideas ? Are they really packing _that_ much bloat ? Sagemath needs at least 3 hours on a good processor to compile (and may require from 5 to 10 Gio's to install). I can compile the Linux kernel in less than that. I can't even answer, because I am unsure of what you meant. > This is why you need to have two screens, you need to add more RAM and you > need to replace your computer. You are stretching too far. Is it related to our problem ? (Replying you on my one only screen). By the way, using two screens is not the best solution, from a health perspective. It is in general recommended to use only one screen. I have been using multiple 10 years-old computers recently. We are getting out of the point of this discussion. > There is a word for this, the dependency-trap or the application-trap or > something. Are we even forced to fall into it ? Can we not improve with user > feedback ? Without packing software on top of each other ? I think so. Your opinion is terribly negative right from the start. This discussion is here to envision graphics rendering and ideas to unite them. Yes we will maybe not achieve it. Maybe, we'll get only partial solutions. It doesn't mean, we'll make one heavy library to do everything. It might be just a kind of DSL/converter that outputs in your API library. It might be something like pandoc, that transforms your GUI into a CLI spec, that you will have to rewrite manually after due to an imperfect intermediate representation. This is far better than nothing. It might also guide specific libraries to be easier to switch from Web to Desktop GUI development. I am personally really interested to see more GPU accelerated rendering for the web to arise. It will probably have an ecological impact. But we have to keep in mind that many GPUs ressources are not yet fully used and are just going to waste. The webGPU w3's specification is one promising API struggling against so many hardware limitations. See, we can still have progress in one seemingly daunting endeavour. I prefer desktop applications, because I can trust them much more easily. We can check Internet traffic, ressource access, while it looks more complex on the web, with server's backends and data being easily fetched by library/APIs. Yet, I like the HTML/CSS/Javascript GUI dev design. It separates well content from style. Latex (pdf rendering is another form of interface, with some form of content protection) and desktop GUIs do not achieve it as well. @minnim Thanks for your summary of Nim GUI's libraries. I have only fiddled with Nigui's library so far.
