Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-07 Thread Luciano Montanaro 
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 much of shipping all the
>> > assets in one binary package, of which the user will only see a part, but
>> > other applications might prefer to save some space if they contain many
>> > assets.
>>
>> The problem is that this model does not scale. Now there is one device
>> using SailfishOS, next June there will be two...
>> Hopefully there will be more in one year.
>>
>> So you want to make one build for each model that will use SailfishOS
>> in the future?
>
> I did nowhere say that. I say that MAYBE you want to trim some assets if you
> have OS specific assets (and you have a non-negligible gain). And for that you
> need to know the OS you are building for. As I explained, other systems have
> built in support in Qt for knowing the OS.
>

Well, os specific, all right. But I understood you wanted a different
configuration on tablet vs phone, and to that I would object.
But you do not need a Qt .config file for that -- and when you build
Qt, Sailfish is just a Linux target.

>> I think Jolla hopes to license the OS to other vendors. If they
>> succeed, optimization s targeted to single devices will not be
>> practical.
>>
>> The best option is to build the asset in a scalable format (or ship it
>> at high res) and then render it at install time...
>> Like what has been proposed for the icon scaling.
>
> Exactly what I said: "Other features like screen size, language, etc. Of
> course you want to do it at runtime."
>
>> > 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 runtime (well, you could do it I think, but you really
>> > don't want to, given that you already have to set a special binary name,
>> > for example, and it complicates things for no reason).
>>
>> Well, I think the easiest thing to do is do out-of source builds, and
>> since the target configuration
>>
>> qmake -config sailfishos
>> qmake -config blackberry
>
> I don't follow you here. What's that qmake flag?

I think it is not documented, but it allows you to pass a custom
configuration to the qmake.
You could also use

qmake CONFIG+=sailfishos, for example.
Then in the .pro file you put specific files and rules in specific sections

sailfishos {
...
}
ubuntu {
}
linux {
}
blackberry {
}
...

sections. Note that the linux rule is predefined, and would apply in
both sailfishos and uuntu build.

If you use Qtcreator, You can modify the target build configuration so
that the qmake step includes the -config for architecture you want to
build for.


>
>> Then if you want to have different assets, you can do this as well...
>> But it makes no sense to ask for a generic way to do that.
>> In the end, the Qt platform for sailfish os is indeed simply Linux, or
>> if you want Linux+Wayland.
>> The rest of the dependencies should be checked package for package:
>> So on linux, check if there is libsailfishapp, and build the sailfish
>> version. Check for... Mir, and build for Ubuntu.
>> Or build for a desktop Linux if you do not find mobile specific libraries.
>
> I also explained the problem with the tooling that a library check has. And
> that is not only about the library.
>

All right, but then the proper solution would bet to fix the check,
not shipping more qt .config files.

> But well, if so many people disagree, I'll just give up. Only one more thing
> so I don't need to add more traffic to the mailing list:
>
>
> El Sunday 07 December 2014, Attila Csipa escribió:
>> 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 it yourself - if what you want is to detect a library,
>> then that's what
>> you should be doing.
>
> I did not say that. You even quoted what I said. Read it again please. :)
>

Well, even in this case, the trick above would work.

I just wish there were CMake templates available - qmake is badly
documented, and it quickly get messy if the project grows.

> --
> Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
> http://barnacity.net/ | http://disperso.net
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org



-- 
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams
_

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-07 Thread Alejandro Exojo 
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 which the user will only see a part, but
> > other applications might prefer to save some space if they contain many
> > assets.
> 
> The problem is that this model does not scale. Now there is one device
> using SailfishOS, next June there will be two...
> Hopefully there will be more in one year.
> 
> So you want to make one build for each model that will use SailfishOS
> in the future?

I did nowhere say that. I say that MAYBE you want to trim some assets if you 
have OS specific assets (and you have a non-negligible gain). And for that you 
need to know the OS you are building for. As I explained, other systems have 
built in support in Qt for knowing the OS.

> I think Jolla hopes to license the OS to other vendors. If they
> succeed, optimization s targeted to single devices will not be
> practical.
> 
> The best option is to build the asset in a scalable format (or ship it
> at high res) and then render it at install time...
> Like what has been proposed for the icon scaling.

Exactly what I said: "Other features like screen size, language, etc. Of 
course you want to do it at runtime."

> > 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 runtime (well, you could do it I think, but you really
> > don't want to, given that you already have to set a special binary name,
> > for example, and it complicates things for no reason).
> 
> Well, I think the easiest thing to do is do out-of source builds, and
> since the target configuration
> 
> qmake -config sailfishos
> qmake -config blackberry

I don't follow you here. What's that qmake flag?
 
> Then if you want to have different assets, you can do this as well...
> But it makes no sense to ask for a generic way to do that.
> In the end, the Qt platform for sailfish os is indeed simply Linux, or
> if you want Linux+Wayland.
> The rest of the dependencies should be checked package for package:
> So on linux, check if there is libsailfishapp, and build the sailfish
> version. Check for... Mir, and build for Ubuntu.
> Or build for a desktop Linux if you do not find mobile specific libraries.

I also explained the problem with the tooling that a library check has. And 
that is not only about the library.

But well, if so many people disagree, I'll just give up. Only one more thing 
so I don't need to add more traffic to the mailing list:


El Sunday 07 December 2014, Attila Csipa escribió:
> 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 it yourself - if what you want is to detect a library, 
> then that's what
> you should be doing.

I did not say that. You even quoted what I said. Read it again please. :)

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-07 Thread Attila Csipa 


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 it yourself - if what you want is to detect a library, 
then that's what
you should be doing. That also goes for the includes, linker flags, etc 
- that's why people
invented pkgconfig and such. This way you avoid the problems of "what if 
not all
Sailfish devices have that lib in the future (or their API changes)" and 
similar.


The same would apply for, say, Ubuntu - if I want to write lenses/scopes 
for it, then I

should be checking for libunity, and not a Q_OS_UBUNTU.

Best regards,
Attila
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-07 Thread Luciano Montanaro 
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 prefer to save some space if they contain many
> assets.
>

The problem is that this model does not scale. Now there is one device
using SailfishOS, next June there will be two...
Hopefully there will be more in one year.

So you want to make one build for each model that will use SailfishOS
in the future?
I think Jolla hopes to license the OS to other vendors. If they
succeed, optimization s targeted to single devices will not be
practical.

The best option is to build the asset in a scalable format (or ship it
at high res) and then render it at install time...
Like what has been proposed for the icon scaling.

> 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
> runtime (well, you could do it I think, but you really don't want to, given
> that you already have to set a special binary name, for example, and it
> complicates things for no reason).
>

Well, I think the easiest thing to do is do out-of source builds, and
since the target configuration

qmake -config sailfishos
qmake -config blackberry

etc.

Then if you want to have different assets, you can do this as well...
But it makes no sense to ask for a generic way to do that.
In the end, the Qt platform for sailfish os is indeed simply Linux, or
if you want Linux+Wayland.
The rest of the dependencies should be checked package for package:
So on linux, check if there is libsailfishapp, and build the sailfish version.
Check for... Mir, and build for Ubuntu.
Or build for a desktop Linux if you do not find mobile specific libraries.



> Other features like screen size, language, etc. Of course you want to do it at
> runtime. But note that the default +android, +blackberry directories that are 
> different anyway, do something like

for the sailfish
> QFileSelector knows about should work out of the box with plain Qt. See for
> example:
>
> https://github.com/qtproject/qtbase/blob/8ee7aa78afd3d3dee6e333953d51aa72cb227441/src/corelib/io/qfileselector.cpp#L349-386
>
> This can still be added to the QQmlFileSelector of the engine through
> libsailfishapp, so I think I'll send a pull request anyways.
>
> --
> Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
> http://barnacity.net/ | http://disperso.net
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org



-- 
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-07 Thread Alejandro Exojo 
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. Tablet isn't arm based. :)
> 
> So far, I don't think Jolla has actually needed it's own mkspec, and using
> the defaults is working ok.
> 
> I'm not against the idea and would probably +2 any qt-project MR's, but
> then Jolla would have to use it in their builds.

That's what I wanted to know. :)

If there is not interest, well, I'll forget it and maybe propose a pull 
request for QFileSelector in libsailfishapp as I mentioned in the other mail.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-07 Thread Alejandro Exojo 
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 which the user will only see a part, but 
other applications might prefer to save some space if they contain many 
assets.

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 
runtime (well, you could do it I think, but you really don't want to, given 
that you already have to set a special binary name, for example, and it 
complicates things for no reason).

Other features like screen size, language, etc. Of course you want to do it at 
runtime. But note that the default +android, +blackberry directories that 
QFileSelector knows about should work out of the box with plain Qt. See for 
example:

https://github.com/qtproject/qtbase/blob/8ee7aa78afd3d3dee6e333953d51aa72cb227441/src/corelib/io/qfileselector.cpp#L349-386

This can still be added to the QQmlFileSelector of the engine through 
libsailfishapp, so I think I'll send a pull request anyways.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-06 Thread Luciano Montanaro 
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 I think it could be. Blackberry sets there the
> > QMAKE_PLATFORM and Q_OS_BLACKBERRY.
>
> 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.
>
>
> ~/depot/qt/qt5/qtbase/mkspecs/devices $ [tizen]> ls
> blackberry-playbook-armle-v7-qcc/   linux-archos-gen8-g++/
  linux-beagleboard-g++/
linux-mipsel-broadcom-97425-g++/linux-snowball-g++/
> blackberry-playbook-armv7le-qcc/linux-arm-amlogic-8726M-g++/
  linux-g++-tizen/linux-rasp-pi-g++/
  linux-tegra2-g++/
> blackberry-playbook-x86-qcc/linux-arm-hisilicon-hix5hd2-g++/
  linux-imx53qsb-g++/ linux-sh4-stmicro-ST7108-g++/
> common/ linux-arm-trident-pnx8473-g++/
  linux-imx6-g++/ linux-sh4-stmicro-ST7540-g++/
>
>
>
> >
> > Yes, yes. I know there is a solution: pass a parameter to the qmake
> > invocation. Store the invocation flag on the RPM packaging for final
> > deployment, and maybe a .pro.shared file for development. That's what
Puzzle
> > Master has now too. Still I think there is some value in having this
sorted
> > out in a more general way, specially given that you'll want people to
also
> > distinguish a build for the Jolla phone or the Jolla tablet.
> >
> Well, this one is easy. Tablet isn't arm based. :)
>

Actually, no, you want to detect features at runtime, not at build time.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-06 Thread Lorn Potter 

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 
> QMAKE_PLATFORM and Q_OS_BLACKBERRY.

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.
 

~/depot/qt/qt5/qtbase/mkspecs/devices $ [tizen]> ls
blackberry-playbook-armle-v7-qcc/   linux-archos-gen8-g++/  
linux-beagleboard-g++/  linux-mipsel-broadcom-97425-g++/
linux-snowball-g++/
blackberry-playbook-armv7le-qcc/linux-arm-amlogic-8726M-g++/
linux-g++-tizen/linux-rasp-pi-g++/  
linux-tegra2-g++/
blackberry-playbook-x86-qcc/linux-arm-hisilicon-hix5hd2-g++/
linux-imx53qsb-g++/ linux-sh4-stmicro-ST7108-g++/
common/ linux-arm-trident-pnx8473-g++/  
linux-imx6-g++/ linux-sh4-stmicro-ST7540-g++/



> 
> Yes, yes. I know there is a solution: pass a parameter to the qmake 
> invocation. Store the invocation flag on the RPM packaging for final 
> deployment, and maybe a .pro.shared file for development. That's what Puzzle 
> Master has now too. Still I think there is some value in having this sorted 
> out in a more general way, specially given that you'll want people to also 
> distinguish a build for the Jolla phone or the Jolla tablet.
> 
Well, this one is easy. Tablet isn't arm based. :)

So far, I don't think Jolla has actually needed it's own mkspec, and using the 
defaults is working ok.


I'm not against the idea and would probably +2 any qt-project MR's, but then 
Jolla would have to use it in their builds.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-06 Thread Mohammed Hassan 
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 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 course, but 
kind of just pushes the problem a bit further away, and does not make it 
disappear.



On Fri, Dec 5, 2014 at 4:03 PM, Mohammed Hassan 
mailto:mohammed.has...@jollamobile.com>> wrote:
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,
>  tortoisedoc

I have an application which I build for Harmattan, SailfishOS and Android.

I have a common C++ codebase (95% common maybe), A QML abstraction and
platform specific QML ui bits.
I also have a separate .pro file per platform.
Each .pro file adds an OS specific macro.
harmattan.pro adds -DHARMATTAN=1
sailfish.pro adds -DSAILFISH=1
android.pro adds -DANDROID=1

Here is an example:
https://gitorious.org/quran/quran/source/sailfish/sailfish.pro
https://gitorious.org/quran/quran/source/n9/n9.pro

Works fine for me.

Cheers,
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to 
devel-unsubscr...@lists.sailfishos.org

___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-06 Thread Tone Kastlunger 
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 course,
but kind of just pushes the problem a bit further away, and does not make
it disappear.



On Fri, Dec 5, 2014 at 4:03 PM, Mohammed Hassan <
mohammed.has...@jollamobile.com> wrote:

> 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,
> >  tortoisedoc
>
> I have an application which I build for Harmattan, SailfishOS and Android.
>
> I have a common C++ codebase (95% common maybe), A QML abstraction and
> platform specific QML ui bits.
> I also have a separate .pro file per platform.
> Each .pro file adds an OS specific macro.
> harmattan.pro adds -DHARMATTAN=1
> sailfish.pro adds -DSAILFISH=1
> android.pro adds -DANDROID=1
>
> Here is an example:
> https://gitorious.org/quran/quran/source/sailfish/sailfish.pro
> https://gitorious.org/quran/quran/source/n9/n9.pro
>
> Works fine for me.
>
> Cheers,
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-05 Thread Mohammed Hassan 
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,
>  tortoisedoc

I have an application which I build for Harmattan, SailfishOS and Android.

I have a common C++ codebase (95% common maybe), A QML abstraction and
platform specific QML ui bits.
I also have a separate .pro file per platform.
Each .pro file adds an OS specific macro.
harmattan.pro adds -DHARMATTAN=1
sailfish.pro adds -DSAILFISH=1
android.pro adds -DANDROID=1

Here is an example:
https://gitorious.org/quran/quran/source/sailfish/sailfish.pro
https://gitorious.org/quran/quran/source/n9/n9.pro

Works fine for me.

Cheers,
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-05 Thread Attila Csipa 
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 - technical or policy).

Attila

On 12/5/2014 11:05 AM, Alejandro Exojo wrote:

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 going to be fixed because is by design that Creator is not going to
execute things that could have side effects:

 Why the project file evaluation can't run a separate process?
Performance? Thinking how to workaround https://bugreports.qt-
project.org/browse/QTCREATORBUG-11510
 Qt Creator treats packagesExist incorrectly -
https://bugreports.qt-project.org/browse/QTCREATORBUG-11510
 suy: what does your question have to do with that bug report?
 dt|tt: you said in the bug report "packagesExists is implemented via a
$system call. Since we don't want to run arbitrary processes while parsing the
project (...)"
 suy: right, it should be self-evident why we don't want to run
arbitrary processes while parsing a .pro file
 suy: we don't know what side effects there are
 dt|tt: not to me, that's why I'm asking. :)  I'm not a creator
developer. I was thinking if qmake can do it, creator can do it, unless the
trouble is of course that it has to do it again
 suy: not while parsing the project
 suy: that would be insane
 Yes, I though its a security risk. But, well, somebody can still add a
system() call in a pro file and do nasty things when running qmake, isn't it?
 suy: parsing needs to be side effect free
 suy: it's not just a security risk, it's also executing stuff more
often and/or at other times than a regular qmake run would. so lots of fancy
mechanism set up in the .pro are likely to break in that situation.

  

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 of
Q_OS_..., one could argue for Q_OS_DEBIAN and Q_OS_REDHAT, etc. What is
(from a developer's perspective) special about SailfishOS is how it is
different from
other Linuxes, hence the package detection being the "right way".

Yes, I've given it some thought, and is not an easy to draw line. There is
certainly a distinction, but one could defend that such detection has to be
done at runtime instead. For example, a dialog in KDE has a different
OK/Cancel ordering than in GNOME (and different look, etc.). The binary might
be the same, but the application chooses behaviour at runtime.

I thought that Sailfish might be a different than a simple "environment where
the app might be executed" in that it has some platform specific libraries
(libsailfishapp, booster). Also, the fact that Blackberry 10 is treated
different than QNX, so they have the boilerplate set up. I'll see what the
Ubuntu Touch people do.



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-05 Thread Alejandro Exojo 
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 with QFileSelector (supported out of the box by the QML engine since 
5.2).

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-05 Thread Alejandro Exojo 
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 going to be fixed because is by design that Creator is not going to 
execute things that could have side effects:

 Why the project file evaluation can't run a separate process? 
Performance? Thinking how to workaround https://bugreports.qt-
project.org/browse/QTCREATORBUG-11510
 Qt Creator treats packagesExist incorrectly - 
https://bugreports.qt-project.org/browse/QTCREATORBUG-11510
 suy: what does your question have to do with that bug report?
 dt|tt: you said in the bug report "packagesExists is implemented via a 
$system call. Since we don't want to run arbitrary processes while parsing the 
project (...)"
 suy: right, it should be self-evident why we don't want to run 
arbitrary processes while parsing a .pro file
 suy: we don't know what side effects there are
 dt|tt: not to me, that's why I'm asking. :)  I'm not a creator 
developer. I was thinking if qmake can do it, creator can do it, unless the 
trouble is of course that it has to do it again
 suy: not while parsing the project
 suy: that would be insane
 Yes, I though its a security risk. But, well, somebody can still add a 
system() call in a pro file and do nasty things when running qmake, isn't it?
 suy: parsing needs to be side effect free
 suy: it's not just a security risk, it's also executing stuff more 
often and/or at other times than a regular qmake run would. so lots of fancy 
mechanism set up in the .pro are likely to break in that situation.

 
> 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 of
> Q_OS_..., one could argue for Q_OS_DEBIAN and Q_OS_REDHAT, etc. What is
> (from a developer's perspective) special about SailfishOS is how it is 
> different from
> other Linuxes, hence the package detection being the "right way".

Yes, I've given it some thought, and is not an easy to draw line. There is 
certainly a distinction, but one could defend that such detection has to be 
done at runtime instead. For example, a dialog in KDE has a different 
OK/Cancel ordering than in GNOME (and different look, etc.). The binary might 
be the same, but the application chooses behaviour at runtime.

I thought that Sailfish might be a different than a simple "environment where 
the app might be executed" in that it has some platform specific libraries 
(libsailfishapp, booster). Also, the fact that Blackberry 10 is treated 
different than QNX, so they have the boilerplate set up. I'll see what the 
Ubuntu Touch people do.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-05 Thread Franck Routier (perso) 
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. 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 preprocessor macro that can also
choose different paths in C++ and adding support in QFileSelector is trivial.

The big question is: do you want such thing in Qt? If yes, I would gladly do
it myself, since I have some time available and I'm looking for ways to
contribute to Qt, learn, etc.

Rationale:

Right now everyone is baking its own way, with varying degrees of success. ;-)

I looked at it a year ago when I started writing my Sailfish application, and
I was pointed to puzzle-master's sources, where a simple
packagesExist(sailfishapp) did the trick... or so I thought. Since I wasn't
testing the non-Sailfish branch much, I didn't realize Creator always returns
true on this condition (by design: not allowed to fork a process when parsing
.pro files). Seems a petty complaint (who cares about Creator that much? it
works for qmake just fine), but with harbour requiring a "harbour-" prefix in
the name of the executable, Creator might not even be able to start the
application because it doesn't find it if you use a different value for
TARGET.

Lately I've been finding time for the app again and I finally noticed the
problem, so I asked on IRC again. I was pointed at other application, and the
check used was even worse. :-)

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
QMAKE_PLATFORM and Q_OS_BLACKBERRY.

Yes, yes. I know there is a solution: pass a parameter to the qmake
invocation. Store the invocation flag on the RPM packaging for final
deployment, and maybe a .pro.shared file for development. That's what Puzzle
Master has now too. Still I think there is some value in having this sorted
out in a more general way, specially given that you'll want people to also
distinguish a build for the Jolla phone or the Jolla tablet.

Cheers.



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-04 Thread Attila Csipa 

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 of

Q_OS_..., one could argue for Q_OS_DEBIAN and Q_OS_REDHAT, etc. What is
(from a developer's perspective) special about SailfishOS is how it is 
different from

other Linuxes, hence the package detection being the "right way".

Best regards,
Attila

On 12/4/2014 6:38 PM, Alejandro Exojo wrote:

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 preprocessor macro that can also
choose different paths in C++ and adding support in QFileSelector is trivial.

The big question is: do you want such thing in Qt? If yes, I would gladly do
it myself, since I have some time available and I'm looking for ways to
contribute to Qt, learn, etc.

Rationale:

Right now everyone is baking its own way, with varying degrees of success. ;-)

I looked at it a year ago when I started writing my Sailfish application, and
I was pointed to puzzle-master's sources, where a simple
packagesExist(sailfishapp) did the trick... or so I thought. Since I wasn't
testing the non-Sailfish branch much, I didn't realize Creator always returns
true on this condition (by design: not allowed to fork a process when parsing
.pro files). Seems a petty complaint (who cares about Creator that much? it
works for qmake just fine), but with harbour requiring a "harbour-" prefix in
the name of the executable, Creator might not even be able to start the
application because it doesn't find it if you use a different value for
TARGET.

Lately I've been finding time for the app again and I finally noticed the
problem, so I asked on IRC again. I was pointed at other application, and the
check used was even worse. :-)

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
QMAKE_PLATFORM and Q_OS_BLACKBERRY.

Yes, yes. I know there is a solution: pass a parameter to the qmake
invocation. Store the invocation flag on the RPM packaging for final
deployment, and maybe a .pro.shared file for development. That's what Puzzle
Master has now too. Still I think there is some value in having this sorted
out in a more general way, specially given that you'll want people to also
distinguish a build for the Jolla phone or the Jolla tablet.

Cheers.



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] SailfishOS as an OS/platform in Qt

2014-12-04 Thread Tone Kastlunger 
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.
>
> 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 preprocessor macro that can also
> choose different paths in C++ and adding support in QFileSelector is
> trivial.
>
> The big question is: do you want such thing in Qt? If yes, I would gladly
> do
> it myself, since I have some time available and I'm looking for ways to
> contribute to Qt, learn, etc.
>
> Rationale:
>
> Right now everyone is baking its own way, with varying degrees of success.
> ;-)
>
> I looked at it a year ago when I started writing my Sailfish application,
> and
> I was pointed to puzzle-master's sources, where a simple
> packagesExist(sailfishapp) did the trick... or so I thought. Since I wasn't
> testing the non-Sailfish branch much, I didn't realize Creator always
> returns
> true on this condition (by design: not allowed to fork a process when
> parsing
> .pro files). Seems a petty complaint (who cares about Creator that much? it
> works for qmake just fine), but with harbour requiring a "harbour-" prefix
> in
> the name of the executable, Creator might not even be able to start the
> application because it doesn't find it if you use a different value for
> TARGET.
>
> Lately I've been finding time for the app again and I finally noticed the
> problem, so I asked on IRC again. I was pointed at other application, and
> the
> check used was even worse. :-)
>
> 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
> QMAKE_PLATFORM and Q_OS_BLACKBERRY.
>
> Yes, yes. I know there is a solution: pass a parameter to the qmake
> invocation. Store the invocation flag on the RPM packaging for final
> deployment, and maybe a .pro.shared file for development. That's what
> Puzzle
> Master has now too. Still I think there is some value in having this sorted
> out in a more general way, specially given that you'll want people to also
> distinguish a build for the Jolla phone or the Jolla tablet.
>
> Cheers.
>
> --
> Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
> http://barnacity.net/ | http://disperso.net
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org