From: Johannes L. <joh...@ma...> - 2013-09-28 10:15:43
|
Hey, We have many widgets that don't just take a parent. Thus, they can not be used in Qt Designer (AFAIK). I propose the following changes to remove additional parameters from constructors: * The knob class has an int describing its style. Since there are only 4 types (and mostly only one type used), I suggest adding 5 specialisation classes to knob.h. * The led_checkbox class takes a text argument before the parent. Would it not be possible to call setText in a retranslate function later? (Retranslations are better style anyway, imo) * The lcd_spinbox is usually only used with 1,2 or 3 digits. Make 3 specialisations. * For more widgets, I'd suggest to try similar techniques. Anyone against these changes in these core widget's headers? Thanks for reply and a nice weekend, Johannes |
From: Johannes L. <joh...@ma...> - 2014-02-09 09:47:16
|
This topic is half a year old, but can someone please give comments? Do you think it is useful? Imo it would be only a few lines of code and would help us to build new UI widget way faster (and cleaner). > Hey, > > We have many widgets that don't just take a parent. Thus, they can not be > used in Qt Designer (AFAIK). I propose the following changes to remove > additional parameters from constructors: > > * The knob class has an int describing its style. Since there are only 4 > types (and mostly only one type used), I suggest adding 5 specialisation > classes to knob.h. * The led_checkbox class takes a text argument before > the parent. Would it not be possible to call setText in a retranslate > function later? (Retranslations are better style anyway, imo) * The > lcd_spinbox is usually only used with 1,2 or 3 digits. Make 3 > specialisations. * For more widgets, I'd suggest to try similar techniques. > > Anyone against these changes in these core widget's headers? > > Thanks for reply and a nice weekend, > Johannes |
From: Tobias D. <tob...@gm...> - 2014-02-09 17:40:02
|
Yes, it'd be a good thing to have all of our widgets available in Qt Designer so we can replace lots of code with code that is generated from the UI files. Do you have ambitions for implementing this, you're welcome to do so :-) However I disagree about the specializations. Properties like "number of digits" etc. should be made real properties (Q_PROPERTY) so they eventually can be changed inside the Qt Designer. HTH Toby |
From: Johannes L. <joh...@ma...> - 2014-03-16 14:06:09
|
> However I disagree about the specializations. Properties like "number > of digits" etc. should be made real properties (Q_PROPERTY) so they > eventually can be changed inside the Qt Designer. Hi, not sure about what you mean. Let's take the knob type, which is passed to the knob's ctor. Of course, we can "wrap" a Q_PROPERTY "around" it. Still, the knob type must be known in the constructor. So how does a Q_PROPERTY help to get rid of the constructor parameter? Kind regards, Johannes |
From: Tobias D. <tob...@gm...> - 2014-03-17 22:33:29
|
2014-03-16 15:06 GMT+01:00 Johannes Lorenz <joh...@ma...>: > not sure about what you mean. Let's take the knob type, which is passed to the > knob's ctor. Of course, we can "wrap" a Q_PROPERTY "around" it. Still, the > knob type must be known in the constructor. It doesn't have to. Knob pixmap initialization etc. could be moved into a setter function for the knob type property. As long as the knob type is not set, the background is not drawn. > So how does a Q_PROPERTY help to > get rid of the constructor parameter? Q_PROPERTY declares the interface to change a certain property via Qt mechanisms. Of course you still have to implement proper getter/setter methods. Toby |
From: Johannes L. <joh...@ma...> - 2014-03-19 14:16:43
|
> It doesn't have to. Knob pixmap initialization etc. could be moved > into a setter function for the knob type property. As long as the knob > type is not set, the background is not drawn. While I understand what you mean, I don't think it's good. A good example is probably the lcd widget: There is no good reason that the number of digits should ever be changed (and no function to do that). So it should be declared const (it is not, a bug imo). However, const members must be set on construction, so this will conflict with setter functions. For comparison: Advantages of setter function: * You can change some things on runtime (but it's pretty unlikely you'll ever do that) Advantages of value template parameters, i.e. LcdSpinBox<1>, LcdSpinBox<2>...: * You can use const values which have (small) runtime advantages and make the code safer/cleaner. Are you really sure it is better to use properties than value template parameters? |
From: Tobias D. <tob...@gm...> - 2014-03-19 15:03:43
|
Hi, yes properties are better than value templates as the latter one lead to massive bloat, at least if you do not move the existing class to a non-templated parent class. I guess however that using template-classes is rather inconvenient, especially in Qt Designer even though I admit that parameters like these rarely will change. Toby |
From: Johannes L. <joh...@ma...> - 2014-03-19 16:37:13
|
Hi again, so you'd suggest to simply add overloaded ctors with less parameters + setter functions + properties using these setters? If yes, I could do that. - Johannes > Hi, > > yes properties are better than value templates as the latter one lead > to massive bloat, at least if you do not move the existing class to a > non-templated parent class. I guess however that using > template-classes is rather inconvenient, especially in Qt Designer > even though I admit that parameters like these rarely will change. > > Toby |
From: Tobias D. <tob...@gm...> - 2014-03-19 16:43:43
|
Yes, that would be the most straight forward design. Thanks in advance! Toby |
From: Johannes L. <joh...@ma...> - 2014-03-19 18:50:13
|
> We also need to ensure that these changes don't break any existing UI > elements. So if we make changes to how widgets are initialized, then all > the parts of the UI using that widget need to be adapted to those changes. Yes, though the number of changes will be very small (existing code will just be moved into other functions). So it should hopefully not happen. > While we're at it, we should move as much of the graphical attributes > (widget colours, backgrounds, images etc.) to the CSS, which should be > doable since we can set values for qproperties in the CSS. IIRC, this would mean that for every widget, we'd use the default ctor, and instead pass the other parameters via css script? Due to the amount of overall widgets, this could be a lot of work. It sounds sane to me, though. |
From: Vesa <di...@nb...> - 2014-03-19 21:26:30
|
On 03/19/2014 08:50 PM, Johannes Lorenz wrote: >> We also need to ensure that these changes don't break any existing UI >> elements. So if we make changes to how widgets are initialized, then all >> the parts of the UI using that widget need to be adapted to those changes. > Yes, though the number of changes will be very small (existing code will just > be moved into other functions). So it should hopefully not happen. Hopefully, yeah. >> While we're at it, we should move as much of the graphical attributes >> (widget colours, backgrounds, images etc.) to the CSS, which should be >> doable since we can set values for qproperties in the CSS. > IIRC, this would mean that for every widget, we'd use the default ctor, and > instead pass the other parameters via css script? Due to the amount of overall > widgets, this could be a lot of work. It sounds sane to me, though. Yeah. It may be lots of work. Of course, some things can still be set in code - like if changing the size of a widget would break a layout or break other functionality, we can keep hardcoding the size in code so themers won't accidentally mess with it and then wonder why things don't work. I was planning to start migrating graphical properties to CSS after 1.0.0 in any case... |
From: Vesa <di...@nb...> - 2014-03-19 17:07:35
|
On 03/19/2014 06:37 PM, Johannes Lorenz wrote: > Hi again, > > so you'd suggest to simply add > > overloaded ctors with less parameters + > setter functions + > properties using these setters? > > If yes, I could do that. > > We also need to ensure that these changes don't break any existing UI elements. So if we make changes to how widgets are initialized, then all the parts of the UI using that widget need to be adapted to those changes. While we're at it, we should move as much of the graphical attributes (widget colours, backgrounds, images etc.) to the CSS, which should be doable since we can set values for qproperties in the CSS. |
From: Tres F. <tre...@gm...> - 2014-03-19 17:51:54
|
Would QT Designer modeling potentially move GUI development into an IDE? I know we spoke briefly about qmake and I don't understand enough to speak on it's behalf, but from what I've read QT Designer can tremendously help with creating OSX builds. Again, this is speculative on my part, but from what I've read on the QT wiki QT5 does the QT lib dependency stuff eliminating the need for the bulky MacPorts approach, but I am speaking purely from speculative knowledge. -Tres - Tre...@gm... On Wed, Mar 19, 2014 at 1:07 PM, Vesa <di...@nb...> wrote: > On 03/19/2014 06:37 PM, Johannes Lorenz wrote: > > Hi again, > > > > so you'd suggest to simply add > > > > overloaded ctors with less parameters + > > setter functions + > > properties using these setters? > > > > If yes, I could do that. > > > > > > We also need to ensure that these changes don't break any existing UI > elements. So if we make changes to how widgets are initialized, then all > the parts of the UI using that widget need to be adapted to those changes. > > While we're at it, we should move as much of the graphical attributes > (widget colours, backgrounds, images etc.) to the CSS, which should be > doable since we can set values for qproperties in the CSS. > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > |
From: Vesa <di...@nb...> - 2014-03-19 18:03:48
|
On 03/19/2014 07:51 PM, Tres Finocchiaro wrote: > Would QT Designer modeling potentially move GUI development into an IDE? Well, optionally at least. I guess it's up to each developer which tools they want to use. |
From: Johannes L. <joh...@ma...> - 2014-03-19 18:55:39
|
> I know we spoke briefly about qmake and I don't understand enough to speak > on it's behalf, but from what I've read QT Designer can tremendously help > with creating OSX builds. You can use both Qt Designer, Qt Creator and qmake independently. So we can use Qt Designer without switching to qmake. So this is actually OT :) > Again, this is speculative on my part, but from what I've read on the QT > wiki QT5 does the QT lib dependency stuff eliminating the need for the > bulky MacPorts approach, but I am speaking purely from speculative > knowledge. If it is just about library dependencies, CMake should be able to do the same. |
From: Tres F. <tre...@gm...> - 2014-03-19 19:29:40
|
> > If it is just about library dependencies, CMake should be able to do the > same. > Asking more questions here... doesn't QT Designer come bundled with the proper libraries for this? The reason I ask is because the MacPorts approach looks like a -- pardon my language here -- a bloated mess. We're not particularly interested in running a KDE desktop via X11 but rather utilize the Cocoa hooks and use a minimum subset of build dependencies, right? Again, I'm speaking from a very naive and inexperienced background in cross-platform C/C++ development, however I do enjoy the choice of desktops currently and would like to understand how tremendously difficult or easy these tasks could be so Jonathan and I could start working toward a build (or shelf the idea if it's impractical, etc). Thanks for allowing me to take this conversation a bit off-topic. -Tres |
From: Lukas W. <luk...@gm...> - 2014-03-19 19:48:59
|
Tres, to be honest, I don't understand what you are suggesting here. Qt Designer has nothing to with any bundled libraries or the OS you're building on. Qt is cross-platform, it supports Mac natively. How is there a need for MacPorts? Also, this is off topic, we should continue discussing your ideas in another thread. 2014-03-19 20:29 GMT+01:00 Tres Finocchiaro <tre...@gm...>: >> If it is just about library dependencies, CMake should be able to do the >> same. > > > Asking more questions here... doesn't QT Designer come bundled with the > proper libraries for this? The reason I ask is because the MacPorts approach > looks like a -- pardon my language here -- a bloated mess. We're not > particularly interested in running a KDE desktop via X11 but rather utilize > the Cocoa hooks and use a minimum subset of build dependencies, right? > > Again, I'm speaking from a very naive and inexperienced background in > cross-platform C/C++ development, however I do enjoy the choice of desktops > currently and would like to understand how tremendously difficult or easy > these tasks could be so Jonathan and I could start working toward a build > (or shelf the idea if it's impractical, etc). > > Thanks for allowing me to take this conversation a bit off-topic. > > -Tres > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > |
From: Jonathan A. <eag...@gm...> - 2014-03-20 08:04:21
|
Have any of these that have been mentioned been filed as enhancement requests in the tracker? Also are these set as milestones for 1.1? On Wed, Mar 19, 2014 at 6:07 PM, Vesa <di...@nb...> wrote: > On 03/19/2014 06:37 PM, Johannes Lorenz wrote: > > Hi again, > > > > so you'd suggest to simply add > > > > overloaded ctors with less parameters + > > setter functions + > > properties using these setters? > > > > If yes, I could do that. > > > > > > We also need to ensure that these changes don't break any existing UI > elements. So if we make changes to how widgets are initialized, then all > the parts of the UI using that widget need to be adapted to those changes. > > While we're at it, we should move as much of the graphical attributes > (widget colours, backgrounds, images etc.) to the CSS, which should be > doable since we can set values for qproperties in the CSS. > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > -- Jonathan Aquilina |
From: Vesa <di...@nb...> - 2014-03-20 08:16:38
|
On 03/20/2014 10:03 AM, Jonathan Aquilina wrote: > Have any of these that have been mentioned been filed as enhancement > requests in the tracker? Also are these set as milestones for 1.1? > No these aren't filed in the tracker yet but I might put them there at some point, maybe. These are definitely things that are going to be done after 1.0 is released, not sure about any specific milestones - moving things to CSS is more of an ongoing thing, which I've already made a very small start in by making the pattern colours and palette be defined in the CSS. Ideally I'd like every colour and graphic in LMMS to be defined in CSS, to achieve complete stylability. I'd also like it if we could provide a stable API for theming, meaning that themes won't break (any more than they absolutely have to) for every release like they do now between 0.4.15 and 1.0.0. |
From: Jonathan A. <eag...@gm...> - 2014-03-20 08:18:26
|
I couldnt agree more with you on the stable API for theming. My question and challenge for you is this is there alot of work to go into migrating every aspect of a theme to css? On Thu, Mar 20, 2014 at 9:16 AM, Vesa <di...@nb...> wrote: > On 03/20/2014 10:03 AM, Jonathan Aquilina wrote: > > Have any of these that have been mentioned been filed as enhancement > > requests in the tracker? Also are these set as milestones for 1.1? > > > > No these aren't filed in the tracker yet but I might put them there at > some point, maybe. These are definitely things that are going to be done > after 1.0 is released, not sure about any specific milestones - moving > things to CSS is more of an ongoing thing, which I've already made a > very small start in by making the pattern colours and palette be defined > in the CSS. > > Ideally I'd like every colour and graphic in LMMS to be defined in CSS, > to achieve complete stylability. I'd also like it if we could provide a > stable API for theming, meaning that themes won't break (any more than > they absolutely have to) for every release like they do now between > 0.4.15 and 1.0.0. > > > -- Jonathan Aquilina |
From: Vesa <di...@nb...> - 2014-03-20 08:31:50
|
On 03/20/2014 10:17 AM, Jonathan Aquilina wrote: > I couldnt agree more with you on the stable API for theming. My > question and challenge for you is this is there alot of work to go > into migrating every aspect of a theme to css? > Mostly it's just finding every paintevent in the code, adding qproperties in the classes (or alternatively, figuring out how to use the already existing CSS properties, like color, background etc.), modifying the paintevents to read colours etc. from the CSS. |
From: Jonathan A. <eag...@gm...> - 2014-03-20 08:34:20
|
You mention finding the code. If you are on linux you could probably grep what you want to find in a particular code base if you know what you are looking for. On Thu, Mar 20, 2014 at 9:31 AM, Vesa <di...@nb...> wrote: > On 03/20/2014 10:17 AM, Jonathan Aquilina wrote: > > I couldnt agree more with you on the stable API for theming. My > > question and challenge for you is this is there alot of work to go > > into migrating every aspect of a theme to css? > > > > Mostly it's just finding every paintevent in the code, adding > qproperties in the classes (or alternatively, figuring out how to use > the already existing CSS properties, like color, background etc.), > modifying the paintevents to read colours etc. from the CSS. > -- Jonathan Aquilina |
From: Vesa <di...@nb...> - 2014-03-20 09:25:33
|
On 03/20/2014 10:33 AM, Jonathan Aquilina wrote: > You mention finding the code. If you are on linux you could probably > grep what you want to find in a particular code base if you know what > you are looking for. > Eh, no need for that really. It's easy to just go through all the GUI code, it's pretty well organized. |
From: Johannes L. <joh...@ma...> - 2014-04-05 09:45:07
|
Hey, currently, I'm about to implement this for the knob class. One question: should the knob number have a default value, or should we enforce the programmer to always choose one in qt designer? I think the last one would be more relaxing for programmers... If we do not use default values, should we smash a qFatal() if the programmer forgot to set one in qtcreator/code? Am Sonntag, 9. Februar 2014, 18:39:54 schrieb Tobias Doerffel: > Yes, it'd be a good thing to have all of our widgets available in Qt > Designer so we can replace lots of code with code that is generated > from the UI files. Do you have ambitions for implementing this, you're > welcome to do so :-) > > However I disagree about the specializations. Properties like "number > of digits" etc. should be made real properties (Q_PROPERTY) so they > eventually can be changed inside the Qt Designer. |
From: Vesa <di...@nb...> - 2014-04-05 09:58:47
|
On 04/05/2014 12:44 PM, Johannes Lorenz wrote: > Hey, > > currently, I'm about to implement this for the knob class. One question: > should the knob number have a default value, or should we enforce the > programmer to always choose one in qt designer? I think the last one would be > more relaxing for programmers... > > If we do not use default values, should we smash a qFatal() if the programmer > forgot to set one in qtcreator/code? > Set the default value at 1, the "standard knob", which is the most commonly used in LMMS - or "knobBright_26" if you use the enum names. Note that there are likely going to be more knob types in the future... Note also that I was going to put some GUI colour things in qproperties, as part of the "making things stylable" thing. The knob class needs "lineColor" and "arcColor" qproperties, for defining the line/arc colors for the "regular" knobs. Since you're editing the class, you could add these while you're at it... they don't need to be effective yet, I can add the GUI code to utilize them later. |