Hi guys, Me and Albert had a chat about this last night and what we came up with was pretty much whas Pascal just wrote.
Basically we could have a skin define a bunch of layouts (implemented via QLayouts), which could be things like player1, eqs1 or whatever. Initially the skin could provide a couple of different arrangements of the layouts for different screen sizes or aspect ratios. In the long term we could allow the user to customise the layout by dragging, dropping or turning different layouts on and off. At the moment we don't have that many controls that don't appear on the screen by default. But one of our major issues at the moment is what to do when we add new features, looping, hotcues, ladspa all need more knobs that require relayout of whole skins. In this scheme you'd just need to edit one of your layouts in Qt Designer or whatever. As Pascal suggests it's something we can do incrementally on the existing setup too, which is nice. Adam 2010/1/24 Pascal Huerst <pascal.hue...@bluewin.ch>: > Hi again... > I didn't mean a "reflowing of controls" but a mode, where you can setup the > interface in terms of: "I want this know to be there and this control to be > there". This can be done in groups. (Using what qt has to offer: QLayout) > After editing, this group is locked up and has a defined size (depending on > the controls you want to have in this group). Maybe 200x200 for a player. > Then only this (200x200) player "flows" on the main window. But the player > and the knobs it holds always keeps the 200x200. > This can be done without changing all our Widget (WWidget) classes as a > first step. And its not a big deal, but we already get a fluid layout. ( But > like that there won't be a scene image as background ) > And then to change the look of the knobs, I would suggest to use stylsheets. > But therefore we will have to change all "Customwidgets", so they are able > to be styled by the qss-stylesheets. > With these changes, a player can have a look as flexible as now, BUT there > won't be a global scene like now. So the background of the mainwindow will > rather have a standard style, maybe with a "hardcoded" mixxx logo, to avoid > these "eBay problems"... > The good thing is: Since like that we use the standard qt4 way to style our > app, we will get all the advantages qt includes in future releases for free. > So if they add feature X to their stylesheets, we get that "for free". Also > with the layout stuff... Animations and so forth. > To change the WWidgets will take a while, so for the beginning they won't be > able to be styled by qss. Therefore I would take the look of the widgets > from current skins, but not their positioning. > Pascal > > > Am 24.01.2010 um 17:06 schrieb Garth Dahlstrom: > > On Sun, Jan 24, 2010 at 11:56 PM, Pascal Huerst <pascal.hue...@bluewin.ch> > wrote: >> >> Hi Garth! >> I'm not sure if this really solves the problem. I mean if we start >> "stretching" the current layouts, things might look very bad (even in 1:1). >> So I would not do that, even if its easy to realize as a starting point. >> As already mentioned, I'd rather use the old skins for the look of the >> knobs and so on, and make something new for the arrangement. >> What do others think about that? > > Not sure I'm clear on your plan... if you were to implement reflowing of > controls, then you could have something reflow from the right hand side to > the next row down on the left hand side... Not a problem for text, but > when a right deck control ends up on the left side one row down, me thinks > that wouldn't work. > Maybe there would be some kind of resizing constraints? if these are > overly complicated users might end up asking why this skin doesn't resize > one way, where on another skin with a different arrangement of controls the > skin does resize. > There is also the question of how people design skins to keep a certain > layout ascetic. > If there's to be no stretching of controls, they are still going to look > overly big and cramped on small screens (see outlineMini compressed to fit > an 800x480 eeepc 701 screen [or maybe a future media tablet], where the is > no space to add loop in/out & hot cues) and overly small on larger displays > (32x32 knob is really small on a 30" display running at 2560x1600). > I'm not saying your approach won't work, just not clear on how it > would address these challenges? > Cheers, > -G > >> >> Pascal >> >> >> Am 22.01.2010 um 22:19 schrieb Garth Dahlstrom: >> >> Hi Pascal, >> I expect Sjors will offer an obvious API call that can solve the whole >> problem in a minute, but here would be my non-WebKit approach to starting >> to tackle the problem... :P >> To transitioning existing skins, I think it easiest to avoid fluid >> layouts, since these would be very hard to do while maintaining what the >> original skin author intended in terms of aspect (there would also be >> problems with what to do for the scene background too). >> Instead, as an initial step in the evolution, I would offer restricting >> resizing to a 1:1 aspect ratio changes and do sizing / positioning widgets >> based on where they are located at percentage wise in the original skin >> size... >> i.e. >> When a widget is created calculate these values: >> widget.start_x% = widget.x / form.width >> widget.start_y% = widget.y / form.height >> widget.width% = widget.width / form.width >> widget.height% = widget.height / form.height >> >> // If QSS supports percentages for x,y,width, height, one could generate a >> QSS stylesheet from the values >> // Otherwise, set-up widget like this: >> move( >> start_x% * form.width, // convert to int >> start_y% * form.height // convert to int >> ); >> resize( >> widget.width% * form.width, // convert to int >> widget.height% * form.height // convert to int >> ); >> // ^- This is overly simplifying the other stuff around form aspect resize >> restrictions and triggering resizing of everything... >> The obvious limitations of this approach are: >> * Artwork is not vector based (.SVG), so as stretching occurs controls >> might start to look crappy >> * truncating/rounding of positions and sizing might result in some slight >> imprecision in placement (probably worse the smaller things get) >> Drag and drop reorganizing of widgets would be cool for editing skins >> (i.e. an "edit" mode), but I would want stuff locked down (accept for the >> ability to open overlays) while playing. >> Cheers, >> -G >> __ >> --- == __/ t.O ==-- >> http://stacktrace.org/ >> >> >> On Sat, Jan 23, 2010 at 4:34 AM, Pascal Huerst <pascal.hue...@bluewin.ch> >> wrote: >>> >>> Hi RJ, >>> >>> You are right we should keep that possibilities everything should be as >>> flexible as now. >>> >>> What I'M thinking about is, that if the UI is resizable, the "things" on >>> the mainwindow have to align. Thats what we mean by "resolution >>> independent", right? But i don't know how to define these things. Is it >>> really a skin designer? Maybe we should distinguish between "Interface" and >>> "Skin". I think a skin should define how things look like and an Interface >>> how they behave on resizing or so. ? Maybe there should be a mode, where you >>> can build a Deck, like setup a Mixer as you like and a player as you like >>> and then apply a skin to it ?! >>> >>> Thanks for the answer. Maybe I will be confusing, till I get a clear >>> image about the solution ;-) >>> >>> Pascal >>> >>> >>> >>> Am 22.01.2010 um 18:42 schrieb Russell Ryan: >>> >>> > Hey Pascal, >>> > >>> > First off, thanks a lot for joining this discussion. It's really >>> > beneficial to get as many people as possible in on this discussion so that >>> > we can really understand all the perspectives and use cases involved. >>> > Whatever we decide on for a new skinning system will hopefully last Mixxx >>> > for a long time -- so we need to talk about it a lot to make sure we cover >>> > all the bases. >>> > >>> > I read your post to the Mixxx forums and this email and I have one >>> > question. If you group all the widgets into a grouping that is identified >>> > as >>> > a Mixer or a Player, then what happens when someone comes along and wants >>> > to >>> > make a skin where the EQ section of the mixer is separate from the >>> > crossfader section? >>> > >>> > In all the current Mixxx skins, none of them have a clear boundary >>> > between the widgets that you could draw a box around and say 'Here is the >>> > Mixer'. The parallel waveform display concept, for example, is something >>> > that we believe is a major aid to DJ'ing. The waveform displays are front >>> > and center in the outline skins, while the rest of the player widgets are >>> > on >>> > the left or right. In terms of commercially available software, Virtual DJ >>> > and Torq agree with us in this respect, while Traktor does not. In my >>> > opinion, a skinning system shouldn't constrain the organization of widgets >>> > on the screen -- rather it should facilitate it. >>> > >>> > I'm for a more general approach that doesn't involve grouping widgets >>> > at all along functional boundaries. Why not allow the skin to specify >>> > groupings which have layouts, but are not necessarily tied to the >>> > grouping's >>> > functional purpose? That seems a lot more flexible to me. >>> > >>> > Cheers, >>> > RJ >>> > >>> > pascal.hue...@bluewin.ch wrote: >>> >> Hello, >>> >> >>> >> i need some feedback on that topic. I thought a lot and reviewed the >>> >> code. And I was thinking about how to make a "soft" transition to a new >>> >> interface. >>> >> >>> >> To change the skinning engine, i think there has to be some >>> >> modifications to the interface itself. Now all the widgets are placed by >>> >> absolute coordinates and like that its not possible to get a fluid >>> >> layout. >>> >> So I'd like to keep the current xml files, but change the positioning in >>> >> the >>> >> wwidget.cpp: >>> >> >>> >> >>> >> >>> >> void WWidget::setup(QDomNode node) >>> >> >>> >> { >>> >> >>> >> // Set position >>> >> >>> >> QString pos = selectNodeQString(node, "Pos"); >>> >> >>> >> int x = pos.left(pos.indexOf(",")).toInt(); >>> >> >>> >> int y = pos.mid(pos.indexOf(",")+1).toInt(); >>> >> >>> >> //move(x,y); <- remove that to realize a fluid layout >>> >> >>> >> >>> >> >>> >> // Get tooltip >>> >> >>> >> m_Tooltip = selectNodeQString(node, "Tooltip"); >>> >> >>> >> >>> >> >>> >> ..... >>> >> >>> >> >>> >> >>> >> Then I think I will write a container class (a QWidget with layout >>> >> abilities), which holds some widgets and allows to arrange them by drag >>> >> and >>> >> drop. But then I will have to store the positioning somewhere. WHERE??? >>> >> >>> >> >>> >> >>> >> The container class will align on the mainwindow. >>> >> >>> >> >>> >> >>> >> Second thing: Somehow i have to know, which controls i have to put >>> >> together into a container class. This means: I'll have to put all the >>> >> Mixer >>> >> controls into one container class and all the Player controls into one >>> >> and >>> >> so forth... Any ideas how i can find out which control elements belong >>> >> together? >>> >> >>> >> >>> >> >>> >> I'll try to catch some of you on irc later.... >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> Thanks! >>> >> >>> >> Pascal >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >>> >> Throughout its 18-year history, RSA Conference consistently attracts >>> >> the >>> >> world's best and brightest in the field, creating opportunities for >>> >> Conference >>> >> attendees to learn about information security's most important issues >>> >> through >>> >> interactions with peers, luminaries and emerging and established >>> >> companies. >>> >> http://p.sf.net/sfu/rsaconf-dev2dev >>> >> _______________________________________________ >>> >> Mixxx-devel mailing list >>> >> Mixxx-devel@lists.sourceforge.net >>> >> https://lists.sourceforge.net/lists/listinfo/mixxx-devel >>> >> >>> > >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Throughout its 18-year history, RSA Conference consistently attracts the >>> world's best and brightest in the field, creating opportunities for >>> Conference >>> attendees to learn about information security's most important issues >>> through >>> interactions with peers, luminaries and emerging and established >>> companies. >>> http://p.sf.net/sfu/rsaconf-dev2dev >>> _______________________________________________ >>> Mixxx-devel mailing list >>> Mixxx-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel >> >> > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
