Setting System brightness Above 255?

Post your questions and help other users.

Moderator: Martin

Pepy
Posts: 76
Joined: 31 Oct 2018 10:53
Location: Canada

Re: Setting System brightness Above 255?

Post by Pepy » 27 Apr 2019 21:44

Your replies are always so long :lol:

So anyway, by common practice, do you mean preferences (such as curly brace placement)?

From your previous reply, I already do understand what you meant by your concept of "flow variables", but I just don't see why you would not just use a Global Variables instead.
Perhaps it will be somewhat helpful since it can be stored in a separate place and not clutter up the list of global variables, but other than that, performance will probably just be the same. How exactly would making it restricted to one flow make it only slow down that flow and not the others? Plus, it'll be restricted to for use in only one flow which might be a bad idea, since some tasks can take more than just one.

If you need to log large amounts of data, why not just export it to multiple separate files (such as by day) like you said? If you separate the files, it'll make it much easier and faster to handle them.

As for calculating the range for multiple devices, are you sure it's a good idea to do this? If we just have the user write down the different ranges for when auto brightness is on or off, for example, we could just switch between them since they'd be stored in a map. Converting them would make no sense, since we have no way to tell what the other range the device use would be. If the user can te you the range, they should also be able to just give you the min and max values. From there, we just have to worry about how much to increase/decrease by each time the vume buttons are pressed.
Last edited by Pepy on 01 Jun 2019 22:53, edited 1 time in total.
Hope my post was helpful :D
Device: OnePlus 5T running crDroid, rooted with Magisk 8-)

User avatar
Desmanto
Posts: 2709
Joined: 21 Jul 2017 17:50

Re: Setting System brightness Above 255?

Post by Desmanto » 28 Apr 2019 07:10

Pepy wrote:
27 Apr 2019 21:44
Your replies are always so long :lol:

So anyway, by common practice, do you mean preferences (such as curly brace placement)?

From your previous reply, I already do understand what you meant by your concept of "flow variables", but I just don't see why you would not just use a Global Variables instead.
Perhaps it will be somewhat helpful since it can be stored in a separate place and not clutter up the list of global variables, but other than that, performance will probably just be the same. How exactly would making it restricted to one flow make it only slow down that flow and not the others? Plus, it'll be restricted to for use in only one flow which might be a bad idea, since some tasks can take more than just one.

If you need to log large amounts of data, why not just export it to multiple separate files (such as by day) like you said? If you separate the files, it'll make it much easier and faster to handle them.

As for calculating the range for multiple devices, are you sure it's a good idea to do this? If we just have the user write down the different ranges for when auto brightness is on or off, for example, we could just switch between them since they'd be stored in a map. Converting them would make no sense, since we have no way to tell what the other range the device use would be. If the user can te you the range, they should also be able to just give you the min and max values. From there, we just have to worry about how much to increase/decrease by each time the vume buttons are pressed.
Hehehe, You ask for it :D

Yes, common practice for making our scripting style readable and consistent, such as :
- Curly braces always in new line
- Always indent 2 spaces for each logic level (in loop or if statement)
- newList or newMap always put per line
- always have space before and after operator
- When creating function script, always use newList() instead of pure string.
- and so on


For glovar vs flowvar, No, the perfomance is a big difference. I realize this one day when doing some logging with chrome announcement windows. I am trying to see if I can utilize the UI event to close the popup. Suddenly my scrcpy flow react so slow. Pressing Ctrl+C in PC usually will immediately copy the clipboard from phone. But it takes more than 5 seconds to do it. There were also so many delay in other flows, such as toast message disappear before it even fully appear, input dialog very slow to show up and many others. It is at time I know my variables.bin have piled up to 100+ KB. I will show you the difference later when i finish typing the request and example flow to test (in few days). currently I am still building the glovar manager flow, to clean up my accumulated glovar; before I can build some test flow.


Logging directly to file is totally different than logging to glovar or flowvar. With glovar, to add the logging, it is simply single script

Code: Select all

addElement(global_sms_log, newList(triggertime, sms_sender, sms_text);
But with files, if we choose to keep the json structure, we have to init the log text file, convert it back to object, add the element, convert back to json, and the write to file. This already takes up 3 actions. Even if we don't keep the structure, this will at least takes 2 action, 1 for the script and another write to file - append. But the log will be ugly, since it can't be in json format. (append will destroy json format). For fast logging flow, this is a problem, as it will reach AES much faster, and hog up some unnecessary resource.

Keeping multiple files per logging also have problem. If we keep one file per flow execution, When we need to reinit all the log file, then we have to loop init all files in the logging folder (if 100 executions, 100 files, 100 init variable text file looping). While logging to glovar, we only loop upon glovar, not to action init variable text file. What I mean for separate files is after the glovar is filled let say with 100 elements, then dump it to text file, clean the glovar afterward (which is what my glovar manager will do)

The other aspect of the flowvar that I request is it will be exported along with the flow. So far, when export the flow, glovar is not included. So if I have flow with predefined variable that users should modify according to their phone, I can put it in flowvar and ask them to change it directly (example, path to the directory, resolution, appname, username, IPAddress etc). Flowvar will ensure the structure is the same. I should make it clear later in the feature request.


For range converting, Using map is possible. Let's say we declare 10 step of changes, and each to the corresponding value. But if the max min is totally different value, example : 0 to 30 range, then user need to change all possible value and calculate by themselves (0, 3, 6, 9, .... 30). If we use min max, user only need to fill 0 and 30 only. And our formula will calculate the range and adapt it to our 0 to 100 scale.
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.

Post Reply