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
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 easy.
On Sun, Dec 7, 2014 at 10:33 AM, Alejandro Exojo s...@badopi.org 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
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
El Sunday 07 December 2014, Luciano Montanaro escribió:
On Sun, Dec 7, 2014 at 10:33 AM, Alejandro Exojo s...@badopi.org 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,
On Sun, Dec 7, 2014 at 10:29 PM, Alejandro Exojo s...@badopi.org wrote:
El Sunday 07 December 2014, Luciano Montanaro escribió:
On Sun, Dec 7, 2014 at 10:33 AM, Alejandro Exojo s...@badopi.org wrote:
That's the opposite of what most people are trying to do.
If the overhead is negligible,
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
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 users.giulie...@gmail.com wrote:
I think the idea to include different project files for defining which
On 5 Dec 2014, at 2:38 am, Alejandro Exojo s...@badopi.org 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
On Dec 6, 2014 8:30 PM, Lorn Potter lorn.pot...@jolla.com wrote:
On 5 Dec 2014, at 2:38 am, Alejandro Exojo s...@badopi.org 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
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.
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
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
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 -
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..)
best,
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
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
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
18 matches
Mail list logo
