Okay, so after a day of battling with the API, I got my big clock app kinda working. But a few things are still broken - the replicant doesn’t update, and the code kinda needs a cleanup.
The sources are now here! Please help take a look at it. Feedback can be either here or via GH issues.
Hello! You may want to exclude object and binaries generated after build from the repository files. As far as I know this could be done by including a rule in git.
I’ll remove them in the next commit - Sorry, I was in a hurry XD.
New idea: use BView::FindView to update the pointers on unarchive (I was trying to get the archiving process to do that for me)
Edit: Yes, that totally solved the problem! The replicant now fully works. Next up: code cleanup, about dialog, transparent background, white text on dark backgrounds
AFAIK real transparency is impossible/very difficult, there is HiQDock which uses a screenshot of background and draws over it. That is unless i have outdated info.
Hiqdock is not replicant, thus afaik not relevant.
There are many transparent replicants, like NetworkStatus.
Yeah, apparently setting the draw mode is enough to get transparency going. I still need to get the dragger handle to behave, but! 
P.S. Yes, this is pretty close to the ultimate goal of the BigClock project! Finally! 
Hey, very nice pice of work! Great. Is it possible to change the font?
The font used in the program is the “normal font” in your settings. The size of the time text would be an option added soon(
).
Is it possible to calculate the font size from the window size?
I would just start it, resize the window with mouse and place it as replicant.
That would be the ideal UX, but I can only think of two methods, both kind of unsatisfying:
Set the size of the text so a fixed number of “ems” will fit in the window. The big question: how many ems? I’m using the locale kit to generate the text, so some crazy pants locale could have a significantly longer name for Wednesday or something like that, and the box would overflow.
Render it to a huge bitmap and scale it down while drawing to the window. Yeah… it doesn’t sound particularly efficient.
There’s also a small bug where the dragger handle would stop the window from getting narrower, but doesn’t stop it from getting shorter. This is probably my fault though. (also, BDragger doesn’t work with the layout engine yet)
Of course, if any of you have a better solution, feel free to chime in!
Picking a font size from a window size is indeed not very convenient. Usually, starting from a template string, you use StringWidth() and increase or decrease the font size until it fits (you can do a binary search, I think).
The problem is deciding on a good template string, typically in this case I would pick something like “MMMMMMMM DDDDDDDDDD NN YYYY”, assuming that this is long enough to cover any language. Maybe everytime you show an actual date, check the StringWidth in case it’s actually longer, and reduce the font size accordingly then. It’s not perfect.
If you want something a bit more complex, testing 12 * 7 dates to have all possible day/month combinations and finding the longest one isn’t that bad, if you do it only when the window is resized and not multiple times every millisecond.
Yup, the problem is picking the right tenplate string. Fortunately, in this layout the thing that would actually hit the window border is the time, not the date. (The date would either always be at be_plain_font or a fixed multiple in size of the time font.) So I can probably use “MM:MM ABRACADABRA” as a template string, and survive even against locales which do something like “09:35 before-noon”. And let it wraparound nicely if it got through even that. (This is using the layout engine, so hopefully it doesn’t go through the edge)
Right now I believe (barring wrapping) text width corresponds directly to the font size, so it’s going to take one try to find the perfect font size. Hopefully.
A similar solution for the time would be to check the widths of something like 12:46 AM and 12:46 PM to get a good idea of the width for a given language (and add a few pixels of extra margin). And then see if someone complains that it doesn’t work with some language/font/size combo, and extend your testcases 
At large font sizes, you can indeed assume that the text width is proportional to the font size. At small sizes, not quite, because of hinting, but in your case this should not be a problem.
Check the width of
12:34amand12:34pm
Great idea, thanks! Now to hope I’ll have time to work on this…
Dear @Parnikkapore,
I am interested in this Big clock -
how about it actually ?
I searched for a similar digital and sizeable clock in the Haikudepot, but besides of small classic, non-sizeable Beos Clock, there were only binary clocks and a funny Word clock available.
Also that’s fine its replicant option from my expectation -
Have you finalized a stable version - I mean what you would not offer to test but for regular use as well ? 
I assume during years that passed since last post you could have secured / polished … I just ask
if I could get that latest one ? 
and finally how it looks like ?
is it adjustable per size and time format ?
Unfortunately, I’ve long moved on since 
Still couldn’t figure out how to make the clock transparent on the desktop though. I tried setting B_TRANSPARENT_COLOR on the subview + all the labels, tried giving B_TRANSPARENT_BACKGROUND to the window and view… the view is transparent, but the labels have a visible background. Always.
Perhaps, the new ‘about window’ replicant could serve as example?
That’s one of the things I looked at too - it’s way too complex than should be needed though. I also had a look at the Weather app.
For now, after reading the actual source today as a result of this thread, resetting the background color of the StringView in an AllAttached seems to do the trick.
Why this is needed is a mystery to me.
thanks @KitsunePrefecture for the nerdsnipe 