Re: [SailfishDevel] SailfishOS as an OS/platform in Qt
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
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: 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. ___ 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
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] Announcing Mono for Sailfish
Hey2, I've been playing with this myself a bit, but have not gotten too far, summer weather, travels and all. What Ville is suggesting is exactly what I'm after - not a full binding set, but just a UI bridge. In API rich environments like python/.net/etc the application framework API parts of Qt don't mean much (and their existence/quality varies depending on platform anyway). Mono (and even Xamarin) falls a bit short on the UI side, and a good QML/QtQuick bridge would help a whole lot. And before someone gets the wrong idea - this is still not about having a single QML codebase, but rather having a common language for UIs powered by whatever is the best tech choice on the given platform (QtQuick, Silica, QML components wrapping native APIs, you name it). Best regards Attila Csipa On 8/22/2014 11:12 AM, Ville M. Vainio wrote: Hey, We discussed this on twitter already, but here we go in 140 characters as well ;-). Making it possible to create QML applications with Mono would be interesting on every platform, not merely Sailfish. Think Android, iOS, desktop. Xamarin costs nontrivial amount of money, so QML + Mono would be a free alternative to that (with somewhat limited capabilities of course)., Better path than QtSharp would be just creating a QML bridge to Mono, i.e. instantiate a QML runtime and make Mono talk with it. Example for this architecture is PyOtherside (http://thp.io/2011/pyotherside/) Sufficient api would be: - register Mono functions to be callable from QML javascript Analogue: http://pyotherside.readthedocs.org/en/latest/#call - receive signals (free form objects) from Mono side Analogue: http://pyotherside.readthedocs.org/en/latest/#received Another example (though a lot larger) is golang-qml binding: http://godoc.org/gopkg.in/qml.v1 Mechanically exposing large parts of Qt's C++ api (including QML engine) like sip, pyside et al are doing is probably going to yield lots of unuseful code, where developers only need 2% subset, but you will pay the price of the bloat and complexity anyway (troubles with PySide are a good example of this). Therefore I think QtSharp is suboptimal approach. Obviously I don't want to act as stop energy, but look before you leap so to say. On Fri, Aug 22, 2014 at 12:13 AM, Bob Summerwill b...@summerwill.net mailto:b...@summerwill.net wrote: See http://www.mobilelinuxnews.com/2014/08/introduction-mono-sailfish-os-jolla/. I'm happy to announce that development on Mono for Sailfish is underway (http://monoforsailfish.com).This is a continuation of MonoTizen (http://monotizen.com), on which development has been suspended because the Tizen project is broken (see http://kitsilanosoftware.wordpress.com/2014/08/13/the-tizen-project-is-broken-we-will-be-spending-some-time-apart-3/). Dimitar Dobrev, the author of https://github.com/ddobrev/QtSharp has been upstreaming bug-fixes (and addressing newly discovered issues in) to http://github.com/mono/CppSharp.He'll be building the bindings, and will probably end up doing the Mono Runtime port as well, based on the fantastic job which Damien Diederen did for the Tizen Mono Runtime. Cheers, Bob Summerwill, Kitsilano Software http://twitter.com/bobsummerwill http://bobsummerwill.com | http://kitsilanosoftware.com | http://monoforsailfish.com -- b...@summerwill.net mailto:b...@summerwill.net ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org mailto:devel-unsubscr...@lists.sailfishos.org ___ 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] When does Jolla give us an API?
On 13/02/14 12:29, Filip Kłębczyk wrote: well if Harbour QA would be doing so well why the flashlight app with some hidden data gathering passed it (Artems little provocation :))? That shows that Jolla QA doesn't have to be better than community QA in terms of user security and privacy. Exactly. Store QA (harbour or any other) is largely *NOT* about security/privacy/quality. It's just about sanity-checking the basic functionality of the app. Best regards, Attila Csipa ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] When does Jolla give us an API?
On 12/02/14 12:36, Timur Kristóf wrote: I posted the stuff to together so we can continue the discussion online: https://together.jolla.com/question/27052/roundtable-discussion-jolla-harbour-apis/ My personal advice is - don't overthink it. The bottom line/driver is the user experience. It's super-easy to overthink and overengineer in the hope that strong and restrictive policies will somehow protect you. In both my personal and professional experience, they largely won't, as at some point there will be a change of behaviour/policy even in those supposedly stable APIs or there will be that weird app that actually depended on a bug, and the framework fix broke it. Life of a platform vendor is hard. The other thing I'd like to highlight for the cases WHEN YOU HAVE LIMITED REPOSITORY TESTING BANDWIDTH (yes, that's all caps), it IMHO shouldn't be the repository QA that tries to validate all versions and use-cases. There is a reason why in appstores it's the users who give the stars and comments, and not the repo QA. Repo QA is more about will it start and will it burn your house down. If it breaks later on, annoys, users will one-star it and it will sink to the bottom of the store search. Tough luck, life of a app developer is hard, too. What's happening right now is the exact opposite - apps that have perfectly fine user experience are turned down because they link to verboten libs (even if the app would still work fine if the lib went away). At the same time you can publish the world's most inefficient and annoying app if it uses the right libs and services. Finally, there is the segment about hackability and open development. The current *harbour* limits are IMO worse than what we had even in the Ovi days - the intent of why some parts of the system are off limits doesn't matter, if in the end that prevents people making/getting cool apps to people - remember Aegis? That was also a tool to guard platform, users and developers alike. If in the end all I can make is a Flappy bird or Doodle jump, your platform doesn't stick out the tiniest bit (on the contrary) from the others - at that point it's really tempting to just go full Android and say your problem if an APK doesn't work on a Jolla/Sailfish device. I can take a one-star rating with pure profanity as the comment to my face a lot easier than hard-policies that prevent me from getting (hopefully cool) stuff to people. Best regards, Attila Csipa ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] undefined symbols
On 12/02/14 16:06, . . wrote: help needed. new to Qt and Sailfish development (but not new to C++) does anyone know how i can build a console application for Sailfish that uses Qt? i only want to use certain Qt classes with no UI. i must be missing something in my .pro file as the compiler is complaining about unresolved symbols? i created a new project under Qt Creator as C++ application. #include QGuiApplication #include QQuickView Note that these are quite GUI (so not console), should be a QCoreApplication and no QQuickView. The unresolved errors are due to not linking the lib with haptics. Best regards, Attila ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] When does Jolla give us an API?
On 09/02/14 14:52, David Greaves wrote: On 09/02/14 11:28, Putze Sven wrote: As pointed out from others, it's not simply done with the Qt documentation. The Sailfish OS is built upon many libraries, frameworks and layers. But which one is to use? Qt. Seriously. You asked for an API. Jolla supports the Qt API precisely because it is a single, high level, app-suitable API that is well managed and open. It provides a significant degree of platform independence by abstracting a large amount of platform capability provided by those underlying layers; there is not much 'limited' about it :) Even the list of Qt libs at https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/blob/master/allowed_libraries.conf is fairly skimpy. Skimpy to the point that even all the Qt essential modules are not covered. The fact that Qt itself is a bit, well, optimistic when it says They are available on all supported development platforms and on the tested target platforms is a different matter. With the loss and current slow rebuilding of the mobility functionally, feature-rich/low-level development is on the hard side. Back in the Harmattan days this was the exact reason why there was the QtSDK for the high-level app-developer and a Platform SDK for all the people who didn't mind their hands getting dirty and getting an incompatibility or two as things moved on. Attila ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 07-Nov-13 22:02, Jonni Rainisto wrote: But feel free to give suggestions what kind of API's you would prefer to have as a developer in Harbour to make your life easier. 1. Expose/Tunnel/Replicate Silica to Android Qt apps 2. Expose other half APIs to Android apps That would be pretty much it. Best regards, Attila Csipa ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 08-Nov-13 13:48, Michal Jerz wrote: So it is actually a matter of *ALTERNATIVE COST*. Make it sufficiently cumbersome (and possibly also risky) and at least SOME people will find paying $1 simply EASIER and QUICKER than bothering with not so easily installable and potentially risky stuff. Or opt for lack of any protection How about we try to figure out how to make the legal way Easy and Painless, rather than trying to figure out how to make software installation/usage (even) more complex and difficult? Best regards, Attila ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 07-Nov-13 12:06, Marcin M. wrote: Well, the whole problem with repos and deps is not about the user side but the server side ;) Maemo.org doesn't expose DiffIndex like Debian does but normal Packages and Release (maybe compressed). DiffIndex would greatly reduce download time. It's like the zypper story. It's a great and fast solution to a problem that (in that particular context) should not exist in the first place (why do you need to pool for/get *any* kind of (Diff)Index or Packages? The store *knows* what do you have based on your request, and upon an app being published *knows* who should be notified to upgrade). About the storing list of apps on-device... Hmm... In my debian repo, it's ~1 KB per package. Let's assume 1 million apps. It's 1 GB. Much too Will come out as more than that if you add the extra metadata (icon, translations...). Then also factor in multiple versions of the app (for different firmware versions, dependent apps/libs etc). Numbers grow pretty big pretty quick. much. But if only installed apps were added as a repo? Let's assume a The only problem that I see that would mitigate (but not solve) is the update-check data traffic (which is the smallest problem). Dependency resolution, search, update notifications, etc would still have to be done somehow. Best regards, Attila Csipa ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 07-Nov-13 13:40, Jonni Rainisto wrote: DRM has nothing to to do with with copy protection. Copy protection *is* one of the cornerstones of DRM (which, arguably, is a lot broader term). Feel free to check wikipedia :) Hopefully that answered your question. Not quite :) What I'm interested in is what *will* be there (or, rather, what resources will it limit) as opposed to what is NOT going to be there (whether not having Aegis there is good, or bad, depends on what you will have there instead is better or worse than Aegis). I just hope it's lightweight enough so the resources wasted (yes, that's just my personal opinion, feel free to disagree ;) producing it are not missed elsewhere and the negative impact it will have on the hackability of the device will not be large enough so that it's easier to just go with a Nexus. Best regards, Attila ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 07-Nov-13 13:42, Michal Jerz wrote: So it's like with door locks. Despite none of them being 100% proof to unauthorized opening, somehow people continue to use them in their doors rather than just having doors without any locks only because they're not 100% secure. They at least REDUCE abuse. Without serious research, I will contest that as wishful thinking. Some people will argue that the monetary outcome of piracy is actually POSITIVE, because the benefit of the larger userbase outweighs the (questionable-sized) drop in legal sales (would all those who would take a free beer maybe rather NOT have a beer than PAY for it?). The effect of torrents on Netflix and the TV/movie industry holds a LOT of learnings in this area. Personally, I think copy-protection schemes have nothing to do with piracy or those who pirate. They are actually born out of the need to be able to project a message to developers that their work is somehow safe(r) and (more) protected - playing on the positive sense of control (even if it actually is detrimental to the business-perspective). If existing stores are anything to go by, the *ease* of how easily one can legally get to your content (at the micro-pricing levels) will, in effect, dwarf the impact of any DRM scheme. Best regards, Attila ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 07-Nov-13 15:51, Mohammed Hassan wrote: Not quite :) What I'm interested in is what *will* be there (or, rather, what resources will it limit) as opposed to what is NOT going to be there (whether not having Aegis there is good, or bad, depends on what you will have there instead is better or worse than Aegis). As Jonni said: After you enable developer mode, you have _true_ root access to the device and can freely replace system binaries and do what ever you want with your device (you may lose warranty when you enable developer mode). That's good, but what I don't get in that case is... does that coincidentally mean enable developer mode == disable copy protection? Best regards, Attila ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 07-Nov-13 17:31, Michal Jerz wrote: Well, as Ronni wrote, using their copy-protection library is going to be entirely OPTIONAL, so its existence should not hurt anyone That will depend on what it actually does, and what kind of support it requires from the system. At the most benign level it can just try to figure out if the IMEI is authorized and such, at worst, it can interfere with system activities (how you guarantee a chain of trust if your copy-protection library relies on calls to user-replaceable parts of the system?). Rather than studying any researches, I'd prefer to simply give it a try myself and see if it makes any difference for me. After two years with the That's also a way of research :) Nokia Store preventing use of any protection, I'd really like to at least TRY and see what difference it can make. Certainly, I'm not implying what other developers must or must not do - everyone is free to make their own business decisions, good or bad (and since I still didn't earn a million $ by selling apps, I will not claim to be a monetization guru :). I'm just baffled at just how hellbent some people are on reducing the number of pirated copies without fully understanding the cost of development and dynamics of app-stores. And every hour a Jolla engineer (or 3rd party dev) spends devising or employing a copy-protection scheme is an hour that he's not putting towards other parts of the platform or his/her apps. One thing I know for sure is that in 2013, after all those who used to crack and release Symbian 'warez' got disinterested in the dying platform, sales of my Symbian applications actually noticeably INCREASED, despite the rapidly shrinking user base. So there must be some correlation between these things... Again, without proper context and research, the origin of that correlation might not be obvious (Was legally buying it in the beginning hard or an obstacle? Did Nokia introduce carrier billing or better payment coverage in some markets along the way?). The same applies here. I agree there is an inflection point, where the platform is too small for real piracy to exist, but then the question is - who wants to remain a small player? And if you get big, that scheme will not help you anyway, so why make it? Best regards, Attila Csipa ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 06-Nov-13 03:06, Karl Granström wrote: Today we're launching Jolla Harbour harbour.jolla.com, the portal for submitting applications to the Jolla Store. You can submit and manage your applications. Consumers will be able to install them directly from their Jolla phones. The dry dock and slipway for developers is under maintenance at the moment. :( HTTP 502 Bad Gateway ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 06-Nov-13 13:05, Roberto Colistete Jr. wrote: - current (2013) smartphones are fast (dual or quad core @ 1,0 GHz, fast flash memory, etc), equivalent to low cost net/notebooks some years ago, so it is not a problem to have repositories with thousands of packages; Luckily we all live in the world where everyone has (the equivalent of) Nexus 5+ hardware and a free and steady LTE connection. Not. And yes it's a problem. How bad is it? Well, for one, the updates are polling-based (did you say 2013?). You're wasting hundreds of megabytes of flash space for things you have no use for (effectively, you cannot update once you run out of space, and as the app catalog grows, your free space will be going down even if you don't touch anything). You're wasting battery life (those zippy CPUs are like a race-car engine, press on the pedal and watch your tank dry!). I did a test with a clocked-up N900 back in the day (comparison to big Ubuntu in a 100K app scenario), and it was pretty defeating (far more than just add a core and double the clock, and it's going to be fine). Best regards, Attila ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Jolla Harbour and Jolla Store
On 06-Nov-13 13:33, Roberto Colistete Jr. wrote: 1st Jolla smartphone I expect to be 4-6 times the speed of Nokia N9. ... and all of that still doesn't address the crux of problem: Desktop-style Linux distros rely on having to have all the data LOCALLY and doing the dependency resolution on the HOST machine. That is completely unnecessary and pure overhead in all of storage/RAM/CPU/network aspects. The classic Linux package dependency model is built for the scenario where the resource abundance is on the client side, and server resources are scarce (hence the dumb file repo approach). In a mobile context it's just the opposite - the resource challenge is on the client side, and the abundance shifted to the server side. As for the actual speed comparison - there is no need to expect, we should be able to guess that pretty well. Unless something changed recently, only a single core is used for packaging/dependency resolution purposes. The N9 was a 1GHz Cortex A8. 1st Jolla is a 1.4GHz Snapdragon - I don't know the generation, but it's probably a Krait. An A8 is ~2 DMIPS/MHz, Kraits are ~3.3, which means the JollaPhone is ~2.5 times faster than the N9 for this purpose (not counting memory/flash bandwidth, etc). Oddly enough they have the same amount of memory (which I personally find to the be the Achilles heel of the Jolla device in the context of a heavy multitasker). No need of Nexus 5 hardware. Almost all smartphones are current dual core and some quad core, all 1.0 GHz each core. The CPU of the That's a very western tech-heavy view. Most of the world runs smartphones a lot more modest than that (why do you think Gingerbread refuses to die?). Smartphones are not getting faster as much as they are getting cheaper. Single core ARM11 smartphone devices didn't disappear - they just went to different markets. And Mer/Nemo Mobile/Sailfish don't use .deb, but .rpm packages. Most of the overhead problems are unrelated to whether the package format is deb or rpm, they are just different kinds of dinosaurs in this context. Best regards, Attila Csipa ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Start learning for sailfish
On 24-Oct-13 12:49, FIlip Kłębczyk wrote: Writing a native Sailfish app will allow your app to have better UX and best integration with the platform. So the interface will be more A question regarding this occured to me - is any platform functionality exposed in the Android layer? Ie. if I have a hybrid Android Java/Native app, would my native code there see any of the Sailfish APIs/libs, or is it completely sealed off and looking like a bog-standard Android? Best regards, Attila ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Multiplatform apps on Sailfish, a.k.a. scoping and ifdeffing
On 13/03/13 23:14, David Greaves wrote: On 13/03/13 20:29, Attila Csipa wrote: Hi, I'm wondering if Sailfish has or plans to have any qmake level scoping or ifdeffing to make development for multiplatform projects less painful? I understand Sailfish is just Linux, but just Linux doesn't imply Silica and similar, Qt is a bit on the stubborn side when it comes to graceful QML fallbacks and detection, so help would be more than welcome. In a worst case scenario, I would expect at least something along the lines of what Harmattan had (see http://wiki.meego.com/Porting_Fremantle_Applications_to_Harmattan#Harmattan_scope ). Yes. What would you like? A way for conditionals in qmake (mostly for packaging), and #ifdef. I have no particular emotional attachments of how to call these constants (also depends on how Sailfish sees itself in terms of future versioning, licensing, subsequent releases, etc), but the mechanism used in Harmattan is good enough for me - have a .prf that qmake can pull in (it's linux enough that I would refrain from OS-style platform scoping) and a qplatformdefs.h for the C++ side. Best regards Attila Csipa ___ SailfishOS.org Devel mailing list
