• GeneralSolved
  • Feature REQ: Turn flashlight on/off by holding power button

f13a-6c3a

I'm sure there are many freelancers. But how many have ever actually submitted a pull request that has been accepted by GrapheneOS?

Many open source projects have a very tight knit project team. I'm not sure the recommendation of paying freelancers has ever actually been done on this project.

    dirksche Puh. I'm very sorry that I started this weird discussion. I'm out. 😁

    That's all it took? Really? It must not be then "this extremely practical feature" :)

    Graphite I'm not sure the recommendation of paying freelancers has ever actually been done on this project.

    I was thinking about that when typing the recommendation and if it was me who needed something like that, I'd probably start in the Matrix chat, get some details from the mods and devs and MAYBE, offer one of the GOS devs a quick side gig (if it was indeed quick) to get it done. If unsuccessful, then I'd re-evaluate based on the probability of GOS including my pull request, or just pay to have GOS fork of my own with the function I need.
    The bottom line: there is no free lunch :)

      Along with getting someone to work on and implement features like this, it also has to be considered whether the project actually wants the feature to be added in the first place, and whether it's something that they want to maintain going forward.

      In all of the issues linked in this thread, the project's position was explicitly clear on that it is not a feature that they want to add. Even if someone submitted a pull request for it, either as a volunteer or someone who was paid to do it, it's very unlikely that GrapheneOS would accept that patch.

        matchboxbananasynergy now I'm getting irritated. 🤷‍♂️
        /s

        That's it! That's the answer - not happening in GOS, the only other solution for someone who absolutely needs a function that's not in GOS is to fork their own

        matchboxbananasynergy

        Very true. For this feature request, it's never going to happen.

        There are other features that I would like to see that currently have a feature request open in the OS issue tracker on GitHub. Low priority and been open for a while. I think those are the targets to get outside help.

        f13a-6c3a MAYBE, offer one of the GOS devs a quick side gig

        1. No joy. I asked on GitHub if I could donate just to get higher priority for this feature, and was promptly shot down.

        Features are not prioritised based on the amount of donations/bounties for it. GrapheneOS team are not contract workers.

          matchboxbananasynergy

          I don’t mean this with any disrespect and I generally agree that a feature like this doesn’t necessarily fit with the prioritization of security with Graphene. One comment though, the ‘project’ doesn’t have a position as it’s not a living/thinking thing. Often times depersonalization language like that is used to avoid saying some person (presumably Daniel) or couple of ppl (devs) doesn’t agree, but to try to make it sound more official and less authoritarian.

          Just my two cents

          f13a-6c3a That's all it took? Really? It must not be then "this extremely practical feature" :)

          What do you want to know now exactly. My only point is, that i'm irritated because of the harsh tone of the devs, that this feature will never be implemented. Thats all. As a LOS user I loved the feature.

            jarell 'd hate for GrapheneOS to go under because the community became too toxic for the devs to handle.

            You stated that the devs are few in number. I can see that on the github page, unless there are many not listed there.

            In my decades of experience, most devs in anything but a tiny project should develop - not interface with the public.

            Many devs have knowledge and experience which are in short supply - as stated here repeatedly. Their valuable time is squandered by hanging in chat forums. And some devs are not people persons so they actually do their project harm by interacting directly with users and leaving bad, public impressions instead of designing, coding, testing, and releasing which only they can do.

            Fortunately, GrapheneOS devs are complemented by non-devs like @matchboxbananasynergy who have proven enthusiasm and skills dealing with users - even me - day after day. I would suggest that folks like @matchboxbananasynergy are equally as valuable to a F/LOSS project like GrapheneOS.

            If a dev on any project is getting turned off by "toxic" users, I suggest they focus only on the software work, especially in a project like GrapheneOS where there are already excellent public-facing volunteers doing a good job. People who create excellent documentation are equally valueable.

            On that, I want to give a big shout out to the longtime developer and F/LOSS community member Marcel Bokhorst of FairCode, who has not only produced an excellent F/LOSS mail client, which I use on GrapheneOS, but has top notch, friendly interpersonal communication with his users. I am a new FairEmail user and just gave him a big donation this week for all of these attributes.

            A well-known tenet in the non-profit fundraising world of which I have experience is that people give do not give to infrastructure or even organizations. They donate to people. GrapheneOS falls short here in my experience with many organizations, but that can be changed and the project - and devs - will benefit.

              @ve3jlg I appreciate the kind words, truly!

              That said, I would try to extend a tiny bit more good faith towards the development team who's doing their absolute best to provide an OS that people depend on.

              If someone requests something that has been requested 50 times before, and the answer has always been "no", with varying degrees of an accompanied explanation as to why, there has to come a point where the response is less patient.

              Things like duplicate feature requests will happen, that's inevitable, but I urge the community in the general to keep in mind that there are humans behind the project who are working around the clock to provide this OS for us. When interacting with the project, we should try to put an effort in to look for previous issues about the same thing, or, for example, if we're experiencing a bug, try to at least do a search around the Internet to see if it's happening to non-GrapheneOS users as well. Things like that might seem minor, but if everybody does their due diligence, the workload of dealing with bug reports/feature requests will be significantly slimmed down.

              Furthermore, when it comes to feature requests, people often don't accept no for an answer, I've found. Personally, I am glad that the project has a specific vision for what it wants and doesn't want, instead of simply taking every request on board and ending up with a franken-system of everybody's little pet feature, but that's just me.

              Not only does being selective with which features to add/consider keep the OS lean from a user perspective, but it also keeps the OS lean from a development and maintenance perspective. I'm sure people who have used the OS for a while have noticed how quick it is to port to new Android versions, quarterly releases, and even entirely new devices. This is not an accident. Sure, it's partly because the development team working on the project is highly skilled, but it's also because the OS is kept lean so that it's easy to port. Other OSes that have these fancy features pretty much always take significantly longer to update/port etc. That's not a coincidence. There's a debt that comes with the more features you add, and I think GrapheneOS has the right idea by primarily considering features that improve the security and privacy of its users first.

                matchboxbananasynergy There's a debt that comes with the more features you add, and I think GrapheneOS has the right idea by primarily considering features that improve the security and privacy of its users first.

                Technical debt is a HUGE thing. Understanding this really helps to not push for some features that would add significant debt.

                matchboxbananasynergy we should try to put an effort in to look for previous issues about the same thing

                It also might help if someone were to compile an Official "To-Do" list that the devs are working on already. But its best if no feedback is allowed on the list.

                ve3jlg some devs are not people persons so they actually do their project harm by interacting directly with users and leaving bad, public impressions instead of designing, coding, testing, and releasing which only they can do.

                This ^^^ 100%. IT people in general can be perceived as salty and unapproacheable. Developers are often this to the nth degree.

                dirksche

                GoS goal is to take AOSP and harden its security - that's it. The devs aren't "being harsh," you're just not in touch with the philosophy of the GoS project.

                There are probably thousands of GoS users who do NOT want the devs to spend their time implementing, and then maintaining, this flashlight feature.

                I first and foremost care that the devs are able to continue to give us a secure, degoogled Android experience.

                Press the power button, wipe down, touch "Flashlight." Best of luck.

                Thanks GOS devs for all your work!

                Here is an in part solution. Download keymapper and give it accessabilty permissions and map the flashlight to what ever button you like. I was using vol down twice quickly to toggle it.

                  23 days later

                  panopticon Good tip, unfortunately it doesn't work when the screen is off (if you don't have root) which I think is the primary use case for many (me included).

                  With all the respect in the world, I have to push back on the development team on this a bit.

                  Quick flashlight access is clearly a feature that many users want to have, and personally I agree with them. One of the only things I really miss about the Motorola phone I once used is its gestures like 2 "chops" to activate the flashlight immediately.

                  We are grateful for the work the team does on GrapheneOS, and there may be a valid technical/security reason to not link flashlight activation to the power button, but there is definitely a dismissive tone for this request that seems needlessly insensitive.

                  Surely there are ways to look for a solution? Maybe a combination of power button with volume up/down? Maybe a shake/chop motion like what Motorola uses? Perhaps a specific small app as part of GrapheneOS to let the user configure this function? I don't know what the right answer is, just throwing out ideas here. But to flatly ignore repeated requests for a feature offered by many manufacturers to fill a clear and obvious preference for many users cannot be the right answer either.

                  https://twitter.com/MishaalRahman/status/1620926942630354944

                  Android 14 may provide the ability for people to add shortcuts front and center on the lockscreen, and this can include the flashlight. You can already turn the flashlight on while the device is locked by swiping down and using the quick tile, but for people who want to do this even faster, this might be an option.

                  The flashlight will not be mapped to the power key or other gesture at this time. There are other much more useful shortcuts that could be mapped to the button instead. If this was done in AOSP, I don't think GrapheneOS would remove it, but it is unlikely to implement it outside of that.

                    matchboxbananasynergy Thank you for taking the time to respond. The corner function pinning on the lock screen does look like a reasonable solution, particularly with the ability to pin 'do not disturb' or another function as well to the other corner. If the power button or gestures is a solid no-go as it appears to be, this does bridge the quality of life gap, at least for me. Appreciate the info.

                    19 days later

                    @Shendai ... leaving Moto for an LG a while back I missed the chop too and found Shake Torch on Play Store at https://play.google.com/store/apps/details?id=org.rnazarevych.shaketorch was the closest. It says In-App Purchases but is just donations via Play Store and it installed fine from Aurora Store for me, too.

                    Now leaving LG for Graphene I'm trying new stuff and want to thank @[deleted] as I just tried Button Mapper mentioned and think I like that even better, as it's free and easy to setup a long press on a volume button to toggle the flashlight. May buy pro just to support the dev!