I disagree, this adds a long term support burden, complication and wastes
resources when a more simple solution exists. Keep in mind this is only for
testing. We can use compile time configure flags, then a developer when
compiling sfw can then chose which backend he wants.
Also, testing of t
I made the change here https://codereview.qt-project.org/#change,25091
As suggested, I simplified the enum like that.
enum QService::InterProcessMethod {
Native,
LocalSocket,
}
The only thinks that changes are 2 new constructors
QServiceManager(QService::Scope scope, QServic
> From: "jan-arve.saet...@nokia.com"
>ext Corentin Jabot wrote on 2012-05-02:
>
>>
>> bool
>> QServiceManager::setInterProcessMethod(QService::InterProcessMethod);
>>
>> enum QService::InterProcessMethod {
>> Native,
>> LocalSocket,
>> DBus
>> }
>>
>Wouldn't
>
On Wed, May 02, 2012 at 09:00:37AM +, lars.kn...@nokia.com wrote:
> [...] In total I am more leaning towards reverting it, but would
> also be ok to add Oliviers patch. [...]
>From my perspective either is fine, and I don't have any
particular preference.
Regards,
Andre'
___
This sounds like something we should have.
e.g. QTPLAYGROUND as the project (instead of QTBUG) and one or more components
for each playground project.
Does anyone from the JIRA experts group have a comment?
--
> -Original Message-
> From: development-bounces+shane.kearns=accenture@q
Hello all.
I am also interested in this question.
Say please, where and how can get a bug-tracker for projects from a playground?
Is this possible?
Without such features are very hard to make a contribution to the development.
For example, users are forced to send bugs to the forums (which are
I believe changing the string in Q_DECLARE_INTERFACE is binary incompatible but
fully source compatible.
The string gets embedded in moc generated code as well as .o files on the
caller side when doing a q_object_cast to an interface.
At run-time they must match for the cast to succeed.
Simon
The task https://bugreports.qt-project.org/browse/QTBUG-23273 is assigned to
me and requests that we stop using the "com.trolltech" reverse domain in our
interfaces.
I have not a single clue about how Q_DECLARE_INTERFACE works or where it's
used. I will happily do the search and replace, but I nee
Context: if you're reading this out of context, here's the context: we're
changing the default encoding for QString's methods that deal with 8-bit data.
In Qt 3 and 4, it was a variable encoding and defaulted to Latin 1 (set with
QTextCodec::setCodecsForCStrings). In Qt 5, the variability was remov
ext Corentin Jabot wrote on 2012-05-02:
>
> bool
> QServiceManager::setInterProcessMethod(QService::InterProcessMethod);
>
> enum QService::InterProcessMethod {
>Native,
>LocalSocket,
>DBus
> }
>
Wouldn't
enum QService::InterProcessMethod {
Nativ
On quarta-feira, 2 de maio de 2012 13.59.02, Corentin Jabot wrote:
> The default value would be Native, corresponding on DBus where DBus is
> available.
>
> The library overhead should be minimal and this will not add
> additional dependency anywhere.
> It will also made easier the add of potential
Hi.
I'm working with QtServiceFramework for remote services on Linux. It
use QDbus as a backend and it's great.
But I find more convenient to use the QLocalSocket implementation for
development and debugging purposes since it's easier to deploy and
test - the service process has it output redirect
On Apr 28, 2012, at 12:25 PM, ext Alberto Mardegan wrote:
> Hi all!
> I really miss a QML version of QFileDialog. There currently isn't a Qt
> Component for choosing a file or a directory from the filesystem, and I
> think we should fill this gap ASAP. There's a bug I created to keep
> track of
On Wednesday, May 02, 2012 11:57:48 Thiago Macieira wrote:
> On quarta-feira, 2 de maio de 2012 10.21.36, Giuseppe D'Angelo wrote:
> > In a related patch I suggested something like
> >
> > int QRegExp::foo() const
> > {
> >
> > QRegExp copy = *this;
> > return copy.foo();
> >
> > }
> >
> >
On 5/2/12 11:57 AM, "ext Thiago Macieira"
wrote:
>On quarta-feira, 2 de maio de 2012 10.21.36, Giuseppe D'Angelo wrote:
>> In a related patch I suggested something like
>>
>> int QRegExp::foo() const
>> {
>> QRegExp copy = *this;
>> return copy.foo();
>> }
>>
>> which although being source
Hi all. I was implementing some platform-specific features for my program -
"open with list" and "move to trash" functionality for 3 OSes - win, mac, linux.
Under Linux, i had to use desktop-files, which are described in freedesktop.org
specification.
I encounter with a problem that i can't read
On quarta-feira, 2 de maio de 2012 10.21.36, Giuseppe D'Angelo wrote:
> In a related patch I suggested something like
>
> int QRegExp::foo() const
> {
> QRegExp copy = *this;
> return copy.foo();
> }
>
> which although being source compatible, is behaviour incompatible
> (QRegExp users do expec
casper.vandonde...@nokia.com said:
> >
> >In the meantime we can/should think about doing another alpha. Thiago
> >proposed that one option here could be to simply release the first source
> >package that works on all platforms as the second alpha. Like that we
> >don't
> >use any additional resou
On 2 May 2012 09:48, Thiago Macieira wrote:
> Given the negative reaction here and on Gerrit, I'm wondering if we should
> revert it.
>
> In fact, for the simple fact that the SIC change wasn't discussed here before
> it went in (my bad, sorry for that), it deserves to be reverted.
>
> What do you
On Wed, May 02, 2012 at 09:00:37AM +, ext lars.kn...@nokia.com wrote:
> Reverting it completely would fit in with saying that QRegExp is done
> and close to being deprecated, so there's no benefit in SC breakages
> in these classes.
>
otoh, the change has the potential to reveal subtle threadi
On Wed, May 2, 2012 at 10:48 AM, Thiago Macieira
wrote:
> Given the negative reaction here and on Gerrit, I'm wondering if we should
> revert it.
I think that one is probably going to cause a reasonable amount of
pain - from looking at the creator diff - so I do think that doing
something about i
On 5/2/12 10:48 AM, "ext Thiago Macieira"
wrote:
>Given the negative reaction here and on Gerrit, I'm wondering if we
>should
>revert it.
>
>In fact, for the simple fact that the SIC change wasn't discussed here
>before
>it went in (my bad, sorry for that), it deserves to be reverted.
My bad a
Given the negative reaction here and on Gerrit, I'm wondering if we should
revert it.
In fact, for the simple fact that the SIC change wasn't discussed here before
it went in (my bad, sorry for that), it deserves to be reverted.
What do you think?
Another option is what Olivier has proposed:
On 30 Apr, 2012, at 22:13 , ext Thiago Macieira wrote:
>>> Still, I meant my own task: since these are API-level considerations, I
>>> was and still am under the impression that they are needed by beta time.
>>
>> I'm not sure what you mean by this.
>
> This is what answers the "now" part. The c
On 30 Apr, 2012, at 21:07 , ext bradley.hug...@nokia.com wrote:
> No, I'm not rebuilding just the platform plugin(s), this has to do with all
> of qtbase (mostly). I will double check this though, since things are
> constantly changing everyday. The situation may have improved (but that
> doesn'
>
>In the meantime we can/should think about doing another alpha. Thiago
>proposed that one option here could be to simply release the first source
>package that works on all platforms as the second alpha. Like that we
>don't
>use any additional resources and time on creating that second alpha.
>
26 matches
Mail list logo
