Additional Skin for the Main Window

[corrados]

@pljones and @gilgongo: I have a nice new project for you if you like. Right now we have the "normal" and "fancy" stile. Instead of a check box we could introduce a combo box with {normal, fance, nice ;-)} options. There are plenty of nice GUIs out there, e.g. the Ardour style: Or others. My idea would be that @gilgongo is the designer and @pljones does the coding. Regarding the design, you could integrate all the requirements for color-blindness, contrast, etc. You could also incorporate feedback from the community. Regarding the coding, @pljones it would be great to discuss the details with me. I already have some ideas how to implement that.

Are you both interested?

[gilgongo]

Sounds interesting! I take it the skin would use the same underlying UI structure, and we'd just apply "styles" to the objects (like the lights and buttons and text and stuff), is that right?

[corrados]

Yes, exactly. But it should also be possible to exchange the LED level meters by bars. For that the code has to be modified a bit but it should be fairly straightforward.

[gilgongo]

OK, well I can have a go at something and see what it looks like :-)

[pljones]

Does Qt have tools built in for validating styling? (My approach to UI is if the user can interact with the app, it works! ;) )

[corrados]

I don't know if I understood your question correctly, but the way I did it was to use, e.g., the style of the GUI control, see: https://github.com/corrados/jamulus/blob/master/src/clientdlg.cpp#L1190

[pljones]

I was actually thinking about allowing "user skins", I guess - you'd need a "published model" for the widget set and then some way to validate the skin against that model.

But if it's just another entry in place of the existing two, should be "safe" - should be easy to spot glitches.

[corrados]

No, I am not talking about user skins. I am just talking about adding one more built-in skin. Right now we have the default Windows design any my "fancy" design. You would just add another one.

[pljones]

The code to switch style sheets would be simple enough (one caveat -- two strings are needed, the main style sheet and the rbtReverbSelL/R patch string).

That's if just styling the existing widgets is done. Switching the widget design (e.g. using more, smaller segments in an LED bar) would require significantly more thought :) .

https://github.com/corrados/jamulus/blob/master/src/multicolorled.cpp#L32-L38 and https://github.com/corrados/jamulus/blob/master/src/multicolorledbar.cpp#L137-L141 would also need thinking about.

[corrados]

Maybe you can modify the CMultiColorLEDBar class so that it also supports bars. There are GUI controls in Qt which implement bars. It would be good to have something like a CLevelMeter class with a SetStyle() function where you can select the Multi Color LED Bar style and a new Simple Bar style.

[corrados]

Today I have implemented the support for showing bars instead of LEDs for the normal skin (the "fancy" skin still uses LEDs): How do you like that?

[nicolopozzato]

I think that it's great!

Only green bar or are you thinking about adding yellow and red?

Also do you think about adding a db value on top or bottom of the bar and the fader? to view and read a db value that the signal is or tha fader is set to?

(if I don't mistake the fader is logaritm, and I find it hard to set it at the right volume without kwnowing the levels)

[pljones]

The mixer display levels are 0, 1, 2 and 3. It's a two binary digit value per channel to keep the network traffic low. These are then decayed over time to smooth them visually. Effectively, there's no meaning other than "pretty quiet", "audible", "fairly full on" and "really too loud".

[Snayler]

Looking sexy! Please implement that, it will be my favorite.

I also think a yellow and red part should be implemented in the bars, to give better visual feedback on who's clipping.

[nicolopozzato]

The mixer display levels are 0, 1, 2 and 3.

Got it! I assumed that the server send to the client the db levels 😉

[pljones]

Got it! I assumed that the server send to the client the db levels 😉

Another reason why the mixer meter for your own level doesn't track the local level is that the server is only sampling about once every fifth of a second (for all clients at that time). Again, keeps the overhead low. It's just so you've a better clue who's playing and who's not.

So it's got some rough value that it then maps to another tiny range... I was surprised how well it works -- it really does make the sessions feel more "involved", where the servers have been upgraded to support it, though.

[nicolopozzato]

I'm using the led bar to mix a streaming mix without earing anything... (I know that is not the correct use 🤣)

Every sunday in our church service... i set the volume by the led... after a song I go in the live streaming and listen back what was on air, and base on that I make changes... I can't listen live because the streaming pc is in the sanctuary and I'm remote managing from my home, all the streaming: scene changing, volume of mic and the song (jamulus)... I also sing with jamulus in my pc, and my pc is also our private jamulus server (internet church 100mb down and 20mp up, mine is the same) all the client in jamulus have a max ping to my server (my pc) of 8/10ms and we use 128 buffer. Also for eliminate dropouts in the streaming pc i set a high local/server jitter buffer (like 10/15 so the output audio from jamulus is very clean, we also listen at what the pastor say in real time). On top of that we also integrate in the livestreming our webcam with a google meet (muted) call! We have a great response from our comunity that they love what we are doing every week (we are in Italy with a complete lockdown). If anyone want to see/listen what we can archive with some free software (obs, anydesk, JAMULUS) and a couple of soundcard you can see there our last Mass https://www.facebook.com/parrocchiadizelarino/videos/254392355952962/?t=3926 (link to the last song, nothing super, but many other church nearby ask us how we can make this happen... magic ❤ )

[corrados]

@geheimerEichkater Are you interested in designing a new skin of the Jamulus main window which is in the same style as the new icon and banner? As an example you can find the pictures used for the fancy skin here: https://github.com/corrados/jamulus/blob/master/src/res/mixerboardbackground.png https://github.com/corrados/jamulus/blob/master/src/res/ledbuttonpressed.png https://github.com/corrados/jamulus/blob/master/src/res/ledbuttonnotpressed.png https://github.com/corrados/jamulus/blob/master/src/res/faderhandle.png https://github.com/corrados/jamulus/blob/master/src/res/faderbackground.png Additional GUI control overlays might be defined for, e.g., the level meter bar.

[WolfganP]

Just as a reference, qBitTorrent (another Qt5 based UI project) went thru the same process of implementing themes (after years of "Dark Theme please!" issues), and they decided to go thru loadable themes that may be developed/customized by non core developers.

Intro to the implemented solution at https://github.com/qbittorrent/qBittorrent/wiki/Create-custom-themes-for-qBittorrent

[geheimerEichkater]

@corrados yup, totally, I'd love to. I was already collecting my thoughts and questions about that topic. So I understand it's possible to give it a different skin by exchanging the graphic files with their exact dimensions, a simple face lift. How much can the dimensions be stretched i.e. the fader handle without breaking the structure? As @WolfganP referenced the qBitTorrent project (thank you) – does the Jamulus skin also have a .qss-file to handle font styles etc? How do I go about adding a new skin and not just replace the old one at the same time? Would it also be possible to rearrange the underlying wireframe? Or is that too far fetched for now and that would be a later stage?

[corrados]

does the Jamulus skin also have a .qss-file to handle font styles etc?

No it doesn't. And actually I do not see a need for that right now. Maybe at some later point in time.

How much can the dimensions be stretched i.e. the fader handle without breaking the structure?

That depends on what you want. A lot of things are possible. Just make a proposal and I check out what can be implemented and what not.

How do I go about adding a new skin and not just replace the old one at the same time?

New png files are added. The old ones are not overwritten. The new skin has to be added in the source code. I could do that part.

Would it also be possible to rearrange the underlying wireframe? Or is that too far fetched for now and that would be a later stage?

What do you mean by "wireframe"? Do you mean the positions of the GUI controls? They are fixed. But we could change them but this would also be applied to all other skins then.

[corrados]

I'll close this isse since we now have a more recent issue open which addresses basically the same thing: https://github.com/corrados/jamulus/issues/787