Open dougc84 opened 1 year ago
For 1 and 2, I'd say just a user-defined X and Y offset value would suffice. So, let the positioning happen jus as it does today, but once that's decided, just add the user-defined values to the location. Defining these values as either positive or negative as needed would allow whatever positional tweaking might be necessary.
For 3, as you say, those would values just need to be made "configurable"...
For 4... There have been multiple discussions / experiments here with various weather overlays, but they all obviously start to blur the lines of a simple, solid, picture frame app. The idea of displaying content from some external source (a file) is potentially interesting, but I'm not sure how much traction it'd get...
So, 1-3 are fairly easy to achieve - it's just a matter of someone having the time / desire to do the work.
No. 4 I'd say is a bit more controversial, but I'm interested in seeing where the discussion might go.
@jgodfrey I'm not even talking about, for point #4, to connect in a weather API or deal with any of that. I think the show_text
option could have a file
option that reads the first line of a file that's either hard-coded into the config or can be specified as a config option. That way, you get out of having to do anything with weather or overlays or whatever. Leave it up to the user to do what they want.
@dougc84 - Thanks. Yep, I understood that from your OP.
I have the same interests as @dougc84 (though inspired by the appearance of the clock/weather on Chromecast/Google Nest and on Fotoo Android photoframe app). I haven't had time to do anything on weather functionality but I've come up with a solution that works for me on the changes to time display so thought I would share it here.
First, instead of using pixel offsets from the sides of the display, I decided to use percentages for flexibility on different display sizes. The existing code uses 50 pixel offset for width which is about 2.6% on a 1920x1080 display and it uses 20 pixel offset for height which on that size display is about 1.8%. I settled on having defaults of 3%, figuring that would appear similar regardless of the dimensions of the display used.
Second, I added a parameter for displaying the clock at either the top or the bottom with the default being the top.
I am running a fresh version of Bookworm on my Pi3B on which I first ran pi3d_demos/PictureFrame2020.py and as I did a Picframe install via pip, submitting a change to be merged (cloning, updating for manual install, making changes, pushing back to github and submitting) isn't something I can do right now; maybe later. In the meantime, here are the changes involved. I'm providing them as diff output showing the two lines before and after each change. For anyone not familiar with diff, lines with a - are removed and lines with a + are added (but without the + at start of the line).
Note: the code I am using has a fix (described in Issue 143) not yet in the main branch so if you have the current main branch version of viewer_display.py the line numbers in the diff output below will not be correct; you'll have to manually locate and update/add this change.
configuration.yaml:
--- configuration_example.yaml_orig 2024-08-11 21:15:32.047222521 -0500
+++ configuration_example.yaml 2024-08-11 20:38:26.903880421 -0500
@@ -42,4 +42,7 @@
clock_format: "%I:%M" # default="%I:%M", strftime format for clock string
clock_opacity: 1.0 # default=1.0 (0.0-1.0), alpha value of clock overlay
+ clock_top_bottom: "T" # default="T" ("T", "B"), whether to display clock at top or bottom of screen
+ clock_wdt_offset_pct: 3.0 # default=3.0 (1.0-10.0), used to calclate pixels between clock text and side of screen
+ clock_hgt_offset_pct: 3.0 # default=3.0 (1.0-10.0), used to calclate pixels between clock text and top/bottom of screen
menu_text_sz: 40 # default=40, menu character size
model.py:
--- model.py_orig 2024-08-11 19:45:08.101911813 -0500
+++ model.py 2024-08-11 20:35:47.999741211 -0500
@@ -48,4 +48,7 @@
'clock_format': "%I:%M",
'clock_opacity': 1.0,
+ 'clock_top_bottom': "T",
+ 'clock_wdt_offset_pct': 3.0,
+ 'clock_hgt_offset_pct': 3.0,
'menu_text_sz': 40,
'menu_autohide_tm': 10.0,
viewer_display.py:
--- viewer_display.py_fix_orig 2024-08-11 19:45:45.510151389 -0500
+++ viewer_display.py 2024-08-11 21:39:13.267119550 -0500
@@ -98,4 +98,9 @@
self.__clock_format = config['clock_format']
self.__clock_opacity = config['clock_opacity']
+ # New configuration parameters for clock text offsets and top or bottom
+ self.__clock_top_bottom = config['clock_top_bottom']
+ self.__clock_wdt_offset_pct = config['clock_wdt_offset_pct']
+ self.__clock_hgt_offset_pct = config['clock_hgt_offset_pct']
+
ImageFile.LOAD_TRUNCATED_IMAGES = True # occasional damaged file hangs app
@@ -400,5 +405,8 @@
# time strings containing a "seconds" component will rebuild once per second.
if current_time != self.__prev_clock_time:
- width = self.__display.width - 50
+ # Calculate width and height offsets based on percents from configuration.yaml
+ wdt_offset = int(self.__display.width * self.__clock_wdt_offset_pct / 100)
+ hgt_offset = int(self.__display.height * self.__clock_hgt_offset_pct / 100)
+ width = self.__display.width - wdt_offset
self.__clock_overlay = pi3d.FixedString(self.__font_file, current_time, font_size=self.__clock_text_sz,
shader=self.__flat_shader, width=width, shadow_radius=3,
@@ -409,5 +417,8 @@
elif self.__clock_justify == "C":
x = 0
- y = (self.__display.height - self.__clock_text_sz - 20) // 2
+ y = (self.__display.height - self.__clock_text_sz - hgt_offset) // 2
+ # Handle whether to draw the clock at top or bottom
+ if self.__clock_top_bottom == "B":
+ y *= -1
self.__clock_overlay.sprite.position(x, y, 0.1)
self.__prev_clock_time = current_time```
I will try this offset system, I don't see why it shouldn't go in with other pending mods in the dev branch.
I've also been pondering displaying other info on picframe (octopus agile electricity cheap price slots) so I might add functionality to check and disply text from a file in /dev/shm/
I've pushed some changes to the dev branch https://github.com/helgeerbe/picframe/commit/5d40c555e3492f6aa54654aae9c40fe8d1b33dee which allow the clock to be shown top or bottom and inset using the percentages as @NateEaton posted. I've also made the clock look for text in /dev/shm/clock.txt
ramdisk and this will be added after the actual time text. This is a minimal alteration but it allows an external program to write whatever you want into the file
I saw the quick responses you made to #297 so I thought I'd throw a feature request in the mix.
For starters, I really like picframe. It's pretty rad and it works great.
However, I'm trying to emulate what the Amazon Echo Show does for photos... without the whole Amazon part. The one piece that's missing in the puzzle in the clock functionality. And there's a few pieces to this puzzle.
clock_justify
is set to L (and... for that matter, when it's set to R as well). The time has a noticeable larger offset from the side than it does in the top. Would it be possible to introduce some sort of X and Y offset values here? That would likely mean having to add x and y offsets for theshow_text
option as well (I don't use that option, but that setting might conflict with others that do use it).show_text
has offset values as well, it could work. But I'd really like to display the current weather. I understand this is a photo gallery app, and that's not your priority is adding geolocation and weather APIs and such, but maybe just reading the value from a specified file (in another config option) that's updated by a separate process could work?Thanks so much.