On Sun, Dec 7, 2014 at 10:29 PM, Alejandro Exojo wrote:
> El Sunday 07 December 2014, Luciano Montanaro escribió:
>> On Sun, Dec 7, 2014 at 10:33 AM, Alejandro Exojo wrote:
>> > That's the opposite of what most people are trying to do.
>> >
>> > If the overhead is negligible, you may not care muc
El Sunday 07 December 2014, Luciano Montanaro escribió:
> On Sun, Dec 7, 2014 at 10:33 AM, Alejandro Exojo wrote:
> > That's the opposite of what most people are trying to do.
> >
> > If the overhead is negligible, you may not care much of shipping all the
> > assets in one binary package, of whi
On 12/7/2014 11:33 AM, Alejandro Exojo wrote:
However, the main thing that motivated me to dig into the issue and
send the mail was libsailfishapp. That library is, AFAIK, only
relevant on Sailfish, and also requires one to add special code in
main(). That can't be done at
There, you said i
On Sun, Dec 7, 2014 at 10:33 AM, Alejandro Exojo wrote:
> That's the opposite of what most people are trying to do.
>
> If the overhead is negligible, you may not care much of shipping all the
> assets in one binary package, of which the user will only see a part, but
> other applications might p
El Saturday 06 December 2014, Lorn Potter escribió:
> Tizen also and their own branch even.
>
> There are also quite a few other devices that have their own mkspec, so
> there is precedence for supporting a sailfish/jolla platform mkspec.
Oh, true, I forgot them.
> (...)
> Well, this one is e
El Saturday 06 December 2014, Luciano Montanaro escribió:
> Actually, no, you want to detect features at runtime, not at build time.
That's the opposite of what most people are trying to do.
If the overhead is negligible, you may not care much of shipping all the
assets in one binary package, of
On Dec 6, 2014 8:30 PM, "Lorn Potter" wrote:
>
>
> On 5 Dec 2014, at 2:38 am, Alejandro Exojo wrote:
>
> >
> > Then I searched a bit in the branch of the mer-qt/qtbase repo. I see
you don't
> > use any mkspec for SailfishOS or Jolla, right? That's where I thought
you
> > might have it, and where
On 5 Dec 2014, at 2:38 am, Alejandro Exojo wrote:
>
> Then I searched a bit in the branch of the mer-qt/qtbase repo. I see you
> don't
> use any mkspec for SailfishOS or Jolla, right? That's where I thought you
> might have it, and where I think it could be. Blackberry sets there the
> QMAK
At least my C++ includes have the same names.
The difference is the implementation but all implementations adhere to the same
interface.
Cheers,
On Dec 6, 2014 2:46 PM, Tone Kastlunger wrote:
I think the idea to include different project files for defining which platform
to compile on is a co
I think the idea to include different project files for defining which
platform to compile on is a correct workaround;
however, this forces you to include files with different names depending on
which system you want to compile on,
which means you need to have specific .pro files; which is ok, of c
On Thu, Dec 04, 2014 at 10:12:37PM +0200, Tone Kastlunger wrote:
> Anything that makes a developer's life easier is absolutely welcomed
> I'd say.
> I must admit to have cursed many times over such a feature not being
> present (either as macro OR as selectior that win32:unix:mac: are..)
> bes
If there is any difference from running qmake "raw", from the command
line, and
from QtCreator, something is amiss (kinda kills the "Integrated" part of
the IDE
approach). At the very least, it should flash a warning that you are
doing something
it cannot comply with (whatever the reasoning - t
El Friday 05 December 2014, Franck Routier (perso) escribió:
> There is probably an interesting paper here
> https://fruct.org/publications/fruct11/files/Par.pdf
> (but I did not take the time to dig into yet...)
That looks a bit dated (Symbian! :) ). From a quick look, everything could be
done
El Friday 05 December 2014, Attila Csipa escribió:
> I would rather have packagesExist fixed (I also ran into this one, see
> https://bugreports.qt-project.org/browse/QTBUG-42499 :)
Didn't know that. I found this instead:
https://bugreports.qt-project.org/browse/QTCREATORBUG-11510
This isn't go
There is probably an interesting paper here
https://fruct.org/publications/fruct11/files/Par.pdf
(but I did not take the time to dig into yet...)
Franck
Le 04/12/2014 17:38, Alejandro Exojo a écrit :
Hi.
I've asked this a couple of times on IRC, but I haven't found a fully
satisfying answer.
Hi,
I would rather have packagesExist fixed (I also ran into this one, see
https://bugreports.qt-project.org/browse/QTBUG-42499 :)
A (philosophical?) problem is that from Qt's perspective, Sailfish is
not really an
OS - that would be Linux - but merely a distro. Once you start down this
path
Anything that makes a developer's life easier is absolutely welcomed I'd
say.
I must admit to have cursed many times over such a feature not being
present (either as macro OR as selectior that win32:unix:mac: are..)
best,
tortoisedoc
On Thu, Dec 4, 2014 at 6:38 PM, Alejandro Exojo wrote:
> Hi.
Hi.
I've asked this a couple of times on IRC, but I haven't found a fully
satisfying answer. I want to see SailfishOS as any other OS/platform is
featured in Qt: by having some qmake support to detect wheter I'm compiling
for SailfishOS or not.
Once that is done, having a Q_OS_SAILFISH prepro
18 matches
Mail list logo