Homebrew Homebrew app Ultrahand Overlay - The fully craft-able overlay executor

[alfonsovin]

In

sdmc:/config/ultrahand/themes/

You can use the key combo in addition to the swipe gesture (both are enabled). It works well for me, but I’m using an OLED model; I haven’t tested it with any other screens. But i have heard from others testing it that it works well for them. It helps if you use your thumb, then do a smooth swipe from off the screen inwards. Cover a distance of a little over a centimeter and it should trigger.

I could potentially make the sensitivity (swipe duration and distance traveled) configurable variables so people can refine it more themselves, but I’ve found how it is currently setup to be a decent default configuration.

I will try more times but I can tell you that gestures work but key combo not always. I must proof again

 

[ppkantorski]

I will try more times but I can tell you that gestures work but key combo not always. I must proof again

ah so your key combo isnt working? that is indeed weird. (also first time ive heard this). for me and everyone else I know that has tested, swipe should not affect using your key combo at all.

 

[alfonsovin]

ah so your key combo isnt working? that is indeed weird. (also first time ive heard this). for me and everyone else I know that has tested, swipe should not affect using your key combo at all.

What I suspect after read you, I have a problem with ZR button. Need to review my Joycon. I need to change the led last week and maybe close it bad

 

[NotUsingAnAltAccount]

@ppkantorski This swipe to open function is amazing! Thank you, no more L + ZL + R + ZR

 

[impeeza]

@ppkantorski hello there, have you played with PNGShot? look into this issue:

https://github.com/J-D-K/PNGShot/issues/2#issuecomment-2357253584

 

[ppkantorski]

@ppkantorski hello there, have you played with PNGShot? look into this issue:

https://github.com/J-D-K/PNGShot/issues/2#issuecomment-2357253584

has something to do with how they handle `captureButtonPressEvent`. I know this issue isnt present in BMPPrinter, so it comes down to how they implemented it. Ultrahand utilized `captureButtonPressEvent` to make screenshots opaque. i cant quite figure out the exact way to prevent issues with PNGShot on my end, so something may have to change in PNGShot's code.

Post automatically merged: Sep 19, 2024

has something to do with how they handle `captureButtonPressEvent`. I know this issue isnt present in BMPPrinter, so it comes down to how they implemented it. Ultrahand utilized `captureButtonPressEvent` to make screenshots opaque. i cant quite figure out the exact way to prevent issues with PNGShot on my end, so something may have to change in PNGShot's code.

i will look into it a little more though to see if theres anything i can do to prevent the capture event from triggering. the way their code is setup, even if the event is not a button press but is a capture button event, it will trigger a screenshot. this is why it triggers a screenshot every time. it appears to me that even just initializing `hidsysAcquireCaptureButtonEventHandle` will trigger an event upon initialization. but this should happen in a very short window (shorter than it takes for one to actually click and release the button)

bmpprinter does some more checks for the button press duration (which pngshot does not do). this also means pngshot will trigger screenshots even if you do a long hold of the screen capture button as well. I think that if pngshot took button press timing into consideration a bit more thoroughly, they could easily address this problem.

 

[ppkantorski]

Screen underscanning (adjusted screen size) fix for libtesla now live in Ultrahand v1.7.8.

Overlays will still need to be recompiled for these fixes to be applied (like my rebuild of Edizon Overlay for instance).

 

[hippy dave]

Screen underscanning (adjusted screen size) fix for libtesla now live in Ultrahand v1.7.8.

Overlays will still need to be recompiled for these fixes to be applied (like my rebuild of Edizon Overlay for instance).

It doesn't seem clear from the commit messages where to look for these fixes, maybe you could highlight them for other devs to refer to more easily?

 

[ppkantorski]

It doesn't seem clear from the commit messages where to look for these fixes, maybe you could highlight them for other devs to refer to more easily?

See `getUnderscanPixels` and `init` in `tsl::gfx::Renderer`. Or try building the overlay with the updated libtesla (which includes many more fixes and tweaks than just this one.)

 

[ppkantorski]

Ultrahand Overlay has now been split into its own library for building overlays (and linked).

https://github.com/ppkantorski/libultrahand

libultrahand for building overlays is currently a work-in-progress. I am still going through the process of ensuring that more overlays can be built without issues. So far many I've rebuilt have zero problems, but I am still patching up the rough edges that may have been left from some of my modifications. (like trackbars for instance, which I may need to make either backwards compatible with my new implementation, or just include the old methods on the side by renaming the current methods)

 

[Tyvar1]

Ultrahand Overlay has now been split into its own library for building overlays (and linked).

https://github.com/ppkantorski/libultrahand

libultrahand for building overlays is currently a work-in-progress. I am still going through the process of ensuring that more overlays can be built without issues. So far many I've rebuilt have zero problems, but I am still patching up the rough edges that may have been left from some of my modifications. (like trackbars for instance, which I may need to make either backwards compatible with my new implementation, or just include the old methods on the side by renaming the current methods)

Thanks for your contribution to the scene!

Will you release your fork of FPSLocker?

 

[ppkantorski]

Thanks for your contribution to the scene!

Will you release your fork of FPSLocker?

I actually submitted a pull request to Masagrator, so hopefully he can make a decision sometime on if he wants to include `libultrahand`. I didn't distribute it on my fork for that reason (but it can be compiled). I've also submitted a pull request to proferabg for updating EdiZon.

I think there will be a desire for many out there to update overlays with the updated libraries over time, so hopefully devs at least consider using the libraries so that others don't just refork and redistribute their work with these improvements every time they release something new. But I am not here into force anyone to use my libraries either. I say its optional, but comes with many benefits and tools to make development easier. For devs, if you want those benefits, then maybe consider using the newer libs within your projects. If you don't, then keep in mind that others may be rebuilding the project with the newer libraries over time and re-distributing.

 

[Tyvar1]

I actually submitted a pull request to Masagrator, so hopefully he can make a decision sometime on if he wants to include `libultrahand`. I didn't distribute it on my fork for that reason (but it can be compiled). I've also submitted a pull request to proferabg for updating EdiZon.

I think there will be a desire for many out there to update overlays with the updated libraries over time, so hopefully devs at least consider using the libraries so that others don't just refork and redistribute their work with these improvements every time they release something new. But I am not here into force anyone to use my libraries either. I say its optional, but comes with many benefits and tools to make development easier. For devs, if you want those benefits, then maybe consider using the newer libs within your projects. If you don't, then keep in mind that others may be rebuilding the project with the newer libraries over time and re-distributing.

I see. Thanks!