ubuntu-touch-coreapps team mailing list archive

[Pat McGowan <pat.mcgowan@xxxxxxxxxxxxx>]

CC Zoltan and Ben as I doubt they are on this mailing list.

Guys please check the bug entered by Nicholas for an explanation. I believe
this work is already planned.

Pat


On Mon, Feb 17, 2014 at 1:40 PM, Nicholas Skaggs <
nicholas.skaggs@xxxxxxxxxxxxx> wrote:

> The goal of these changes, and my pushing for the click-buddy tool was to
> solve the app developer workflow. I want a sane and sensible workflow for
> app developers to make it easy and useful to incorporate testing into their
> development process.
>
> Changing to cmake, as Sergio mentioned, was to allow for proper click
> package building, and from that, we should be able to easily deploy and
> test those packages via qtcreator to the emulator or phone. My original bug
> on this sort of spells this out.
> https://bugs.launchpad.net/phablet-tools/+bug/1269163
>
> Perhaps we should open a bug that reflects this desire and file it against
> qtcreator as well as phablet-tools so it could be tracked more easily? That
> might be a useful thing, so I've done so. If nothing else it will push
> Sergio to finish click-buddy. No pressure <3
>
> https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1281234
>
> Nicholas
>
>
> On Mon, Feb 17, 2014 at 3:21 AM, David Planella <david.planella@xxxxxxxxxx
> > wrote:
>
>> 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
>>>>
>>>>
>>>>
>>>
>>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-touch-coreapps
> Post to     : ubuntu-touch-coreapps@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-touch-coreapps
> More help   : https://help.launchpad.net/ListHelp
>
>