[HN Gopher] Closing a 30 pixel gap between native and web
___________________________________________________________________
Closing a 30 pixel gap between native and web
Author : vyrotek
Score : 186 points
Date : 2022-09-27 18:25 UTC (4 hours ago)
(HTM) web link (blogs.windows.com)
(TXT) w3m dump (blogs.windows.com)
| [deleted]
| cebert wrote:
| Hopefully Apple keeps moving in the direction of better embracing
| PWAs. I am encouraged that iOS 16 includes support for web push
| notifications. This suggests to me Apple may be more willing to
| embrace PWA web standards.
| asherah wrote:
| this looks great! hopefully this can be better standardized soon
| MaXtreeM wrote:
| With all this Electron and PWA focused development a cannot shake
| a feeling that we add an extra layer of a "runtime" on top of an
| operating system, that could be avoided. An extra layer which
| occupies RAM space and processor time which feels unnecessary but
| it is where we are headed. I wonder if the reason is simple, that
| we (myself included) have not provided anything better or the
| reason is that big corporations who control most of the market
| have pushed this technology forward. I hope we can learn from
| this and bring back some of this lost performance while keeping
| the productivity and security gains.
| whywhywhywhy wrote:
| It makes perfect sense for the user but developers will always
| argue for Electron so that they only have to test one browser
| engine.
|
| I can't even gets web devs to test on anything but Chrome and
| when something they code does break I have to listen to the
| Safari whine even though they all use iPhones so are part of
| the reason it's relevant. Dread to think how an argument for
| supporting 3+ web engines for a "native" app would go.
| kitsunesoba wrote:
| What seems even crazier is not even wanting to test against
| different builds of Chromium to help keep pace with Electron
| updates. At that point isn't one's code just too brittle?
| criddell wrote:
| A lot of developers are not fans of Electron. Generally, it's
| a quality vs quantity tradeoff. Are you willing to make a
| crappier thing if it means more people can use it?
|
| For companies like Microsoft making something like Teams, I
| think it sucks. They have the resources to make native apps
| and when you have tens of millions of users, adding support
| for another platform would cost them pennies per user.
| com2kid wrote:
| > For companies like Microsoft making something like Teams,
| I think it sucks. They have the resources to make native
| apps and when you have tens of millions of users, adding
| support for another platform would cost them pennies per
| user.
|
| Back when I worked at Microsoft, 2014 or so, we had serious
| problems finding _Win32_ developers. We essentially had to
| train people up. While I am sure the Windows org had lots
| of them, put out a job req and even internally not very
| many people are going to have native Windows development on
| their resume.
|
| Nearly had to draw straws to see who had to get "stuck"
| learning Windows stuff.
|
| I imagine native MacOS developers are similarly rare as a %
| of the overall developer pool.
|
| Android and iPhone developers, easy peasy.
|
| Likewise, Web developers, not a problem.
|
| The other thing is, Electron has tons of momentum behind
| it, which means more and more people jump onboard to learn
| it, which makes hiring easy. Tutorials and learning
| resources get made, making developing for it even easier.
|
| IIRC we ended up dropping the native C++ Windows app and
| just used C# and one of the UI toolkits, I forget which
| one.
| gw99 wrote:
| This.
|
| I encountered hell the other day. I saw a corporate Citrix
| deployment that had 45 users running three electron apps on an
| underprovisioned server with the CPU, disk and memory rammed at
| 100% lagging out. That's 135 separate browser stacks basically.
|
| Microsoft are moving office to this stack as well. Ugh.
|
| Of course I was there trying to work out why our simple old
| fashioned web app was running slowly in a chrome tab...
| RunSet wrote:
| When you see decades of Windows version after Windows version,
| each billing itself as "the fastest Windows ever!" and each
| having higher minimum system requirements than its predecessor,
| two conclusions are inescapable:
|
| 1. The Redmond wizards have devised a method to make software
| run faster and all it requires is faster hardware.
|
| 2. Microsoft is in bed with hardware manufacturers.
| loudmax wrote:
| 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.
| madeofpalk wrote:
| This feature itself has nothing to do with Electron. Electron
| has long had similar capabilities.
| _gabe_ wrote:
| 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 different. However, and this may be an unpopular
| opinion, I don't want developers building an app that's meant
| to be used on a mobile device and a desktop. They're 2
| separate ways of using a computer and they should be treated
| as such.
|
| When I think of desktop apps like Photoshop, Outlook, Word,
| Chrome, and Da Vinci Resolve, they all look and behave _very_
| differently than their mobile counterparts (if they have
| one). If you want to develop for mobile and desktop, then you
| need to invest the time to make it a good experience on both.
| I _hate_ desktop apps that have been mobile-ified to support
| mobile-first design. Design a proper UI and UX for the
| platform you 're targeting. Otherwise don't bother
| "supporting" a platform you never test, intend to test, or
| design specifically for.
| mkoubaa wrote:
| Porting a large-scale windows desktop app to linux takes
| engineer years.
| trap_goes_hot wrote:
| That ship seems to have sailed with the (over?)use of VMs a
| long time ago.
| amadeuspagel wrote:
| The obvious solution to this is to remove the bottom layer so
| that the browser is not a layer on top of the OS, but is the
| OS.
| kllrnohj wrote:
| That won't meaningfully change performance at all. Browsers
| aren't slow because they have to make slow syscalls - they
| mostly don't. They are slow because web technologies
| themselves are slow, sometimes by design, sometimes because
| of security/abuse concerns, but often just because HTML & CSS
| are absolutely crap platform for interactive UIs, something
| they were never intended to be and retrofitting that doesn't
| result in a very efficiency stack.
| robocat wrote:
| > HTML & CSS are absolutely crap platform for interactive
| UIs
|
| I mostly disagree. HTML is great for plain forms, that
| seamlessly work at different form-factors (from mobile to
| desktop) with very little work. Browsers are also good at
| graphical outputs.
|
| Browsers can fall down when you need rich, complex, or
| custom inputs: because virtual keyboards are very different
| from real keyboards (iOS especially poor), and touch is
| very different from mouse, and game consoles are something
| else again!
|
| But we go where the users are, which is usually a wide
| variety of devices which makes browser based deployment the
| default choice, so you work within the limitations of
| browsers.
| sanroot99 wrote:
| Hypervisor based os is future ,for eg qubes os
| 323 wrote:
| Do you think Microsoft loves it that people are building
| Windows apps with Google tech?
|
| But this ship has sailed a long time ago.
| criddell wrote:
| I think they do love it! I'm pretty sure they chose Chromium
| for Edge because they see Electron or something like it as
| the future.
| armchairhacker wrote:
| I want the opposite of a PWA.
|
| I want an app which can be compiled into Desktop/mobile builds
| and also interpreted in browsers. An alternate HTML/CSS/JS with
| no JavaScript.
| danans wrote:
| So ... Flutter? https://flutter.dev/
| armchairhacker wrote:
| Sure. As well as certain other platforms like Kotlin
| multiplatform
|
| The only issue is that these still have to compile to
| JavaScript, which in practice leads to slower performance and
| potential for improper semantics on the JS side. It would be
| better to have them executed in WASM and then have better
| WASM-browser integration
| postalrat wrote:
| A better WASM-browser integration would mean more security
| risks running WASM.
| LtWorf wrote:
| qt can do that with WASM
|
| https://www.qt.io/qt-examples-for-webassembly
| tiarafawn wrote:
| Seems exploitable for phishing
| sirjaz wrote:
| If anyone is wondering why Microsoft is pushing pwa, thank the
| likes of Google, Salesforce, etc.. that will make a mobile app,
| MacOS app, or a web app. They all send a big FU to Microsoft. In
| addition, their CEO doesn't care about the platform anymore as
| long as you use Azure.
| jwcacces wrote:
| Looks like the perfect place to fake some browser chrome and
| trick people...
|
| https://www.theregister.com/2017/01/19/browser_line_of_death...
| drewzero1 wrote:
| That was my first thought as well, but I couldn't remember the
| name for that boundary. I hope there is a well-designed per-
| site control/setting/user consent system to keep tech support
| scam sites (or worse!) from adding one more tool to their
| arsenal.
| fiddlerwoaroof wrote:
| I've seen it called "The Line of Death"
|
| https://textslashplain.com/2017/01/14/the-line-of-death/
| [deleted]
| nicoburns wrote:
| I think you'll only get access to this API if the user has
| explicitly installed your app as a PWA, not just when visiting
| it as a webpage.
| gildas wrote:
| And then a shady company offers to buy the owner's website...
| tshaddox wrote:
| That's a real problem, of course, but it seems fairly
| equivalent to any native app you install that can update
| itself or otherwise make a network request to obtain
| instructions.
| gildas wrote:
| I agree with you. On the other hand, in the case of a
| native application, we can hope that the antivirus
| removes it. I hope that Microsoft has planned to update
| Defender accordingly.
| int_19h wrote:
| JavaScript malware has been a thing for a while now, and
| antiviruses have been targeting it accordingly.
| gildas wrote:
| It's not necessarily a JavaScript malware. A pure HTML
| page with a <form> tag could suffice to steal
| credentials.
| postalrat wrote:
| Unlike the native app you probably won't have to worry
| about web page encrypted your files and asking a ransom.
| jb_s wrote:
| XSS will mean that attackers control browser UI, that's kind
| of bad
| coldtea wrote:
| > _We talk a lot about Progressive Web Apps (PWA) in the context
| of mobile devices, but they have an enormous potential on desktop
| operating systems that's only beginning to materialize._
|
| Do we? I think we talk about PWA's on mobile and desktop equally,
| if not more so in the Desktop (e.g. with Electron and regular
| browser-viewed PWAs).
| nullcaution wrote:
| This seems widly exploitable. Even on the OS level, I would argue
| an application should not have access to thoes 30 pixels.
|
| Beyond rhe security concerns, this seems like a proprietarization
| of the web for Win11, a la Internet Explorer.
| cush wrote:
| You have to install PWAs, and any platform can implement this.
| It's a pretty good spec that can help a lot with the adoption
| of PWAs
| adamesque wrote:
| They do explicitly discuss how the feature might work on other
| platforms (aka Mac OS and Linux), and have published a spec,
| which is also an interesting read:
| https://wicg.github.io/window-controls-overlay/
| intrasight wrote:
| > ability to create their own title bar experiences
|
| It was a sad day, IMHO, in UX-world when this became possible in
| desktop apps. The window system should own the chrome and the
| apps should not be able to touch it.
| postalrat wrote:
| They still do.
|
| https://blogs.windows.com/wp-content/uploads/prod/sites/33/2...
|
| Didn't that picture make it obvious?
| jonathankoren wrote:
| Looking forward to the day when Winamp style apps are back.
|
| Remember round windows? They're back, in Electron form.
| MartinMond wrote:
| Love how we're realizing that .hta was actually incredible. I
| have fond memories of building my own
| https://en.m.wikipedia.org/wiki/HTML_Application
| mmastrac wrote:
| .hta really had to go through the standardization process to
| tighten up security. Those things were awesome, but you'd
| basically be owned immediately.
| jimmygrapes wrote:
| Quick shout out to the Compiled HTML[0] (.chm) format for
| similar but unrelated reasons. The Help viewer application was
| one of the pinnacles of good UX, in my opinion.
|
| [0]: https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help
| rnestler wrote:
| It's kind of impressive that one can still run the same .hta
| app even on Windows 11 according to the wikipedia article:
|
| > HTAs are dependent on the Trident (MSHTML) browser engine,
| used by Internet Explorer, but are not dependent on the
| Internet Explorer application itself. If a user removes
| Internet Explorer from Windows, via the Control Panel, the
| MSHTML engine remains and HTAs continue to work. HTAs continue
| to work in Windows 11 as well.
| chrismsimpson wrote:
| Is this not introducing a massive UI threat vector considering
| we're talking about HTML/JavaScript downloaded from the web?
| mwcampbell wrote:
| Counterpoint: Seams (2014): https://adactio.com/journal/6786
|
| Edit: related, from the same author: Regressive Web Apps (2016):
| https://adactio.com/journal/10708
| dmayle wrote:
| I think this is a sign that Microsoft sees the writing on the
| wall. There will be a day when Windows is left behind, and they
| want to make sure that they can continue to deliver the Microsoft
| experience, even on other platforms.
| echelon wrote:
| I think this is the wrong take.
|
| Microsoft is trying to land on the PWA beachhead in an attempt
| to make mobile devices irrelevant and app agnostic.
|
| Furthermore, they want to provide the tooling to develop and
| deploy into this ecosystem. Github, Github CI, VSCode, Azure,
| ...
| guhidalg wrote:
| I don't think Windows is ever going to be left behind, you
| still need a kernel to make use of all your hardware and an OS
| to give users something to do. I view this move as Microsoft
| recognizing that the future of most development is cross-
| platform web technologies and they need to give Windows users
| reasons not to migrate to macOS and ChromeOS (though it's ok if
| they do as long as they're paying for O365 and Azure).
| ieegdiuf wrote:
| smoldesu wrote:
| I think you're right, but that also poses the possibility
| that Windows _will_ get left behind, as a kernel. If the
| future of development happens on the web, the significance of
| Windows as a kernel is going to greatly diminish. We 've
| already reverse-engineered a huge amount of Windows API
| calls, and you can run vast amounts of fairly complex Windows
| software without the NT kernel at all.
|
| If our future does shift towards thin-clients and web-
| browsers, MacOS and Windows will make increasingly less
| sense. Both OSes have a pretty significant amount of cruft
| and unjustified overhead which already seems unnecessary to a
| generation of Google Docs and Soundcloud users.
| FpUser wrote:
| >"If our future does shift towards thin-clients and web-
| browsers"
|
| Please no. I like to control what I have. No way for me to
| be fed by thin client. Sure I do not mind web apps /
| services where it makes sense (banking for example). But
| the possibility to be suddenly cut off for whatever reason
| (maybe my app provider does not like my political views) -
| fuck that. Or when everything goes through some portal what
| will prohibit from them jacking up subscription fees sky
| high? I understand by many developers wanting to use webapp
| hummer for everything but I think they're digging their own
| grave
| amadeuspagel wrote:
| I don't see how an offline-first browser app is worse
| then a native app in terms of control.
| FpUser wrote:
| My answer was in particular to: "If our future does shift
| towards thin-clients and web-browsers".
|
| Thin client leaves processing to a server. It does not
| matter in this case if your "offline-first" UI is
| resident / cached on a client side. These are just
| glorified web bookmarks
| smoldesu wrote:
| Those problems are also realistically an issue for native
| apps. The internet is your distribution platform
| regardless of if the web is your target.
|
| I would _hope_ that the industry could work together to
| provide a comfortable cross-platform app development
| experience, but none of the big players bought-in. So now
| the web is our only option, and they 're the ones to
| blame.
| FpUser wrote:
| For what it is worth I distribute my products from my
| company's website. However little reputation I have is
| all mine. It does not depend on some portal. The revenue
| is all mine as well. Besides those products are heavy
| apps that use features not accessible from non native
| apps.
| Sohcahtoa82 wrote:
| > I don't think Windows is ever going to be left behind
|
| I do, but not for reasons most people think about.
|
| The Windows 11 UI/UX is trying to emulate MacOS. Clearly,
| Microsoft is giving the finger to people that use Windows
| _because_ it 's not MacOS.
|
| I can't wait for Windows 12 to happen and all the UX things I
| hate about MacOS get implemented in Windows. Might as well
| start training my muscle memory to hit the Windows key
| instead of CTRL now, so that when Microsoft decides that
| CTRL-X/C/V should be WIN-X/C/V, I'll be ready.
|
| Or maybe I'll just switch to Linux.
|
| In either case, I'll leave Windows behind.
| com2kid wrote:
| Few years back everyone was complaining Apple was copying
| Microsoft by going all in on flat UIs.
|
| While at MS I did run into the ever present problem of many
| designers only using MacOS so their designs would basically
| say "do what MacOS does!"[1] which entailed a lot of work
| by developers to change the default Windows UI widget
| behaviors to look like MacOS. Thankfully when I got one of
| those requests across my desk I was able to point and shout
| at MS's design language rules and say no. :/
|
| [1] I don't think it was on purpose, I just think many
| designers have never used anything else and they didn't
| even realize other UIs exist outside of MacOS and iPhones.
| These problems started popping up when MS loosened up on
| their rules about only using MS products for development,
| it was a needed change but ugh, UX designers and their
| MacBooks...
| [deleted]
| ElijahLynn wrote:
| Love that MS is going all-in on PWAs!
|
| The PWA future is looking bright!
| wolpoli wrote:
| I actually wish programs do not put content in the Title bar
| area. The title bar area is meant for users to move the Window
| around.
|
| Try opening Microsoft Word, make the window narrow and drag the
| window. You have to hunt for a small bit of empty space in the
| title bar or you have to understand you could drag on the Title
| text, Search box and the Sign in Username, but not the Auto Save
| text, Upcoming Features icon, or the Ribbon Display Options icon.
| marcosdumay wrote:
| The Windows style for bars (both title and status) is way too
| large. Ditto for the task bar.
|
| It's no wonder people are tempted to not use status bars, and
| shove as much as possible at the title. If applications could
| exploit the task bar, they would too.
|
| (Anyway, you don't need an entire bar for system interaction.
| But applications aren't designed in a way that allows this.)
| airstrike wrote:
| Well, here's an AHK script for those that want to move away
| from depending on the titlebar drag. Use Alt+Shift+Mouse drag
| anywhere on ANY window to move it on Windows (puns unintended):
|
| https://dpaste.org/pV1aQ
|
| I would paste to gist.github.com but the corporate overlords
| won't let me
|
| If you already have a script running at startup and all that,
| you can save this as a standalone file called e.g. winmove.ahk
| and add the following to your existing script:
| #include C:\path\to\winmove.ahk
| danuker wrote:
| Thanks. I was using AltDrag, but I found it a bit sluggish.
| kroltan wrote:
| I have something similar in my Linux setup, Win+LMB anywhere
| on a window drags it, Win+RMB resizes. Never used a title bar
| again, highly recommend if you can get a similar setup.
| Analemma_ wrote:
| Hard disagree. Vertical space is a scarce resource and I hate
| when it's used for dead space I can't get rid of or use
| productively. Alt-drag is the way to go.
| smegsicle wrote:
| > The title bar area is meant for users to move the Window
| around
|
| i thought that's what alt-drag was for? maybe microsoft didn't
| get that memo either...
| com2kid wrote:
| The most basic of window operations shouldn't require a
| hotkey.
|
| Rearranging windows on MacOS and Windows now requires video
| game precision aiming. It is absurd.
|
| What's more, every app places things in different parts of
| the title bar, so I have to search for "where to click" based
| on which app window is up. Absurd.
|
| The move to controls in the title bar is absurd. It used to
| be Windows had standard chrome, title bar, then menu,
| toolbar, then content area. Now days it is the wild west what
| UI elements are where.
| banana_giraffe wrote:
| I don't disagree.
|
| It's for this kind of nonsense that I have "alt-space -> s ->
| down -> right" burned into my fingertips followed by moving the
| mouse cursor to resize a window deterministically (along with
| "alt-space -> m -> any arrow" for move, doubly useful to
| "rescue" an off screen window)
| [deleted]
| jolmg wrote:
| > alt-space -> s -> down -> right
|
| > alt-space -> m -> any arrow
|
| Are those keybindings default on a particular OS/DE/WM/WC or
| are they just your personal config?
| banana_giraffe wrote:
| Default behavior for Windows applications (since 3.x, I
| think). Alt-Space brings up the Window menu.
|
| Some odd-ball apps will replace it with their own menu, but
| few apps go to the effort to override the default shortcut
| it, even if they otherwise hide it.
| sedatk wrote:
| Alt-space menu is Windows specific IIRC.
| drekipus wrote:
| Gnome does the same, I use it all the time for "pin
| window always on top"
|
| Which windows still doesn't have, for some reason.
| bm-rf wrote:
| Works on windows for me. Also never really thought about
| this for rescuing a stuck window, I've always used winkey +
| arrow keys and kept mashing buttons until it appears on one
| of my monitors :P
| david2ndaccount wrote:
| I also dislike how apps are now disabling the classic win32 app
| icon in the top left corner. If you click on it, you get a menu
| with window management options and double clicking it closes
| the window. It's so burned into my muscle memory as the way to
| close a window I get frustrated when apps hide it.
| airstrike wrote:
| Alt+Space to the rescue ;-)
| p1necone wrote:
| 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.
| sedatk wrote:
| Yeah Microsoft Word is terrible in that aspect. You don't even
| need to make the window too narrow.
| https://twitter.com/esesci/status/1414631138379792384
| kanonieer wrote:
| > We're excited to announce the availability of a new PWA feature
| that closes this gap and helps blur the line between apps and
| websites even more.
|
| I don't see how they can use "blurred line" as a positive trait
| here. There are important differences between native apps and web
| apps, why hide this information from a regular user, especially
| when this information can be conveyed by 30 pixels.
| chpmrc wrote:
| What difference does the runtime make to the (average) end
| user? I love that I can create shortcuts of some web apps that
| have their own window, menu bar etc. (this is already possible
| in Chrome) and I don't really care they are "web" apps.
| LtWorf wrote:
| > What difference does the runtime make to the (average) end
| user?
|
| "Incredibly slow and draining the battery 3x as fast" vs
| "regular"
| make3 wrote:
| because actual regular answers don't understand what any of
| this means, and this just means that the devs have more control
| over what experience they give them
| int_19h wrote:
| We're talking about web apps that are specifically intended to
| be installed locally and look like native apps. What are those
| "important differences" in this context?
|
| (and note that you can still use PWA in the browser if you want
| to, and thus deny it this ability)
| drewtato wrote:
| Well right now, the alternative isn't "keep it in the browser",
| it's "ship it in electron".
| uptown wrote:
| Does this apply to Edge Mobile on iOS? To my knowledge, there's
| no way to hide the browser chrome on that app, which is ironic
| considering they open the article talking about PWAs on mobile
| devices.
|
| Last time they weighed in on the topic, this was their response:
|
| https://answers.microsoft.com/en-us/microsoftedge/forum/all/...
| gernb wrote:
| Is it part of "Project Fugu" because like blowfish, if you
| prepare it wrong you kill your customers? /s
| GuB-42 wrote:
| > 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 rewrite it all by yourself, or more likely, import a framework
| that does it for you. Traditional Windows apps all use system
| provided common controls, because they are good, and therefore
| they have a consistent look and feel, even through OS updates. It
| is even user customizable. Now it is not uncommon to see 10
| different styles in a single screen, Windows since 8 is not even
| consistent with itself, and it is becoming worse every version.
| And it is not just aesthetics, there are serious usability
| concerns here, and system-wide customization is gone.
| n8cpdx wrote:
| > Traditional Windows apps all use system provided common
| controls, because they are good, and therefore they have a
| consistent look and feel, even through OS updates.
|
| This hasn't been consistent since at least Vista and the
| release of WPF, which does totally custom control rendering.
| Circa 2006.
|
| 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).
|
| Even Office and Visual Studio (not Code) are using web
| technologies to render substantial parts of the UI.
| 323 wrote:
| I for one welcome our Electron future.
| gw99 wrote:
| Oh look they turned Chromium into IE6. Forced ads, difficult to
| eviscerate search engines, proprietary extensions, dubious
| security posture! Oh goody!
| lvass wrote:
| Why are the window decoration buttons considered critical on
| Windows? People using Windows without a keyboard maybe? I always
| disabled those (or the whole bar) on any system I've used since I
| can remember.
___________________________________________________________________
(page generated 2022-09-27 23:00 UTC)