MiniTime 1.07 released

Version 1.07 of MiniTime is now available for download.

MiniTime is a small application that displays the date/time in a small icon or window. It was written as a replacement for SmallTime which does the same thing but doesn’t run on modern hardware and the licence doesn’t allow for altered versions to be distributed.

Changes in this version are:

• The option to position the iconbar-icon has been split into 2 options. This does away with the somewhat cryptic high and low positions, making it easier to understand.
   
• A double-click on the MiniTime window will lower it for 5 seconds. This is useful when it’s configured to be at front and you need to get at something that’s underneath it.
   
• Dragging the MiniTime window didn’t work correctly, it would often jump back to a previous location.
   
• On a font or mode change don’t recreate the MiniTime window but resize it instead. This should avoid a potential abort in the following Open window event.
   
• On font or mode change recreate time icon in such a way that it stays in the same relative position.
   
• If the time is shown in iconbar-icon then open the main menu in the same vertical position as other iconbar menus.

MiniTime can be freely distributed under the 3-clause BSD licence, and comes with the source included. As always all feedback is welcome.

Version 1.07 of MiniTime is now available for download.

Nice.

The colouring of the calendar is surprisingly configurable. Took me a read of the help file before I realised that the highlighting of “current day in other months” was intentional. I’ve tweaked the colours to stop this.

The double-click to lower is great. Thanks for adding that.

I have two more suggestions (quick! hide!):

• Calendar – current day (in current month) optionally in bold.
• Calendar – some sort of shortcut to bring you back to “Present Time, Present Day, hahaha”.¹

Thanks again for this.

¹ If you don’t recognise the quote, Google it, all will become clear. :-)

Nice.

Thanks.

The colouring of the calendar is surprisingly configurable.

It is, and deliberately so to match the flexibility of the time configuration.

Took me a read of the help file before I realised that the highlighting of “current day in other months” was intentional. I’ve tweaked the colours to stop this.

The layout of the calendar was modelled after the Ubuntu’s date/time applet. This highlights the current day in all months and in the same colour.

I decided to use a different colour for other months so that there was a clear distinction and to allow it to be turned off separately.

The double-click to lower is great. Thanks for adding that.

No problem. Ctrl-click as you initially suggested has some issues but double-click is actually better IMO as you don’t have to reach for the keyboard.

• Calendar – current day (in current month) optionally in bold.

This is a tricky one. The calendar is built up of regular icons as that keeps things simple. Just use the validation string to set the colours and make sure the text string is correct. The Wimp will then sort out all the redraw stuff (bpp, eigen values, anti-aliasing).

It might be possible to get the desktop font handle (Wimp_ReadSysInfo) then get its name through Font_ReadDefn. Then use Font_FindFont to try and open a bold style. The font handle can go in the top byte of the icon flags (as colours are set in the validation string) and hopefully that’ll do it.

It seems feasible but I need to do some experiments to see how well it works.

• Calendar – some sort of shortcut to bring you back to “Present Time, Present Day, hahaha”.1

This on the other hand is easy. I’d already considered such a button, so now I’ve added all 7(!) instructions needed to implement this.

It’s done through a new button showing an asterisk. I’ve placed it between the 2 central adjusters for month and year. I just call it the now button. ;-)

Thanks again for this.

My pleasure, literally as it was/is a fun thing to write. :-)

It reminds of the old c64 days where you had to keep things small because of the memory available. Okay, okay, a 10k clock is a tad on the big side for the c64. ;-)

It might be possible to get the desktop font handle (Wimp_ReadSysInfo) then get its name through Font_ReadDefn. Then use Font_FindFont to try and open a bold style. The font handle can go in the top byte of the icon flags (as colours are set in the validation string) and hopefully that’ll do it.

Brilliant. We need more people in the world like this, people who look at a problem and think “hmmm, maybe this’ll work?” instead of not knowing because the internals of their interacting pile of frameworks and libraries aren’t documented.

The calendar is built up of regular icons as that keeps things simple.

That makes sense. Why do complex redraw stuff when you can get the Wimp to do it for you? ;-)

so now I’ve added all 7(!) instructions needed to implement this.

;-)

It reminds of the old c64 days where you had to keep things small because of the memory available

Just imagine what the result would be if we did something like this for Windows? Let’s see how many tens of megabytes the .Net framework would require…

• Calendar – current day (in current month) optionally in bold.

Had a closer look at this and it’s easier than I thought. The calendar is a toolbox object and so its icons are button gadgets. There a couple of toolbox methods that are very useful here; Button_SetFont and Button_SetFlags.

Button_SetFont can be used when the calendar is initialised to give each ‘day’ icon a bold outline font. Then when the grid of days is updated, Button_SetFlags can be used to turn the outline font on or off.

The main problem left is how to get the fontname for the bold style. If the desktop font is BaseName.Regular then just use BaseName.Bold but BaseName.Oblique would have to become BaseName.Bold.Oblique.

Perhaps I should just take advantage of the toolbox and add a fontmenu and let the user select the font(style) to use. That way I’d only have to worry about how to neatly add it to the configuration window. :-)

Just imagine what the result would be if we did something like this for Windows? Let’s see how many tens of megabytes the .Net framework would require…

Oh no, let’s not go there. My mom has a tablet (mainly to play Wordfeud) and of course it has an on-screen keyboard. You’d think this would be fairly small but nope. It’s 25 MB + 9 MB of data. OMG

Let’s see how many tens of megabytes the .Net framework would require…

I presume you mean the app itself rather than the enormous pile of, er, code that you have to install to get anything to work otherwise I’d point out that the decimal point needs to move…