Earlier quoted context omitted.
I'm hoping that Microsoft just implements it natively eventually - their window snapping/tiling-lite functionality has been steadily getting better so they clearly have people working on this kind of window UX QOL stuff.
> window snapping/tiling Put me in the camp that hates window snap/tiling. I have a certain workflow that needs this window there, and this one here ... don't snap to a location or go full screen.
Closing a 30 pixel gap between native and web
261–270 of 313 posts
Re: Closing a 30 pixel gap between native and web
#262Earlier quoted context omitted.
And it doesn't support window and monitor layouts that were possible and useful in Visual Studio 2003, or probably earlier.
Agree. VS Code is simply not comparable to a full blown IDE. It's a text editor with some integrated language tooling.
Re: Closing a 30 pixel gap between native and web
#263Earlier quoted context omitted.
I much prefer what a lot of Linux desktop environments support, which is holding down alt and clicking anywhere on a window to move it. With that + a keyboard shortcut for closing a window you can get rid of title bars on apps entirely if you want. Sadly Windows doesn't support it natively, although there's another comment on this thread talking about ways to make it work.
I love this feature and it's since become indispensable to me. I find it pretty funny that my #1 favorite desktop UI feature is from Linux. One of the first things I'll put on a fresh install of Windows or MacOS is a utility that re-creates this behavior. I use AltDrag on Windows (requires a quick tweak for HiDPI): https://stefansundin.github.io/altdrag/ And Easy Move + Resize on MacOS: https://github.com/dmarcotte/e…
Re: Closing a 30 pixel gap between native and web
#264Earlier quoted context omitted.
> I think web is taking over on Windows because any of 10 or 15 different design systems can get you to a better app than the native (whatever that means) toolkits in much less time. It is easier to get a decent color picker in a web app than a WPF, WinForms, UWP, WinUI, or Win32 app (assuming you have a reasonably high expectation for UI/UX, as I do). I'll grant you that it's probably easier and cheaper to get a wor…
I think I agree with you, but I need a clear definition of "cheaper." To me, "cheaper" means that companies are putting fewer resources into Windows-specific app development. That's not unexpected, given large portions of their user base are using MacOS, Android, or iOS. Why would I hire 8 developers to make 4 apps, when I could hire 6 developers to make make 3 or even 2 apps? Oh, as an added bonus, now my app can al…
Re: Closing a 30 pixel gap between native and web
#265Earlier quoted context omitted.
I see this all the time, and I honestly do not get it. As someone that has ported a game written in C++ for Windows to Linux... its not that hard. It took me 2 days, about 4 hours of work total, and most of the ports I had to make were because I'm an obstinate developer and didn't use the std lib functions that would handle the OS wrapping for me. Now, I've never ported an app to mobile, and that may be entirely diff…
Porting a large-scale windows desktop app to linux takes engineer years.
Re: Closing a 30 pixel gap between native and web
#266Earlier quoted context omitted.
The bottom line is that Electron is portable. Unless native apps become as portable as Electron there will be a need for this layer. The optimistic scenario is that WASM becomes the single target that everyone settles on, and that the performance penalty is minimized while the security sandbox is strengthened.
Java Swing apps were portable across Windows, Mac and Linux desktops waaayy back in 2004 and probably earlier. Write once run everywhere _was_ very much possible back then. The biggest complaint was they didn't look native. From working on a Swing application back then, management and marketing would often ask if we could make it look more like other Windows applications, because looking like a native Windows XP appl…
For enterprise apps with no strong competitors these minor aesthetic issues didn't impact revenue so those UIs remained in Java. But for everything else it was worth it (financially) to migrate to native.
I sometimes armchair quarterback and wonder whether Java would have been more successful if the Swing folks had focused more on design. It seemed like the most they ever did UI wise was attempt to catch up to platform native widgets so they were perpetually several years out of date and slightly inconsistent. Had they skated to where the puck was going to be rather than where it is perhaps Java applications would be the ones people pointed to when asking devs to "make it look sexy" instead of iTunes.
Re: Closing a 30 pixel gap between native and web
#267> installed desktop web apps are really starting to look and feel like native apps I think we are having the opposite problem: native apps are really starting to look and feel like web apps, and in many cases, they are. The problem: the web has a terrible UI toolkit for desktop apps. It has clickable links and basic forms, that's all. It was made for documents, not apps. If you want better than that, you have to rewr…
Re: Closing a 30 pixel gap between native and web
#268Earlier quoted context omitted.
Agree. VS Code is simply not comparable to a full blown IDE. It's a text editor with some integrated language tooling.
Of course it is comparable. They are not quite the same thing, sure, but for many people they are definitely comparable and more often than not, VSCode is the better option. It may not support some things, but the same can be said about the “full blown IDE”.
I don't know how you came to that conclusion but I'd guess that you mostly work on small projects? (where I'd say smallish is Stuff I'd miss in VS Code coming from JetBrains Rider:
- Docking of panels to top, bottom, left, right
- built-in database explorer (with table designer, script runner, ...)
- built-in unit test explorer
- built-in memory/perf profiler (not talking about a simple text interface!)
- nice config options of project settings (in either text with completion or the UI)
- NuGet package explorer UI
- integrated IL viewer
- great git blame / annotation view
... could continue for a while
Re: Closing a 30 pixel gap between native and web
#269Earlier quoted context omitted.
VSCode is adequate, not great. The bar for responsive and minimal application is so bad these days thanks to web apps.
You can make fast web apps and you can make slow native apps. Check out VSCode's older brother and be amazed by how unresponsive and glitchy is.
Re: Closing a 30 pixel gap between native and web
#270Earlier quoted context omitted.
VSCode is adequate, not great. The bar for responsive and minimal application is so bad these days thanks to web apps.
It's great and the best desktop app I've ever used.