ubuntu-touch-coreapps team mailing list archive

[David Planella <david.planella@xxxxxxxxxx>]

On Sun, Feb 16, 2014 at 2:42 PM, Sergio Schvezov <
sergio.schvezov@xxxxxxxxxxxxx> wrote:

>
> On 16/02/14 07:29, David Planella wrote:
>
>  On Sun, Feb 16, 2014 at 2:28 AM, Sergio Schvezov <
>> sergio.schvezov@xxxxxxxxxxxxx <mailto:sergio.schvezov@xxxxxxxxxxxxx>>
>> wrote:
>>
>>     Just a quick self follow up
>>
>>     After removing my QtCreator config I get the Build/Ubuntu submenu
>>     and could explore the context of the problem a bit more.
>>
>>     The desktop part can be resolved by changing the
>>     -set(DESKTOP_FILE "${PROJECT_NAME}_${APP_NAME}.desktop")
>>     +set(DESKTOP_FILE "${PROJECT_NAME}.desktop")
>>
>>
>> Thanks Sergio for looking into that. I think Nekhelesh's point was that
>> before the cmake migration it was much easier to test pure QML apps. Adding
>> cmake to the mix now requires a build step that needs to be done outside of
>> Qt Creator to generate the .desktop file.
>>
>> Before, pressing Ctrl+F12 would just copy the files over to the device
>> and run the app. Granted, this would not test confinement, but for rapid
>> app development (and especially if it's an app that has been tested to work
>> in confinement) it is very convenient. App confinement could then be tested
>> with a click build and install before release.
>>
>
> This hid the fact that the source as it was, was insufficient to build a
> quality grade click package; ie; I cannot
>
> bzr branch lp:ubuntu-clock-app trunk
> cd trunk
> bzr export app
> click build app
>
> If I do that, I would get a click that:
>
>  * includes debian dir
>  * has a desktop with:
>      o Exec=.*/usr/share/ubuntu-clock-app/ubuntu-clock-app.qml
>      o Icon=/usr/share/ubuntu-clock-app/.*
>  * includes a test dir
>  * includes un-gettexed po files
>
> If you have a better idea on how to get this commonly fixed, I'll wait for
> an MR; cmake seemed like the right tool for the job to me.
>
>
I'm not debating that, and I agree that cmake is probably the best way to
automate that for CI. However, I feel we shouldn't compromise the developer
experience.

One of the successes of the core apps project has been the low entry
barrier the QML projects have offered. I would be keen to keep it as it is,
and encourage core app developers to use Qt Creator and dogfood our
toolset, rather than resorting to the command line.

I'd like to find a way to have the best of both worlds: automation for CI
and an optimal app developer experience. From what I gather, the only thing
preventing the previous "run on device" workflow is the prerequisite to
generate the .desktop file. Thus what I'd suggest to keep things simple is
to simply commit a dummy .desktop file to the project, so that Qt Creator
can find it. The CI system could still then generate it from the .in file
an overwrite it.


>  But I think the main point here is that we've broken Qt Creator's
>> workflow for pure QML apps by introducing a build step as a requirement.
>> Can we still get the best of both worlds, perhaps by adapting Qt Creator's
>> scripts (e.g. the one that is called by pressing Ctrl+F12)?
>>
>
> ctrl+12 should be fixed; I would prefer a common workflow for everyone
> instead pure qml which 3 already aren't:
>
>  * music
>

Note that music is going to be back at being a pure QML app as soon as
media-hub and the mediascanner2 QML bindings land.


>  * terminal
>  * file manager
>
> The new reminders application as well.
>
>
>      but to be honest, I think that qtcreator should look into the
>>     manifest to search for desktop files; this would allow for an easy
>>     transition to multiple apps per package namespace when it arrives.
>>
>>
>> Would you mind filing a bug for that? I also agree that resolving this
>> dynamically would be much better than hardcoding it to a given .desktop
>> file name.
>>
>
> https://bugs.launchpad.net/ubuntu/+source/qtcreator-
> plugin-ubuntu/+bug/1280781


Thanks!


>
>
>      After hacking the desktop file that in I saw why it wanted to sed it:
>>     Exec=/usr/bin/export
>>     DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-LRsqEGysw5;
>>     APP_ID=com.ubuntu.clock qmlscene
>>     /home/phablet/dev_tmp/com.ubuntu.clock/ubuntu-sdk-13.10-
>> armhf/click_package/share/qml/com.ubuntu.clock/com.ubuntu.clock.qml
>>     --desktop_file_hint=/home/phablet/.local/share/
>> applications/com.ubuntu.clock.desktop
>>
>>     It really should be installing the click package and using that so
>>     it uses upstart-app-launch to launch the application under
>>     confinement.
>>
>>
>> I'm not sure I can follow this one. Could you elaborate on what's needed
>> to do here, whether fix the cmake rules or the Qt Creator scripts?
>>
>
> This is QtCreator; I don't see why when someone does ctrl+12 it doesn't
> just build the click package on the fly and run it. I may be missing
> something here.
>
>  David.
>>
>>
>>     On 15/02/14 21:48, Sergio Schvezov wrote:
>>
>>
>>         On 15/02/14 18:53, Nekhelesh Ramananthan wrote:
>>
>>             This is a request to revert the cmake transition for all
>>             the core apps since it is effectively blocking crucial
>>             application testing on the device through QtCreator.
>>             Before the cmake transition, my work flow comprised of
>>             implementing a patch/feature and then immediately testing
>>             it on the device by pressing Ctrl+F12 through Qtcreator.
>>             This made testing applications on the device quite easy.
>>             However as now, that no longer works since QtCreator now
>>             complains of a missing desktop file. I have tried fixing
>>             it by discussing it with zBenjamin and balloons on IRC,
>>             however at the end of the day this is still broken.
>>
>>
>>         What does ctrl+12 actually do? Does it require writable mode?
>>
>>
>>             I understand the major motivation for the cmake transition
>>             was to help easily build click packages (using
>>             click-buddy) and ready them for deployment to the device.
>>             However this is already easy enough to do in Qtcreator by
>>             simply pressing *Ctrl+F12* or rather using the "*Install
>>             on Device*" feature. As far as I understand, click-buddy
>>             doesn't help with running autopilot tests on the device
>>             either. I am really questioning the benefit of the cmake
>>             transition. If there is something that I am missing here,
>>             please do explain this to me.
>>
>>
>>         The other major motivation is to actually build click packages
>>         without any hacks; as it was before all the packages had
>>         hardcoded paths for the debs.
>>
>>         If you run the autopilot tests in 'deb' mode you aren't really
>>         testing on the target. To really test on the target you need
>>         the click package built, installed, and run in confinement;
>>         using debs doesn't provide any of that.
>>
>>         If the installing and testing requires writable mode on
>>         devices, that it is also broken in my opinion.
>>
>>
>>             If you agree to the request, please submit patches
>>             reverting the commits done.
>>
>>
>>         If there's no hard coding, I'm fine. But there was serious
>>         hard coding before.
>>
>>         Although I say, do not despair :-)
>>
>>         Immediate temp solution, is to make the build dir your actual
>>         branch in Project/Build
>>         http://ubuntuone.com/3FqnDSLJpg2CUSYAtwj2oM
>>
>>         The reason you can't run locally in QtCreator is that, well,
>>         the system doesn't know about out of source builds that
>>         easily; and something like this is needed:
>>
>>         https://code.launchpad.net/~sergiusens/ubuntu-clock-app/
>> run_from_qtcreator/+merge/206598
>>         <https://code.launchpad.net/%7Esergiusens/ubuntu-clock-app/
>> run_from_qtcreator/+merge/206598>
>>
>>
>>
>>         For running autopilot and installing on the device I would
>>         need more info on what you currently do.
>>
>>
>>
>>     --     Mailing list: https://launchpad.net/~ubuntu-touch-coreapps
>>     <https://launchpad.net/%7Eubuntu-touch-coreapps>
>>     Post to     : ubuntu-touch-coreapps@xxxxxxxxxxxxxxxxxxx
>>     <mailto:ubuntu-touch-coreapps@xxxxxxxxxxxxxxxxxxx>
>>     Unsubscribe : https://launchpad.net/~ubuntu-touch-coreapps
>>     <https://launchpad.net/%7Eubuntu-touch-coreapps>
>>     More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>