Jump to content
AIDA64 Discussion Forum

vlad

Members
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

0 Neutral

About vlad

  • Rank
    Member

Recent Profile Visitors

953 profile views
  1. Well, I wish I could help with that... But I can`t. I will be patient. Thank you for your efforts!
  2. I was curious: how are things going with the implementation of the requested feature?
  3. I think that option 1 (Just like with HWiNFO) makes the most sense. You can display any value that you need, without blocking the device. The intended use scenario is having a subfolder with the sensors, while keeping the rest of the buttons for other functions. Perhaps CPU and GPU visible in all the other shortcut folders to always have a general view of the most important stats, no matter what I do. Thank you for moving so fast with this!
  4. Thank you for your efforts. I was hoping for good news. From what I have noticed in your case, no news is usually good news being a sign that you are looking into the matter. I am convinced that you will do a great job exploiting the potential of this device.
  5. It has been a week. I was curious if you can give me an answer, whatever is possible or not to implement this functionality? I am hoping for a positive answer, because I like the Aida64 software and do not really want to install HW info
  6. There is a plugin for HW info that works like this: https://github.com/exension/hwinfo-streamdeck It would be possible to implement something similar for Aida64?
  7. A big hello to the developers, followed by a question: Any chance to add LCD support for Elgato Stream Deck? https://www.elgato.com/en/gaming/stream-deck That would be nice...
  8. Noticed that this morning, when I swaped the white "background" color for a desaturated light blue that turned white on the said keys. Then I did some color testing and come up with the bug...
  9. Have another bug for you: The Numpad numbers and and the top raw numbers (so only the part actualy used by a 2 or 3 digit meter) have the B <-->R channels swaped for the "background" color. Meaning that white shows white, but using any combination of RGB that does not have R and B equal results in wrong colors, compared to the rest of the keboard "background" keys. If you put, for example a pure red you can see that very well, because the number keys "background" becomes blue instead.
  10. It works as expected. Thank you for taking care of the problem. Excelent work!
  11. Thank you for taking the time to deal with this!
  12. Thank you. It works much better. Still a problem with using 2 or 3 digits to represent a sensor, the number keys (top raw and and numpad numbers for 3 digits) not responding to background color (unlit).
  13. Yes there is, but if you have a sensor maped to a raw of keys, say qwerty, and the "bar" is up to lets say "letter" the ones after it from"y" onward, will remain unlit, regardless of the "background color" chosen. So if you map 3 sensors to the 3 raws of keys: "qwerty", "asdf" and "zxcv" you will have most of the key unlit, unless the sensor "bar" ar always close to 100%
×
×
  • Create New...