[03:20] <liuxg>  has anyone used actions in MainView? it seems that it does not show the icon
[07:11] <dholbach> good morning
[08:54] <rarara> hi guys. I am gaving trouble including my c++ code in the project. First problem: #include <iostream.h> is not found, neither are all the other imports.
[11:34] <liuxg> I have a horizontal ListView, snapMode: ListView.SnapOneItem, when view.currentIndex is changed, the ListView's view is changed. The problem is that the speed of moving is very slow. Does any one know how to set the moving speed. My source code is at bzr branch lp:~liu-xiao-guo/debiantrial/visualitemmodel
[11:46] <sverzegnassi> liuxg: http://doc.qt.io/qt-5/qml-qtquick-listview.html#highlightMoveDuration-prop
[11:47] <liuxg> sverzegnassi, thanks. I just tried highlightMoveVelocity, and it seemed to the right one.
[12:02] <didrocks> zbenjamin: hey, with the .pro template, how/when is pot built and how are the po refreshed from it? Doesn't seem that the traditional "run" debug or release does it?
[12:06] <zbenjamin> didrocks: on make i think
[12:06] <didrocks> zbenjamin: there isn't the traditional make pot or make po target generated by .pro
[12:06] <zbenjamin> didrocks: well the po are not automatically updated afaik
[12:06] <didrocks> zbenjamin: you have some "po" target generally in build systems for merging
[12:07] <zbenjamin> didrocks: i modelled it after the cmake stuff. I think it does not exist there as well
[12:07] <zbenjamin> didrocks: but enlighten me if you know the command to do that automatically
[12:07] <didrocks> zbenjamin: ok, sounds like something we should get a fix at, I know the general command like msgmerge and so on, but we should look if there isn't some qmake automation already
[12:08] <didrocks> zbenjamin: ok, I'll dig into this I guess :p
[12:09] <zbenjamin> didrocks: well traditionally qmake would not use po and pot files
[12:09] <zbenjamin> didrocks: it would use lupdate an lrelease
[12:10] <zbenjamin> didrocks: but lp does not have support for these afaik
[12:10] <didrocks> zbenjamin: yep, lp only support .pot (and refresh .po for you based on this)
[12:12] <didrocks> zbenjamin: the cmake templates have rules for it
[12:13] <didrocks> zbenjamin: po/CMakeLists.txt
[12:13] <didrocks> I know more cmake than qmake, do you think you can translate those into qmake?
[12:14] <didrocks> (I think I can't really promote our qmake template by default as long as we don't have proper i18n support in the tools)
[12:16] <didrocks> (same issue for the desktop file, which is bug #1443351)
[12:32] <zbenjamin> didrocks:  i do not see any code that updates the po files from the pot
[12:33] <didrocks> zbenjamin: this is:
[12:33] <didrocks> add_custom_target(${DESKTOP_FILE_NAME} ALL
[12:33] <Elleo> 3/7
[12:33] <Elleo> oops
[12:33] <didrocks>     COMMENT "Merging translations into ${DESKTOP_FILE_NAME}"
[12:34] <didrocks>     COMMAND LC_ALL=C ${INTLTOOL_MERGE} -d -u ${CMAKE_SOURCE_DIR}/po ${CMAKE_BINARY_DIR}/app/${DESKTOP_FILE_NAME}.in ${CMAKE_BINARY_DIR}/app/${DESKTOP_FILE_NAME} > /dev/null
[12:34] <didrocks> )
[12:34] <didrocks> for the desktop file
[12:34] <zbenjamin> didrocks: this just updates the desktop file
[12:34] <zbenjamin> didrocks: yeah
[12:35] <didrocks> zbenjamin: but you are right, it only refreshes the .pot file, not the .po, we can fix this easily
[12:35] <didrocks> (in cmake)
[12:35] <didrocks> zbenjamin: but at least it builds the .pot files which qmake doesn't, right?
[12:36] <zbenjamin> didrocks: qmake does create the pot file
[12:36] <didrocks> zbenjamin: hum, did you change the template recently? It didn't for me
[12:36]  * didrocks tries to create one qmake project now
[12:37] <zbenjamin> didrocks: ah there is a bug, do not rename the hook
[12:37] <zbenjamin> didrocks: leave it to be "app"
[12:37] <zbenjamin> didrocks: we just stumbled over that yesterday
[12:37] <didrocks> zbenjamin: ah, so probably this :p
[12:37] <didrocks> I guess you then rely on launchpad for the pot -> po, right? and when do you build the .mo then?
[12:38] <didrocks> also:     $$files(app/*.qml,true) \
[12:38] <didrocks> but that doesn't work for files in subdir, right?
[12:38] <didrocks> (or is it the true param?)
[12:38] <zbenjamin> the true param enables recursive search
[12:38] <didrocks> ok
[12:39] <zbenjamin> change it to:  $$files(*.qml,true)
[12:39] <didrocks> yeah, same for js and such
[12:39] <didrocks> and what do you build the .mo then? (and how do you handle the desktop file?)
[12:39] <didrocks> (also, another bug with the hook: aptest.commands = bash $$PWD/app/tests/autopilot/run
[12:41] <didrocks> and template is named template.pot (doesn't use the gettext domain)
[12:41] <zbenjamin> didrocks: http://bazaar.launchpad.net/~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk/view/head:/ubuntu-click-tools.prf#L61
[12:43] <didrocks> ah ok, so only on click build (which makes sense in a way)
[12:43] <zbenjamin> didrocks: well it happens when you load(ubuntu-click)
[12:44] <zbenjamin> didrocks: when you create a new po file you need to rerun qmake so its picked up
[12:45] <zbenjamin> didrocks: thats this part
[12:45] <zbenjamin> # specifies all translations files and makes sure they are
[12:45] <zbenjamin> # compiled and installed into the right place in the click package
[12:45] <zbenjamin> UBUNTU_PO_FILES+=$$files(po/*.po)
[12:45] <didrocks> zbenjamin: yeah, so only the ide integration is missing? (let me confirm, but it seems that I running through the IDE doesn't create the .pot at first)
[12:45]  * didrocks tries a new blank project
[12:46] <zbenjamin> didrocks: as i said, as long as you do not rename the hook ;)
[12:46] <didrocks> zbenjamin: yeah, just did that, and indeed, this works
[12:46] <didrocks> zbenjamin: one issue is that you don't specify CHARSET by default though
[12:46] <kivi> zbenjamin, just curious if you could get around to reviewing this branch https://code.launchpad.net/~akiva/qtcreator-plugin-autopilot/Improve-code-issue-readability
[12:47] <zbenjamin> didrocks: fyi this is just a problem in the qtquick app template
[12:47] <kivi> tldr; it aligns the source file's order with the header, and it makes the issues more readable.
[12:48] <zbenjamin> kivi: if you move code around please do not make additional changes
[12:48] <zbenjamin> kivi: that way i can not see what was changed
[12:48] <kivi> zbenjamin, sure. its a small change though. Only a function was changed
[12:49] <didrocks> zbenjamin: hum, but rerunning the app after copying and fixing the hook name doesn't create the .mo file, contrary to "qmake . && make"
[12:49] <didrocks> (rerunning from the IDE)
[12:49] <didrocks> we don't load(ubuntu-click) in that case?
[12:49] <zbenjamin> didrocks: ubuntu-click is always loaded
[12:50] <didrocks> zbenjamin: want me to open a bug on this? (there is already one about the desktop file, I can retarget the other one for charset + hook renamed) and this one?
[12:50] <zbenjamin> didrocks: yeah add it to that one
[12:50] <zbenjamin> didrocks: however try make distclean after renaming
[12:51] <zbenjamin> didrocks: like:   rename -> make distclean -> qmake -> mak
[12:51] <zbenjamin> e
[12:51] <didrocks> zbenjamin: yeah, that works, I guess we need to fix the template and get the integration done
[12:51] <didrocks> let me write to it and tell me what you think
[12:52] <zbenjamin> didrocks: ok
[12:54] <zbenjamin> didrocks: would be awesome to get launchpad support for lrelease and lupdate . The developer experience is much better imho
[12:54] <zbenjamin> didrocks: you have a great UI tool that helps with the translations
[12:57] <didrocks> zbenjamin: well, most of the FLOSS projects standardized around intltool nowdays, I think it's good enough and there are some UI tools. I don't think changing this would be a big priority
[12:57] <didrocks> zbenjamin: tell me how bug #1481325 sounds?
[12:58] <didrocks> zbenjamin: also, qmake is the third option here, didn't you want to rename it to be first?
[12:58] <didrocks> (for QML app with simple UI)
[12:59] <zbenjamin> didrocks: we did, and it should be released already
[12:59] <zbenjamin> didrocks: if you are on vivid do you use the ppa?
[12:59] <didrocks> zbenjamin: yep, I also have hookname == appname by default
[13:00] <didrocks> (I thought that was in the same release)
[13:00] <didrocks> zbenjamin: http://people.canonical.com/~didrocks/tmp/order_new_project.png
[13:01] <didrocks> (see for the other, qmake is first, not on the first option though)
[13:01] <didrocks> also, unsure what is "QtQuick App with QML UI" vs "QML App with C++ plugin"
[13:03] <zbenjamin> didrocks: wtf, ok seems shame is on me, i misread (cmake) and (qmake) seems the cmake version is not first
[13:04] <zbenjamin> didrocks: QtQuickApp == native application, QML APp with C++ plugin == app using qmlscene loading a c++ plugin
[13:04] <didrocks> zbenjamin: ahah, on reading, I prefer that TBH :p
[13:04] <didrocks> zbenjamin: want a bug? :)
[13:05] <didrocks> zbenjamin: ok on QtQuickApp, so it seems we would prefer QtQuickApp over QML App with C++ plugin for things handling c++? (or is there any preference?)
[13:06] <zbenjamin> didrocks: no preference, its up to the dev if he wants a main.cpp or not
[13:07] <didrocks> ok
[13:08] <zbenjamin> didrocks: well i personally would prefer the qtquick app because thats how the Qt devs suggest it to do.
[13:08] <zbenjamin> didrocks: but its just a personal opinion
[13:08] <didrocks> zbenjamin: so not using qmlscene but having our own "starter"
[13:11] <zbenjamin> didrocks: no starter at all, the app is its own starter
[13:11] <zbenjamin> didrocks: just the bare minimum what the app needs to startup the qml surface, instead of all the other stuff qmlscene supports
[13:12] <didrocks> zbenjamin: ok, making sense
[13:12] <didrocks> zbenjamin: so, on the i18n, keep me posted if you need any other info, I'm just using the workaround for module name for now
[13:15] <zbenjamin> didrocks: ok , sorry for the inconvenience though :(
[13:16] <didrocks> zbenjamin: no worry, it's more minor than what I was afraid of :)
[14:32] <kalikiana> zsombi: fyi if you haven't seen https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/swipeListItemWithActiveChild/+merge/266390 one comment
[15:06] <aquarius> seb128, ping about avahi-daemon on the phone
[15:06] <seb128> aquarius, wrong person to ping I guess
[15:06]  * aquarius grins
[15:06] <seb128> I've no clue about avahi on the phone
[15:06] <ogra_> aquarius, not doable
[15:07] <ogra_> it needs to be able to send constant broadcasts ... cant do that without keeping the wifi permanently on
[15:07] <seb128> ogra_, convergence?
[15:07]  * ogra_ had this discussion multiple times
[15:07] <ogra_> seb128, yeah, but only via IPs :P
[15:07] <aquarius> seb128, you may well point me at someone else! At the moment the phone doesn't run avahi, and I'm wondering whether it can. Before that, though, I want to confirm something which I think you'll know -- if I put a file in /etc/dbus/services/*.service which advertises a service on a port, is it avahi-daemon that uses those files?
[15:08] <ogra_> aquarius, see my answer
[15:08] <seb128> aquarius, I'm pointing you to ogra then ;-)
[15:08] <aquarius> ogra_, agreed that's a reason against it, but the iphone manages it, so it can't be, y'know, impossible to keep the wifi on sometimes or something; I'm just exploring what the deal is ;)
[15:09] <ogra_> aquarius, there was an avahi implementation that allowed to work with not constantly running, but lennart abandoned it very early
[15:09] <ogra_> aquarius, pitti is acually our avahi specialist
[15:09] <aquarius> seb128, :-) I think I'm right that it's avahi-daemon which reads those files and advertises the service, yes? Even if we've decided to not do that for ogra_ reasons ;0
[15:10] <seb128> aquarius, I've no clue about avahi, maybe pitti does
[15:10] <aquarius> seb128, cheers; will talk to pitti!
[15:10] <aquarius> ogra_, ah, so ios has a zeroconf implementation which doesn't require wifi on always or something, and we don't?
[15:10] <aquarius> ogra_, I assume it's hard to make it so it only works *when* wifi is on?
[15:11] <ogra_> aquarius, i would guess so ... i always have a hard time imagining the IOS source in my dreams :P
[15:11] <aquarius> ogra_, like, put "start on network up; avahi-daemon start" in /etc/init/avahi or whatever?
[15:12] <ogra_> in any case there was a mdns implementation that didnt need to run permanently
[15:13] <aquarius> it'd certainly be cleverer to have an avahi which ran all the time but knew to not do any work when there was no wifi, but wouldn't just starting avahi on wifi-up and killing it on wifi-down be OK? Or is that a bad idea too?
[15:13] <ogra_> there must be a blog entry from lennart about it somewhere
[15:21] <aquarius> ogra_, separate issue, then (if you don't know I'll ask pitti); what's required to have avahi-daemon on the phone? If I switch it to apt rather than system-image and apt-get install avahi-daemon, would you expect it to work? (Even if it eats my battery?)
[15:21] <ogra_> aquarius, mightz or might not, worth a try i guess :)
[15:21] <ogra_> i think it will depend on the fact if it needs writable dirs that arent writable currently
[15:22] <aquarius> ogra_, ya, this is what I don't know :)
[15:22] <ogra_> well, if you find missing dirs you can just add them to the config and reboot
[15:25] <aquarius> ogra_, what I want is for the phone to run an ssh server, and advertise it over zeroconf, so that it shows up automatically in Nautilus. The nautilus bit of this already works -- if I can make the phone bit work then I can lobby jdstrand about how it'd be a good idea for people even if less good for security ;)
[15:26]  * ogra_ uses ssh:// all the time with the phone :)
[15:27] <aquarius> ya, but that's because you know your phone's IP address, which is not information sensibly available to, say, my dad :)
[15:27] <ogra_> sure
[15:27] <aquarius> hence avahi -- and then it just appears in Nautilus's Browse Network folder, which is fantastic. Automatic phone-to-laptop appearance for Ubuntu users.
[16:07] <kalikiana> aquarius: +1000
[16:08] <aquarius> kalikiana, ya, hence wanting it. But it needs avahi, which will keep the wifi network powered up the whole time, so ogra_ says :(
[16:08] <ogra_> well, talk to pitti
[16:08] <ogra_> or re-vivie the other daemon (of which i forgot the name) that lennart abandoned
[16:09] <ogra_> that was able to work on-demand
[16:09] <aquarius> ogra_, just so I understand -- the problem is that it keeps the wifi *radio* on? So starting avahi on wifi connection and killing it on wifi disconnect won't help, because the problem is that the wifi card isn't able to sleep?
[16:10] <ogra_> aquarius, it needs a working IP stack ... constantly
[16:10] <ogra_> so it is more than just the radio
[16:10] <aquarius> ogra_, and the phone... shuts down the IP stack when nobody's using it, even if you're connected to wifi?
[16:11] <aquarius> sorry that you have to give me the Dummies' Guide To How The Phone Works :)
[16:11] <ogra_> well, the phone shuts down the radio ... and tears down  the IP stack alongside
[16:11] <aquarius> ogra_, ah, and avahi then starts up the IP stack again? Or avahi explodes because it doesn't have an IP stack?
[16:11] <ogra_> the latter
[16:12] <aquarius> right, I get you now.
[16:12] <aquarius> and we don't want to stop and start avahi when the phone shuts down the radio, because we'll be doing it a lot and just starting up avahi will itself use lots of battery?
[16:12] <aquarius> could *suspend* avahi, but it probably doesn't like that either :)
[16:12] <kalikiana> ogra_: this one? http://0pointer.de/lennart/projects/nss-mdns/
[16:13] <didrocks> ogra_: how are we working on wifi then, like for push notification? We put up the wifi + IP stack up again at x number of seconds interval?
[16:14] <ogra_> didrocks, it gets woken up every 5 min and polls for notifications
[16:14] <didrocks> ogra_: ah, so let's say I get a new email, and even with push notification up, it can wait for 5 minutes before getting notified?
[16:14] <ogra_> yes
[16:15] <didrocks> interesting, thanks for the info :)
[16:15] <aquarius> indeed. annoying, eh? :)
[16:15] <ogra_> kalikiana, i'm not sure, but yeah, that could have been it
[16:15] <didrocks> not sure how the google "low energy connexion constantly up" works
[16:16] <kalikiana> ogra_: it says in the scription it's implementing dns via zeroconf and can be run without avahi
[16:16] <didrocks> (it's a persistent xmpp one)
[16:16] <ogra_> kalikiana, well, it has  big fat warning about security probs when not using avahi with it :)
[16:16] <ogra_> ..."Thus, nss-mdns will not work unless Avahi is running! That makes Avahi essentially a hard dependency of nss-mdns. Pass --enable-legacy to reenable the mini mDNS stack again."...
[16:17] <kalikiana> ogra_: yes, a very useful warning given 0 reasoning...
[16:17] <kalikiana> the description only points out that ipv6 support will be incomplete
[16:17] <ogra_> so you would have to use that flag but apparently open security holes
[16:18] <kalikiana> yet he did write the code, surely he had a point other than to release insecure code
[16:18] <ogra_> anyway, talk to pitti ... this was iterated over multiple times in the last years
[16:18] <kalikiana> *nod*
[16:19] <ogra_> and always decided to be not feasible for now
[16:19] <ogra_> (probablly something changed though ... )
[16:19] <zsombi> kalikiana: got back home
[16:20] <zsombi> kalikiana: the click is tested in the tst_listitem.qml
[16:20] <ogra_> aquarius, btw, with snappy that might be easier ... (teh webdm snap ships its own mini avahi for example)
[16:20] <zsombi> kalikiana: that has been tested before, the click should happen if you don't start swiping over the active component
[16:21] <zsombi> kalikiana: so far that test was there alone, the swipe just got introduced
[16:22] <kalikiana> zsombi: the new test case has a different setup. that's not testing the click
[16:23] <zsombi> kalikiana: hmm... the new test case should test that the swipe does not produce click on the button...
[16:23] <zsombi> kalikiana: ahh, you're right, the signal spy target should be the button, not the item
[16:23] <zsombi> kalikiana: I'll fix it
[16:25] <kalikiana> zsombi: yep
[16:27] <zsombi> kalikiana: just fyi, I may need to redo the swipe logic... design wants to have the ListItem swipable only thru touch... :/
[16:30] <kalikiana> zsombi: I've seen some discussion in the backlog. not sure why it matters much to design, but it for sure will be fun for any developer who doesn't have a touch screen on their development machine...
[16:31] <zsombi> kalikiana: right, that's why I'm trying to back this topic a bit...
[16:31] <didrocks> zsombi: agreed, as long as we don't have a "touch emulator" for developers, that doesn't sound like a good move
[16:32] <didrocks> as, how to test it on your desktop?
[16:32] <kalikiana> free touchscreen for everyone :-P
[16:32] <zsombi> LOL
[16:32] <didrocks> "download the SDK, get a free toy"
[16:32] <ogra_> just ship it with the iso
[16:32] <zsombi> free Willy for everyone... wait... that's free anyway :D
[16:33] <kalikiana> lol
[16:33] <didrocks> seriously, I think it's something to really put in perspective with design
[16:33] <zsombi> yep
[16:35] <zsombi> didrocks: kalikiana: we have the launcher, that can do mouse-to-touch... maybe we should start promoting it?
[16:35] <didrocks> zsombi: start promoting it to me then! I even don't know what this is :p
[16:36] <zsombi> didrocks: it's a launcher we use to test touch related functionality on desktop
[16:37] <didrocks> zsombi: sounds interesting, is it installed and integrated with the sdk?
[16:37] <zsombi> didrocks: but it is only available in tests :(
[16:37] <didrocks> ah
[16:37] <didrocks> so yeah, we should probably do this first
[16:37] <zsombi> right
[16:37] <didrocks> zsombi: is it only for mouse-to-touch or also handle things like calling services like media-hub emulation?
[16:37] <zsombi> but then we're back to the 3year discussion, should we have our own launcher, or should we use qmlscene... :/
[16:37] <zsombi> didrocks: no, only mouse-to-touch
[16:38] <didrocks> zsombi: I started to dream :)
[16:38] <zsombi> didrocks: mention it to kalikiana, he will get mad :D
[16:38] <didrocks> heh, you already pinged and ruined his evening I guess :p
[16:39] <didrocks> but at least an easy way to simulate those touch interactions seem a prerequisite to remove this swap with mouse if design really wants to
[16:39] <kalikiana> zsombi: grrrrrr
[16:39] <didrocks> (I find it weird to break pattern that people know on other platforms though)
[16:40] <kalikiana> didrocks: it's basically a slim replacement for qmlscene and it aids with testing since it can open qml unit tests and simulate touch events, things qmlscene can't
[16:41] <zsombi> didrocks: qmlscene aint suppose dto be used by any platform for released projects
[16:41] <zsombi> it's a prototyping tool, which helps you to run your QML apps...
[16:42] <didrocks> so yeah, let's maybe a better way to run this launcher to emulate touch events for developers (independent of the design discussion, but a prerequisite IMHO)
[16:42] <kalikiana> didrocks: it's been discussed to death that qmlscene is officially a "developer tool" and now we have a dozen variants of it and still use it
[16:42] <didrocks> kalikiana: yeah, I remember those discussions
[16:42] <didrocks> I'm unsure how many pure QML project we have though
[16:43] <didrocks> I guess as soon as someone followed some C++ tuts, they created their own main.cpp
[16:43] <kalikiana> well, pure as well as qml+plugin
[16:43]  * ogra_ guesses the majority of click packages in the store that arent webapps are plain QMl
[16:43] <didrocks> yeah… from previous discussion, I got that :p
[16:44] <kalikiana> and almost all of them use qmlscene, if not oxideqmlscene
[16:44] <ogra_> only a few use C++ extensions i guess
[16:45] <zsombi> ogra_: actually there are few (mzanetti's ones are I think all) which use CPP runner, so the qml is loaded from the cpp and the models are exposed straight from the loader code
[16:46] <zsombi> not even using extension plugins...
[16:46] <ogra_> a few, yeah :)
[16:46] <ogra_> i doubt it is the majority though
[16:46] <zsombi> most likely not...