Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Closing a 30 pixel gap between native and web

blogs.windows.com

Post reply on HN
Print view View original

301–310 of 313 posts

Re: Closing a 30 pixel gap between native and web

#301

Post by hulitu »

dncornholio wrote: post #233
pjmlp wrote: post #216

Earlier quoted context omitted.

Office is using web technologies because they don't want to rewrite their code for Office 365, so native users get the Web stuff on a Web widget instead of a proper native UI. Which is kind of tragic, given how Office was the testing ground for many Windows UI components.

Who cares if it just works? Who cars if it's made in Flash or in COBOL when it just works? What's sad about this? It just works right?

That's the problem: it does not work. I don't care if the programm is written in assembly or in rust as long as it functions properly. But when the blinking cursor stops blinking, when the scrollbar or window border is so thin that i cannot select it with a mouse, when the title bar is so cluttered with buttons that any click brings up a menu instead of being able to double click or click and hold, then _it matters_.

I stop here in order to not throw profanity at MS engineers.

Re: Closing a 30 pixel gap between native and web

#302

Post by hulitu »

austhrow743 wrote: post #241
lelanthran wrote: post #207

Earlier quoted context omitted.

> When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS. The html-apps-as-a-local-app (like electron-based stuff) became popular prior to "how to centre a div" was answered. IOW, they became popular in spite of having shitty layouts specifications.

Flexbox predates electron let alone electron being popular.

Firefox is not a good example of good (G)UI. It was at the beginning until they started copying Chrome.

Re: Closing a 30 pixel gap between native and web

#303

Post by hulitu »

dmitriid wrote: post #286
pronlover723 wrote: post #190

Earlier quoted context omitted.

What are these common controls? Looking at this list: https://learn.microsoft.com/en-us/windows/win32/controls/ind... Animation -> video tag Button -> button tag Combobox -> select tag Date picker -> input type=date Time picker -> input type=time Edit -> input type=text or textarea Scroll bar -> Not needed, automatic Hot Key -> WAT? IP Address Control -> Is this really so common it needs a custom box? does it handle…

It means that you've never really developed an actual app. And that you haven't ever thought about all the controls and layouts (with their complex interactions) even in the apps you use daily. No. Menu isn't "the one control". Menu is one of multitude of controls. Go ahead and try and implement a treeview correctly with nested details (including all the necessary keyboard interactions). Meanwhile treeviews have been…

> And those are just the most trivial things native UIs solved half a century ago.

My favourite: A window with 1 (only one) input field which is not focused by default. Why ? Why do i have to click and type instead of only typing ?

Re: Closing a 30 pixel gap between native and web

#304

Post by hulitu »

davnn wrote: post #174
p1necone wrote: post #100

Earlier 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.

Windows has pretty decent keyboard shortcuts for manipulating windows‘ positions, though. Clicking and manual window manipulation should very rarely be necessary, shouldn’t it?

Resizing a window with the keyboard shortcuts, especially on a high resolution monitor is time consuming.

Re: Closing a 30 pixel gap between native and web

#305

Post by hulitu »

marcosdumay wrote: post #271
Dalewyn wrote: post #158

Earlier quoted context omitted.

The older I get, the more I respect bigger user interface elements and text. It's not even failing eyesight either; I'm still in my mid 30s and have great eyesight and dexterity. I've come to respect bigger interface elements because they are quicker to work with. I don't have to peck for a title bar if it's there, big and empty in front of me. I don't have to hunt for a scroll bar that hides itself and reveals a 1px…

The larger the elements that you don't use all the time, the smaller all the other ones have to be. If you have large high resolution screens, you won't miss the space, but you can't blame people for optimizing their own applications for the screens most people use.

> If you have large high resolution screens, you won't miss the space, but you can't blame people for optimizing their own applications for the screens most people use.

Have you seen the new Microsoft calculator ? (i.e. calc.exe). It seems to be designed to be operated by spear throwers from 100 foots away.

Re: Closing a 30 pixel gap between native and web

#306

Post by hulitu »

sneak wrote: post #239
tshaddox wrote: post #20

Earlier quoted context omitted.

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.

Native apps that autoselfupdate have RCE vulnerabilities by definition and should be considered remote access malware already, before the developer release keys are compromised. I am the reason Signal desktop now has a preference to opt out of autoupdate.

"It won't happen to me."

Re: Closing a 30 pixel gap between native and web

#307

Post by hulitu »

jb_s wrote: post #96
nicoburns wrote: post #13

Earlier quoted context omitted.

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.

XSS will mean that attackers control browser UI, that's kind of bad

Bad ? I thought that was a feature. "Want to change your browser behaviour ? Just put this CSS in user.js".

Re: Closing a 30 pixel gap between native and web

#308

Post by hulitu »

sanroot99 wrote: post #34
amadeuspagel wrote: post #24

Earlier quoted context omitted.

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.

Hypervisor based os is future ,for eg qubes os

TBH, it doesn't matter how many levels of abstraction you have when the programs are crap.

Re: Closing a 30 pixel gap between native and web

#309

Post by hulitu »

svnpenn wrote: post #254
amadeuspagel wrote: post #24

Earlier quoted context omitted.

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.

better yet we should just outlaw personal computers and laptops, they are causing too much trouble. Better for everyone to just have iPads and iPhones, kill Android too.

Well , to not shoot yourself in the foot, port first the development environmets to those platforms. /s

Re: Closing a 30 pixel gap between native and web

#310

Post by hulitu »

luvs2code wrote: post #169
MaXtreeM wrote: post #6

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 w…

I'm gradually starting to see X11/Xlib as a solution for cross platform desktop apps. It is the native GUI API for most UNIX operating systems. Ports exist for Windows(win11) and Mac which makes X11 technically portable to them as well. Its not exactly an elegant solution I have to admit. But the licensing problems with QT make a lot of people nervous, GTK seems to be pretty polarizing, and for whatever reason WxWidg…

They saw it's good so are now deprecating it.
Post reply on HN