Re: [SailfishDevel] Setting application screen orientation from C++
Den 31.07.14, 10.39 skrev Tomasz Sterna to...@xiaoka.com: Dnia 2014-07-31, czw o godzinie 08:49 +0300, Iosif Hamlatzis pisze: the same answer that I should do the rotation translation my self and not only for rendering but for touch screen. Also a regression from Maemo... where the only thing application cared is getting notified, that its window dimensions is not 480x800 anymore, but 800x480 and it needs to relayout. Also, the relayouting process was cleverly hidden by rotating the screenshot of the last state of the application, so the user does not see the relayouting itself. It¹s a change (I wouldn¹t call it a regression, as I¹m quite sure it was a deliberate choice) from Maemo 5, but not Maemo 6. Maemo 6 did not do server-side rotation or window resizing. It was up to the client toolkit (MeeGo Touch, or qt-components being the built-in examples) to do that. The only part that is different is the default frame buffer orientation (landscape on Maemo devices, portrait on the Jolla). ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Setting application screen orientation from C++
Den 31.07.14, 07.49 skrev Iosif Hamlatzis i.hamlat...@gmail.commailto:i.hamlat...@gmail.com: I had asked a while a go the same question regarding orientation when I started porting my SDL games and received the same answer that I should do the rotation translation my self and not only for rendering but for touch screen. Also the same question that it would be faster if I did the calculations instead of the system automatically. You’re right, that doesn’t sound correct in today’s world. If there is a difference, I can’t imagine it’s a significant one: there’s still going to be a transform (whether it’s on your client application’s rendering) or when rendering the client texture in the compositor, after all. In the past, though, it did make quite a lot of difference. X11 was a totally different beast to the graphics stack we had now, and it had much larger problems with things like performantly resizing and such. Client side rotation does buy you some things, though: the capability to do more complex transitions and to customize the transition if you feel like it. See for instance: https://sailfishos.org/sailfish-silica/qml-sailfishsilica-page.html#defaultOrientationTransition-prop https://sailfishos.org/sailfish-silica/qml-sailfishsilica-page.html#orientationTransitions-prop So the answer: Do it yourself because it's faster has NO merit. IMHO either jolla doesn't have the skills or the man power to do it. You’re right, we don’t. We attempted this shortly (~1-2 months) before shipping if I recall rightly, because I think that server-side transitions do make sense for a large number of cases (like SDL). Unfortunately, we ran into driver bugs that made it an impossible task at the time (given the time constraints we had), and due to a lack of time/resources we haven’t revisited the problem since then. There’s an awful lot of work on our plate, and we really need to pick and choose what work we take on to give the largest slice of our user base the biggest «bang» for their buck. So far, this hasn’t been considered a priority. If you think it should be, then feel free to file a suggestion on together.jolla.com and try gather some interest for it. It doesn't matter any more, for the company I work for we no longer consider porting our games to this platform, not in the near future. We tested it and given it an F (for fail) It’s a shame to hear that. I hope that one day you’ll be able to reconsider. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Qt 5.2 in devel
Den 07.07.14 20:12 skrev Timur Kristóf timur.kris...@gmail.com: Why just 5.2? Why not go straight to 5.3? Gunnar already answered this, but I¹ll repeat it somewhat: We¹ve put a reasonable amount of work into stabilizing 5.2, and are fairly confident that it¹s of acceptable quality by now. Pushing any change into that has an inherent risk of regression (I can say certainly say that we found more than our fair share of bugs along the way during this upgrade, and are still running into some new ones from time to timeŠ :)) That doesn¹t mean further upgrades won¹t happen in the future, it just means they won¹t happen immediately. When precisely they happen will depend on when we can spare effort to it (which in turn depends on what benefits we get out of itŠ) and the quality of the upstream releases. This might sound strange and all, but do realize that we are probably one of the most extensive users of the Qt stack (in that we literally use pretty much all of it) and certainly one of the most extensive users of QtQuick QML. We¹re a pretty good stress-test for finding corner cases, so we need to be careful. On the bright side, I¹m fairly confident that future upgrades will be less painful, as part of the pain was also on our side in that we rushed a few things to get to market last year, and we paid the price in doing that work properly. BR, Robin ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] Qt 5.2 in devel
Hello intrepid developers, Qt 5.2 rebuilds have (finally, thank god) finished in devel. I’ve updated a single device (via version —dup) so far without too many ill effects (see below), and done some brief smoke testing. The device rebooted the user session successfully, and rebooted to a UI OK, applications start, and at a very light play, they appear to be in reasonable shape. The one symptom of bad behavior I’ve seen so far is that orientation does not appear to work (at least once), this appears to be a hardware adaptation problem: /system/bin/sensord was not running on reboot. Rebooting again made it appear. There are some rough edges, but nothing apparently life threatening: * Gunnar, can you please remove the v8 dependency from the scene graph adaptation plugin? * Bernd, can you please remove cutes-qt5 from sailfish-version (and remove cutes-qt5 from the repos)? I guess there’s nothing else requiring it after backup’s removal of it (Denis/Giulio, can you help out with anything needed here?) * Cor appears to be failing to build on ARM in devel. I don’t think this is related to Qt, but needs checking. Denis? Developers: please upgrade your devices with some caution and see how your areas look. I’m going to head to bed now. If problems occur, if it isn’t urgent, file it in bugzilla, and add the Qt5.2 keyword CC me. If it is urgent, please try pretend that it isn’t until I’m around again, or alternatively, you can (try to) call me on +47 9059 2624. If you’re lucky, I may even leave the phone off silent :). BR, Robin ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Qt 5.2 in devel
Sorry folks. This wasn’t intended to be posted here, but, have a slight visual on what’s going on behind the curtain anyway. :) tl;dr: Qt 5.2 upgrade is on the way in the nearish (but not immediate) future :) Fra: Robin Burchell robin.burch...@jolla.commailto:robin.burch...@jolla.com Svar til: Sailfish OS Developers devel@lists.sailfishos.orgmailto:devel@lists.sailfishos.org Dato: onsdag 18. juni 2014 05:10 Til: Bernd Wachter bernd.wach...@jolla.commailto:bernd.wach...@jolla.com, Gunnar Sletta gunnar.sle...@jolla.commailto:gunnar.sle...@jolla.com, Denis Zalevskiy denis.zalevs...@jolla.commailto:denis.zalevs...@jolla.com, Giulio Camuffo giulio.camu...@jolla.commailto:giulio.camu...@jolla.com Kopi: Sailfish OS Developers devel@lists.sailfishos.orgmailto:devel@lists.sailfishos.org Emne: [SailfishDevel] Qt 5.2 in devel Hello intrepid developers, Qt 5.2 rebuilds have (finally, thank god) finished in devel. I’ve updated a single device (via version —dup) so far without too many ill effects (see below), and done some brief smoke testing. The device rebooted the user session successfully, and rebooted to a UI OK, applications start, and at a very light play, they appear to be in reasonable shape. The one symptom of bad behavior I’ve seen so far is that orientation does not appear to work (at least once), this appears to be a hardware adaptation problem: /system/bin/sensord was not running on reboot. Rebooting again made it appear. There are some rough edges, but nothing apparently life threatening: * Gunnar, can you please remove the v8 dependency from the scene graph adaptation plugin? * Bernd, can you please remove cutes-qt5 from sailfish-version (and remove cutes-qt5 from the repos)? I guess there’s nothing else requiring it after backup’s removal of it (Denis/Giulio, can you help out with anything needed here?) * Cor appears to be failing to build on ARM in devel. I don’t think this is related to Qt, but needs checking. Denis? Developers: please upgrade your devices with some caution and see how your areas look. I’m going to head to bed now. If problems occur, if it isn’t urgent, file it in bugzilla, and add the Qt5.2 keyword CC me. If it is urgent, please try pretend that it isn’t until I’m around again, or alternatively, you can (try to) call me on +47 9059 2624. If you’re lucky, I may even leave the phone off silent :). BR, Robin ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.orgmailto:devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] A kickoff meeting about SailfishOS, open source, collaboration, way forward @ 15 April, 15:00 UTC
On 07 Apr 2014, at 16:11, Filip Kłębczyk fklebc...@gmail.com wrote: We don't want the community to work on the bugs and take our jobs!. I don’t know any of the context of the discussion you’re referring to, so I won’t say anything about that particular case. I will say this: You’re of course free to criticise whatever you want. But don’t let that criticism of an individual tar an entire company, 80+ people with their own opinions, minds, and thoughts by the same brush - especially if you expect those same people to listen to your thoughts. Taking an offensive stance is a great way to elicit defensive reactions unnecessarily (and unhelpfully). ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] A kickoff meeting about SailfishOS, open source, collaboration, way forward @ 15 April, 15:00 UTC
On 05 Apr 2014, at 10:21, Thomas B. Rücker tho...@ruecker.fimailto:tho...@ruecker.fi wrote: Reading this I can't help but wonder if Jolla now claims ownership of Mer/Nemo then. Even with fancy hat changing. Bringing this discussion up in a strictly Sailfish context implies this. I think you’ve read a little much into things, but I’d like to point out the obvious here: Jolla are doing the majority of the work in these two projects. So purely in terms of governance and technical knowledge, they are in a position of quite a bit of power. Now, that having been said, the work on these projects has always (without exception) been done in the public realm, with the aim of collaborating with others, to some degrees of success. We’ve seen people make tools/hacks/fixes around that stuff, and that’s great. It might be improvable, but it’s a positive thing already. I guess what I’m trying to say is that, from a strictly open source point of view, the ones doing the work dictate the direction - one could even say this implies ownership, yes. But on the other hand, while I can’t speak for the entire company, I (and the folks I know and work with on a daily basis) have collaboration and cooperation at heart, even if execution could be improved on - which is what provided the impetus for this thread. Power doesn’t necessarily mean dominance. There are other downstream projects relying on Mer and I'd expect this to be discussed with them, in a completely vendor neutral setting. Mer used to be big about this, before it got dragged into a ship a product race of one of the involved parties. This is open source. We can’t dictate what other people do. And if we’re polite, we talk first, of course. I do think that some of the things you were replying to are about addressing a very real problem, though, which is that contributing to Nemo (and Sailfish, Mer, and the surrounding universe) has a lot of rough edges. It won’t be a panacea, but it’s something to start thinking on. ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] undefined symbols
On 12 Feb 2014, at 15:54, Attila Csipa q...@csipa.in.rs wrote: On 12/02/14 16:49, Andrey Kozhevnikov wrote: because there are no qt5 config for Qt0Feedback, but pkgconfig did the magic with including libraries :) Well, technically, there is a /usr/share/qt5/mkspecs/modules/qt_lib_feedback.pri (which would make it just CONFIG += feedback, right?) but it does look rather WIP (0.0.0 versioning). QT += as it’s a Qt module, not a feature (which is what CONFIG is for) and yes, QtFeedback has not been released by the Qt Project, so any and all API is subject to change BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] how to get qml debug output to file
On 04 Feb 2014, at 22:37, Tero Siironen tero.siiro...@iki.fi wrote: Andrey Kozhevnikov coderusin...@gmail.com kirjoitti 4.2.2014 kello 23.14: This is messages handler i'm using in my projects: This doesn’t seem to make a difference for me, the log file still contains only c++ side debug prints, qml prints (like console.log()) are not handled with messagehandler. Actually I found out that even if set in pro-file: DEFINES +=QT_NO_DEBUG_OUTPUT DEFINES +=QT_NO_WARNING_OUTPUT I still get qml debug prints printed out to console, so it seems that those prints from qml are not handled via normal debug handling at all? I would like to get no debug printing at all, or then just to file. DEFINES in qmake adds additional defines (-D) to the cflags used to build C++ affect code compiled with them. QtDeclarative was not compiled with these defines, so your adding them won’t affect console.log (whose C++ implementation lives inside QtDeclarative). If you don’t want debug prints, you need to install a message handler (you say you’ve tried this and it doesn’t work, I can’t answer why that would be the case, it should work, as it uses the same infrastructure). BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] QStandardPaths not working when app is run from Launcher
Hi, Can you please provide a small sample demonstrating this? As I’m quite sure it works for our own uses. BR, Robin On 19 Jan 2014, at 14:34, Sylvain B. sth...@hotmail.commailto:sth...@hotmail.com wrote: Hey, My app did not want to read the some cached content it was supposed to have written in QStandardPaths::CacheLocation. To understand why, I tried to run it from the terminal, and... everything is working fine. Since we don't have logs when we run the app directly from Launcher, I updated it to display some logs directly in the UI and I figured out that, when the app is run from the Launcher on the actual device (it's ok on the emulator), QStandardPaths does not work correctly: QStandardPaths::CacheLocation returns /home/nemo/.cache/mdeclarativecache_pre_initialized_qapplication-X X is a random number, so each time I run my app, it creates a new one. When run from terminal, QStandardPaths::CacheLocation correctly returns /home/nemo/.cache/ I tried with QStandardPaths::DataLocation but it's the same, I get /home/nemo/.local/share/AppName/mdeclarativecache_pre_initialized_qapplication-X So for the moment, I temporarily hardcoded /home/nemo/.cache/ Thanks! Sylvain. ___ SailfishOS.orghttp://sailfishos.org/ Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] xdg folder stuff: howto? more info
On 09 Jan 2014, at 00:37, Thomas Tanghus tho...@tanghus.net wrote: On Wednesday 08 January 2014 09:22 Jonni Rainisto wrote: IMHO applications that use QStandardPaths should be always accepted, there must be something wrong with the process or rules if that is the cause for rejection. If QStandardPaths points to wrong directory then its a bug which should be fixed. Can we consider this as a (semi-)official answer? I would also say that harbour applications should not be rejected because of a (seemingly) Qt-bug that should be easily patchable i.e. that QStandardPaths.data doesn't reflect XDG-* standards. I’m not sure I understand what bug you’re talking about. See the source: https://qt.gitorious.org/qt/qtbase/source/f0f6c1d0edd8c71530b8e47b61d70aa55a0c6a0c:src/corelib/io/qstandardpaths_unix.cpp Can you please provide a demonstration? BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Undocumented Silica components
For things in Qt itself, keep an eye on Qt upstream. When they are part of an official Qt release (that is: stable API), then we can look at them when we upgrade. As far as I know, nobody has yet prioritised work on either of those, and platform support is scarce, so I don’t see them happening in the immediate future. BR, Robin On 06 Jan 2014, at 12:57, Timur Kristóf timur.kris...@gmail.commailto:timur.kris...@gmail.com wrote: Hi Martin, So, we're okay with using PullDownMenu::busy and OpacityRampEffect, but we should avoid GlassItem for the moment. Right? What about other APIs that are there but aren't allowed yet, such as QtDocGallery and QtFeedback? When can we use those in harbour? Thanks, Timur Timur On Mon, Jan 6, 2014 at 2:16 AM, Martin Jones martin.jo...@jolla.commailto:martin.jo...@jolla.com wrote: Hi, As a general rule, if it’s not documented then it isn’t public API. The GlassItem API hasn’t been reviewed for public use. It will probably change and is not safe for use. The busy property of PullDownMenu is documented, but the docs have not been updated in the SDK. OpacityRampEffect has been reviewed for public use, but is not yet documented. We’ll do this asap. Best Regards, Martin. On 3 Jan 2014, at 6:58 am, Luciano Montanaro mikel...@gmail.commailto:mikel...@gmail.com wrote: I don't know if this has been addresed already, but... In my application, I would like to use a few components that the componentgallery is demoing, but that are not documented in the reference documentation. Is it OK to use everything that works there? Specifically, I want to use * OpacityRampEffect for my coverpage * the busy property of the PullDownMenu while fetching status updates * possibly the GlassItem as an indicator of the train delay Since I would like for my application to eventually be distributed through the Harbour, I would like to know if it is OK to do so. Best regards, Luciano -- Luciano Montanaro Anyone who is capable of getting themselves made President should on no account be allowed to do the job. -- Douglas Adams ___ SailfishOS.orghttp://SailfishOS.org Devel mailing list ___ SailfishOS.orghttp://SailfishOS.org Devel mailing list ___ SailfishOS.orghttp://SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] QDnsLookup always fails
Hi, On 22 Dec 2013, at 19:31, Alexander Stante sta...@gmail.com wrote: Looking at the source code of QDnsLookup for Unix operating systems, it looks like it can't load / find certain libraries. Has onyone else experienced the same problem? I've tried it with the latest version of the SDK. Is there an other way to obtain SRV records? This looks to have been fixed in 6c5e6a030dc49f36a5d4f2846fe78daf3d02a03d in qtbase, which we’ll get when we upgrade Qt sometime next year. BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] QtMultimedia SoundEffect Vs Audio
Hi, On 20 Dec 2013, at 12:21, Kimmo Lindholm kimmo.lindh...@eke.fimailto:kimmo.lindh...@eke.fi wrote: First I used QtMultimedia Audio component which seems to follow system volume setting, but after the sound is played, there is glitch in animations running on the screen. This sounds like a bug. Can you please give me the source of your example demonstrating this, for use as a test case? (please see http://sscce.org/) Then I switched to SoundEffect component, but it plays always with full volume regardless of system volume settings (or muting). I can ‘manually’ adjust the volume through with SoundEffect.volume –property. Is there any way that I can pass system volume/muted value to SoundEffect.volume? This sounds like another bug. It should be inheriting this. Again: source would be appreciated so I can file this. BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Delegate creation on demand
Can you please provide a minimal test case (i.e. ideally a single QML file, usable with qmlscene) demonstrating your problem? Please see http://sscce.org/ On 15 Dec 2013, at 21:03, Hendrik Borghorst hendrikborgho...@gmail.com wrote: Hello, the problem isn't my delegate. It is quite minimal. The problem is I think a bug in QML Listview. It goes absolutly crazy if it is invisible and starts making delegate for around 50% of all items. This causes the memory to run full. A workaround I added is model: visible ? modelVar : null which works quite nicely. I think this bug could be an upstream qt bug? greetings Am Sonntag, den 15.12.2013, 10:01 +0100 schrieb christopher.l...@thurweb.ch: Hi Hendrik Have you seen this? http://qt-project.org/wiki/Performance_tip_Lists The general advice is to keep the delegates is lightweight as possible, and to use Loaders for anything needed later (e.g. onClick) Chris Zitat von Hendrik Borghorst hendrikborgho...@gmail.com: Hello folks, I've got a problem with long lists (~25000 elements). All delegates are created at once which causes the memory usage to explode beyond the devices capability. I already tried setting cacheBuffer: 0 in SiliciaListView but it doesn't change it. Is the something I'm doing wrong. You can see the actual page code here: https://github.com/djselbeck/smpc/blob/master/pages/CurrentPlaylistPage.qml Shouldn't the delegates be constructed on demand? It is weird because my old n8 wasn't struggling with qml lists with this size. greetings and congrats on getting the devices to your customers (I'm very pleased) ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] best way to set QML properties from within C++ in Sailfish?
On 12 Dec 2013, at 13:42, Wim de Vries wsvr...@xs4all.nlmailto:wsvr...@xs4all.nl wrote: I need to set many properties in QML elements from within C++. You may find it easier to expose these properties *from* C++ to QML, using a singleton type (for example) http://qt-project.org/doc/qt-5.0/qtqml/qtqml-cppintegration-definetypes.html#registering-singleton-objects-with-a-singleton-type QT documentation: QQmlEnginehttp://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html engine; QQmlComponenthttp://qt-project.org/doc/qt-5.0/qtqml/qqmlcomponent.html component(engine, MyItem.qml); QObjecthttp://qt-project.org/doc/qt-5.0/qtcore/qobject.html *object = component.create(); qDebughttp://qt-project.org/doc/qt-5.0/qtcore/qtglobal.html#qDebug() Property value: QQmlPropertyhttp://qt-project.org/doc/qt-5.0/qtqml/qqmlproperty.html::read(object, someNumber).toInt(); QQmlPropertyhttp://qt-project.org/doc/qt-5.0/qtqml/qqmlproperty.html::write(object, someNumber, 5000) Still in Sailfish we only have a QQuickView*, no QQmlEngine/QQmlComponent. How do I get their from QQuickView? http://qt-project.org/doc/qt-5.1/qtquick/qquickview.html#engine Also, Can I get to all Pages (even if not active) and their nested childs via the above mentioned QObject* ? Not easily, AFAIK. ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] best way to set QML properties from within C++ in Sailfish?
On 12 Dec 2013, at 14:28, Wim de Vries wsvr...@xs4all.nlmailto:wsvr...@xs4all.nl wrote: I need to set many properties in QML elements from within C++. You may find it easier to expose these properties *from* C++ to QML, using a singleton type (for example) http://qt-project.org/doc/qt-5.0/qtqml/qtqml-cppintegration-definetypes.html#registering-singleton-objects-with-a-singleton-type Yes, I have to control many property values. I’m not sure how that matters.. see: http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlRegisterSingletonType-2 You can register your object instance as a singleton, exposing as many properties/methods as you like - there’s no limitations and it’s fairly easily done Theme properties in Silica are exposed through a singleton, for example. ___ SailfishOS.org Devel mailing list
[SailfishDevel] Harbour API additions
Ahoy, We have today added two new items to the Harbour-accepted list of supported APIs. = QtWebkit = Due to popular demand, we are now accepting applications using QtWebkit directly, both QML and C++. It should be noted that QtWebkit has no upstream support, and we do not have any real resources dedicated to working on it. = libmlite = libmlite is a small library primarily encompassing small pieces that were useful from libmeegotouch, like desktop file parsing. Its primarily intended purpose is to ease porting. Onward sails, The Harbour Crew ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] QWindow in main?
On 06 Dec 2013, at 10:32, Wim de Vries wsvr...@xs4all.nl wrote: For now I am just trying to get a QWindow working together with some QML. Problem starts with main. It is only about QQuickView. Where to got with my QWindow? Thanks. If you want to do OpenGL and QML together, you’ll need to use a QQuickView. QWindow is only useful for the case where you want to do all drawing yourself. See http://qt-project.org/doc/qt-5.1/qtquick/scenegraph-openglunderqml.html for an example of how this might work (pay particular attention to the Squircle class) BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Sharing version number (and other constants?) between .yaml/spec, .pro and .cpp/.qml
https://github.com/nemomobile/mlite/blob/master/rpm/mlite-qt5.yaml#L20 gives you https://github.com/nemomobile/mlite/blob/master/rpm/mlite-qt5.spec#L60 if you want to go all out gung-ho with automation, you can also do something like https://github.com/nemomobile/mlite/blob/master/src/src.pro#L3 in your project file for local builds. On 06 Dec 2013, at 23:45, Artem Marchenko artem.marche...@gmail.commailto:artem.marche...@gmail.com wrote: Hi All Does anybody know a way to share constants between .yaml and any other project file (preferably .pro, but any other way would do as well)? I sort of got tired to duplicate version numbers in .yaml and app's about dialog :) Writing app description in one place only would've been good too. Best regards, Artem. -- Artem Marchenko http://agilesoftwaredevelopment.comhttp://agilesoftwaredevelopment.com/ http://twitter.com/AgileArtem ___ SailfishOS.orghttp://SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Linking to qwidget, or any other method to access the clipboard
Hi Michael, The QClipboard pointer should also be available with QGuiApplication: http://qt-project.org/doc/qt-5.0/qtgui/qguiapplication.html#clipboard Or is there something else that I’m missing? BR, Robin On 02 Dec 2013, at 10:19, Michael Demetriou qwa...@gmail.com wrote: Hello, I'm trying to port speedcrunch to sailfish, and I have functionality that uses the clipboard (cover swipe copies last result to the clipboard), however since harbour does not allow linking to qtWidgets this is not possible. Is there a workaround to this? I am not using widgets for the interface, I just need to include QApplication. Thank you. Michael Demetriou ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Qt5Svg links against Qt5Widgets - rejected in Harbour
Hi Alessandro, On 27 Nov 2013, at 20:43, Alessandro Portale alessan...@casaportale.de wrote: my app uses QtSvg and got rejected because it requires the blacklisted QtWidgets. That was corrected a while ago: https://github.com/mer-packages/qtsvg/commit/b2d0ef6a21f3956830c6f4b89c19527193bdabbc This command, executed on the Emulator confirms it: ldd /usr/lib/libQt5Svg.so.5 ... libQt5Widgets.so.5 I don’t get that on my more recent device software: root@localhost:~% ldd /usr/lib/libQt5Svg.so.5 | grep -i wid (W47 - 11/27@21:19:16 CET) zsh: exit 1 An emulator update will fix this I’d guess. Now I wonder where that comes from? Shouldn't Qt for SailfishOS be configured with QT_NO_WIDGETS defined, so that stinkers like QSvgWidget are stripped from QtSvg? Not at present. Maybe in the future. BR, Robin ___ SailfishOS.org Devel mailing list
[SailfishDevel] Update on application naming for Harbour applications
Ahoy, In Iekku’s mail yesterday, we referred to application names needing to use a “dotted” form (e.g. com.example.myapp). It was brought to our attention that this isn’t factually possible at this time due to limitations in Qt Creator/qmake, so we’re unfortunately forced due to time limitations - so as to not inconvenience you developers - to change plans. The new requirement is that application names must start with a prefix of “harbour-“. The reason (if it wasn’t clear) for this requirement is so that applications do not clash with other installed packages on the device. We’re very sorry for the confusion. Thanks for understanding. Should you have any questions on this or anything else, feel free to send an e-mail as always! P.S. We’ll be launching a FAQ explaining this (and other store requirements) in detail early next week, unless anything unforeseen crops up. Happy hacking, The Jolla Crew ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Cannot launch app by clicking app icon in emulator
Hi, Running applications from SSH requires that the environment be correctly set up. See the files in /var/lib/environment/nemo. Developer mode (which I guess parts of which may filter back down to the SDK, at some point, maybe) will set this up for you when enabled, but in the meantime, you'll have to do it by hand. For diagnosing such problems, run (as root) journalctl -af which will output useful information about what is going on on the system. BR, Robin On Sun, Nov 17, 2013 at 8:20 AM, Stockona stock...@ovi.com wrote: My app launches fine when deployed by QtCreator. But clicking the app icon in emulator only showed a cover with Loading label, then the app died silently. I took a look at jolla-settings.desktop and didn't understand what was wrong. My .desktop looks like this [Desktop Entry] Type=Application Name=Stockona Icon=/usr/share/icons/stockona.png Exec=invoker --type=silica-qt5 -s /usr/bin/stockona Comment=Sailfish UI application For comparison, jolla-settings.desktop is [Desktop Entry] Type=Application Name=Settings ... Exec=invoker --single-instance --type=silica-qt5 -s /usr/bin/jolla-settings In both cases, I could not launch the apps by typing the exec command in terminal. Help please? ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Account management
Correct. I've started asking around to make sure we publish exact lists of what is and isn't off-limits for store usage ASAP, but for now, the working assumption should be that anything in Qt is OK, anything outside that is not. We'll of course want to expand that further, and will want help from you folks to do that over the course of time. BR, Robin On Thu, Nov 14, 2013 at 7:41 AM, Tone Kastlunger users.giulie...@gmail.com wrote: Hi sorry to drop in on this, but on a similar track, Jonni can you also confirm transfer-ui plugins not to be yet ready as well? Best, tortoisedoc On Thu, Nov 14, 2013 at 12:50 AM, Tigre-Bleu de...@tigre-bleu.net wrote: Ok, thanks for the info. I will then just wait for the Sailfish accounts control implementation details and implement everything in the app for the moment. Antoine - Mail original - De: Robin Burchell robin+me...@viroteck.net À: Sailfish OS Developers devel@lists.sailfishos.org Envoyé: Mercredi 13 Novembre 2013 23:41:48 Objet: Re: [SailfishDevel] Account management Hi, On Wed, Nov 13, 2013 at 9:26 PM, Tigre-Bleu de...@tigre-bleu.net wrote: Hi Jonni, nemo-qml-plugin-accounts-qt5 looks like what I'm looking for, but I have a hard time trying to figure out how it's working because I can't find a lot of documentation/examples. You most likely don't want that. It was an earlier evolution of things, and is not currently used on Sailfish. There is some stuff related to sharing/accounts that is not yet released at this time, and we will not be providing a public API for this initially. If I understand correctly and correlates to what I've read about accounts-ui for harmattan, it is only needed to put a service/provider xml file to the right path in the file system. Am I correct? If yes then I can't find the right path to put the files on the emulator. According to the tests on github ( https://github.com/nemomobile/nemo-qml-plugin-accounts/blob/master/tests/tests.pro ) the files shall be in /usr/share/accounts/services /usr/share/accounts/providers You will want services/provides files, and a UI to create accounts with if you want to look at hacking around on your device. Unfortunately, we aren't yet ready to promise forward compatibility for the sharing/accounts framework, so this is something that would not be accepted in the store at this time. However those files do not exist on the emulator and there is no app to add accounts also in the app menu of the emulator. Is this a limitation of the emulator or is there some package to install on the simulator that I didn't find? Accounts control is handled in the settings application, which is not included in emulator images at this time. BR, Robin ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Status of Sailfish SMS?
Hi, On Wed, Nov 13, 2013 at 11:08 PM, Seppo Tiainen seppo.tiai...@gmail.com wrote: Yes, that's the way to go. In Harmattan QML, there were: Qt.openUrlExternally(tel:012345x) for calls, and Qt.openUrlExternally(sms:01234567444 + ?body= + bodytext) for SMSs. tel: is already supported. sms: is not yet supported, and may not be supported in the initial software release, but is the planned initial public API for messaging and should not be complicated to support. I've made sure we try to prioritize it for an early update. We do not intend to expose the capability to directly send SMS to store-using applications for the reasons Jonni mentioned earlier. However: this does not restrict people from hacking around with the functionality on their own devices. The Messaging API from Qt Mobility never made the transition to the Qt 5 world, and we have no intentions of working on this at this time. BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Account management
Hi, On Wed, Nov 13, 2013 at 9:26 PM, Tigre-Bleu de...@tigre-bleu.net wrote: Hi Jonni, nemo-qml-plugin-accounts-qt5 looks like what I'm looking for, but I have a hard time trying to figure out how it's working because I can't find a lot of documentation/examples. You most likely don't want that. It was an earlier evolution of things, and is not currently used on Sailfish. There is some stuff related to sharing/accounts that is not yet released at this time, and we will not be providing a public API for this initially. If I understand correctly and correlates to what I've read about accounts-ui for harmattan, it is only needed to put a service/provider xml file to the right path in the file system. Am I correct? If yes then I can't find the right path to put the files on the emulator. According to the tests on github ( https://github.com/nemomobile/nemo-qml-plugin-accounts/blob/master/tests/tests.pro ) the files shall be in /usr/share/accounts/services /usr/share/accounts/providers You will want services/provides files, and a UI to create accounts with if you want to look at hacking around on your device. Unfortunately, we aren't yet ready to promise forward compatibility for the sharing/accounts framework, so this is something that would not be accepted in the store at this time. However those files do not exist on the emulator and there is no app to add accounts also in the app menu of the emulator. Is this a limitation of the emulator or is there some package to install on the simulator that I didn't find? Accounts control is handled in the settings application, which is not included in emulator images at this time. BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Bug in sailfish silica scroll feedback
Hi, This is already known and tracked internally. It's due to behavioural changes we ran into when switching from Qt 4 to Qt 5. We will either fix this for all cases, or disable it completely for the time being in a future SDK update. BR, Robin On Tue, Oct 29, 2013 at 9:19 PM, Dmitry energyc...@gmail.com wrote: Hi. As i understand i can report bug here. So steps to reproduce: 1. Run SDK components demo 2. at first screen put your finger at center of screen and move a little up and then down. Once you move down color of text become dim. have feedback 3. release you finger. 4. now just move down finger, and list is not scrolled and no feedback i think at step 4 color of text should be also dimed ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] MeeGo runtime support in Sailfish
Hi, On Thu, Oct 24, 2013 at 6:27 AM, Tone Kastlunger users.giulie...@gmail.com wrote: I noticed there is a minimal meego runtime in Saifish (/usr/include/mlite5); even tho I do not know the details about how MTheme co could work under Sailfish, are there any plans for an extensive meego runtime support? mlite contains a few small, useful pieces from libmeegotouch. Nothing more. libmeegotouch itself has no active maintainers, and is tied to X11/Qt 4, which are not part of our platform. We have no plans to work on it. Note that mlite is also not part of the public supported API, meaning it has no backward-compatibility guarantees on API or ABI (or even existing), so you should avoid relying on it. BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Problems porting our game to Sailfish - welcome any advice
Hi, You probably don't want to hear this, but please note that QtWidgets (which includes the QGraphicsView framework) is not really a supported configuration on Sailfish. It may work, it may not. If it breaks, you probably get to keep the pieces. Even if it does work, you should keep in mind that performance will be far from optimal, as you are going to be doing software rendering, and on top of that, you'll use SHM buffers on the Wayland side, which is going to be terrifically slow as IIRC it involves a full texture upload to the GPU each time you redraw. I also don't know whether our store intake rules will allow widgets-using applications. I hope not, for reasons of suboptimal user experience due to the above, for instance. Anyway, that aside: - Constantly redrawing is not a good idea, neither is assuming 60fps (not all displays refresh at 60fps). You should use QWidget::update when you need an update, and Qt will redraw as soon as it can. - Your packaging looks wrong (you will need a PkgConfigBR on Qt5Widgets) - I suggest that if you want more useful feedback, reducing your application to a small, self-contained example demonstrating your problem would be a good first step - if the problem is somewhere in your code, often, going through this process will make you realise the problem. Take a look at http://sscce.org/ for more information. All the best, Robin On Thu, Oct 24, 2013 at 4:20 PM, Duncan Waugh duncan_wa...@hotmail.co.uk wrote: Hello everyone, I've started work porting our Qt-based game from Symbian over to Sailfish and I'm hitting a pretty major roadblock at the moment. It looks like I haven't set something up in the graphics system properly and would be very grateful for any help that anyone can provide. A brief outline: * The application uses the QGraphicsView framework. We set up the QGraphicsView object once at the start of the game and then replace the QGraphicsScene object at various points as the user moves through the application. * We have overriden the drawForeground() method within the QGraphicsScene objects and manually pass the QPainter object that we receive to the various elements of the UI, which use it to draw to the screen. * The QGraphicsView object is set not to update itself. We have a timer in a manager class, which fires 60 times a second, from where we manually call repaint() on the QGraphicsView object. Current state: * All code has been tidied up to build under Qt5 and non-Sailfish components, such as Phonon, are currently #ifdeffed out. * On execution the game runs and moves through a couple of QGraphicsScenes, but only ever displays a white screen. The calls to QGraphicsView::repaint() are ignored and the QDisplayScenes only have their drawForeground() methods called once, directly after instantiation. Why we only get a white screen I'm also not sure. This is all on the latest emulator. An excerpt from the log is shown below with basic class hierarchy: DisplayScene -- QGraphicsScene BootupScene -- DisplayScene TitleMenuScene -- DisplayScene 0:Using Wayland-EGL 1:libpng warning: Malformed iTXt chunk 2: 3:calling QGraphicsView::SetScene() 4:DisplayScene::drawForeground QRectF(1,1 538x958) 5:BootupScene::UpdateNotification 52 6:GameManager::FrameTimerTick - repaint 7:GameManager::FrameTimerTick - repaint 8:BootupScene::UpdateNotification 52 9:GameManager::FrameTimerTick - repaint 10: GameManager::FrameTimerTick - repaint 11: 12: ... 13: 14: GameManager::FrameTimerTick - repaint 15: GameManager::FrameTimerTick - repaint 16: BootupScene::UpdateNotification 51 17; SWITCH 18: GameManager::FrameTimerTick - repaint 19: GameManager::FrameTimerTick - repaint 20: 21: calling QGraphicsView::SetScene() 22: GameManager::FrameTimerTick - repaint 23: TitleMenuScene::drawForeground 24: DisplayScene::drawForeground QRectF(1,1 538x958) 25: GameManager::FrameTimerTick - repaint 26: GameManager::FrameTimerTick - repaint 27: GameManager::FrameTimerTick - repaint 28: 29: ... 30: 31: GameManager::FrameTimerTick - repaint 32: User requested stop. Shutting down... 33GameManager::FrameTimerTick - repaint As you can see when the GameManager calls QGraphicsView repaint() we don't get any calls to the Scenes' drawForeground(). The setup code for the QGraphicsView is: 0:setScene(iScene); 1:setOptimizationFlags(QGraphicsView::IndirectPainting); 2:setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff); 3:setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff); 4:setRenderHint(QPainter::Antialiasing); 5:setCacheMode(QGraphicsView::CacheBackground); 6:setViewportUpdateMode(QGraphicsView::NoViewportUpdate); 7:resize(iScreenWidth, iScreenHeight); 8:viewport()-setAttribute(Qt::WA_AcceptTouchEvents); I'm assuming the issue is either here or that I have incorrectly set up the configuration files for
Re: [SailfishDevel] Application always active
Hi, On 22. sep. 2013, at 13:19, Marcin Mielniczuk marmistrz...@gmail.com wrote: I'm trying to utilze ApplicationWindow.applicationActive to set the cover text. But the onApplicationActiveChanged signal isn't emitted, and the applicationActive property is always true. Try Qt.application.active instead. applicationActive was needed due to details about how our X11 stack worked. In a future release, applicationActive is deprecated (and aliased to Qt.application.active). There were some fixes required to make it work, however, so it could be the case that it simply won't work until a future SDK update. BR, Robin ___ SailfishOS.org Devel mailing list
