I am using the application Qalculate on Windows 10. Qalculate is written in C++. I would like to apply a dark theme, possibly contributing to the Github project.
GitHub
GitHub Libraries
Website
Screenshots
Here is what the app currently looks like on my system:
The screenshots on the Qalculate website show a dark theme:
I've contacted the primary developer Hanna-kn about how to apply the dark theme. This was her reply:
You can either add environment variable (in advanced system properties) GTK_THEME with value Adwaita:dark, or create a file named settings.ini, in folder C:\Program Files\Qalculate\share\gtk-3.0 or C:\Users[username]\AppData\Local\gtk-3.0, with the following contents
[Settings]
gtk-application-prefer-dark-theme=true
It appears that she is using Linux and the process to apply a theme to a specific application in Windows 10 is different than Linux.
What code would need to be added to the Github project to allow a dark theme? Or is there another application that would allow an application specific dark theme in Windows 10.
Note:
Dark theme is already turned on in the Windows 10 settings:
Developer Hanna-kn updated her code to allow a dark theme.
Before and After code here:
https://github.com/Qalculate/qalculate-gtk/commit/d16c0f424d5bb71dd6a69291d1972b45a2b84f4a
Related
I am trying to develop apps in Core App C++/WinRT. I notice that it has a wWinMain entry point, so I am assuming it supports code from Windows Desktop Application. I cannot find documentation specific to Core App C++/WinRT. Should I be using the W32 documentation on msdn? When I try to add sample code from Windows Desktop Applications I cannot access header files such as winuser.h. I am using Visual Studio 2022, so the windowsapp.lib should already be included (I have also tried adding the windowsapp in a pragma comment directive). Can someone help?
Core App (C++/WinRT) is a project template for a Universal Windows Platform (UWP) app that doesn't use XAML. Instead, it uses the C++/WinRT Windows namespace header for the Windows.ApplicationModel.Core namespace. After building and running, click on an empty space to add a colored square; then click on a colored square to drag it. You could know about this from the document: Introduction to C++/WinRT.
I trying to use Windows.Gaming.Input API via C++/WinRT from Windows Console Application and it is not working as supposed with Xbox 360 Wireless Controller (reported as Xbox 360 Wireless Receiver for Windows (0x045e:0x0000)).
I got GamepadAdded event, then trying to read gamepad state via gamepad.GetCurrentReading() and seems GamepadReading struct is not filled at all for Xbox 360 Wireless Controller.
Also I found that there is some strange error message on MSVS debug console:
onecoreuap\xbox\devices\api\winrt\pnpdevicewatcher.cpp(500)\Windows.Gaming.Input.dll!00007FFE453AABC7: (caller: 00007FFE453AA367) ReturnHr(1) tid(4e04) 80070006 The handle is invalid.
Xbox One Game Controller (0x045e:0x02d1) is working fine though.
What is wrong with my code? Or this is bug in Windows?
Code is here: https://github.com/DJm00n/cppwinrtgamepad
Using Windows 10 1809, MSVS 2017 15.9.9, cppwinrt v1.0.190211.5, Windows SDK v10.0.17763.0, xusb22.sys v10.0.17163.1, xboxgip.sys v10.0.17163.1.
PS: I also tried UWP Simple3DGameXaml app from https://github.com/microsoft/Windows-universal-samples repo - and both controllers works in it.
This is a known issue. Apparently this is caused by how focus handling works. Windows.Gaming.Input basically doesn't work for console apps as a result, but does work for Win32 or UWP apps that have a window in focus.
Note that the one case where the Xbox One controller worked for you is only because both the user was an admin -and- because you had developer mode enabled. It wouldn't work from a console app at all otherwise.
If you need game controller support for a legacy Win32 console app, you should use XINPUT. See this blog post.
In order to help us investigate this issue more clearly, could you please share your Visual Studio 2017 version to us? You can get version info selecting Help -> About Microsoft Visual Studio, then selecting Copy Info from the right side of the About dialogue.
Could you please check if you can reproduce this issue on 1903 with SDK 18362?
By the way, it will be better if you can upgrade your project dependencies as well, what you are using is an old version of the Microsoft.Windows.CppWinRT NuGet package: 1.0.190211.5. The current latest stable version is v2.0.190722.3.
Besides, the C++ Language Standard was set in project properties, but the value was not set. This should be set to ISO C++17 Standard (/std:c++17) under Project Properties -> C/C++ > Language > C++ Language Standard.
Thanks for your collaboration.
Our users are experiencing crashes when Windows 10 Creators Update (1703) is automatically installed through Windows Updates. The Windows application of ours is a multilevel, C++ WinForms application. The application can start, but if we click on certain menus, it crashes. Appears to be a graphics issue or something to do with fonts, perhaps. Why?
When the Windows 10 1703 update was applied, the installer replaced the Windows/Fonts directory and did not include shortcuts to fonts included elsewhere in Windows.
In our case, our application was needing Lucida Sans Typewriter font, which had been registered with Windows, but located in a bundled JRE for IBM Client Access off Program Files (Our application uses some IBM Client Access components).
Shortcuts of the Lucida fonts were in the Windows/Fonts directory before the update, but absent after the update (which caused our application to crash).
The Fix: We had to copy/paste all the Lucida fonts (there are 8 of them) required from the embedded JRE/lib/fonts directory into the Windows/Fonts directory to resolve the issue. We found if we did this before the 1703 update or after, our application continued to work.
The Lesson: We are going to ensure our applications use fonts that we control 100%, by copying them into Windows/Fonts during install.
Two weeks ago I downloaded and installed Dot42AndroidSetup.exe.
There was helpful info on running Android on Hyper-V and hopeful possibilities about using VS and C# to directly target Android x86 and debug.
Since then I've seen strange behavior from an automatic update program "TallApplications.Update.exe"
There were 16 entrees in Control Panel\All Control Panel Items\Notification Area Icons for the same program.
When I checked on the web, I saw that Dot42 is associated with this update service. (http://www.tallapplications.com/)
I was able to uninstall the Tallapplications from control panel, however I had to manually delete many registry entries associated with it.
If anyone knows, please tell me how to remove Dot42 without harming VS2010 or VS2012.
There are registry entrees associated with Dot42 product for both versions of Visual Studio.
I also noticed the multiple entries in the Notification Area Icons which doesn't look good. You say you uninstalled 'TallApplications' - did you mean 'dot42'? What registry entries are left after uninstalling? Did you check the \Common7\IDE\Extensions folder? The dot42 folder should be gone after uninstalling. This is the dot42 integration with Visual Studio.
PS. this is not really a programming question - superuser.com or the dot42.com support area is probably a better entry.
Well, I am facing a strange problem. I have developed a sample MFC ribbon application on my machine - Windows 7 , with Visual Studio 2008. When I copy paste the .exe onto my laptop and run the app , I don't see the ribbon menu (in fact the app has not menu now) .
I have tried looking up the .dll that load in each case(on my work machine and laptop) using process monitor but I am unable to locate what I might be missing. Any help will be greatly appreciated.
Edit 1 -
Ok, So thanks for your responses. Some progress has been made with this issue
I changed my IDE to VS 2010. The ribbon was coded manually and I figured out if I could add it as a resource maybe the problem would be solved. VS 2008 did not have the option of adding a ribbon as a resource.
I installed the VS 2010 Service Pack Redistributable X86/X64 depending on whether the machine is 32 or 64 bit.
I built a new "ribbontest.exe" app from VS 2010 and deployed it on other machines on which I would test my actual app. The ribbon for "ribbontest.exe" loads without any problems.
When I deploy my app and run it, first the old menubar loads for a sec or two, then the ribbon flashes and disappears.
A little history of the app I am referring to -
Initially my application had the menubar view. I followed this article http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm to accommodate a ribbon.
Any suggestions?
Most likely there's a conflict in the settings 'paths'. In your InitInstance() handler, you've got a statement like this:
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need
// Change the registry key under which our settings are stored
SetRegistryKey(_T("yourappname"));
If you haven't changed that name yet, do it. If you did, open regedit.exe on your target machine and remove the whole key under HKCU\Software\yourappname and then try again.
MFC stores user customizations of Ribbons/Menus/... under that key. But if you changed your app those settings don't necessarily match anymore and you can end up with stuff not showing correctly or not at all.
Make sure you download and install the Visual C++ Redistributable Runtime on your destination machine: http://www.microsoft.com/en-us/download/details.aspx?id=29
Or, something like it. Make sure you have architecture (x86/x64) correct and make sure it matches with the service pack version you compile with.
Joe is right: you need redistributable.
Joe is right: you cannot run 64-bit program on 32-bit machine.
All of the above would be indicated by the system (missing DLL, configuration incorrect, or 64/32 bit discrepancy)
Joe is right: your application must be built for specific set of minimum Windows version and service pack.
In addition to Joe’s post you must run release build not debug build.
If all of those requirements are met and you still have this problem, try linking MFC statically and see if problem persists.