Closed HolyNameSoftware closed 3 months ago
Hi. Thanks for reporting. A screenshot of the widget would of course be very helpful in diagnosing the issue.
Regarding Android 13, despite any warnings that may be displayed, the app is tested fully functional. It simply targets an older version of Android that Google Play deems "too old". Any problems you encounter are likely unrelated to that and should be reported here so I can fix them.
v0.15.16
targets Android 7 (api25). I'm am releasing v0.16.0
today, which increments the target to Android 9 (api28). I cannot say when the app will target Android 13 (api33) though. This last update took me longer than anticipated and introduced a ton of bugs (that I'm cautiously optimistic are all solved). When I'm confident there are no serious problems, I'll increment the target again (most likely to api29 or 30).
Thanks for the screenshot. I recognize this behavior (known bug). It happens whenever the timezone doesn't agree with local mean time. The image should wrap around but doesn't.
I think a workaround is to configure the widget's time zone to "local mean time"; this should center it.
It looks better now. Yeah I reported that bug a while back didn't I mostly about Natural Hour clock face. You still haven't fixed it?. Do you have any further information about the instrumentation readouts like the angles and stuff, maybe a youtube tutorial, I have pretty much ignored that and look to look into the datasource time-4j. This widget functions well to visualise and be mindful of how much sunlight you have left in a day.
Yeah I reported that bug a while back didn't I mostly about Natural Hour clock face. You still haven't fixed it?
Sorry. I'm not seeing anything here. I might have lost track of the issue, but I thought Natural Hour v0.2.2
fixed the known issues. What version are you running?
Those numbers above the graph, from left to right;
with those instruments I guess it uses time-4j for the calculations and gps coordinates of is it the NAVSTAR-GPS 1984 ellipsoid?
NaturalHour looks fine now it seemed to be the same bug of rendering the graphic bad based on CUT system time and being that NH is an extension of Suntimes I kindof guessed the bug was rooted in Suntimes on over to NH when seeing the same bad graphic render.
Why does suntimes use Gaelic moon phases? Isn't it supposed to be a Roman theme? It is your app you can do whatever you want to it. Or is that Gaelic?: a quick search of the term Lughnasadh returns Gaelic talk.
Those numbers above the graph, from left to right;
- current elevation (41 degrees above the horizon)
How does the app determine the horizon would it be mean of an ellipsiod or the visual horizon in the geography which would be seen?
- current direction (259 degrees west on your compass)
Can you make a compass app to go with these. If you confirm these calculations come from time-4j then is time-4j using magnetic north to guage the direction and if so magnetic north on which data?
- direction at sunrise (65 degrees)
I see here you did not note " on your compass " could it be that these directions use a different definition of north?
- elevation at solar noon (69 degrees)
- direction at sunset (294 degrees)
How does the app determine the horizon would it be mean of an ellipsiod or the visual horizon in the geography which would be seen?
It's determined by the library; I'm collecting notes here; https://forrestguice.codeberg.page/Suntimes/help/more/data/datasources/availablesources/
If you are curious you might compare the output of the 4j
and cc
algorithms (I haven't looked closely). I have noticed that the library ignores the supplied altitude (at sea level), so there is sometimes noticeable error in the sun position dialog.
I see here you did not note " on your compass " could it be that these directions use a different definition of north?
I hadn't given it that much thought actually. I only meant to indicate that some of those values were altitudes, while others azimuths.
If you confirm these calculations come from time-4j then is time-4j using magnetic north to guage the direction and if so magnetic north on which data?
I assume the library is reporting values against "true north", so to find them with an actual compass you'll need to adjust for magnetic declination (which is of course a big part of knowing how to use a compass); https://www.usgs.gov/educational-resources/magnetic-declination-varies-considerably-across-united-states
Can you make a compass app to go with these.
I've considered it (but I'm not sure I feel like taking on new projects). There are a lot of compass apps out there, but none seem to be a substitute for the real thing.
Why does suntimes use Gaelic moon phases?
These are "cross-quarter days", which are midpoints between solstices and equinoxes. There's been some previous discussion on the labels, and v0.16.0
changes them yet again.
If you wanted to investigate in detail you might try "driving" the library yourself.
This is the api; http://www.time4j.net/javadoc-en/net/time4j/calendar/astro/SunPosition.html
An example of the app using it; https://github.com/forrestguice/SuntimesWidget/blob/819f8b1332123885bcb21fe00effed5a7e5ca16b/app/src/main/java/com/forrestguice/suntimeswidget/calculator/time4a/Time4ASuntimesCalculator.java#L415
It seems to me you need a stable reference you can't just build on top of libraries. For instance a compass may test if the app output is producing accurate readouts but you don't know how the lib defines north you also didnt respond on horizon if is it a mean of the ellipsoid construct or a visual which is less likely because of needing more calculations of surrounding elevation. I can visualy check the angles later and see if they are correct to the degree. And because there are various GNSS I ask if the library dependency uses NAVSTAR-GPS 1984 ellipsoid earth snapshot. The point of the app or library dependency was that you may tell time without a clock it is essentially a virtual sundial with global geography.
This conversation is starting to seem kind of passive aggressive. I'm sure that is unintended, since people communicate in different ways. I don't have the bandwidth to answer all of your questions, but I had hoped that pointing you to the library would help you answer these questions yourself.
BTW, the bug originally reported here will be fixed in v0.16.1
I still need to investigate why this site time4j.net doesn't load for me. ( seems appropriate you use past tense words as if you knew it is down )
If you wanted to investigate in detail you might try "driving" the library yourself.
This is the api; http://www.time4j.net/javadoc-en/net/time4j/calendar/astro/SunPosition.html
BTW limited bandwidth is a good excuse to not answer or participate in discussions however these days it seems unnecessary to have any such bandwidth limit: a few kilobytes to exchange text.
I still need to investigate why this site time4j.net doesn't load for me. ( seems appropriate you use past tense words as if you knew it is down )
If you wanted to investigate in detail you might try "driving" the library yourself.
This is the api; http://www.time4j.net/javadoc-en/net/time4j/calendar/astro/SunPosition.html
BTW limited bandwidth is a good excuse to not answer or participate in discussions however these days it seems unnecessary to have any such bandwidth limit: a few kilobytes to exchange text.
If you are hurting that bad for bandwidth in Arizona you and I can look into StarLink and you can work for my business.
Apparently the issue is with ProtonVPN either time4j.net or proton is causing connection reset. Wouldn't it be so bad if Wi-Fi "routers" were routers and not hubs. I took a look at the java class document what do I need to drive it for myself? Do I need open-jdk?
This is a misunderstanding. I should avoid speaking idiomatically - based on your English I assumed you were a native speaker.
In this case "bandwidth" refers to my time and mental energy. I do my best to respond to every message posted here, but my time is not unlimited, nor is this my job.
I appreciate the suggestion for better internet, but what I really need is a long vacation. ;)
I appreciate the suggestion for better internet, but what I really need is a long vacation. ;)
Oh. Ha ha ha ha ha ( Gannon laughs )
Describe the bug A clear and concise description of what the bug is: Widget not displaying properly on android 13 the Sun Position Widget cuts off somewhere including the sunsetting blue hour on the right side of the bar.
To Reproduce Steps to reproduce the behavior:
Expected behavior A clear and concise description of what you expected to happen: expect widget to display properly
Screenshots If applicable, add screenshots to help explain the problem: upon request ONLY IF NECESSARY
Version Info:
Additional context Add any other information about the problem here: F-droid may warn the app was made for an older version of Android. When can Suntimes support Android 13 and the API may be 33. Send or tell any more information about what version support entails.