On Monday 01 December 2014 12:38:02 Jędrzej Nowacki wrote:
> Hi,
>
> Personally, I think Q_OBJECT should not change access level and so
> Q_GADGET.
I agree.
But it's not possible since we have to declare public and private stuff, so we
must change the access.
So unless you find a way to decl
On Friday 28 of November 2014 13:55:44 Simon Hausmann wrote:
> On Friday 28. November 2014 12.41.47 Olivier Goffart wrote:
> > On Friday 28 November 2014 12:19:45 Simon Hausmann wrote:
> > > Hi,
> > >
> > > Monsieur Goffart did awesome work in the dev branch on allowing
> > > structures
> > > with
On 2014-11-28, Simon Hausmann wrote:
> I feel that Q_GADGET has its primary use with structures and the default
> access level for those is public. I find it awkward that you currently have
> to
> write:
I have a lot of code in the wild using classes and Q_GADGET.
Having Q_GADGET not change
On 28/11/2014 16:13, Gunnar Roth wrote:
> Hi Simon
>
>> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event
>> that somebody
>> a) produces a DLL and cares about binary compatibility
>
> Why do you think that is unlikely?
>
> Actually right now i depend on that. I ge
Hi Simon
>2) On paper it breaks binary compatibility with MSVC, in the unlikely event
>that somebody
>a) produces a DLL and cares about binary compatibility
Why do you think that is unlikely?
Actually right now i depend on that. I get stuff build against qt 5.2.1 dlls
and use that stuff an
On Friday 28. November 2014 12.41.47 Olivier Goffart wrote:
> On Friday 28 November 2014 12:19:45 Simon Hausmann wrote:
> > Hi,
> >
> > Monsieur Goffart did awesome work in the dev branch on allowing structures
> > with Q_GADGET to have properties and invokable methods. This brings the
> > macro t
On Friday 28. November 2014 13.36.56 Al-Khanji Louai wrote:
> Out of the box, C++ makes class member declarations private. I quite
> strongly feel that changing that behavior in a macro is not what the user
> expects. So for me at least the "better API" box is not being checked here
> - I quite reg
Out of the box, C++ makes class member declarations private. I quite strongly
feel that changing that behavior in a macro is not what the user expects. So
for me at least the "better API" box is not being checked here - I quite
regularly declare private variables under Q_OBJECT and have done so
On Friday 28 November 2014 12:41:47 Olivier Goffart wrote:
> On Friday 28 November 2014 12:19:45 Simon Hausmann wrote:
> > Hi,
> >
> > Monsieur Goffart did awesome work in the dev branch on allowing structures
> > with Q_GADGET to have properties and invokable methods. This brings the
> > macro to
On Friday 28 November 2014 12:19:45 Simon Hausmann wrote:
> Hi,
>
> Monsieur Goffart did awesome work in the dev branch on allowing structures
> with Q_GADGET to have properties and invokable methods. This brings the
> macro to a much wider audience and I'd like to use this opportunity to
> propos
On 28 Nov 2014, at 12:19, Simon Hausmann
wrote:
> Hi,
>
> Monsieur Goffart did awesome work in the dev branch on allowing structures
> with
> Q_GADGET to have properties and invokable methods. This brings the macro to a
> much wider audience and I'd like to use this opportunity to propose a
ject.org
> Subject: [Development] changing Q_GADGET
>
> Hi,
>
> Monsieur Goffart did awesome work in the dev branch on allowing
> structures with
> Q_GADGET to have properties and invokable methods. This brings the macro
> to a
> much wider audience and I'd like to use
Hi,
Monsieur Goffart did awesome work in the dev branch on allowing structures with
Q_GADGET to have properties and invokable methods. This brings the macro to a
much wider audience and I'd like to use this opportunity to propose a slight
change to it that may be controversial:
The macros Q_OB
13 matches
Mail list logo
