TimeKeeper - a clock/calendar

[scirath]

This is part of a project I'm working on, but it stands alone for a demo as well. NanoNote Clock (http://love2d.org/forums/viewtopic.php?t=2306) forms the basis for the drawClock() function, so oofoe should get the credit for that part!

Also included is a bunch of X11 color definitions ... I think someone did something along those lines before, but this one adds alpha to everything in 5% increments. E.g., SlateBlue25 is SlateBlue with alpha=64 (25% opacity). Ultimately, it doesn't play a huge role in the demo, but someone might find it useful.

Note: Clicking on the clock switches between running ("window") and icon mode.

(screenshot)

snapshot.png (32.96 KiB) Viewed 2850 times

TimeKeeper.love

(39.45 KiB) Downloaded 169 times

EDIT: Removed the color definitions; they don't add anything to the demo.

[zipperipper]

well it works, well done

[Ellohir]

Nice and smooth, it's all we can ask for

[coffee]

Nice work. Your analog clock runs smoothly. And I liked your color library because was sorted by range of colors which is for sure very handy to choose colors later (mine is unfortunately only A-Z sorted and is based on web-named colors instead).

EDITED BTW about alphas I don't name the gradations in conjunction with the colors name (too much combinations possible to list) but alphas have their own names itself.

Code: Select all

color = {
        aliceblue = {240, 248, 255},
        antiquewhite = {250, 235, 215},
        aqua = { 0, 255, 255},
        aquamarine = {127, 255, 212},
--- rest of colors
	}

alpha = {
	total =		000,
	transparent =	000,
	trans =		000,
	half =		128,
	semitrans =	128,
	translucid =	128,
	translucide =	128,
	translucent =	128,
	semiopaque =	128,
	opaque =		255,
	none =		255,
-- add the needed ones
}

function setColor(wantedColor,wantedAlpha)

   love.graphics.setColor( wantedColor[1], wantedColor[2], wantedColor[3], wantedAlpha )

end

and then i call:
setColor( color.white )
or setColor( color.white, alpha.half ) if need put any other alpha than the default one

[scirath]

I like the idea of naming the alpha channels like that, coffee. It's pretty intuitive.

For my needs, I had to simplify it further--just "one" argument vs. "two" in this case--because I'm using it in what's shaping up to be a rather large project (a GUI of sorts -- eyecandy render test here: http://imagebin.org/192681 ). ....And I find myself having to type in long sequences of colors over & over again. The call to runTimeKeeper() in itself takes five RGBAs (even though I'm really only using the RGB components for the demo), and that's only a single line. So, I'm being lazy in a way, and just getting it all done at once.

@the nice work replies: Thanks! I know it's not the most impressive thing that's rolled through the forums, but I'm pretty proud of it, especially the calendar part (lol, the most plain to look at). It took a few hours of rage to work out the kinks, starting with ... "given the day-number within the month, and its position in the week, figure out where the month starts & ends." My head hurt a little afterward.

[coffee]

I like the idea of naming the alpha channels like that, coffee. It's pretty intuitive.

For my needs, I had to simplify it further--just "one" argument vs. "two" in this case--because I'm using it in what's shaping up to be a rather large project (a GUI of sorts -- eyecandy render test here: http://imagebin.org/192681 ). ....And I find myself having to type in long sequences of colors over & over again. The call to runTimeKeeper() in itself takes five RGBAs (even though I'm really only using the RGB components for the demo), and that's only a single line. So, I'm being lazy in a way, and just getting it all done at once.

Well, I not sure if you gain much advantage and if you gain very much in shortness or speed over my 2 argument method in a function (unless you doing realtime alpha effects). Also doing "setColor(C_DIMTEXT, A_DIMTEXT)" would turn your code same lenght than your "love.graphics.setColor (DIMTEXT)". Note, I also keep something like a custom color variable file for project colors and use like like you DIMTEXT, BRIGHTEXT assign variables. As drawback when using my method, you had to create a C_DIMTEXT and A_DIMTEXT but would bring flexibility, independence, and less named colors/table size/code size.

Let's image you want to do an alpha animation in the text or background of your clock. How hard and "stuck" you would be when you could do it more easily with a cicle setColor(C_DIMTEXT, A_DIMTEXT) only changing the alpha variable (and not have to get/set the respective color/alpha combination).

Also there is another better ways giving you OO flexibility if you want. You can check for the thread I asked help for miko solution http://love2d.org/forums/viewtopic.php? ... 854#p41760) and see how things evolved.

But however it's easy to point you the problems of not have alpha independent of color. That way to cover each color you had to create 20 names (in 5% steps) for EACH color (aliceblue5, aliceblue10, aliceblue15,...aliceblue50,aliceblue55,---aliceblue80, and so on right?). Not very flexible. And that painfully increases the size of your named color library. Instead of a library/table with 3341 lines you could have one with about 170 lines for colors and let's say 30 max for alpha gradations to cover 5% steps.

EDITED Good luck working in your desktop GUI. You have can check a similar project here http://love2d.org/forums/viewtopic.php?f=5&t=4786

[scirath]

The advantage for me is in being able to glance at my code and not having to scan 4 or 5 lines to spot/change something. It's just the way my brain works.

For example, say I'm developing my windows' appearance...

Code: Select all

function drawTestWindow(name,element,x,y,w,h,COLOR,FILLCOLOR,TITLECOLOR)
--some code
end

I can call

Code: Select all

drawTestWindow("Render Test",TITLED+CLOSEABLE+FRAMED+DRAGABLE,150,150,400,200,LightSlateGray80,FireBrick80,White80)

vs.

Code: Select all

drawTestWindow("Render Test",TITLED+CLOSEABLE+FRAMED+DRAGABLE,150,150,400,200,{{color.LightSlateGray},alpha.active},{{color.FireBrick},alpha.active},{{color.White},alpha.active})
-- i'm not even sure i got all those curly braces right lol

(after having defined alpha.active to be 205). When they get crammed between tons of other test lines, I short-circuit trying to find whichever particular parm I'm looking for if the list gets too long. For example, both ways are INFINITELY better than...

Code: Select all

drawTestWindow("Render Test",true,true,true,true,false,false,false,false,false,false,false,false,false,false,150,150,400,200,119,136,153,205,178,34,34,205,255,255,255,205)
-- this would use a different function declaration, of course

I still have to clean up my code quite a bit, so I'll probably find a way that works even better for me, at least I hope so. At the moment, I don't use the 'WhateverColor80' arrangement on that particular test (unless I'm overriding something); it's just a +ACTIVE on the first parameter--and I still think it looks ugly. Eventually, I'll have the "window manager" handling the color assignments and opacities as part of its internal logic, so I may not use the defs I made too much in the end.

EDIT: I see what you're saying on the length of the library, though. That's where writing a script to write it for you comes in handy.

[coffee]

Well, you invented your way, you are proud of it, and you feel comfortable with that. That's good. But neverthless with a little bit of flexibility of yours my system would end the same simplicity and shortness like yours (only using more 3 vars) doing certain things. Like turn color. and alpha. to c. and a., readapt the function to don't have to declare alpha. and color. but only the value inside the color/alpha table or left to the end the alpha arguments so we haven't even to declare it if they "normal". But that's ok. I don't really want to push you to use my method or use a more pretty intuitive table, that's isn't really a problem but a choice.

However I'm "worried" and done my work warning you the dangers of group color with alpha. IMHO I think it's not really good coding fatting the code the x20 more variables and for now be a really nightmare to add and declare new colors. And with the problem of need to workaround if you need to do only alpha fade ins/outs as used in desktop gui's.

But can I give you a last suggestion/alternative if you want to keep color+alpha but without the need to declare all alpha degrees?
I'm not good dealing string manipulation but you could only declare the "vanilla" colors and then with a function to parse/append/get/decode the last 2 chars (or after a certain char like "_") bluemarine20 or bluemarine_20. In that function would also do a simple fast %<->255 conversion. Then you would not have to declare/pop all the color/alpha variations and have less x20 variables! (or have the work of auto-assign the alpha degrees).

[scirath]

I'm not proud of it per se, more of confused as to why it's become a focus point.

I view the thing as a more or less non-essential part of the overall code, used for development. The alpha part is built-in as a way of not having to remember "X alpha is Y percent" while playing around with what colors, shading, or transparency I want to use. It's also a bit of a hold-over from my prior programming experiences: develop your tools, use them to develop your project, then clean whatever's non-essential out of your code.

But anyways, it's just a module. Don't use it if you don't like it. I barely use it in the TimeKeeper demo, and I'm beginning to rue not just hardcoding the damned colors in the first place.

EDIT: I revised colors.lua a bit to try to accommodate for named alphas, but without necessarily having to integrate everything (although that's still an option). It's not too elegant, but ehh ... like I said, I really only use this for testing. In the end, I intend to have colors stored in a loadable table, to allow users to set and name their own colors. Alphas would be handled separately, depending on whether a given GUI object was in focus or not; I haven't decided yet if that could be overriden.

colors-revised.lua

(93.47 KiB) Downloaded 80 times

[miko]

The advantage for me is in being able to glance at my code and not having to scan 4 or 5 lines to spot/change something. It's just the way my brain works.

For example, say I'm developing my windows' appearance...

Code: Select all

function drawTestWindow(name,element,x,y,w,h,COLOR,FILLCOLOR,TITLECOLOR)
--some code
end

I can call

Code: Select all

drawTestWindow("Render Test",TITLED+CLOSEABLE+FRAMED+DRAGABLE,150,150,400,200,LightSlateGray80,FireBrick80,White80)

vs.

Code: Select all

drawTestWindow("Render Test",TITLED+CLOSEABLE+FRAMED+DRAGABLE,150,150,400,200,{{color.LightSlateGray},alpha.active},{{color.FireBrick},alpha.active},{{color.White},alpha.active})
-- i'm not even sure i got all those curly braces right lol

For such complicated API my way is to change the API so you woud do:

Code: Select all

window=newTestWindow():setTitle("Render Test"):setPosition(150, 150):setWidth(400,200)
  :setFillColor(color.White)
  :setColor(color.Black)
  :draw()

Advantages:
- in the constructor you can set default values (for example size), to you can skip some parameters if they do not change
- you can easily split it to many lines without decreasing readibility
- you always know which parameter you set, you do not get lost even if you have many parameters.