3 ms·
It's a Win32 app, that just so happens to use UWP-like XAML for the UI. In the near future, the lines between a UWP app and a Win32 app are going to get blurrie
by zadjii 5y ago
It's a Win32 app, that just so happens to use UWP-like XAML for the UI. In the near future, the lines between a UWP app and a Win32 app are going to get blurrier and blurrier, until you should be able to do anything from either type of app (and there's no longer any distinction at all).
I'm actually hard at work on tearing out tabs - it turns out that's a bit of a hard problem, but one we've got a plan for!
> the app was very slow
We actually fixed one particular memory leak in this release that was causing a lot of sluggishness. That might be better now!
> the UI, context menu, sizing/scaling, animations, all felt very bad
Unfortunately, "it felt bad" doesn't really give much constructive feedback to work with. Anything specifc?
- siproprio 5y agoFelt bad = Feels like it was designed for a touch screen, with mouse and keyboard as an afterthought. Specific examples are spacing, which is bigger on uwp; latency and animation speed; and of course, windowing. In terminal settings, for example, the settings editor is limited to the terminal window, and the save buttons are aligned to corners. That means, for example, if the window is too big, the buttons are going to be very far away - lots of mouse travels, it means also that the window sizing will not be ideal - look at settings in Mac apps - there's a popout panel which adapts in size. If the window is small, things will be cramped. On low resolutions or smaller screens, things are too big and cramped. The save bar occupies a large emtpy space bar on the bottom. On large screens, high res, it's comically huge and with mostly empty space. It's just stupid. Is this specific enough? I just saw in an issue about this your PM say you're following uwp guidelines. That's certainly a part of the problem. It's the classic "Garbage in, garbage out".