clickness (win32-exe only!)
Not 100% ready yet, but it supports these features:
- shows quickhint in the dragbar when moving over a button
- has 2 strings for the titlebar, one for the title, one for a secondary text, like current project.
- your mouse being idle on a button for 1 second: enhanced help in a dedicated helpdisplayer, upon reveiving an event for this the displayer format event.extra.tostring() according to the displayer-size. Helpformat includes color and newlines, there are 16 pre-made colors to choose from.
- [F1] on a button immediately shows the enhanced help (if even 1 sec is TOO much for you :P)
- [Z] and [X] mimic LMB and RMB on buttons (and later on also the dragbar). WHY!? you might think? I've a tablet, I don't like the clumsy buttons on my 'pen', so I figured: "why not use the pen for movement and the Z/X for mousebuttons?"
- There's a color-overlay which my gadgets adapt to, in this case the window and the buttons. Change this overlay ( overlay.Setcolor r,g,b )and the rest is updated automagically!
- Current images for the buttons on the window are created within the window object with a small hacky function, but any image can be loaded ofcourse.
- The menu is supposed to be a popupmenu (created outside the window object and then linked to it), since I hardly use such menus at all, one single popup is sufficient for me.
- Window can't be resized, I never allow resizing for my apps anyway. They're creative apps with lotsa stuff on screen, e.g. there's no point in resizing anyway.
- dragbar is currently a 4x4 image (generated the same way as the buttons).. so Mac'ish stripes are also possible, as well as plain 'nothing'.
- Keep-on-window .. love it or leave it.
- Keys for Dragbar are: [C], [H], [Home], [Esc], [Alt]+[F4] (when hoovering the canvas!)
The helpdisplay:
- keys, when hoovering, are: cursor up/dn, page up/dn, home, end.
- the whole display itself can be used with the mousebutton to browse the text, whether you'll go upwards or downwards is highlighted. Mousewheel is also supported naturally..
Everything is eventhook-driven, it requires a no-brainer to use it!
So, why did I do all this?
First, it saves space: Normally I'd have a titlebar, a seperate menubar, and a statusbar to display stuff in, now it's all in one. Next, this things has a fixed height, also the mainpanel below the titlebar has a border of 1 pixel. Because of these guaranteed dimensions there's no-one who will mess up my app due insanely use windowborders, menubars, buttonfonts etc. etc.
Next, there's obviously added functionality, esp. the Z/X for mousebuttons might be nice for ppl with buttonfinger-RSI.
The least arguement is that it can look a bit more nice (with the right images), I wouldn't mind much about that tho..
So, the question is: is this good? Is creating own gadgets/looks ok? Notice that in this case there's actually added value, not just a stupid skin (like you see with many audio applications) that's actually cumbersome to use.
Not 100% ready yet, but it supports these features:
- shows quickhint in the dragbar when moving over a button
- has 2 strings for the titlebar, one for the title, one for a secondary text, like current project.
- your mouse being idle on a button for 1 second: enhanced help in a dedicated helpdisplayer, upon reveiving an event for this the displayer format event.extra.tostring() according to the displayer-size. Helpformat includes color and newlines, there are 16 pre-made colors to choose from.
- [F1] on a button immediately shows the enhanced help (if even 1 sec is TOO much for you :P)
- [Z] and [X] mimic LMB and RMB on buttons (and later on also the dragbar). WHY!? you might think? I've a tablet, I don't like the clumsy buttons on my 'pen', so I figured: "why not use the pen for movement and the Z/X for mousebuttons?"
- There's a color-overlay which my gadgets adapt to, in this case the window and the buttons. Change this overlay ( overlay.Setcolor r,g,b )and the rest is updated automagically!
- Current images for the buttons on the window are created within the window object with a small hacky function, but any image can be loaded ofcourse.
- The menu is supposed to be a popupmenu (created outside the window object and then linked to it), since I hardly use such menus at all, one single popup is sufficient for me.
- Window can't be resized, I never allow resizing for my apps anyway. They're creative apps with lotsa stuff on screen, e.g. there's no point in resizing anyway.
- dragbar is currently a 4x4 image (generated the same way as the buttons).. so Mac'ish stripes are also possible, as well as plain 'nothing'.
- Keep-on-window .. love it or leave it.
- Keys for Dragbar are: [C], [H], [Home], [Esc], [Alt]+[F4] (when hoovering the canvas!)
The helpdisplay:
- keys, when hoovering, are: cursor up/dn, page up/dn, home, end.
- the whole display itself can be used with the mousebutton to browse the text, whether you'll go upwards or downwards is highlighted. Mousewheel is also supported naturally..
Everything is eventhook-driven, it requires a no-brainer to use it!
So, why did I do all this?
First, it saves space: Normally I'd have a titlebar, a seperate menubar, and a statusbar to display stuff in, now it's all in one. Next, this things has a fixed height, also the mainpanel below the titlebar has a border of 1 pixel. Because of these guaranteed dimensions there's no-one who will mess up my app due insanely use windowborders, menubars, buttonfonts etc. etc.
Next, there's obviously added functionality, esp. the Z/X for mousebuttons might be nice for ppl with buttonfinger-RSI.
The least arguement is that it can look a bit more nice (with the right images), I wouldn't mind much about that tho..
So, the question is: is this good? Is creating own gadgets/looks ok? Notice that in this case there's actually added value, not just a stupid skin (like you see with many audio applications) that's actually cumbersome to use.