Hi,
try using m_outerColor.isValid() instead. It should return false if
m_outerColor was default-constructed but not initialized explicitely.
Thanks
Toby
--
Put Bad Developers to Shame
Dominate Development with Jenkins
I just wanted to de-pointerize "m_outerColor", but I hit this code:
if( m_outerColor )
{
QRadialGradient gradient( centerPoint(), outerRadius()
);
gradient.setColorAt(0.4, _p->pen().brush().color() );
On 04/06/2014 11:51 PM, Tobias Doerffel wrote:
> I think messing with pointers always should be avoided as often as
> possible. In this specific case, it IMHO adds no value. Using pointers
> here increases code complexity and makes things more crash-prone.
> QColor is a very light-weight class (bas
I think messing with pointers always should be avoided as often as
possible. In this specific case, it IMHO adds no value. Using pointers
here increases code complexity and makes things more crash-prone.
QColor is a very light-weight class (basically it's just an
enumeration and a union of 5 16-bit
On 04/06/2014 11:12 PM, Tobias Doerffel wrote:
> 2014-04-05 13:44 GMT+02:00 Vesa :
>>> QColor lineColor() const;
>>> void setlineColor( const QColor & _c );
>>> ...
>>> QColor * m_lineColor; //!< unused yet
>>> ...
>>> Q_PROPERTY(QColor lineColor READ lineColor WRITE setline
2014-04-05 13:44 GMT+02:00 Vesa :
>> QColor lineColor() const;
>> void setlineColor( const QColor & _c );
>> ...
>> QColor * m_lineColor; //!< unused yet
>> ...
>> Q_PROPERTY(QColor lineColor READ lineColor WRITE setlineColor)
>>
>> So this is the same as for outerColor. Is
Also, about the knob types: If you register the knobtype enum with
Q_ENUMS() then the knobtype enum can be used in the qproperty. Then the
enum values can be used as strings in the property set function.
Might be easier to use that way in QtDesigner or whatever...
http://qt-project.org/doc/qt-4.8
On 04/05/2014 02:33 PM, Johannes Lorenz wrote:
>> 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.
> Thanks. The question is also valid for other widgets:
>
> (a) lcd_spinbox (number of digits)
> (b) led_ch
> 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.
Thanks. The question is also valid for other widgets:
(a) lcd_spinbox (number of digits)
(b) led_checkbox (text right to the checkbox)
Would you also sug
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 relaxi
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, sh
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
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 wrote:
> On 03/20/2014 10:17 AM, Jonathan Aquilina wrote:
> > I couldnt agree more with you on th
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
q
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 wrote:
> On 03/20/2014 10:03 AM, Jonathan Aquilina wrote:
> > Have any of these
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 definit
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 wrote:
> On 03/19/2014 06:37 PM, Johannes Lorenz wrote:
> > Hi again,
> >
> > so you'd suggest to simply add
> >
> >
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
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 ide
>
> 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
> 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 qmak
> 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 ju
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.
--
Lear
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 w
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 ex
Yes, that would be the most straight forward design. Thanks in advance!
Toby
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications.
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
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 paramet
> 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
2014-03-16 15:06 GMT+01:00 Johannes Lorenz :
> 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 et
> 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 cou
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
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
> use
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 typ
34 matches
Mail list logo
