> I dug into the skin a bit while reading the SDK:
> I got the "covers+tracks" view working
> without breaking anything else (well sort of)
The sort-of is probably what I meant: you have to select a smaller subset in the SQL spaghetticode which matches exactly what fits in screen. This is the only way you can later zoom in to an album but still return to the workspace with at the last location - there is no "scroll to this position" functionality in the workspace.
> need to figure out how to implement a nice wide
> easy to finger-drag vertical scroll bar (for
> those albums with too many tracks to fit
> vertically in the workspace.
That is easy native SJ, see WorkspaceVScroll at http://www.silverjuke.net/sdk/scrollbar-targets.html
The only drawback is that the full workspace scrolls, including the album art. To me that is unacceptable for the purpose of this skin, that is one of the other reasons I did not add code for that mode.
> Everything works as it should, unless the user
> doubleclicks on a SONG (amd somehow times it just
> right between polling for the single click)in the
> covers+tracks view. In that case, a track can be
> queued on accident and the track selection dialog
> still pops up.
I think you can fix that by adding an onClick="..." to the <workspace> element, and just do what you want from there. You could also deactivate doubleclick that way, I just never bothered as I think a touchscreen driver should prohibit doubleclick all over (not natural, it's a desktop-computer-mouse trick. Apple was right on this, only too strict for a desktop).
> It amazes me that one has to poll for single
> clicks instead of the applications framework
> providing an event for clickable areas other than
> buttons.
As I see it scripting has organically grown into SJ, first only changing graphical elements, and slowly growing more powerful. With yours truly enjoying himself by pushing it's bounderies beyond breaking. So its API is lacking in unexpected places.
> I have not delved into your event code or
> the layers model of this package yet ( I hate C,
> C++, Java, etc), but would imagine that using
> transparent overlay images as "buttons"
> would work as they are singleclick targets. Thern
> again I know so little about the framework that
> it may not be possible.
Yes you'd expect that and it would solve this, but it does not work over a workspace
From what I gather the scripting/skinning part is separate from the workspace rectangle. All mouse/screen events inside the workspace are handled by the workspace object and bypass the scriptengine.
(As an aside: in my library in progress I use for the teaser skin I take a similar route - my graphical engine draws whatever I want under scriptcontrol, but outside the normal scriptengine. But as a tradeoff I do not use the workspace anymore so I still have only two engines left fighting over messages and screenupdates
)
> What do I like about the skin? It is straight
> forward and uncluttered. The interface is perfect
> for a touch screen (I will be putting 19"
> touchscreens thoughout my home) with nice big
> easy to use buttons that are not gaudy or tacky.
> It appears to be stable and pretty much idiot
> proof. It is missing very little to be
> "perfect" for my application. The
> colors are fiarly tame and will go well in my
> kitchen and basement.
OK, in that case I can make no predictions if you'd like the way the teaserskin is going. If you are interested: sign up, PM me an email address and I'll mail you an alpha.
> I have installed the "milkdrop"
> visualization and it appears to work well with
> other skins. It would be great to have an option
> to allow it to to play fullscreen after a user
> configurable period of inactivity during payback
> (I.E. like a screensaver when music is playing).
> A simple "touch" on the screen would
> deactivate it (but not register any other event
> on the skin).
This is easy to add to the current skin, should probably take you no more than a few minutes. I might add that to the public skin as well, not 100% clean from a GUI perspective but I think much appreciated on parties.
> The volume slider (with admin configurable kiosk
> mode "max" setting) would be great, as
> the AMP is in the basement, far away from the
> jukebox. Not all of my music is normalized and/or
> some if it has a lot more bass or presence. Volume
> control would be good without having to drop out
> of the kiosk mode.
Again - while not for parties I think - something I can see added as an configurable option to this skin.
>
> The PAUSE/PLAY button instead of "lower
> half" because I can see the current
> configuration getting clicked a lot on accident
> (drunks are idiots). So I like the pause functin
> but would rather assign it to the slider or a
> small button at the end of the slider.
It is configurable as I see it as optional for homeuse (phone rings), but indeed certainly not for party use...
> I do prefer to see tracks instead of JUST covers
> (the option of "either" would be
> great). I have trouble choosing songs from so
> many covers. I like to see tracks when browsing
> covers. I guess my hacking around has made this
> work (for the most part in covers+tracks mode).
If I had more control over the workspace I would second that, but for me the workspace has too many limitations. I'll save that for the teaserskin.
> I also really need the option of genre based view
> filters becuse I have so many albums that cover
> such a broad range of music (she likes country
> and pop, I like old school punk and classic rock,
> we both lke blues and jazz... who knows what
> guests like).
For the party use I think it too complicated, I just respect the 'limit kioskmode to a fixed musicsearch' for that. But I fully agree for home, it's just that if I am honest I think it will probably remain on my todo-list for ever. So much to do, so little time etc.
> > I had hoped to use the "same" skin for
> both personal and guest use. The NON-KIOSK mode
> would idealy have ratings buttons and a few other
> features to assist me in my daily listening. I
> don't like the idea of changing skins for
> different environments. Both the look and feel
> change, as well as the fact that it is
> cumbersome.
Well, in this case I differ in opinion. My personal skin is more like Shiriuba/100 (http://forum.silverjuke.net/viewtopic.php?t=3073): lots of control and options. But for my guests I prefer totally simple. And when I feel totally simple myself I'll use the guest-version as well. And I even prefer if they look totally different, I think form follows function (apart from colors etc.) here: Shiruba/100 wastes nearly no space but allows lots of control, while this skin covers a lot of screenestate with round lines to signify "don't be scared, I am easy to control"
> I spent the rest of the afternoon looking at the
> SDK and have pretty much deiceded that I don't
> have the time to leanr enough to create my dream
> skin.
Feel free to ask anything about changing this skin for your own use(preferrably in a new separate thread in the scripting forum or by email).
> I have several microcontroller projects
> (aquarium automation, dosing, lighting etc.) and
> some construction projects (CNC router) to
> finish.
Aaahhhh... Those were the days... I can't/won't/don't spend much time on those hobbies anymore. Although last year I did create a remote control receiver for my home made projector screen. Unfortunately it was never fully finished, it should have remembered different screen & masking positions for different aspect ratios, but as I ran into problems with the position feedback I never got it 100% reliably detecting its position. Now it is just an expensive up/down receiver, which I could have bought off-the-shelf for less
Bye,
SilverEagle
PS:
> (I hate C, C++, Java, etc)
Than what do you program? I myself love C, like C++ and stumble around in javascript.
