This is a project I have been working on for the last couple weeks.
Premise: I wanted to display the current weather conditions and moon phase as an icon, while also putting their position on an arc that represents their position between when they rise and set. I was also not satisfied with existing solutions which used a half circle, as I found the height of the 180 degree arc unpleasant, and wanted something a bit shallower.
Result: This widget displays the time, date, sunrise/set time, current temp, the day's high/low, with current wind speed and direction. These are in a static position. The current moon phase and weather conditions each move along a 120 degree arc, and are shown for the periods at which they are visible. At night a field of stars is displayed with astrological constellations highlighted, roughly accurate to the day of the year (not pictured).
Extension: Using popup widget 2, clicking on the current conditions or current moon phase icon pops up another widget, which displays the weather/moon forecast.
Time & Weather Zooper widget: attached
Weather Popup widet: attached
Moon Phrase popup widget: attached
Popup widget 2: Available on play store (I can't post links yet)
Wanted to provide a few more details.
The advanced parameters for the current weather conditions are as follows:
[ar]160[/ar]
[as]$-60+((120/((#ASH#+(#ASmm#/60))-(#ARH#+(#ARmm#/60))))*(#DH#-#ARH#)))$[/as]
This essentially determines how many hours (in decimals) there will be in the day, which is used to determine how many steps will be necessary to show the sun's arc over 120 degrees. This is then multiplied by the number of hours that have past since sunrise, and sets sunrise at -60 degrees (or the left horizon).
The truly troubling one was setting the Moon's arc, specifically because it is more complicated. This is because the moon can rise and set at vastly different times, the most problematic being when the moon rises before midnight and sets after; this breaks the math I used for the sun, as sunset hour ends up being less than sunrise hour at these times.
The advanced parameters I used for the moon are as follows:
[ar]160[/ar]
[as]$#AMSH#<#AMRH#&&#DH#>#AMRH#?(-60+((120/((24+#AMSH#+(#AMSmm#/60))-(#AMRH#+(#AMRmm#/60))))*(#DH#-#AMRH#)))$
$#AMSH#<#AMRH#&&#DH#<#AMRH#?((120/((24+#AMSH#+(#AMSmm#/60))-(#AMRH#+(#AMRmm#/60))))*(#DH#))$
$#AMSH#>#AMRH#?(-60+((120/((#AMSH#+(#AMSmm#/60))-(#AMRH#+(#AMRmm#/60))))*(#DH#-#AMRH#)))$[/as]
This one is much more complicated, but essentially considers three conditions -
1) Will the sunset be earlier than the sunrise, and is the current time greater than sunrise? If these are true, this tells me that the moon will cross the midnight threshold, but has not yet done so. What follows is a formula similar to the current conditions arc, but adds 24 to #AMSH# to accurately determine how many hours the moon will be in the sky.
2) Will the sunset be earlier than the sunrise, and is the current time less than sunrise? If these are true, this tells me the moon has already crossed the midnight threshold. The previous formula is used, although arc origin is not moved -60 degrees, and the current hour is used to determine location on the arc (#AMRH# is not subtracted from it).
3) Will sunset be later than sunrise? If true, the moon will not cross the midnight threshold and my formula is largely unchanged from that which governs the current weather condition arc.
(hopefully someone finds all of this useful. If there is anything incorrect about this, please let me know)
lydonw said:
Wanted to provide a few more details.
The advanced parameters for the current weather conditions are as follows:
[ar]160[/ar]
[as]$-60+((120/((#ASH#+(#ASmm#/60))-(#ARH#+(#ARmm#/60))))*(#DH#-#ARH#)))$[/as]
This essentially determines how many hours (in decimals) there will be in the day, which is used to determine how many steps will be necessary to show the sun's arc over 120 degrees. This is then multiplied by the number of hours that have past since sunrise, and sets sunrise at -60 degrees (or the left horizon).
The truly troubling one was setting the Moon's arc, specifically because it is more complicated. This is because the moon can rise and set at vastly different times, the most problematic being when the moon rises before midnight and sets after; this breaks the math I used for the sun, as sunset hour ends up being less than sunrise hour at these times.
The advanced parameters I used for the moon are as follows:
[ar]160[/ar]
[as]$#AMSH#<#AMRH#&&#DH#>#AMRH#?(-60+((120/((24+#AMSH#+(#AMSmm#/60))-(#AMRH#+(#AMRmm#/60))))*(#DH#-#AMRH#)))$
$#AMSH#<#AMRH#&&#DH#<#AMRH#?((120/((24+#AMSH#+(#AMSmm#/60))-(#AMRH#+(#AMRmm#/60))))*(#DH#))$
$#AMSH#>#AMRH#?(-60+((120/((#AMSH#+(#AMSmm#/60))-(#AMRH#+(#AMRmm#/60))))*(#DH#-#AMRH#)))$[/as]
This one is much more complicated, but essentially considers three conditions -
1) Will the sunset be earlier than the sunrise, and is the current time greater than sunrise? If these are true, this tells me that the moon will cross the midnight threshold, but has not yet done so. What follows is a formula similar to the current conditions arc, but adds 24 to #AMSH# to accurately determine how many hours the moon will be in the sky.
2) Will the sunset be earlier than the sunrise, and is the current time less than sunrise? If these are true, this tells me the moon has already crossed the midnight threshold. The previous formula is used, although arc origin is not moved -60 degrees, and the current hour is used to determine location on the arc (#AMRH# is not subtracted from it).
3) Will sunset be later than sunrise? If true, the moon will not cross the midnight threshold and my formula is largely unchanged from that which governs the current weather condition arc.
(hopefully someone finds all of this useful. If there is anything incorrect about this, please let me know)
Click to expand...
Click to collapse
I just wanted to say that this is really awesome. I just got into Zooper last week, and one of the first things I did was to try to create a moon phase widget. I was able to come up with something that works "ok", but it's ugly as sin and could definitely use a lot of improvement. If I have some time, I'm going to try yours out. Also, the explanation on the math and advanced parameters is helpful as I was disappointed that Zooper didn't handle the time math in the way I expected.
Thanks,
Jeremy
I find very interesting your work: it was long expected that a solution like the one you proposed. Thank you. I'm trying to apply your directions, but I trust in your work complete.
I'm just finding this now and have to thank you very much for the hard work. Looks great, I'm definitely going to be incorporating some of this into my existing Zooper dashboard.
How do I use template once downloaded
Related
I previously sorted out the locking up problems with help from you guys on here, and I'm sure that I have seen something about a battery indicator on screen when not using O2active but can't find it. Can someone post a link to the thread if it actually does exist or does the function not exist out of O2active?It's quite possible that I had a "moment" and imagined that I saw this of course - it's an age thing, hopefully!
Cheers. Alan
Why not load up the GPRS monitor program that the device come with and configure that to display Battery status on the screen - after its free, and a damn good utility if you use GPRS to track the cost - Mike
Or download Batti (just search for it - it's free)... I use it, and love it, for various reasons I won't bother to detail here
Thanks for that, I'll do a bit more digging. I don't use GPRS for monitoring (as far as I know) so I'll have a look at batti.
In. Done. What a handy little thing! Thanks again.
There's several, really... I like to classify them graphically as...
A. Applications
B. Today screen/Tray
C. Task bar
D. Top/Bottom overlay
The first group, Applications, I wouldn't even bother with. They tell you what the battery level is, and sometimes more information, but you do need to actually run the application. So there's no quick view of what the battery level is at any time.
The second group is nice if you're on the Today Screen a lot. They typically have nice graphics. However, they'll only be on your Today Screen, and take up space there. Very often the larger "Does everything!" applications that use the Today Screen will have one of these, typically along with indicators for memory and storage space.
The third is a bit nicer already. You can see it on any screen, as long as the task bar is in view. There's just one problem - they take up space on the precious task bar - and there's not a whole lot of space there on a QVGA device when in portrait mode. Some solve this by putting a tiny little bar underneath the clock - so much for getting a readout 'at a glance', though. In addition, any application that hides the task bar, will hide that indicator as well.
The last category, at least for me, is ideal - and Batti belongs in that category. Thes are the battery indicators that are usually just a line of a few pixels (or even 1 pixel, like Batti) high, going across the top/bottom of the screen. They're always visible, and you can easily tell how full your battery is even if it's just a white solid bar (such as what's in MagicButton).
They usually come in two flavors.. a solid bar going from left to right, or individual little bars, so that you can easily count in percentages. One of SPB's products comes with one of these, for example. Which style you prefer is really a matter of personal likings.
What's extra nice about Batti is that you can set it up to change the color of the bar at two percentages (e.g. 33% for 'low' with an orange color and 10% for 'critical with a red color), all user-definable. It can also indicate charging, and has a nice textual read-out of charge, voltage, temperature, etc. if you click on it (optional). The frequency with which it updates can also be setup. Some of the battery indicators poll every second, for example, thereby actually draining the battery a good bit itself more than it needs to. I have mine set up to update every minute, which is more than enough.
The *only* thing I would love to see added to it is alarms for the two percentages - which I've requested from the author, but haven't heard back from him as of yet Some of the other battery indicators may have alarms, so that might be something to keep in mind.
Batti
Where can I download Batti from ?????
http://www.google.com/search?q=pocketpc+batti
Battery meter.
I downloaded Batti and I dont think its very good at all !!!. The battery level indicator that comes with Pocket Hack Master is way better. However what I realy Real Real need is the OLD battery level software from WM2003. You know the one with red and green in the settings folder. Unfortunately I deleated it when I hard reset my phone.
Please anyone out there who has the old WM2002/3 still on file. Can you send me a copy of the file I need to make that work again.
Thankyou
Rob
I guess you'd have to state your reasons for liking the one that comes with Pocket Hack Master better
There's three things that are at play, to begin with...
1. Pocket Hack Master isn't free. Of course, if you are looking into the functionality it offers (CPU clock speed tweaking, etc.), then its built-in battery meter is a nice bonus when you do buy it anyway.
2. Pocket Hack Master doesn't run on all devices. Due to the fact that it is an application mostly geared towards CPU clock speed tweaking, it will refuse to run on unsupported processors such as the TI OMAP processor. I believe this doesn't apply to the Blue Angel, but does to e.g. the Wizard.
I have an HTC Wizard.
3. Personal preferences. Everybody will prefer their own style of battery meter, etc. You didn't fully explain why you like Pocket Hack Master's better, and unfortunately I can't fully review it as Pocket Hack Master refuses to work on my device. However, from some screenshots it appears that you can only set colors for battery or A/C (i.e. no change of color based on the charge level), the size appears limited (though you can make it a small 2px bar or a series of 4px blocks), and you can't set the refresh rate. On the other hand, you can fully control its positioning and hide the border. All in all - though again.. I'd have to actually be able to run it to make sure.. I haven't seen an screenshot of the 'gradient' method for example - I'd still have to stick with Batti on features alone.
Hopefully they'll add TI OMAP support soon, as it would be worth getting for that, for sure
For the curious, Batti was updated to version 1.4.
Added: Sound Events
Added: Option for turning off the frame around Batti
Added: Option for blinking on critical level
Added: Battery status on Info page (Charging, On AC, On Battery)
Added: Custom color for charging*
Some bugfixes
* charging is different from being fully charged. Sound events can be defined for charge start and charge end as well.
And I forgot to mention in my main rant that you can change the strings for localization easily - most of the main languages are already available for download
My question about this utilities, is which takes least memory space and battery life?
I hate to install something very usefu which on the downside slows down the device and makes me go crazy with the battery.
Of course anything that continuously monitors the battery performance will take up extra battery life itself, though it's typically negligable. Batti itself can be configured to poll only every N seconds - I have mine set to 60 seconds, but obviously there's no real reason to even set it to this frequency - the battery won't drop that much in a minute
As for memory use, I can't really report on others, and you have to keep in mind that several of the battery monitors are part of a larger whole; and if you want the larger whole anyway, then you typically won't lose any additional memory from enabling the battery monitor functionality. For example, MagicButton has a battery indicator line as well.
Batti takes up roughly 40KB
If you want a pure battery monitor proggie:
http://forum.xda-developers.com/showthread.php?t=364278
One of the best
This clock is based on Led Clock by David Horn posted on here some time ago. The principle of the clock is minimalism. The left column represents the hous, the next five columns represent minutes and the final column represents groups of five seconds (if you choose the 'show seconds' option). The hours increment upwards, the minutes increment leftwards then upwards and the seconds increment upwards. I have taken David’s original clock idea and bolted on lots of user options purely as an exercise to get up to speed programming for the compact framework.
Features
=======
Set individual colours for many elements such as hour leds, minute leds, second leds, frame, font and background.
Draw rectangular or round leds
Show / Hide seconds
Show digits on hours, minutes, seconds
Change led size – small, medium, large.
Imaging:
Load image as foreground, the image gets drawn piece by piece like a jigsaw as another led gets added to the clock. Watch your image build up on screen as the hour goes by. Alternatively you can set the image as a background image and the clock gets drawn on top.
Image Folders:
You can also specify a folder of images and set the rotation frequency to minute, hour or day. The current image behaves as above and gets rotated so you can have a new image loaded every day, or hour etc.
I am using GDI to draw the clock but it is heavily optimized. The thread only runs every 5 secs or every 60 secs if you choose not to show seconds. The drawing itself only draws what is absolutely necessary at any time. So if we are not refreshing / painting the form, usually we are only drawing a single led therefore this should be light on resources. As evidence of this, consider the fact that I am not using double buffering anywhere and yet the redrawing is always flicker free and stable.
I wrote this clock as a Touch HD owner but tested it on several of the mobile images. It should run on any Windows Mobile device and on most screen resolutions from version 5 upwards. It currently uses .Net 3.5 but I can port it back to 2.0 if required as all the code is legacy written and I am using no libraries from the newer framework. I’d appreciate any reasonable feedback.
Previews
======
Surely this should've been posted in the themes, apps and software section?
MOD EDIT
Moved to themes, apps and software forum
oops, sorry about that.
On the htc clock/weather widget, the little weather picture (sun, sun with clouds, moon) seems to be off lol. For example, its 10 pm, but according to the weather widget, its still sunny outside. I have the location set right, and refreshed/reloaded it a few times as well. Is that normal, or is there some kind of fix?
I had the same problem until I checked my process/app killer and noticed it was being auto-killed so it wouldn't update, in fact it would disappear from the clock and date completely. I would have to click where it should be and bring up the main weather app and hit the refresh button then click back to the home screen and it would refresh there. Find out what app killer is killing the process and put it in the ignore list.
Cheers...
You're not alone. I've seen this problem on my mom's stock HTC hero and my gf's stock Evo as well as my own rooted Evo using damage control Rom. Even more odd is comparing "current" location with exact same location hand selected. Current location will be totally off while same selected location is correct.
Also worth noting is side by side comparisons of HTC weather widget, fancy widget (available in the market) and the weather channel. They will all show different temps and conditions.
I don't know for sure, but my guess is they pull weather data from different sources and sometimes the sources are not providing accurate data.
Also worth noting is that none of the 3 devices I've mentioned were using a task killer.
Its not that much of a big deal to me. It's kind of irritating to not have things line up right, like exact temperatures and the moon or sun, but oh well. I live in Florida, so all I care about is if it will rain or not. Anything over 80 degrees doesnt matter here haha.
Hi,
this is a topic I want to start in order to help the development of more intelligent brightness control for Galaxy S (probably regional variants of it will benefit as well).
It began with my PM to some of kernel DEVs that I've noticed brownish color instead of black on ONE brightness setting. My idea was to omit that one brightness level.
Overnight, I already got two responses. One that it should be no problem and one that the link I sent might lead to fixing the problem I mentioned as well (color correction).
The other, connected to brightness topic, thing I've noticed is that auto control of it is retarded. First, it's too jumpy without any reason (like let's say change of outside brightness) and second it likes to set level that burn the eyeballs. I've never had such problem on my CM Hero.
Here's my original PM:
embrion said:
Hi,
I'm PMing you as the most popular kernels coders.
Long story short: SAMOLED screens like to make black or similar colors brownish at low brightness. I've (and not only me) noticed that there's a step just about min. when it starts to be brown and a next step after that it magically stops. The idea is to omit this step at all or just in auto brightness table. I believe It's doable by using those methods.
The original story begins here from the first half of #522 post
Like I've wrote there, this problem exists in all kernels and all color temperature variants of them + stock one.
If you're interested, please respond me. If not, also respond as I'd like to know if I can count on anything.
Thanks
Click to expand...
Click to collapse
Some links that might help:
[SOLUTION] Fix for minimum screen brightness! [10/13 - adjustable]
Kernel makers, please add the ability to adjust auto brightness.
[APP] Different auto-brightness
Gizmodo - Why iPhone 4 and Android Brightness Controls Are Effectively Useless
My random thoughts:
One option would be fooling the sensor that it is less bright than it is
Another, more proper I believe, it to modify some brightness tables to leave extreme brightness levels to extreme outside light situations. This one would also help skipping this "brown" brightness level as like I said, it looks to be only one level
Color correction MIGHT fix "brown" problem too, but I'm not sure as COLD and WARM kernel variants didn't changed this brown problem (unless colors are optimized only for some of the levels like I've read at VOODOO site)
CM 6 already has such brightness level options in Settings-> CM Settings - > User interface -> Automatic backlight -> Use custom(just checked on my Hero) so probably lot of code can be reused (as I believe there is CM for Galaxy S)
Kernel DEVs, fell free to hijack this thread. It is to help your cooperation (unless each one of you prefer to solve problems on they own ) Btw. don't be offended if I didn't included you in the DEVs list I've sent my PM. It was late and I PMed only those I've noticed that they kernels I've used. All of you are more than welcomed.
Other, please don't post "I cannot see any brown", and those one that can see it, please stop posting about info after first 5 people do
I'm so happy to read this threat. I had posted questions about display and auto brightness a couple of months ago in the questions section but never received any credible responses.
My problem is that when I turn auto brightness on, not only does my display get exceptionally dark, but it becomes very noticeable that e.g. grey turns more brownish. Comparing my display to yet another Galaxy S confirmed my suspicions that this is not they way the display is supposed operate, i.e. compared to mine the other Galaxy stayed a lot brighter in equal lighting conditions and the grey remained grey (instead of brownish-grey like mine). I compared the grey tones of the numeric buttons in the stock Dialer APP to conclude this.
I suspectED the light sensor might be defective, but I have run the test menu on a couple of Galaxies (*#0589#) and the units always display the same values when put next to mine.
You might see why this is bugging me so much, it seems my galaxy's display is not using less battery even though I get less brightness than the others on auto brightness. Unless I manually bump up the brightness to full the colors on my screen look dull (grey turns Brownish, and over all it looks not as alive) as compared to other units. Simply bumping the brightness up is of course not an option, this drain the battery like crazy.
EDIT: I too have tried the various Kernels, hardcore warm and cold, voodoo w/ color fix sadly all to no avail
EDIT2: @embrion The above all doesn't explain why our phones have this problem, but the far majority of Galaxy S phones doesn't. Of course I cannot statistically back this up, but I have not physically seen any other device that gets brown on autobrightness like ours. Any Ideas?
Do you say your friend's Galaxy S doesn't turn brownish or it does but gives higher brightness than your device in same lighting conditions?
embrion said:
Do you say your friend's Galaxy S doesn't turn brownish or it does but gives higher brightness than your device in same lighting conditions?
Click to expand...
Click to collapse
It does not turn brown and appears much brighter in equal lighting w/ auto brightness ON. I edited my post above, please read again if it was unclear before. Thank you!!
You should check it at manual brightness at level set few steps higher than min. I'd like to separate brownish display problem at one brightness level from inproper light sensor measure
embrion said:
You should check it at manual brightness at level set few steps higher than min. I'd like to separate brownish display problem at one brightness level from inproper light sensor measure
Click to expand...
Click to collapse
Like I said, the light sensor does not give an improper measure, the readings in *#0589# menu are equal across the devices (including mine). The brownish color tones do, to some degree, disappear if the brightness bar is set two ticks to the right of minimum.
(Auto)brightness corrections
Original Auto Brightness level is too high & sluggish.
It 's need to fix like a voodoo Brightness level fix (2.1 only).
schiphol said:
Like I said, the light sensor does not give an improper measure, the readings in *#0589# menu are equal across the devices (including mine). The brownish color tones do, to some degree, disappear if the brightness bar is set two ticks to the right of minimum.
Click to expand...
Click to collapse
Yes, mine too. Second step from min. setting. I'll ask guys at my local forums to get some statistics. If your friend doesn't have such problem at the same color/theme than it must be display fault
embrion said:
Yes, mine too. Second step from min. setting. I'll ask guys at my local forums to get some statistics. If your friend doesn't have such problem at the same color/theme than it must be display fault
Click to expand...
Click to collapse
Which CSC code do you have? I mine was originally XEN (Netherlands). The units I tested that did not have the problem were all DBT (german Sim free). Just asked my brother and he says his phone also gets brownish (also XEN). Have to check product codes later, will update then.
Mine is XEE (Orange, Poland)
Supercurio did some tinkering with those settings:
https://github.com/project-voodoo/l...a2/Kernel/drivers/video/samsung/s3cfb_mdnie.c
I suspect this is the file we need to modify;
Code:
mDNIe_data_type mDNIe_UI[]=
{
#ifdef CONFIG_VOODOO_MDNIE
// Voodoo color: optimized UI mode
// reduce the sharpness filter radius to make it much closer
// to the real fuzzyness introduced by the SAMOLED Pentile pattern
// color saturation boost on everything is also disabled because
// it causes harm on stock settings (exaggerated colors)
0x0084, 0x0040,
0x0090, 0x0000,
0x0094, 0x0FFF,
0x0098, 0x005C,
0x009C, 0x0613,
0x00AC, 0x0000,
0x00B4, 0x0A00,
0x00C0, 0x0400,
0x00C4, 0x7200,
0x00C8, 0x008D,
0x00D0, 0x00C0,
END_SEQ, 0x0000,
Any thoughts and datasheet quotations on this? Because seriously I see just random numbers in this.
Some interesting code begins around line 315, but seriously I'm clueless
Another interesting file:
https://github.com/project-voodoo/l...2/Kernel/drivers/video/samsung/s3cfb_tl2796.c
My screen has brownish/reddish deep grays on brightness settings under 16-17%. However when I set it over 17% and use screen filter app deep grays are NOT brownish/reddish, this means there is definitely something with lower brightness settings.
Xan, check out the link I've posted in the first post. He gives sources that might be helpful
And the problem appears only at 2nd step of brightness (counted from zero brightness)
embrion said:
Xan, check out the link I've posted in the first post. He gives sources that might be helpful
And the problem appears only at 2nd step of brightness (counted from zero brightness)
Click to expand...
Click to collapse
@embrion so did you pm Supercurio? What did he say? It's too bad this color/sharpness fixing will probably be put on a back burner what with Gingerbread and CM7 development. D*RN IT! I tried an app in the market that is more precise than the built-in slider. Try it out Adjbrightness (free). I punched in all values possible between 2-255. The tipping point (where the browness is gone) lies at when you go from 34 to 35. Is this the same for everyone suffering from this problem. Please remove all apps like e.g. 'screen filter' before you try!
For me crucial step is going from
/ # echo 53 > /sys/devices/platform/s3cfb/spi_gpio.3/spi3.0/backlight/s5p_bl/brightness
to 54, however I'm running trasig's voodoo.
While 54 and over looks ok, lower values are... reddish/pinkish.
@schiphol: yes I did but no response. In dark colored Gingerbread era, this problem will be become more and more evident.
@xan: dzieki I'll flash latest Darky as it is based on trasig's voodoo and try your fix.
--edited--
Supercurio just responded me, I'll let you know about results
embrion said:
@schiphol: yes I did but no response. In dark colored Gingerbread era, this problem will be become more and more evident.
@xan: dzieki I'll flash latest Darky as it is based on trasig's voodoo and try your fix.
--edited--
Supercurio just responded me, I'll let you know about results
Click to expand...
Click to collapse
No fix there, just a different behaviour...
Would like to see this in next voodoo, might even write some simple user interface for this.
I have an idea but its not quite clear yet, however if this patch will let most users 'calibrate' their screens.. I think I'll give simple GUI a shot.
@embrion
Could you perhaps upload the screenshots you talked about in R64's thread so I can replicate. Because of different kernels and settings I want to try and establish beyond a doubt that the problem we're having is of the same nature and root cause. Thanks
This wont be visible on screenshots. You need to make a photo, problably with DSLR and know how to do it
I'll try it today and let you know
According to Supercurio, this is Samsung's color profile deviation, not SAMOLED fault itself.
Anything software broken can be software fixed
@schiphol, xan: yes, it won't be noticed at screenshots, I've already compared R64's black notification bar screenshots and my brown ones. Color picker showed a little difference in color (R:24, G:24, B:24 or something VS RGB: 0, 0, 0 - true black). Such difference should'n be visible and is not visible from software screenshot point of view but Samsung color profile makes 24,24,24 brown IN REAL LIFE while 0,0,0 is still black. I repeat, they're both black at screenshots no matter which brightness level is set, but only 0,0,0 black doesn't look like brown when viewed by bare human eye. Samsung profile at this brightness treats 24,24,24 as brown while it should as black.
--edited--
You're right, Xan. It's just another, ( but 1337 ) method of changing the brightness. I thought there's a plaintext table with levels accessible to change by hand
Hi Ok I have kept the brightness at 2 clicks to the right from minimum to stop grey from looking grey-brown all through today. Now my display accounts for 95% of the battery usage, it has never been this high before. The battery is at 25% whilst I only used the display for 44 minutes.
Thats ridiculous battery drainage and should be taken into careful consideration when a fix is developed for this issue. Are you guys having a similar experience??
Thanks for your time. Two questions, #1: I've been around here and throughout other sites, and found (it seems) dozens of different options but none have seemed to work regarding getting an object to follow a CIRCULAR progress bar. In this case, I have a simple clock that I would like to have a sunrise icon and sunset icon (each) move around the outside the clock at the appropriate time. I have tried multiple codes and combos to no avail. I have successfully managed to achieve this result on a straight prog bar using [oy]$(-34+(#BLEVN#*2.70))$[/oy]. Those are, of course, my coordinates plugged in. I've found so many different "Oh, do this, this'll work" codes that don't work, I won't bore you with them (including this one http://forum.xda-developers.com/showthread.php?t=2563932). At any rate, any help would be appreciated.
#2: Is it possible to set up a 12 hour progress bar clock that handles just am and/or just pm?
Thanks again.
#1 Take a look at the Zooper standard analog Clock
#2 Use the 24h. For am use min 0 max 12 and for pm use min 12 max 24
Sent from GT-I9505 via Tapatalk
ibashmuck said:
Thanks for your time. Two questions, #1: I've been around here and throughout other sites, and found (it seems) dozens of different options but none have seemed to work regarding getting an object to follow a CIRCULAR progress bar. In this case, I have a simple clock that I would like to have a sunrise icon and sunset icon (each) move around the outside the clock at the appropriate time. I have tried multiple codes and combos to no avail. I have successfully managed to achieve this result on a straight prog bar using [oy]$(-34+(#BLEVN#*2.70))$[/oy]. Those are, of course, my coordinates plugged in. I've found so many different "Oh, do this, this'll work" codes that don't work, I won't bore you with them (including this one http://forum.xda-developers.com/showthread.php?t=2563932). At any rate, any help would be appreciated.
#2: Is it possible to set up a 12 hour progress bar clock that handles just am and/or just pm?
Thanks again.
Click to expand...
Click to collapse
#1: Moving things circular is a bit different from moving this along a straight line. For circles you need three parameters in Zooper: thie radius of your circle ([ar][/ar]), the sweep angle of said circle ([as][/as]) and finally the rotation ([r][/r]). The first one is static and the other two depend on what you are trying to do. You need to determine the size of your circle in degrees (360 for full, 180 for half etc.) and then determine in how many steps you need to cut that size. For something that moves with the minutes of the hour it would be 60 for instance. Then your amount of degrees per minute is 360/60 and if you multiply that with the numbers of minutes #Dm#, you get your current position and rotation. So for something to move around a circle based on the minutes of the hour you would need these advanced parameters:
[r]<whatever size>[/r]
[as]$(360/60*#Dm#)$[/as]
[ar]$(360/60*#Dm#)$[/ar]To apply this to your idea, you need to figure out in how many steps you want your circle to be broken down to (I would guess 12) and then what's your variable you want to multiply with (#ARK# maybe). With these values it should position the symbol on the hour of the sunrise.
I hope this helps you out and if not, don't hesitate to ask
#2: I think so but you probably would have to work with some advanced parameter conditionals to check whether it's currently am or pm. This depends on what exactly you are trying to do. If you can give me more details I can try to think something up.
kwerdenker said:
#1: Moving things circular is a bit different from moving this along a straight line. For circles you need three parameters in Zooper: thie radius of your circle ([ar][/ar]), the sweep angle of said circle ([as][/as]) and finally the rotation ([r][/r]). The first one is static and the other two depend on what you are trying to do. You need to determine the size of your circle in degrees (360 for full, 180 for half etc.) and then determine in how many steps you need to cut that size. For something that moves with the minutes of the hour it would be 60 for instance. Then your amount of degrees per minute is 360/60 and if you multiply that with the numbers of minutes #Dm#, you get your current position and rotation. So for something to move around a circle based on the minutes of the hour you would need these advanced parameters:
[r]<whatever size>[/r]
[as]$(360/60*#Dm#)$[/as]
[ar]$(360/60*#Dm#)$[/ar]To apply this to your idea, you need to figure out in how many steps you want your circle to be broken down to (I would guess 12) and then what's your variable you want to multiply with (#ARK# maybe). With these values it should position the symbol on the hour of the sunrise.
I hope this helps you out and if not, don't hesitate to ask
#2: I think so but you probably would have to work with some advanced parameter conditionals to check whether it's currently am or pm. This depends on what exactly you are trying to do. If you can give me more details I can try to think something up.
Click to expand...
Click to collapse
Thanks for the response. That's actually the first parameter that I found and tried to work with, and, like then, I still can't get it to work. My "hour clock" numbers are:
x= 60
y= -210
w= 520
Using #Dh#, min 0, max 12
Putting numbers into the codes you gave...
[as]$(360/12*#ARh#)$[/as]
[ar]$(360/12*#ARh#)$[/ar]
...(or even #ARK#) still sends the icon low and to the left, as you can see in the second screen shot (I've enlarged it to show it's position better). I'm living up to my namesake with this, I know, but my guess is I'm missing one small bit that's throwing me off. Apologies, of course.