[SailfishDevel] SailfishOS as an OS/platform in Qt

Alejandro Exojo suy at badopi.org
Fri Dec 5 09:05:38 UTC 2014


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:

<suy> 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_gerrit> Qt Creator treats packagesExist incorrectly - 
https://bugreports.qt-project.org/browse/QTCREATORBUG-11510
<dt|tt> suy: what does your question have to do with that bug report?
<suy> 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 (...)"
<dt|tt> suy: right, it should be self-evident why we don't want to run 
arbitrary processes while parsing a .pro file
<dt|tt> suy: we don't know what side effects there are
<suy> 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
<dt|tt> suy: not while parsing the project
<dt|tt> suy: that would be insane
<suy> 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?
<dt|tt> suy: parsing needs to be side effect free
<andre_> 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


More information about the Devel mailing list