Any App with a menu generally works as I described. And that hails back to the System 7 days, and also NextStep was the same from what I remember (though I mostly used OpenStep.)
System Preferences (especially the iOS-ified version) breaks a lot of rules. The "classic" version is really similar to the System Prefs in Next/OpenStep. The classic version was a single document interface, and it used a back arrow to go back a level. The new one has more persistence IIRC with the list down one side.
This is a MacOS thing - an app is not just windows, it is also a menu. The windows can all be closed and the menu is still there. Apps that don't behave like that feel like they are not proper Mac apps. As a seasoned Mac user, cmd+Q is your friend.
They were still in complete control of the platform though. You couldn't just take a OS build and put it on another generic computer without a lot of hacking and/or picking hardware as close to the actual hardware that the OS could handle the differences. I know people did it - heck I had a hackintosh netbook back in the day, but it was not a trivial process and someone had to have done the work already for the "Average" consumer.
Getting any legacy OS to run on modern hardware is very hard. For example, in my case, BeOS has no EFI boot capability, has a serious RAM restriction, doesn't really like anything past a P4, and has no drivers for anything but legacy hardware (like, no modern storage drivers - IDE only, no SATA unless there is legacy BIOS emulation.) A lot of this is able to be worked around with various hacks, but with 86Box, it will run the OS as is it was on the actual hardware, so it just makes it a no brainer. You can then also use it to emulate old PC hardware on other processor architectures - like ARM.
It wasn't really. It was just another closed platform. BeBox had a real struggle to boot anything but BeOS and the platform was so poorly documented that other than the manuals that came with it and the few brief descriptions in Be Newsletters, there is no real public documentation about any of the hardware. It was also smoke and mirrors, it barely worked in MP mode because the 603's they used didn't do proper MP. There was a software process that had to work around this, which then slowed down the OS in general. The dual processor Mac's with 604's actually ran rings around the BeBox performance wise.
Nitpick, nitpick: BONE was actually a BETA for R5 also, but it was also never released. The Dano version was much more mature and Dano in general is a much later version of BeOS with a lot of changes under the hood.
I think this is very much an age dependent thing for me. When I started programming, there were no LSPs. There was not even any real code completion. I was using the Delphi 1 IDE in my first job and that didn't even really have any type checking till you compiled.
I think Delphi 3 was the first version with basic completion.
I do feel like I have suffered and become a little too dependent on LSPs/AI over time. But it is easy to see why when they can basically write your next line for you with quite a lot of accuracy these days.
"clay ui" actually fails. My top hit is: https://clayui.com/docs/get-started/how-to-use-clay which is a completely different UI library from what I can tell, and probably had the name first too as the Git repo has commits from 4 years ago.
I am forever horrified when my 5G phone, which at my house already only gets 4G at best (the politics of cell towers in Southern England is just a sad sad story) drops now to 2G!!! Dropping a modern smartphone to 2G is like basically saying "no network". The only things I use it for are unusable. I rarely make calls. I rarely send SMS. Vodafone dropped 3G, O2 will drop it early next year and the others some time soonish too. Using a smart phone in a rural area now kind of feels like going back to 2007 if I am going to be honest.
Sure, but the first link is surely only benefiting those using Windows on ARM? I do have Windows on ARM on a MacBook under VMWare, but my daily usage of Windows is under x64. Second link - not really knowing much about Java I don't know enough to comment. 99% of my Java use is indirect because it only gets touched by MSBuild when compiling my APK from C#.
I use the Microsoft JDK daily - to develop in Maui for Android. Other than that, I'm not too sure what anyone would use it for over the actual OpenJDK versions. I'm pretty sure the MS OpenJDK is mostly there to support pushing people to Azure (hence your observation) and Android. I don't think it is there for much else outside of that, but I'm happy to stand corrected if anyone has another use cas for it.
I wish they were SVG, that would make rendering them less of a headache.
There is still no good library which takes in a MVT tile and spits out the appropriate PNG or JPEG for rendering in via a tile base mapping engine. There is still no good cross platform mapping engine that can render vector tiles in a way that is easy to consume. There are certainly engines on specific platforms, but unless we use something like Leaflet or OpenLayers it is hard to make it work with native APIs on, say Windows, MacOs, Linux, iOS or Android without needing to adding a whole browser engine on top of your app.
Interface Builder was a lot more like VB and Delphi in the past, but around the time of iOS 3, Apple completely broke the UI programming metaphor in it. It used to be all drag and drop (with quirks) but actions were like event handlers and outlets like events. Before it was "code first" you could do it all in the UI. I used it quite a bit before XCode existed (XCode used to be ProjectBuilder, even on like Jaguar/Panther IIRC) and it was very close to the version of the same on OpenStep.
Xaml designer - well, the designer is not really a thing because Xaml is usually not created as an absolute layout. There was a version of the Xaml designer early on that would attempt to build a UI that looked absolute, but it did a lot of horrible Xaml markup in the background and made maintaining the UI way harder than it should have been. We (Xaml users) all migrated to using it as pure markup and mos of us now use hot-reload over a designer.
VB beat Delphi to market by a number of years. I remember Delphi 1 arriving in about 95. VB was on version 3 (though I honestly don't remember the prior 2 versions.) I do remember a lecturer in University saying that he was excited for Delphi, because it was going to shift the dominance of VB in the RAD programming arena.
With multiple repos, we can get a single deliverable for each project requirement, manage convergence and still maintain a main branch for each repo. The artifacts can be packaged and consumed by the other dependencies that are changing. It stops monolithic development. It library A needs to branches of change, we don’t need to create 2 branches for the entire product line. You literally only change the parts you are currently working on, and insignificant changes don’t get sucked in by proxy.
No offence, but you might be a little confused by how complex your actual delivery is. That sounds simple. That sounds like it has a clear roadmap. When you don’t, and you have very agile development that pivots quickly and demands a lot of change concurrently for releases that have very different goals, it is not possible to make all your ducks sit in a row. Monorepos suck in that situation. The dependency graph is so complex it will make your head hurt. And all the streams need to converge in to the main dev branch at some point, which causes huge bottlenecks.
Good for you. For us, because we have multiple projects going on, pulling the code in different ways, code that runs on embedded, code that runs in the cloud, desktop apps (real ones written in C++ and .Net, not glorified web apps), code that is customer facing, code used by third parties for integrating our products, no - it just doesn’t work. The embedded shares a core with other levels, and we support multiple embedded platforms (bare metal) and OS (Windows, Linux, Android, iOS) and also have stuff that runs in Amazon/Azure cloud platform. You might be fine, but when you hit critical mass and you have very complicated commercial concerns, it doesn’t work well.
monorepos are appropriate for a single project with many sub parts but one or two artifacts on any given release build. But they fall apart when you have multiple products in the monorepo, each with different release schedules.
As soon as you add a second separate product that uses a different subset of any code in the repo, you should consider breaking up the monorepo. If the code is "a bunch of libraries" and "one or more end user products" it becomes even more imperative to consider breaking down stuff..
Having worked on monorepos where there are 30+ artifacts, multiple ongoing projects that each pull the monorepo in to different incompatible versions, and all of which have their own lifetime and their own release cycle - monorepo is the antithesis of a good idea.
If you open, say Android Studio (or IntelliJ) and start a new project, then open Rider and start a new project - the UI is actually very different for how the projects are managed. PyCharm is different too in different ways.
I think the differences are more akin to the old Visual C# Express and Visual Basic Express IDEs vs Visual Studio. Visual Studio was always "everything", but you used to get the express versions that were "low cost" or free. They only had the single language in them. They were customised to just that language. This is what Rider is to IntelliJ Professional, except from what I understand, the plug-ins for IntelliJ are not always on a 1:1 feature parity. This can even be seen with Android Studio and IntelliJ Community. The Android tooling in IntelliJ Community is almost the same, but it does miss out some stuff in Android Studio. Because Android Studio is specifically for Android development, and IntelliJ Community is more general purpose Kotlin and Java development. I think the Kotlin Native support is slightly better in IntelliJ Community.
With regards to multiple inheritance, this was the C++ Builder criticism, not mine. That and the extra macros needed to support the VCL. I was a Delphi guy, so I appreciated that the Object Pascal version of using the VCL was cleaner to use than the C++ interface.
We no longer use C++ for UI. Any native code is wrapped up in to P/Invokes. I think all of our MFC apps are EOL now. Everything is WPF or Maui for cross platform.
The C# dev kit plug-in improved VSCode a lot, but it is still under the same licensing as Visual Studio Community. So, you need an account to use it, and it is pretty restricted for commercial use without an MSDN/Visual Studio subscription. If you are using it commercially outside of the terms of the Community license, you are probably using it illegally.
Not using the C# Dev kit, the old OmniSharp stuff is miles behind Rider. It is really poor in comparison.
I've been a previous subscriber, but I let my license lapse after this announcement. I don;t really need to be on the "latest and greatest" train, and I can get my company to buy me a license if a new feature comes in that I need commercially. I have got a perpetual fallback Rider license, but I will also use the non-commercial licenses to do any OS work in my spare time going forward (which is mostly on Mac and why I had a paid licence initially anyway.)
I think the issue used to be that proving that involved them vetting you and I know that my contributions were deemed too sporadic. Which is chicken and egg - I would do more with a good IDE, but I can't have a good IDE till I do more. At least now, I can just do what I can without worrying.
It depends on the platform. For example, Rider on Mac will not open vscproj/vcxproj files, because it doesn't support C++ really on non Windows. But I think that is mostly because it would need to use a different C++ compiler and that is non trivial. I would imagine it would also struggle with project types that are not normal (VS extensions, installer projects etc) and C++/CLI as that is not supported outside of Windows too (and I think uses the standard vsc[x]proj file format anyway...)
The latest version can now even open SLNX files, which are the newest format that removes a lot of the stuff that makes VS Solution files painful to maintain in source control.
I haven't touched C++ Builder since mid 2000's. Does it still rely on the VCL? That was always the criticism I heard at the time. The VCL was written in Pascal and no C++ developer liked that it was not C++. It constantly got flack for it. The VCL was good at the time, but Pascal is more akin to C# in the way it does inheritance, so no multiple inheritance was able to be done with VCL components IIRC.
Not sure which version of VSCode you think the new UI is a clone of, but I don't really see it. The tool buttons? VS has always had those, thought they had text by default. Tabs? VS has those too. Bottom bar? VS also. In fact, Rider looks like all the other Jetbrains IDEs - except Fleet, which is actually their VS Code competitor.