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

Comments by a developer inside the Windows Media Player source code

pastebin.com

Post reply on HN
Print view View original

51–60 of 135 posts

Re: Comments by a developer inside the Windows Media Player source code

#51

Post by speedgoose »

skee0083 wrote: post #27
sn_master wrote: post #12

Earlier quoted context omitted.

It was removed from Microsoft code too. This is an old snapshot of the code, almost two decades old. Since the 2002 TWC initiative, anything from easter eggs to things like that are all very strongly banned, and actively get removed as they're discovered.

Not surprising. No fun is allowed anywhere anymore. just dull flat interfaces with grey and black colors. people can say what they want about windows xp and vista but they had soul. todays OSes are souless. Looking at you windows 10..

You can configure the colours in Windows 10 to make it look fun and childish.

Re: Comments by a developer inside the Windows Media Player source code

#52

Post by sterlind »

skee0083 wrote: post #27
sn_master wrote: post #12

Earlier quoted context omitted.

It was removed from Microsoft code too. This is an old snapshot of the code, almost two decades old. Since the 2002 TWC initiative, anything from easter eggs to things like that are all very strongly banned, and actively get removed as they're discovered.

Not surprising. No fun is allowed anywhere anymore. just dull flat interfaces with grey and black colors. people can say what they want about windows xp and vista but they had soul. todays OSes are souless. Looking at you windows 10..

I dunno. I certainly keep my comments family-friendly and clear, but these comments resemble my own in their dry wit. I also use emojis as icons in internal tools, since they don't require finding images, but this had the side effect of people reporting "sad cat" errors and the like.

Re: Comments by a developer inside the Windows Media Player source code

#53

Post by fiddlerwoaroof »

dkersten wrote: post #45
Waterluvian wrote: post #16

Earlier quoted context omitted.

> But key events should be on key-down Why? I like how keyup is less ambiguous: it avoids the question “what do I do if the user is holding the key down?” I also like being able to hold the key down to cue up a command and then at the right time, pull my hand away to execute crisply. For video editing mainly. I’m not saying keyup is the only answer. Just that there isn’t one obvious answer.

Keydowns have the physical button analogue: when you press a physical button, it immediately closes the contact, it doesn't wait until you lift your finger again. Not saying key down is better than key up, there are certainly arguments for both.

Can’t physical buttons work either way, depending whether you want to break a normally closed circuit or close a normally open circuit.

Re: Comments by a developer inside the Windows Media Player source code

#54

Post by harrygeez »

leephillips wrote: post #36
grumple wrote: post #31

Earlier quoted context omitted.

I’ve read at least several hundred books in English, and probably hundreds of thousands of news stories and blog posts, and don’t recall encountering it before. It seems to appear mostly in searches for its definition and gre prep...

Try, say, Google ngram. Would you say that, for example, “disharmonious” is a rare word? Graph them together. Pulchritude is not even moderately rare.

Probably learned it while prepping for their SATs

Re: Comments by a developer inside the Windows Media Player source code

#55

Post by mantap »

fiddlerwoaroof wrote: post #53
dkersten wrote: post #45

Earlier quoted context omitted.

Keydowns have the physical button analogue: when you press a physical button, it immediately closes the contact, it doesn't wait until you lift your finger again. Not saying key down is better than key up, there are certainly arguments for both.

Can’t physical buttons work either way, depending whether you want to break a normally closed circuit or close a normally open circuit.

Imagine a physical button on a car stereo. It activates when you press it, not when you press and release it.

Re: Comments by a developer inside the Windows Media Player source code

#56

Post by senkora »

exikyut wrote: post #49
dijit wrote: post #21

Earlier quoted context omitted.

I think you’re mistaken, YouTube (in all the forms I use it with a keyboard at least) supports spacebar as a pause key. Your browser might try to pop you down half a page if the thing that is selected or highlighted on the page is not the video player itself though. But it works 100% of the time in fullscreen.

YouTube's keyboard handling is Insanely Intuitive™, I must absolutely agree. Usefully, the up/down keys don't change the volume unless the player is also focused. What's incredibly sad is that j/k/l were agreed upon to rewind/pause/forward the video, and these generally work unless you're in a textbox... but dedicated keys were not similarly approved to control the volume. -- My current winner for Absolutely Favorite…

> Vim "up" [j] is assigned to "next", and Vim "down" [k] is assigned to "prev".

j is down and k is up in vim

Re: Comments by a developer inside the Windows Media Player source code

#58

Post by Someone »

jackewiehose wrote: post #13

The bug here is in media player to listen on key-up events. Mouse-button-up makes sense because the user can move the mouse to cancel the click. But key events should be on key-down and that's how it is done most of the time. So if you use key-up you run into these problems.

“But key events should be on key-down”

Should they, in general? If you want to press a key combination, you never press the two keys at exactly the same time. So, if key events were on key-down, you would have to press modifiers before letters to type capital letters, use keyboard shortcuts, etc. I think that would be annoying and slow typists down.

It also rules out using bare modifier key presses as input methods, but that is less of an impact.

Re: Comments by a developer inside the Windows Media Player source code

#59

Post by floatingatoll »

notional wrote: post #2

> so we need to add yet more ugliness in the form of assembler to an app which is already hardly a paragon of pulchritude Throwing some serious vocab shade in these comments, love it.

It's for the alliterativeness.

Re: Comments by a developer inside the Windows Media Player source code

#60

Post by jml7c5 »

Someone wrote: post #58
jackewiehose wrote: post #13

The bug here is in media player to listen on key-up events. Mouse-button-up makes sense because the user can move the mouse to cancel the click. But key events should be on key-down and that's how it is done most of the time. So if you use key-up you run into these problems.

“But key events should be on key-down” Should they, in general? If you want to press a key combination, you never press the two keys at exactly the same time. So, if key events were on key-down, you would have to press modifiers before letters to type capital letters, use keyboard shortcuts, etc. I think that would be annoying and slow typists down. It also rules out using bare modifier key presses as input methods,…

I would argue keydown is generally right, for the sake of latency and immediacy of action.

Do people who want a capital 'A' ever intentionally type A-Shift instead of Shift-A? I've never heard of it before.

Post reply on HN