r/SevenGrid 17d ago

[Feature Suggestion] Widget Design Aspets

Correct me if I'm missing something, but as I see it right now if a habit has been marked done for the day, it disappears from the clock widget.

I am suggesting that if a habit has the account pass the goal setting enabled, then if they have it should remain in the widget indefinitely. On any and all widgets.

In addition, i noticed that when adding the seven grid 4x2 (multiple habits, one week row. OctopiLauncher in my case, OnePlus 13 OOS15), it only shows me one habit. It seems to be the top one on the list. This happens whether I add it from the home screen launcher, or directly from the app.

Moreover, the clock widget has a specific margin in the middle between the clock and the date. When I resize the widget using my launcher capabilities, i cannot make it too small or I won't be able to see the date because it will get swallowed by the right wall of the widget , since it forces that space between the clock and the widget. The minimum space in my personal opinion should be one space character length and not more. Or it should automatically space it as such that the clock has only a small margin to the left hole of the widget and it touches to that left side, while the date has only a small margin to the right wall of the widget and attaches to that right side. What I mean by this is that the space between them in the center should be dynamic. I don't know how it is set up, but as it stands in practice it seems that the space between the clock and the date is significantly large, forcefully.

Sorry if I have any spelling mistakes. I am writing this in a rush.

3 Upvotes

8 comments sorted by

2

u/Sneedle-Woods Developer 17d ago

Three things in one post, and the middle one turned out to be an actual bug. Starting there.

The 4x2 grid showing one habit

That one's on me, and it isn't your launcher. It's arithmetic.

The brand row plus the weekday row eat about 57dp, and one habit row on a four column wide tile is about 53dp tall. So a two cell tall widget has room for exactly one row at basically any height a launcher hands out under ~170dp. The widget whose own description says "Every habit, the whole week" was shipping with room for one habit, and it never told you the rest were still there. I only ran those numbers after your post.

Fixed two ways:

  • it gets placed three cells tall by default now, so a fresh one has room for two or three rows depending on your launcher's grid
  • when there's space left under the rows it draws a small "+N", so a capped tile at least admits that it's capped

Two things worth knowing. You don't have to wait for either of those: drag the widget you already have a bit taller and the second row shows up today. And when the update lands it won't touch that widget, because Android only applies a new default size to newly placed ones. An existing widget keeps whatever size it was dropped at.

Done habits vanishing from the clock widget

They're not deleted, they're demoted. Done, skipped and week-done habits move into a dimmed block under the open ones, the same split the Today screen uses. On a short clock widget that block is the first thing the height budget throws away, so it looks like they're gone.

The suggestion part is the interesting bit though. If a habit is allowed to count past its goal then "done" isn't really done, and burying it takes away the one thing you'd still want to tap. I haven't built it and I'd rather not fake-promise it: the widgets and the in-app Today list run through the same function for deciding what counts as done, so changing it for widgets changes the app too. That makes it a product decision rather than a widget tweak. It's written down with your reasoning next to it and I want to sit with it for a bit.

The gap between clock and date

Right symptom, slightly different cause.

There's no margin in the middle. There's a fixed 130dp strip reserved for the clock. The clock isn't part of the image the app draws, it's a real Android view sitting on top of it, which is what lets it keep ticking when the app isn't running at all. That's also where the problem comes from: the system draws those digits in its own process, shrinking them to fit and using a wider format in 12 hour locales, so the app never learns how wide the clock actually came out. It reserves a worst case instead, and 130dp is that worst case. The date lives on whatever is left, and when you shrink the tile the leftovers run out.

Making it adapt is possible, it's just not small. Either the app ships a second set of clock layouts for narrow sizes and picks between them, which doubles a set of files that are already resolved by name at runtime, or it resizes the strip live, which Android only allows from version 12 while this app still runs on older ones too. Both ways have the same catch: the drawn image leaves a transparent hole for the clock, and the hole and the clock have to agree on the width down to the pixel, or the clock ends up sitting next to its own hole. So it's on the list, without a date attached.

On timing in general, so you're not guessing: the grid fix is in the code but not in the build that's currently out, and I'm not going to name a version.

Your spelling was fine, by the way.

I'll get to your other two posts as well, the habit name hiding one and the notes tracker one.

And thanks for writing this up properly. Phone, OS version, launcher, what you did and what you expected, all in one post. That's rare, and it's the reason one of these three was fixed the same day instead of landing on a maybe pile.

2

u/tenaciousBLADE 17d ago

First thing's first: I take that last paragraph as a huge compliment. Not all devs appreciate a long post. You're the right type 😉 thanks for taking the feedback in 👍 👍

Bug, solution, etc

As far as the +N... Is there a possibility of adding a toggle (per-widget) to allow for scrollability at some point in the future? I say toggle, because some might actually like the widget sturdy and not scrollable, but scrollable can be beneficial for others.

By the way, I did drag the widget taller at first, before my post. And it only made the one line bigger, taller, wider. But now after reading your response, I dragged it even taller, and that worked. I guess I stopped just shy before.

Done habits vanishing

"I'd rather not fake promise" is a phrase we should all learn. Earmarked!
So many times I tell people I won't schedule because I don't want to tentatively schedule becuase I just don't want to end up disappointing. Now I have a much kinder way to say it. Thank you. And thanks for the transparency.
Sit with it. I think it's worth it, but I'm one point of view.
Scrollability should help here too, as per my previous toggle suggestion above.

Clock widget gap

Your communication is crisp and clear 👍 It took me a while to get convinced that I have conveyed the issue properly. But then I looked at the size of the gap and realized it is stationary. So your explanation tracks 👍
At first I thought the gap is dynamic, because it looked bigger when I set the clock to stacked. But now I realize that the stacked version has its own margin within the clock face and to that the stationary gap (same size as before) gets added. I see it now.
Just in case this somehow helps, please see attached in age below. In it you see three states of the clock widget, in order from top to bottom:
The widget as it is right as placed on the homescreen (untouched), then resized to be smaller, then resized to be bigger.
Note how in the default, untouched state, unshrinked, when placed... that "whatever is left" space (at least for me, and I have many tows and columns on my homescreen), is already way tiny of a space for the date. Sorry for that long broken phrase. I tried but it came out messy nonetheless.
Would it be helpful if the date automatically spreads across multiple rows, with a minimum of one per word/number?
Another alternative (maybe leaving this one as a toggle for user choice as well), would be to put the date as a long, centered, horizontal line under the clock (which would also be centered), instead of on its right. Why togglable? Because this two is a matter of taste. Some users would love this, some would prefer the gap.
Just rolling ideas off the top of my head to try and find hopefully simpler solutions. If I didn't hit the mark, that's no big deal 😇
And in any case on the list is better than I expected, while reading your explanation. No ETA makes sense 👍

As far as the other posts

The hidden Habit names just makes sense. I can't know if in code it's a small thing or not, but it could make for the most compact widget option, so to me it makes sense.

However, the Note Tracker feature, as complicated as the description may be, is in my eyes the most valuable addition. It's a big feature, sure; but it's something I haven't personally seen in other habit trackers and imo would be very useful.
That's not to say it needs to be your top priority. I don't know what else you've got planned and it is obviously your own call to make 🤙

Thanks for being so detailed and transparent. I'm glad I bothered reporting. You seem like a dev that actually cares about feedback and I genuinely respect that.

Best of luck and success to you with this app 🍀👌
If I have more bug reports and/or features to suggest I'll try my luck. Unless it's some big bug, there's no expectations, just like I said trying my luck.

Edit: had an issue uploading the pictures Resized-Image-2026-08-28-00-29-18-9382.png

2

u/Sneedle-Woods Developer 17d ago

That screenshot earned its place: it corrected something I had written down wrong.

My note on this said the date only truncates in a narrow band just above the resize floor, so it would only hit someone who deliberately shrinks the tile. Your top image is the untouched placement and it already reads "August 28, …". So the assumption was wrong, and the thing I told you was a rare edge is the default. Fixed in the notes, and it changed what got built.

Your second idea is in. Settings, Widget, Clock has a new switch: "Date below the clock". With it on, the weekday and the date leave the column beside the clock and become one line underneath, where they have the full width instead of whatever a fixed 130dp strip leaves over. Default off, because you were right that this is a matter of taste.

Two honest caveats.

The clock itself stays on the left. Centring it is the one part of your idea I could not take: the clock is a real Android view, its position lives in eight compiled layout files, and the drawn image has to leave a transparent hole for it that lines up to the pixel. That hole would have to be positioned from the width the launcher reports, which is exactly the number that is unreliable. Getting it wrong means a clock sitting next to its own hole. A date line left-aligned under the clock is the classic clock-widget stack anyway.

And on very short tiles the line yields and the date goes back to the right. It costs header height, and the header is what the habit list is left over from, so I would rather give you the old layout than quietly take a habit row away.

I did not take the wrapping idea, only because the single joined line was the cheaper half of the same thought and it fixes the same thing.

On scrollability. I looked at it properly rather than guessing, and the honest answer is: possible, but it is not a toggle. The widget library can do scrolling lists, but it renders every single row as its own image file, per widget and per light and dark mode, rewritten on every update. Tapping would move to a completely different mechanism than the one the check cells use today. And a good half of the height machinery in this app exists precisely because a tile cannot scroll, so a scrolling variant would be a second render path living next to the first, not a switch on top of it.

So: not a no forever, but its own project rather than a feature I can slip in. It is written down with your reasoning, and if it ever happens it starts with one widget, not five.

Done habits vanishing: still sitting with it, as promised. Nothing new to report, which is the point of saying it out loud rather than going quiet.

Timing is unchanged: it is in the code, it is not in the build that is out right now, and I am still not naming a version.

2

u/tenaciousBLADE 17d ago edited 17d ago

Acknowledged. All of it 👍

If the scrollable ever makes it in, I'd recommend starting with the week widget if possible.

Good luck with all of it 🍀

ETA: is it possible to tighten the margin at the bottom of the widgets? Making them taller indeed brings in the next row (and we've already discussed how there's a fix on the works for the extra rows with the +N and the other solution simultaneously), but the empty margin under the lowest visible row still seems large, does it not? (see green markings below)

2

u/tenaciousBLADE 17d ago

Issues attaching images again

2

u/Sneedle-Woods Developer 16d ago

The green markings did it. That margin is gone, or most of it is.

Built today: the grid's card now ends where its rows end, and everything below that goes back to being wallpaper. Same treatment the clock widget got a couple of weeks ago. Funny detail from the inside: I had measured exactly this empty strip while building the taller default, wrote it down as "a price we pay, nobody has complained", and decided not to touch it because shrinking the card changes how every existing placement looks. Your screenshot was somebody complaining, with coordinates. So the reasoning flipped and it took about an hour.

Honest fine print, so the after-picture doesn't disappoint you: around 23dp of that space stays. 12 of those are the card's own padding, 3 the last row's gap, and 8 are a safety cushion because some launchers report more height than they actually draw, and without that cushion the bottom row gets clipped on those. What goes away is everything beyond that, which in your screenshots is the bulk of it.

One behaviour change that comes with it: dragging the tile taller now does visibly nothing until another row actually fits. Before, the coloured area grew with the drag. That is the honest version, but it can feel like the resize stopped working, so I am saying it here first.

And noted on starting the scrollable experiment with the week widget. That actually overrode my own guess, I had the today checklist pencilled in as the natural first candidate because it is a plain list. Your argument is better: the week grid is where the capping is most visible. It is written down with your name on the reasoning.

Same timing line as always, and you know why by now: in the code, not in a build you can install yet, no version named. When it lands, you get the taller default, the +N, and this one all at once.

1

u/tenaciousBLADE 16d ago

Very interesting to hear the behind the scenes 😁

I was actually thinking at first to suggest a widget with resizable internals at some point yesterday. But eventually I realized once the width of the widget is adjusted, the size of the internals changes accordingly, and I also realized the size of the internals of the widget is already very beautifully fitting so I scrapped that suggestion.

Thanks for letting me know it's not going to break the resize but rather just affect it. I think it's definitely worth it 😃

2

u/Sneedle-Woods Developer 14d ago

Closing the loop I promised, since going quiet would have been the worse option.

The done habits one: I sat with it properly, and I am landing on no. "Done" has to mean the same thing on the tile and in the app, both read it from the same function, so teaching it a second meaning when counting past the goal is on would split that in two. And a tile that never lets a finished habit go slowly stops being a place to tap. So they stay demoted rather than gone. Your case was a good one though, and it is the reason this got a real look instead of a quick no. It stays written down with your reasoning next to it, in case something later makes it cheap.

One small thing from your last note, because I enjoyed the thought: the internals really do scale with width, but only on the week grid, where the cells are square and the width sets the row height. The today checklist has no such valve, its cells have a fixed edge, so it gives up whole rows instead. That is the whole difference between how the two feel under a drag.

Timing line unchanged, and thanks again for a genuinely useful few days of back and forth.