| SuperMikeMan |
Posted on 18-10-31, 02:36 in First!
|
|
Post: #1 of 6
Since: 10-31-18 Last post: 1944 days Last view: 72 days |
Hello folks!Posted by tommanSpeaking of color schemes, if you go to Edit profile, you can get at theme selection, which has a bunch of other schemes you could use if you wanted. |
| SuperMikeMan |
Posted on 18-12-31, 00:11 in amethyst (text editor)
|
|
Post: #2 of 6
Since: 10-31-18 Last post: 1944 days Last view: 72 days |
Posted by byuuI decided to be that guy and try this, as I have on many occasions before on hiro/gtk only projects of yours. Setting up msys2 to get windows versions of gtk and then compiling it turned out not to be all that hard. The only real issue compiling was I had to remove -static from the windows stuff in nall/GNUmakefile because there weren't static libs for GTK (although the error the linker spits out for this makes it look like it couldn't find any libs, even though the dynamic ones are right where it's already looking, which is dumb and took a litle bit of figuring out what it was really complaining about). Oh, and I had to copy those two bml files from data to next to the executable, of course. The much bigger issue that took me ages to figure out was why the program was then always closing immediately. As it turns out, the issue was an initialization race condition in hiro where both the Hotkeys and pKeyboard were apparently being initialized before Keyboard::keys which was breaking everything and resulting in every hotkey reading as being pressed on the first keyboard poll, including the quit hotkey, closing the program immediately. More specifically, what would happen is, because of Keyboard::keys not being initialized yet, for all the Hotkeys, hotkey.state->sequence would be set, but hotkey.state->keys would not be breaking Keyboard::poll seen below
auto Keyboard::poll() -> vector<bool> { auto pressed = pKeyboard::poll(); for(auto& hotkey : state.hotkeys) { bool active = hotkey.state->sequence.size() > 0; for(auto& key : hotkey.state->keys) { if(pressed[key]) continue; active = false; break; } if(hotkey.state->active != active) { hotkey.state->active = active; active ? hotkey.doPress() : hotkey.doRelease(); } } return pressed; } Basically, it means active is true, and the for loop doesn't run at all, and the if block does on first poll and runs hotkey.doPress() A similar issue happened in pKeyboard::poll()
auto pKeyboard::poll() -> vector<bool> { Here, Keyboard::keys not yet being initialized when pKeyboard::initialize got called means settings.keycodes never got set and is empty, so nothing ever gets polled.if(Application::state().quit) return {}; vector<bool> result; char state[256]; #if defined(DISPLAY_XORG) XQueryKeymap(pApplication::state().display, state); #endif for(auto& code : settings.keycodes) { result.append(_pressed(state, code)); } return result; } My hacky workaround in both polls was more or less to check if things are initialized correctly in them, and initialize them on the spot if they weren't, namely
auto Keyboard::poll() -> vector<bool> { and
auto pressed = pKeyboard::poll(); for(auto& hotkey : state.hotkeys) { bool active = hotkey.state->sequence.size() > 0; if(hotkey.state->keys.size() == 0) {hotkey.setSequence(hotkey.sequence());} //<-- This line for(auto& key : hotkey.state->keys) { ...
auto pKeyboard::poll() -> vector<bool> { if(Application::state().quit) return {}; if(settings.keycodes.size() == 0) { initialize(); } //<-- and this one vector<bool> result; ... Not really the nicest way to do it, but there's not really a good way around the compiler deciding to run constructors that are using Keyboard::keys before actually initializing Keyboard::keys to any more than an empty vector, which seems to be what was happening. Only on Windows, though, on my linux box, it built and ran cleanly. Which was part of what was so confusing, since it'd be like 95% of the same hiro/gtk code running either way. Also, to Kawa, I'm kind of missing the pre tag for inline code stuff already, bolding just isn't really the same as the kind of formatting the code and source tags here do for blocks |
| SuperMikeMan |
Posted on 19-02-19, 01:23 in board.byuu.org has been closed; byuu.org upgraded
|
|
Post: #3 of 6
Since: 10-31-18 Last post: 1944 days Last view: 72 days |
RIP the second bBoard, it will be missed |
| SuperMikeMan |
Posted on 19-04-12, 02:38 in Help wanted: Windows dynamic rate control support
|
|
Post: #4 of 6
Since: 10-31-18 Last post: 1944 days Last view: 72 days |
Posted by byuuDoes the DirectX SDK for XAudio 2.7 not install on Windows 10 any more? If it really doesn't, then maybe my 6 year old patch to xaudio2.hpp and ruby makefile to make it use XAudio 2.8 (the Windows 8 version that your Windows 10 should definitely already have) instead is finally of some use to you, just to let you be able to test it. https://helmet.kafuka.org/byuubackup/viewtopic.php@f=3&t=3633.html long post most of the way down that link. Yes, that's the older archive, that's how old that is. |
| SuperMikeMan |
Posted on 19-06-23, 08:29 in Mozilla, *sigh*
|
|
Post: #5 of 6
Since: 10-31-18 Last post: 1944 days Last view: 72 days |
So, I got to deal with a fun bug in Firefox today. My mom was complaining to me that when she was opening links from her emails in Thunderbird it was opening it in a new Firefox window instead of in a new tab on her already open window like it used to. Since I'm the guy who knows computers in my family, I'm of course the one who has to fix this. After having a lot of trouble finding anything useful about this, and not even being sure if this was a Firefox problem or a Thunderbird problem, I eventually got to this thread about people having similar issues where they have an open Portable Firefox but external links were opening in a non-portable Firefox or a different profile. From there, I got to see this lovely bug report about the issue at hand. It turns out this is new behavior introduced in Firefox 67, where external links will always open in Firefox's default profile, to the point where it will open a new window to do so even if you already have a running firefox that's using some other profile, because fuck you, that's why. The bug was even nearly instantly closed as RESOLVED INVALID and has several newer bugs marked as duplicates of it, despite that the stated rationale for closing the report that way doesn't really make any sense, and the guy's only answer to the bug reporter and others asking for clarification and/or saying why it makes no sense was just to repeat it a few times. What I had to do to fix the specific issue I was dealing with was manually edit Firefox's profiles.ini to properly know about the profile on my mom's USB drive that I'd jerry rigged a firefox shortcut on the desktop to always open it with, so I could then set that profile to be the default one and give firefox what it wanted. |
| SuperMikeMan |
Posted on 19-07-27, 08:39 in Ubuntu: x86_32 is dead because WE SAY SO!
|
|
Post: #6 of 6
Since: 10-31-18 Last post: 1944 days Last view: 72 days |
Posted by tomman Looking up what AMD processors have AVX2 out of curiosity https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2 tells me AMD was even later to that party than Intel, and only the final generation of pre-Ryzen architecture, Excavator, in 2015 near the same timeframe as Skylake, finally got that. So the move is an even bigger fuck you to AMD processors |
