Skinning Engine

General Mixxx discussion.... discuss

Moderator: garth

Skinning Engine

Postby profoX » Fri Jul 24, 2009 2:06 am

(cross-post from mixxx-devel mailing list)

Today I thought about a new skinning engine. I think it's time we
started working on one.
I have gathered some ideas from different users and created a wiki
page: http://mixxx.org/wiki/doku.php/skinning_engine

Feel free to add your own idea, or to add something to the pro's and
con's of an idea.

Also, feedback from skin creators is very welcome! What would YOU - as
a skin creator - like to see in the skinning engine?
What do you dislike about the current skinning system? And/or what do
you like about it?

Greetings from an old contributor,
who might jump back into Mixxx development with this project
profoX
 
Posts: 9
Joined: Thu Feb 14, 2008 2:18 am

Re: Skinning Engine

Postby jus » Fri Jul 24, 2009 7:58 am

I would more then welcome a new flexible skinning engine.

But keep it simple - Mixxx is about the music ,not to show off the latest cross-platform glitz.

What is the goal?
The new skinning engine should lead to more good skins:-)
Skins should be fun to create and to use.

A future-ready,stable,fast and flexible skinning engine - that is not too hard to implement in the existing environment and sport a low cpu-footprint. Sound like fun :lol:

The current engine
pro:
    it works
    color sheme support
    some skins availlable

con
    needs way to much tinkering with separate graphic files & xml
    poor documentation
    no naming convention
    not resolution independent

Creating skins is actually an challenging and time consuming task.

Wishlist new engine
    Balanced performance on all supported systems
    Vector based
    Resolution independent
    Able to handle features to come ( i.e. future tab support, gui-sets )

I`m not a programmer but the Qt 4 based skinning engine you mentioned in the wiki entry sounds good so far.
The Mixxx Manual, Wiki and FAQ are the best place to start for documentation and support.
Please report any bugs you find to our Bug Tracker.

Find out how to contribute to Mixxx development.
User avatar
jus
Mixxx Artist
 
Posts: 1009
Joined: Tue Jun 16, 2009 5:52 pm
Location: Berlin

Re: Skinning Engine

Postby profoX » Fri Jul 24, 2009 9:47 am

jus wrote:I would more then welcome a new flexible skinning engine.

But keep it simple - Mixxx is about the music ,not to show off the latest cross-platform glitz.

I agree that we probably shouldn't rewrite the whole application to be QGraphicsView-based or based upon the (still experimental) declarative UI technology (although the last one could be pretty useful if it gets more mature and doesn't have to rely on QFxView in the future...) But indeed, the skin may not interfere with Mixxx' performance when mixxxing. That should be a priority.

jus wrote:What is the goal?
The new skinning engine should lead to more good skins:-)
Skins should be fun to create and to use.

A future-ready,stable,fast and flexible skinning engine - that is not too hard to implement in the existing environment and sport a low cpu-footprint. Sound like fun :lol:

My opinion is that we can actually take a lot of parts/ideas from the current engine, but rewrite it anyway to fix some of the current problems. The Qt 4 based approach is capable of doing just that.

jus wrote:The current engine
pro:
    it works
    color sheme support
    some skins availlable

Color scheme support should be in the new engine as well. I think we have to keep supporting legacy functionality if its currently in use (which means its useful to some).
I'm also thinking about some new stuff. I don't know whether they are all good ideas or whether they have drawbacks for skin creators though?..
  • Knobs will rotate automatically without the skin creator having to create many different files for the different states the knob will be in
  • Make it possible to define an overroll/hover image and optionally make it so that this image fades in/out when hovering over it
  • Support style sheets (based on QSS, which is like CSS) to style things like scrollbars or the library list

jus wrote:con
    needs way to much tinkering with separate graphic files & xml
    poor documentation
    no naming convention
    not resolution independent

Creating skins is actually an challenging and time consuming task.

Hopefully not much documentation will be needed. I'm thinking of ways to make it easier to develop skins.
Resolution indepent skins should be the biggest priority of the new skinning engine. I agree with that.
I'm wondering at how to implement it though. Obviously using layouts with 0-margins, which is not too hard to do.
But... how to make it easy enough for the skin developers, that's a more important question.
I'm thinking of some sort of layouting system like the one that Qt uses itself (QLayout)

Maybe it's a good idea to let the skin creator use Qt Designer to create the main layout,
and provide the .ui file (which can be loaded at run-time using QUiLoader),
and an .xml file containing the information about the rest of the skin... not sure yet.

jus wrote:Wishlist new engine
    Balanced performance on all supported systems
    Vector based
    Resolution independent
    Able to handle features to come ( i.e. future tab support, gui-sets )

Performance will be tested and compared to old implementation. We should strive for the same performance, or better performance. But a very tiny bit of performance loss is acceptable too, since the idea is to improve the engine by also adding some new features..

I'm not sure about the vector graphics. This is easy to implement with QSvgRenderer, but the buttons and other widgets themselves should not stretch out on resize, right? So you won't really get any advantage in using SVG.. it will only consume more CPU (although we can probably work around that)

Resolution independency has the highest priority.

I think I should leave it to the skin designer to decide which elements to add in his skin and how he wants to represent the widgets. If he wants to use a tab widget for something, he should be able to. This will however complicate things...
profoX
 
Posts: 9
Joined: Thu Feb 14, 2008 2:18 am

Re: Skinning Engine

Postby jus » Fri Jul 24, 2009 11:04 am

profoX wrote:I think we have to keep supporting legacy functionality if its currently in use (which means its useful to some).

Useful to whom? The new one will be better, so make a cut based on the good the current engine can deliver even if legacy functionality will sacrifice.

profoX wrote:
  • Knobs will rotate automatically without the skin creator having to create many different files for the different states the knob will be in
  • Make it possible to define an overroll/hover image and optionally make it so that this image fades in/out when hovering over it
  • Support style sheets (based on QSS, which is like CSS) to style things like scrollbars or the library list

+3

profoX wrote:Maybe it's a good idea to let the skin creator use Qt Designer to create the main layout..

Designers will most likely rely on there approved graphic tools ( Photoshop,Fireworks, Inkskape , Gimp ...whatever ).
If you want attract designers, make the whole skinning process less technical ( do a google search for QT designer tutorial and you know... ).
If it`s easy enough even for the mildly experienced designer we will have good skins in a snap.

More good skins-->more professional looking mixxx ( lot of ppl judge by the cover) -->good arguments for promotion-->broader user-base and the list goes on....


There are already different approaches around, why not take a look around:
I
Strict color sheme support: The designer can create custom color maps , the layout stays always the same.
Used by M-Audio Torq, Ableton live...

II
Pixmap support: The designer prepares a layout set within conventions ( i.e. using a template ) , which the engine will parse.
Used by Imgeline Deckadance, Virtual DJ....

I prefer option II which is basically the way Mixxx works now.

To sum it up:
profoX wrote::...take a lot of parts/ideas from the current engine, but rewrite it anyway to fix some of the current problems
The Mixxx Manual, Wiki and FAQ are the best place to start for documentation and support.
Please report any bugs you find to our Bug Tracker.

Find out how to contribute to Mixxx development.
User avatar
jus
Mixxx Artist
 
Posts: 1009
Joined: Tue Jun 16, 2009 5:52 pm
Location: Berlin

Re: Skinning Engine

Postby profoX » Fri Jul 24, 2009 5:24 pm

With the legacy functionality I was referring to stuff like the coloring support, which you seem to like. And there are probably some other small thingies that are worth supporting in the new engine.

About the two approaches you mentioned...
I googled around for screenshots of M-Audio Torq / Ableton Live and the system looks very basic. I'd like more functionality.
The second approach sounds better. Can you find some examples of the skin file format they use? I can't find much on the web with a quick search.
I did find something about skinning Virtual DJ though, and I've got an idea. I will post more details soon.

edit: I'm wondering. How does Virtual DJ skin "knobs" ? Or doesn't it have those ?
profoX
 
Posts: 9
Joined: Thu Feb 14, 2008 2:18 am

Re: Skinning Engine

Postby albert » Fri Jul 24, 2009 7:50 pm

One way you can do pixmap-based knobs is by generating a sprite which contains all of the animations (rotations, highlights, etc.) for it. I've done this on a personal project and it worked well. I feed two images, a knob foreground and background image, into my knobcreator program, and then it spits out a sprite with contains the knob at each rotation angle. You could add a highlighted version as well or something.

I'd like to see some flexibility in the way we lay out the GUI, but I'm not sure what the best way to do that is. MDI looks retro, and QLayout might be tricky to modify at runtime in an intuitive way. (Oh, and speaking of which, I wouldn't mind being able to modify the layout at runtime, so we can show/hide certain elements of the GUI. For example, a radio DJ might want a talkover button in their UI, but it would just be a waste of space for an electrohouse DJ.)

Keep the ideas coming!
User avatar
albert
Mixxx Developer
 
Posts: 562
Joined: Wed Feb 13, 2008 5:45 am
Location: Victoria, BC, Canada

Re: Skinning Engine

Postby profoX » Fri Jul 24, 2009 10:20 pm

Interesting points.

Maybe this is an idea:

Skin designer can either create fixed skins or resizable skins
Skins will be created by a "skin creation" application which automatically generates a skin XML file, which works as follows:
- Skin creator sets some values, like default skin size, description, etc.
- Skin creator loads a background image for the whole skin. This background can already contain clickable and pushable buttons.
- Clickable/pushable parts can be selected with a rectangle tool (optionally something else than a rectangle tool as well, but that seems rather unnecessary to me?)
- You can then define properties for the selected button, like: what the button is for, how it should be handled, tooltip, overroll image, fx (fade, duration), optionally fix the position by X and Y value to align it more perfectly with other elements...
- The overroll image is selected from another background image and can be in a different location or have a different size. This makes it possible to create something like a glowing effect on overroll.

However, to allow skin designers to re-use the same components (buttons) and to allow the use of knobs, you can also import images of controls:
- These controls can be placed anywhere over the skin background.
- Controls have their own visual settings for overroll etc. which can be edited by rightclicking the image in the import window and choosing something like "edit control type / edit visual appearance".
- When the control type is a knob, the image will be automatically rotated by the skinning engine itself when the skin is in use. This means you won't have to create about 30 differently rotated knobs.
- To define properties like what the button is for and how it should be handled, you'll have to do that button per button in the interface. The visual appearance for these types of buttons cannot be changed seperately however.

On to layouts... When a skin designer chooses to create a fluid layout (a layout which resized) he should:
- Divide the background image up into parts with something like a slice tool.
- Every part will need a property for horizontal and vertical scaling, which can be: fixed, or tiled. When fixed, the part always stays the same size. When tiled, that part of the background will be repeated for the required length. Technically this should be able to work when using QLayouts with 0-margin and 0-padding.
- Some parts - the ones that contain a certain control like a QSlider or a Waveform or the Library, can optionally stretch in either or both directions.
- In this case, controls which are placed over the background will have to be forced into one of the fixed areas, to not make it too difficult for the programmers.

We should also support normal widgets:
- Why not support normal widgets as well? It makes the application integrate with the desktop better, for those who want to. The skin creator should be able to make use of a few system widgets. Or he could just write a complete theme with system widgets and just define the layout.
- System widgets can be set for any of the overlaying controls (it is an option that can be disabled/enabled globally or per-control)
- System widgets can be styled by using the Qt Style Sheet system. Style sheets will also be necessary if the skin creator wants to skin for example scroll bars or the look of the library list.

But how to support flexible layouts where the actual end-user can define what he wants?
I'm not sure, but I've been thinking about this:
- Let the user create a skin override file by letting him actually change the skin using the skin creator tool.
- The skin override file will be processed after processing the original skin file, so that the original skin stays intact.
- Instead of the library, maybe there should be a tabbed interface or similar, where different things can be selected (or maybe just a stacked widget with a combobox)

I'd like your input on some or all of these ideas.
profoX
 
Posts: 9
Joined: Thu Feb 14, 2008 2:18 am

Re: Skinning Engine

Postby jus » Sat Jul 25, 2009 9:55 am

Thought the skinning for M-Audio Torq & Ableton Live may look simple they allow only colormap support for a good reason imho.
It solves the screen-resolution problem (vector), less support requests ( skin xyz wont work on my abc....., please help etc ), easy option to handle different lighting and other than that mentioned a unified look is yummy for brand recognition ;-)

There are always users who complaining about the look, but the majority are more then happy it just works.
Its about making music. That simple.

Just look around here in the forum, how much complains about the skins?
We need to balance what can be done and what need to be done. More is sometimes less.

profoX wrote:Skins will be created by a "skin creation" application which automatically generates a skin XML file, which works as follows:

A handy tool like that ---> http://www.youtube.com/watch?v=XGuuim9F
can lead to good skins -->http://www.youtube.com/watch?v=kGqYrYdSEUA

This forum post describes skin creation for Virtual DJ and sounds very similar to your ideas. ( Sadly the post there is mixed up, so copy all the text and paste in a new html document to bring it in a readable form.)
The Mixxx Manual, Wiki and FAQ are the best place to start for documentation and support.
Please report any bugs you find to our Bug Tracker.

Find out how to contribute to Mixxx development.
User avatar
jus
Mixxx Artist
 
Posts: 1009
Joined: Tue Jun 16, 2009 5:52 pm
Location: Berlin

Re: Skinning Engine

Postby albert » Sun Jul 26, 2009 5:03 pm

profoX wrote:Interesting points.

Maybe this is an idea:

Skin designer can either create fixed skins or resizable skins
Skins will be created by a "skin creation" application which automatically generates a skin XML file, which works as follows:
- Skin creator sets some values, like default skin size, description, etc.
- Skin creator loads a background image for the whole skin. This background can already contain clickable and pushable buttons.
- Clickable/pushable parts can be selected with a rectangle tool (optionally something else than a rectangle tool as well, but that seems rather unnecessary to me?)
- You can then define properties for the selected button, like: what the button is for, how it should be handled, tooltip, overroll image, fx (fade, duration), optionally fix the position by X and Y value to align it more perfectly with other elements...
- The overroll image is selected from another background image and can be in a different location or have a different size. This makes it possible to create something like a glowing effect on overroll.

However, to allow skin designers to re-use the same components (buttons) and to allow the use of knobs, you can also import images of controls:
- These controls can be placed anywhere over the skin background.
- Controls have their own visual settings for overroll etc. which can be edited by rightclicking the image in the import window and choosing something like "edit control type / edit visual appearance".
- When the control type is a knob, the image will be automatically rotated by the skinning engine itself when the skin is in use. This means you won't have to create about 30 differently rotated knobs.
- To define properties like what the button is for and how it should be handled, you'll have to do that button per button in the interface. The visual appearance for these types of buttons cannot be changed seperately however.


Creating a skin editor just sounds like a lot of work. I don't know if creating an editor should be part of our specification for a new skinning engine. We should keep it in mind that we'd like to have one down the road (maybe a GSoC project?), but it seems like too much work for now, to me at least.

On to layouts... When a skin designer chooses to create a fluid layout (a layout which resized) he should:
- Divide the background image up into parts with something like a slice tool.
- Every part will need a property for horizontal and vertical scaling, which can be: fixed, or tiled. When fixed, the part always stays the same size. When tiled, that part of the background will be repeated for the required length. Technically this should be able to work when using QLayouts with 0-margin and 0-padding.
- Some parts - the ones that contain a certain control like a QSlider or a Waveform or the Library, can optionally stretch in either or both directions.
- In this case, controls which are placed over the background will have to be forced into one of the fixed areas, to not make it too difficult for the programmers.


Can you make a test application that shows how to graphically modify a QLayout at runtime? I want to see what our options are for rearranging QWidgets in realtime.

We should also support normal widgets:
- Why not support normal widgets as well? It makes the application integrate with the desktop better, for those who want to. The skin creator should be able to make use of a few system widgets. Or he could just write a complete theme with system widgets and just define the layout.
- System widgets can be set for any of the overlaying controls (it is an option that can be disabled/enabled globally or per-control)
- System widgets can be styled by using the Qt Style Sheet system. Style sheets will also be necessary if the skin creator wants to skin for example scroll bars or the look of the library list.


Yeah, I'm not opposed to this.

But how to support flexible layouts where the actual end-user can define what he wants?
I'm not sure, but I've been thinking about this:
- Let the user create a skin override file by letting him actually change the skin using the skin creator tool.
- The skin override file will be processed after processing the original skin file, so that the original skin stays intact.
- Instead of the library, maybe there should be a tabbed interface or similar, where different things can be selected (or maybe just a stacked widget with a combobox)

I'd like your input on some or all of these ideas.


Tabbed interface is already on its way, once we have LADSPA. (it's actually just commented out in 1.7) :)

I agree with what jus said about brand recognition, which is at least a good reason for having a solid default skin. The default skin should really be the best skin. :)

I don't know if anyone mentioned this, but (I think) SVGs are a pain in the ass to render in realtime. Someone correct me if I'm wrong. But I don't realistically expect SVG to magically let you resize the Mixxx window in realtime without your PC freaking out, so I'm skeptical about it solving the resizable window problem.

Albert
User avatar
albert
Mixxx Developer
 
Posts: 562
Joined: Wed Feb 13, 2008 5:45 am
Location: Victoria, BC, Canada

Re: Skinning Engine

Postby profoX » Mon Jul 27, 2009 12:04 am

albert wrote:Creating a skin editor just sounds like a lot of work. I don't know if creating an editor should be part of our specification for a new skinning engine. We should keep it in mind that we'd like to have one down the road (maybe a GSoC project?), but it seems like too much work for now, to me at least.

I know. The way I was thinking is like this: create a skin specification first (XML format) and you can always expand from there. If you keep in mind what possibilities a skin creator application would need, you could however make the XML specification better.

albert wrote:Can you make a test application that shows how to graphically modify a QLayout at runtime? I want to see what our options are for rearranging QWidgets in realtime.

Yea, I'll see what I can cook up.

albert wrote:I don't know if anyone mentioned this, but (I think) SVGs are a pain in the ass to render in realtime. Someone correct me if I'm wrong. But I don't realistically expect SVG to magically let you resize the Mixxx window in realtime without your PC freaking out, so I'm skeptical about it solving the resizable window problem.

I agree. That's why I am not seeing the benefit of them, like I said earlier in this topic. Since we are not actually stretching the SVG's (we want a layout-based system) the SVG's are of absolutely no use. They will only slow down rendering considerably.
profoX
 
Posts: 9
Joined: Thu Feb 14, 2008 2:18 am

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 2 guests