I’ve read about Paul complaining that UWP is not making progress and can only be used to build “basic” apps.
As a UWP developer, I don’t understand that claim.
High density UI are possible. It is just a matter of sizing each button accordingly. For example:
https://www.actiprosoftware.com/products/controls/universal/docking
That’s a sample app that looks like Visual Studio (with all the UI features like moving windows, docking, tabs, etc).
It works on Windows 10’s first build (1507).
And UWP keeps becoming more and more powerful for edge cases. For example, it is now possible to launch a UWP app from the command line. So, it is possible to build console applications with UWP.
So, I would like to hear some specific examples of technical features that UWP lacks and that is blocking mainstream UWP developers.
skane2600
<blockquote><a href="#273351"><em>In reply to ecumenical:</em></a></blockquote><p>Most individual developers can't make a living writing apps on any platform, so it's really employers that make or break a platform. There aren't many UWP developers because there aren't many companies hiring them. Windows phone never reached a minimum level of market share to support development and UWP on the desktop was mostly just a redundant subset of what was already available via Win32. So, for the most part there was no business case for third-party UWP development. </p>
skane2600
<blockquote><a href="#273492"><em>In reply to ecumenical:</em></a></blockquote><p>Whether it achieves it or not UWP was obviously planned to allow a class of apps to run on multiple Windows platforms and the emphasis was on mobile with touch being a very important part of the initiative. </p><p><br></p><p>So while a developer can certainly ignore all of that, it's not really unreasonable for someone to observe that a particular application or library is in opposition to the intent of UWP.</p>
skane2600
<blockquote><a href="#273412"><em>In reply to ecumenical:</em></a></blockquote><p>If you're solely targeting Windows. a traditional desktop program allows more design approaches and can take advantage of Win32's greater power. So the question is why bother with UWP? </p>
skane2600
<blockquote><a href="#273490"><em>In reply to hrlngrv:</em></a></blockquote><p>I don't see any moral obligation either way. If people can find a way of to make money by supporting UWP, that's great. </p>
skane2600
<blockquote><a href="#273796"><em>In reply to klients:</em></a></blockquote><p>Can UWP apps provide the ability to be automated from the outside similar to what one can do with vbscript and Office? </p>
skane2600
<blockquote><a href="#273822"><em>In reply to klients:</em></a></blockquote><p>I'm not talking about GUI automation, BTW as someone who has extensive experience in using such systems I can tell you the script you write is very fragile and can stop working if the application you automate is updated in a way that changes the UI elements.</p><p><br></p><p>I'm talking abut automation at a deeper level with something like:</p><p><br></p><p>set obj = CreateObject("Word.Application")</p><p>obj.Application.Documents.Open(aFile.Path)</p><p><br></p><p>etc</p>
skane2600
<blockquote><a href="#273907"><em>In reply to klients:</em></a></blockquote><p>That doesn't really appear to be equivalent and the app service description makes it fairly clear that a UI isn't supported. That would be consistent with Windows services in general.</p><p><br></p><p>But it's not really about a service offering a small set of functionality to apps, but rather a standard way to automate a full app (provided that the app conforms to the standard).</p>
skane2600
<blockquote><a href="#273948"><em>In reply to klients:</em></a></blockquote><p>Isn't an app service (in-process or out of process) the "server" and the code that invokes it, the client? Services don't usually invoke the client. What is the mechanism by which the UI code makes an interface available to the service? </p><p><br></p><p>While vbscript isn't "the" standard way of automating Win32 apps, it is one of the standard ways of automating Win32 apps. At the core, it's all about the Component Object Model.</p>
skane2600
<blockquote><a href="#274567"><em>In reply to lvthunder:</em></a></blockquote><p>It's the ideas that took 20 years to develop, not the implementation. For example, Google Docs took many ideas developed over years from Microsoft Office but was able to implement them in a shorter time.</p>
skane2600
<blockquote><a href="#274610"><em>In reply to hrlngrv:</em></a></blockquote><p>I wasn't implying that every idea embodied in Microsoft Office came directly from Microsoft. The lion's share of credit for the spreadsheet idea obviously belongs to Software Arts with the other companies building on it. </p><p><br></p><p>I would argue though that creating a spreadsheet in a GUI with real vertical and horizontal lines was the single most important added feature that led to a wide adoption of spreadsheets (as is the case with the origin of any technology, it's difficult to say if MS was the very first to do this, but certainly the first to create a successful product using that technique).</p><p><br></p><p><br></p>
skane2600
<blockquote><a href="#274682"><em>In reply to hrlngrv:</em></a></blockquote><p>Congratulations on finding an obscure spreadsheet with lines that may predate the same on Excel. I say "may" because Excel had that feature on the Mac in 1985. I'll take your word that Ability had such a version in the 80s since I can't find a reference for it. The latest DOS version that is shown on Ability's website is a typical DOS spreadsheet without lines.</p><p><br></p><p>I'm not going to argue about relative sales figures of the 80s and 90s since that data isn't really available. We're now wildly off-topic,</p>
skane2600
<blockquote><a href="#275143"><em>In reply to hrlngrv:</em></a></blockquote><p>I doubt I'd get much insight into what made Excel popular by visiting forums that didn't exist at the time in question populated with many people who were children at that time.</p><p><br></p><p>But remember, my original point was just that the number of years it takes to evolve a application to create new functionality doesn't inform how long it takes new applications to implement that same functionality. I just used Microsoft Office vs Google Docs as one example.</p><p><br></p><p>I think we can agree that few if any features of Google Docs were original ideas and that it took a lot less time to implement than it took to come up with those ideas no matter where we want to assign credit.</p>
skane2600
<blockquote><a href="#274200"><em>In reply to lvthunder:</em></a></blockquote><p>"There is no difference in a UWP, PWA, or Bridge app in the store."</p><p><br></p><p>Not sure what you mean by that. As hringrv points out, you can discover differences with some effort and I suspect many apps will self-identify in their description. </p><p><br></p><p><br></p><p>"Also when was the last time a high profile, professional-looking (Office or Photoshop) app was started from scratch."</p><p><br></p><p>Well, when was the last time this occurred on ANY platform? In any case, if new "high profile, professional-looking" programs are no longer being created, that really has nothing to do with relative desirability of developing for UWP.</p><p><br></p><p>I think Paul's more important implication is that developers are going to hesitate to use third-party solutions (which may cost money or may not be supported in the future) to create an interface in UWP that they can do "out of the box" with Microsoft's tools for desktop development.</p><p><br></p><p><br></p>
skane2600
<blockquote><a href="#274390"><em>In reply to klients:</em></a></blockquote><p>Sure. Of course third-parties can't do anything that couldn't be done by the developer themselves. it's just of question of how much knowledge and effort is required. For example MS's introduction of Common Dialogs was a big time saver although it was always possible to program those dialongs "by hand". </p><p><br></p><p>It's just that UWP's "out of the box" UI support is more focused on touch based UI elements than traditional Windows elements. </p>
skane2600
<blockquote><a href="#274496"><em>In reply to klients:</em></a></blockquote><p>I think that's an assumption that in the general case isn't valid. Sometimes the UI is the most time-consuming part of the development with the "business logic" consisting of well-known algorithms. In any case, with today's rapid development any saved time shouldn't be considered "negligible" particularly when that time savings comes from a standard stock capability one doesn't have to maintain.</p>
skane2600
<blockquote><a href="#274534"><em>In reply to paul-thurrott:</em></a></blockquote><p>I agree. I also think that Microsoft has had trouble letting go of the mobile first, touch first, cross-platform philosophy that drove the original design of WinRT. Providing desktop-like controls would be an acknowledgement of their mistake and would make it easier to create UWP apps that can run only on a PC. Of course, UWP is already failed on other platforms, but this would be really throwing in the towel.</p><p><br></p><p>But at the end of the day there's still the question: Why bother to recreate Win32 capabilities in UWP if they run only on the PC anyway?</p><p><br></p><p> </p>