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 < [email protected]> 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 <[email protected] > > wrote: > >> On Sun, Feb 16, 2014 at 2:42 PM, Sergio Schvezov < >> [email protected]> wrote: >> >>> >>> On 16/02/14 07:29, David Planella wrote: >>> >>> On Sun, Feb 16, 2014 at 2:28 AM, Sergio Schvezov < >>>> [email protected] <mailto:[email protected]>> >>>> 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 : [email protected] >>>> <mailto:[email protected]> >>>> 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 : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-touch-coreapps > More help : https://help.launchpad.net/ListHelp > >
-- Ubuntu-quality mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
