Re: WIP on my first app for the M851
> For now my calendar code is just a part of T-Minus. I'll probably factor it out into a separate app to make my own version of "calendar" later on. Maybe by then I'll have improved it to the point where there's some clear benefit to using it over the old Calendar app. (I've got nothing but love and respect for the old Calendar app, though! It's such a simple thing but it's so effective, and so handy! I hope imitation will be considered the sincerest form of flattery in this case.)Ahh, you're tetsujin. I remember our conversation over on the XKCD forums. I'm well, still the same name. :)
> As for uploading... T-minus (and the related code) isn't ready to be uploaded. I'll definitely upload source and binaries to here and the regular users' group when the code is ready. If people want to check it out in the mean time, it's in CVS on Sourceforge (project "tetsujin") - they'll just need a fixed version of dlas to build it. :) (I'll be in touch with the author of dlas about submitting a patch...)
> "T minus" is kind of idiomatic. Lots of people have seen rocket launches, or movies featuring rocket launches, in which there was some countdown expressed that way. They may not know quite why it's expressed that way, but I think it's a safe bet that they'll understand it's a countdown. So I think it can be informative. It's a very clear, compact way of communicating the idea of counting direction. The name of the app also serves to clarify the meaning of the information in the upper DM.Is it really that idomatic? Time (of event) minus X minutes/seconds. We put the event at time 0, and everything else follows. It's like using Julian dates, and setting the day, or whatever it's called. I forget. You're right that it's compact, and clear, though.
> If I took the "T" out of the upper DM and left the + or - sign there, I'd lose context for what the + or - sign means, without gaining much. (Reclaiming 4 pixel columns of upper DM space, which I wouldn't really have any other use for... At best, a reduction of clutter. But if clutter is a major problem I'm probably better off removing seconds from the TOD display.) It's true that space is at a premium, but if I reclaimed that space there's really not much I could do with it.Fair. But you are pushed for space, so it could be argued it's needed. But I agree that splitting the number of days is bad (unless you're splitting into months/days) and you've already made your decision. So the argument is pointless. I defer to the author. (I really just wanted to reply for the earlier comments, inline).
> Plus I think it's a good use of the upper DM, actually, to identify the current mode, when the upper DM isn't needed for something else.
> > To me it seems clear, I see hh:mm:ss, what's this ???| in front? Oh, it must be days.
- --- In firstname.lastname@example.org, Paulo Marques <pmarques@...> wrote:
> A long time ago I wanted to port VDLK to compile in Lazarus.Well, at the moment it's a bit of an idle fantasy... But I may take it on at some point. I've relied pretty heavily on VDLK for my project (honestly, all the things that have gone wrong with the app - I hate to think of how all that would have gone down if I hadn't had VDLK. It's hard to imagine how I would have made any headway at all.) - as such it'd be neat to fix up some of the bugs and limitations I've encountered. That's probably not going to happen unless I port it to Linux first.
> Lazarus is a free, open-source alternative do Delphi that has a lot of
> things compatible with it.
> What I expect to be harder to port is the USB HID direct interface to
> the watch. The rest of the code should be pretty straightforward.
It's good to know Lazarus is there as an option. The fact that it's an attempt, at least to be Delphi-compatible means there's some chance I could avoid rewriting the GUI.
I've honestly never used the USB features of VDLK - luckily libdlusb also incorporates the ROM-dumping functionality, so that was enough to get me up and running. Under WINE the VDLK menu for communicating with watch hardware is greyed out because it's not detecting the watch when it's connected, so I don't even know what the contents of that menu look like. :)
> I don't have enough energy left to do the port myself, but if it isI'm sure if I decide to port and/or enhance VDLK I'll post all about it on here. :)
> something you would consider doing, I could help out if you hit some wall...
--- In email@example.com, "Tons" <tonsofquestions@...> wrote:
> > Yeah, it seems like the list of things to be fixed never ends... Today it was the alarm thing and the year zero thing... Every time I add some new tweak or fix to state 1 I have to reduce the code size by enough to fit the new code in. So far I've managed to find the space I need each time I need to fit something in - but I'm always worried that I'll run out of places to scrounge up a few bytes.
> And now you're truly a Datalink USB developer. Welcome to the club. :)
Ha! I should get a tattoo that says "900 byte overlay"
> > Well, the main thing that has to happen in init is loading the record - so I added code so the app (again) does that any time there's state entry into state 1. So for now I do that and it seems to work. At the moment this also means that I load the event twice on startup (once in the banner state, once in state 1) - which basically sucks, but that's more or less how it has to be right now.
> You could set a bit in the ASD if you're coming from the banner state, and then hit a STATE_ENTRY, and clear it afterwards. It'll prevent the double-load at least, even if it doesn't solve the code-location issue.
Well, two issues with that:
Right now, loading the current event in state 1 is just two code bytes: CARS to the relevant routine in the background handler. (One of these days I will have to try to determine if my app's background handler is fully restored when I return from a background event...) Conditionalizing that code will add code size. I'd rather not load the event twice but my feelings on that point aren't so strong that I'd rather use another use an additional four bytes of program code to avoid it.
Second, there is the possibility that a background task messing with COREWorkBuffer would set those bytes in a way that indicates (to my app) that the record is already loaded... Or (perhaps more likely) leave them alone, in which case their previous state (indicating that the record is already loaded) would continue to hold even as other areas of the COREWorkBuffer get overwritten.
If my app gets an app exit event (there is one of those, right?) when a background task takes over, then I could use that to set something that indicates the record will have to be loaded again when the background task is done - but that, too would be more code. At this point I can't afford even a single additional byte of code in state 1 unless I trim down something else.