I've recently got a Google Home and have created some simple applets. I've created one to run when I go to bed (it's in the living room). So when I say "Good night", I want it to turn the central heating off, turn the lights out and go silent (it may be playing music). I must admit I was astonished how limited IFTTT is, but I linked it to stringify so I could perform more than one action in an applet. However, I can't find anything to silence the Google Home. Has anyone any suggestions? Ideally through stringify but as a separate applet if necessary.
Apologies if there's somewhere obvious to find this information, googling for anything just gets a load of adverts!
For routines that I want to run silently, I add the custom command Turn on Night Mode at the beginning of the routine. This requires that you have previously gone to the device settings and set your Night Mode volume to 0%. You'll also probably want to add the custom command Turn off Night Mode at the end of the routine.
Unfortunately, the routine will only run silently when it is activated by voice (i.e. saying "Hey Google, [routine name]"). If the routine starts automatically at a specific time it will still make noise.
Related
Foreword
Since this appears to be a bug in the d3d9 Emulation on the Windows side, this would probably best addressed to Microsoft. If you know where I could get into contact with the DirectX Team, please tell me.
For the time being, I'm assuming that the only real chance we have is working around the bug.
What
We're investigating an inresponsiveness found in the Game Test Drive Unlimited 2.
Only when opening the Map and only when having an "RTX" Card (I think the most precise we got is GDDR6, because AMD also seems affected).
After long debugging, we found out, that it's not a simple fault of the game, but instead Present returning D3DERR_DEVICELOST even when having the game in Windowed Mode.
When the Game is in Fullscreen Mode, it properly does the required roundtrip over TestCooperativeLevel and Reset, but after the next frame is rendered, Present has lost the device again, causing the Hangup.
Now I'm looking for pointers on how to solve this issue. While it's probably some internal state corruption of some sorts, it's definitely triggered by an API Call only present when rendering the Map in that Game.
We will try to dig into d3d9.dll, but my suspicion is that the error code just comes from some Kernel/Driver Call, where our knowledge and tooling ends.
Ideally I'd like to fuzzy-find the drawcall by just hooking everything and omitting random apicalls, but I guess it's just not so easy and causes a lot more errors in most conditions.
Also note that an APITrace we did, showed D3D_OK for every single call including EndScene, up until Present, so it's not as simple as checking the return codes.
Trying to use Direct X 9 in Debug/Diagnostic Mode is also not really possible on Windows 10 anymore apparently, even when installing the SDK from June 2010
Thanks in Advance for any idea and maybe addresses to direct this problem to.
I have been searching everywhere for all the combinations of things that I want to accomplish hoping something would pop but I can't find anything. Additionally, I am not sure if I am "crafting" my query properly enough so I am hoping I can get some assistance on that here.
What I would like to accomplish is this (pseudo logic)
Create a single container file, for example: vdata.x which will contain everything in it as a single data file
Mount this file as an actual drive/folder in Windows so that you can write to, read from, delete/modify the content as if you were using Windows Explorer. Visible to FS, applications, system/commandline like any other "real" folder on the machine.
Prefer the ability to have this file reside on a thumbdrive and have it mounted either automatically or manually after plugged in and have it show up not as the thumbdrive but as the file inside it, or mount both doesn't matter.
Additionally the ability for that file to be locked, encrypted and accessible (despite auto mounting, if that's the case) after it have been authenticated with a password, random token or whatnot.
Finally a housekeeping element, such as being aware of its available "host" space (aka the thumbdrive) so that as it reaches a certain threshold of expansion, it says, hey move me to a larger device, make room or stop adding more, something akin to, running out of space warning.
I thought about putting this in software recommendation SE but that is not fully up and running yet (at last check) and plus the range of who access that sub-se might very limited, so I am asking here to get feedback and discussion to see if we can answer it better here or it needs to move to there.
Thank you in advance and hope to get some brilliant minds out there to help me accomplish this.
PS. I am not averse to building something like this myself but I am limited in time and health and plus if its already done, why reinvent the wheel right? But if anything could help launch the development of such a tool, I would take that input as well, thank you.
I'm currently working on a Backup Application, and I have received a lot of requests for features to be added recently, and the top one of them is adding a checkbox like "Back Up when on Battery Power" like Time Machine has.
So, is there a way I can get the status of the Power Adapter (plugged in and plugged in)? I assume that if one had a Desktop Mac, like iMac, etc, I would probably just get Plugged In all the time. Therefore, I need means of detecting if the computer is a portable or not.
I assume IOKit would be a library to look at, but I simply could not find anything in the docs, that are barely existent anyways on that Framework. Then, since it is an older Carbon Framework, is there a way to register a callback that gets called when that power state changes? That way I can properly implement this checkbox's functionality.
I'd appreciate help in clarifying this subject.
IOPowerSources.h has the functions you need. Start with IOPSNotificationCreateRunLoopSource() to create a run loop source and in your callback interrogate the power source info starting with IOPSCopyPowerSourcesInfo() and working your way down. There may be better examples, but this file appears to be a reasonable demonstration of how it's done; enough to get you started.
I think one of the main causes of winrot are the sheer number of services that run at startup (and don't shut down) that phone home every x seconds to see if there is a new version of some piece of software.
Me personally, I disable every single one of them because they seem utterly useless to me. Most of the software packages that use these things, have an option to check for updates whenever you launch the program itself too. This looks way more efficient to me.
I was asking myself what the reason is for companies like Adobe and Apple to create such services that bog clients' computers down and at the same time increase the burden on their own update servers for what looks to me as very little return value for neither of them.
My client requests such a service, but I don't see any reason for it. I want to make sure I'm not missing a piece of the puzzle so I can come back with an educated opinion on why this is should or shouldn't be a desired functionality.
It's usually a desire by management to get brand recognition. It goes something like this:
Oh no. If our program just does its job, the user will never see that it's there, and they'll never find out who we are, and what a great company we are.
We need an icon in the tray; we need a shortcut on the desktop, and in the quick launch toolbar, and at the top level of the Start menu. If we could add a control panel applet, and an item on the right-click menu in Windows Explorer, and an icon in Internet Explorer, that'd be fantastic.
Of course, since our program's so important, the user's going to be using it a lot. Let's add a "speed boost" program that runs at startup, that makes sure that all of our binaries and dependencies are pre-loaded in the cache.
Oh, and we'll need an automated update program, to make sure that all of these components are as wham-bam-great as we can make them.
And can you put a splash screen on that as well?
Can you tell I'm bitter?
Roger's spot on.
Plus, once an application has developed to the point where it already has all the features you could expect it to cover for its intended purpose, the vendor is stuck. They need to keep banging out exciting new versions, so scope bloat creeps in. Instead of doing one thing well and getting out of the way, we must do everything related to it. We must always be in the user's face; they must never be allowed to use software that isn't ours; they must always be interacting with our brand. And of course we must take care to always start an updater task in the background, because we added a completely unnecessary internet-facing browser plugin/toolbar/ActiveX thing that will surely turn out to have security holes.
Acquisitive software is a huge problem that is steadily degrading the user experience on Windows. And it's an arms race: Microsoft hide old application surface interfaces (deprecating the classic start menu, removing quick launch, hiding system tray icons, auto-removing inactive Desktop icons) as they become so full of acquisitive-software junk that they're basically unusable, whilst introducing new ones that "will be better". But how long until applications start "helpfully" adding themselves to the Start menu's MRU list (because you're definitely going to want to use our great software a lot!) and pinning themselves to the Windows 7 dock?
Linux is doing better here because the distros own access to the user and aren't going to put up with any of this crap. Not something Microsoft can get away with though unfortunately.
Bonus Did You Know Fun Fact: Once upon a time, Nero was a nice, elegant CD-burning tool.
Given that I only have one monitor, what's the best way to debug a program which uses the entire screen (such as a DirectX application)? Tools such as the step-by-step debugger seem useless in this context. Also, printing to the console isn't as effective, since you can only look at the console once the application has terminated.
Remote debugging is no option?
Else you can possibly borrow a second monitor (with video card).
And if all else fails you can go back to beep signals.
(Or find yourself an old matrix printer and write each line to the printer ;-) )
To just see some runtime information I would overlay debug text within fullscreen. If it were me, I would target the app to be able to run windowed as well- although the onscreen debug is good for play testing (if this is a game).
printf debugging is slow, painful and fool proof.
fill your code full of tracing lines like
fprint(logfile,"%s:%d\n",__FILE__,__LINE__);
or waterer you need for your language and run it. after your done, you can walk through what it did. Make sure you have lots of time and harddrive space first though. It has some advantage like that you can "run" things backwards and diff one run with the next.
I'll go with what BCS said and add that DebugView by SysInternals allows you to connect to it remotely from another machine.
You can test 99% of the code in windowed mode, then for the parts that need to be done in fullscreen you can have it jump to fullscreen, run some test, and jump back soon after (either programmatically or with alt-tab).
Basically I want to stress that most code will not be dependent on the fullscreenness and could be tested in a small window.
You might want to consider reading Joseph Newcombers essay on Graphical Developers Interfaces at http://www.flounder.com/gdi.htm
You may not be coding in MFC but you should be able to get some useful ideas. He's got lots of other interesting articles as well.