**** BEGIN LOGGING AT Tue Jan 13 02:59:59 2015
Jan 13 05:28:21 <DougReeder> Hey, I’m trying to setup a Google C+DAV account, & after authenticating my password, it wants me to “copy this code…to your application”.
Jan 13 05:48:24 <Herrie|2> DougReeder: That should work automagically I think
Jan 13 05:48:28 <Herrie|2> Let me try on my N4
Jan 13 05:48:46 <DougReeder> thanks
Jan 13 05:49:15 <DougReeder> It worked fine wit the same account in December.
Jan 13 06:13:22 <Herrie|2> DougReeder: I don't even get that far on latest nightly build :D
Jan 13 06:13:23 <Herrie|2> :S
Jan 13 06:13:42 <Herrie|2> Just get a white screen with "Sign In with Google" on top when trying to add Google C+DAV
Jan 13 06:13:44 <DougReeder> I’m using latest stable.
Jan 13 06:14:09 <DougReeder> I haven’t checked the log.
Jan 13 06:14:37 <Herrie|2> Also I noticed that the gesture area doesn't always allow me to minimize the app ;S
Jan 13 06:14:38 <Herrie|2> :S
Jan 13 06:14:52 <Herrie|2> Seems like some bugfixing created some other bugs :P
Jan 13 06:15:21 <DougReeder> … well, latest stable as of several days ago.
Jan 13 06:18:48 <DougReeder> I can add a Yahoo C+DAV account without any problems
Jan 13 06:19:44 <Herrie|2> Hmmz
Jan 13 06:19:49 <Herrie|2> Well I have latest nightly
Jan 13 06:20:06 <Herrie|2> Seems window management changes in Luna-Next-Cardshell might have some side effects there
Jan 13 06:20:20 <Herrie|2> I cannot close teh accounts window after I close this google screen with the coe
Jan 13 06:20:27 <Herrie|2> I can move the card but not swipe it up
Jan 13 06:20:58 <DougReeder> Those sound like different issues than I’m seeing.
Jan 13 06:21:42 <Herrie|2> Well I eventually after some tries get to the screen where I can login to google, it gives me teh code to copy
Jan 13 06:22:02 <Herrie|2> When I close that window, I go back to the accounts app but I cannot focus on it or close it
Jan 13 06:22:23 <Herrie|2> morphis did some rework on window management recently which I suspect is to blame for that bug
Jan 13 06:22:29 <Herrie|2> Need to try latest stable to confirm
Jan 13 06:24:23 * DougReeder nods
Jan 13 06:25:29 <Herrie|2> Let me reflash latest stable
Jan 13 06:31:08 <DougReeder> I need to get to sleep. Goodnight, all!
Jan 13 06:31:43 <Herrie|2> Gn8!
Jan 13 06:36:27 <Herrie|2> DougReeder: Yeah same here on stable
Jan 13 06:36:35 <Herrie|2> Seems something is definately broken
Jan 13 06:36:38 <Herrie|2> On nightly even worse
Jan 13 06:36:48 <Herrie|2> On stable I can at least close the accounts app card
Jan 13 06:41:30 <Herrie|2> DougReeder created 801 and 803 for it
Jan 13 13:05:18 <morphis> Herrie|2: bad that those regressions happend ..
Jan 13 13:07:57 <Herrie|Veer> morphis: Can happen: 2 steps forward, 1 step back :) I'm sure you or Tofe will find a solution :P
Jan 13 13:08:16 <morphis> yeah ...
Jan 13 13:08:20 <Herrie|Veer> P.s. I raised for audio service...
Jan 13 13:08:42 <Herrie|Veer> I actually ran into this when I was investigating the odd volume behavior on N4
Jan 13 13:09:02 <Herrie|Veer> Legacy uses a 11 volume step and not a 10 one
Jan 13 13:09:31 <Herrie|Veer> So 0, 11, 22, 33 etc which works better compared to our one
Jan 13 13:14:02 <Herrie|Veer> I can set this to 11 in audio_service.c but not sure what would happen to (service->volume / 10) * 10 if I do that? In general / 10 and multiplying 10 would give the same result but not sure how that works with ints in C++
Jan 13 13:15:18 <morphis> Herrie|Veer: as long as there are guards to verify that the result will not be over 100 or below 0 things are fine
Jan 13 13:15:46 <morphis> guards = if volume > 100 then volume = 100 else if volume < 0 then volume = 0
Jan 13 13:16:01 <Herrie|Veer> OK :)
Jan 13 13:16:12 <Herrie|Veer> I think the 11 step makes more sense
Jan 13 13:16:19 <Herrie|Veer> I checked this on my Veer
Jan 13 13:16:28 <Herrie|Veer> It will give a more accurate indicator
Jan 13 13:16:46 <Herrie|Veer> I noticed it "skipping" a level with our 10 step currently
Jan 13 13:19:09 <morphis> Herrie|Veer: really?
Jan 13 13:20:35 <Tofe> What regression are we talking about?
Jan 13 13:20:57 <morphis> Tofe: http://issues.webos-ports.org/issues/801
Jan 13 13:21:00 <morphis> my fault
Jan 13 13:21:40 <Tofe> oh ? ok, well, I also missed it in the review ;)
Jan 13 13:22:48 <Herrie|Veer> morphis: Yes it skips 1 or 2 levels frequently on my N4 when changing volume
Jan 13 13:42:25 <Herrie|Veer> morphis: Noticed that the audio service is missing quite a bit still compared to legacy
Jan 13 13:42:39 <morphis> Herrie|Veer: I saw the bug
Jan 13 13:42:46 <morphis> that is true
Jan 13 13:43:59 <Herrie|Veer> I think most important what we're missing is the ability to set volume for different things
Jan 13 13:44:06 <Herrie|Veer> Others are not that trivial
Jan 13 13:44:36 <morphis> but it is not that important if we can adjust the global volume
Jan 13 13:44:36 <Herrie|Veer> Things like vibration, haptic feedback, visual voicemail etc are nice to have but not really that urgent
Jan 13 13:45:00 <morphis> we don't even have ringtones etc.
Jan 13 13:45:56 <Herrie|Veer> Also BT switch detection might be good in due time...
Jan 13 13:45:57 <Herrie|Veer> Well I know a lot of users use different ones eventually
Jan 13 13:46:19 <morphis> BT switch?
Jan 13 13:46:31 <Herrie|Veer> I know I do :P That's what lacks on some of the other OS-es
Jan 13 13:46:33 <Herrie|Veer> BlueTooth
Jan 13 13:46:44 <Herrie|Veer> But I know we don't have BlueZ yet?
Jan 13 13:46:45 <morphis> ah you mean bluetooth support in general
Jan 13 13:47:15 <morphis> it is not only bluez
Jan 13 13:47:32 <morphis> Herrie|Veer: lets first finish the other things we have
Jan 13 13:47:36 <morphis> then lets talk about bluetooth ..
Jan 13 13:47:55 <Herrie|Veer> Just the LS2 calls would be different when we have proper audio service, so I think it would be good to change the service now to allow the flexibility later
Jan 13 13:48:21 <Herrie|Veer> We only do calls at very few places now which means easy to change, gets more complicated later
Jan 13 13:48:55 <morphis> why are they getting more complex?
Jan 13 13:49:07 <morphis> we will only be more specific later when adjusting the volume
Jan 13 13:49:13 <morphis> right now we're adjusting the global volume
Jan 13 13:49:26 <morphis> if we adjust it later for single topic that doesn't make much different
Jan 13 13:49:35 <morphis> the current method will still exist then
Jan 13 13:49:37 <Herrie|Veer> OK, so global volume is not conflicting with that
Jan 13 13:49:48 <Herrie|Veer> ? Just confused maybe...
Jan 13 13:50:24 <Herrie|Veer> I thought our current global volume translated to system volume in legacy hence my concern above
Jan 13 13:50:54 <morphis> yeah, but where are we using legacy API's for audio in LuneOS?
Jan 13 13:51:09 <morphis> that is also not an API which is meant to be used by apps
Jan 13 13:53:44 <Herrie|Veer> I didn't check legacy apps to see if there are some that use it, quite sure there are if I search for it :P
Jan 13 13:55:12 <morphis> check which API's palm offered to developers
Jan 13 13:55:45 <morphis> https://developer.palm.com/content/api/reference/services.html
Jan 13 13:55:50 <morphis> only playFeedback is listed
Jan 13 13:55:55 <morphis> no other audio APIs
Jan 13 13:56:03 <morphis> as those are meant to be used only internally
Jan 13 13:56:27 <morphis> no app in the app store can ever used them as otherwise they wouldn't be allowed
Jan 13 13:58:29 <Herrie|Veer> But in Preware they might :P
Jan 13 13:58:40 <Herrie|Veer> I suspect TouchVol uses it for example
Jan 13 13:58:47 <Herrie|Veer> Or PulseAudio Restarter
Jan 13 13:59:46 <morphis> even then we're not recreating the legacy API atm
Jan 13 13:59:55 <morphis> we're on org.webosports.audio so free to do whatever we want
Jan 13 14:00:04 <morphis> unless we provide legacy support for com.palm.audio
Jan 13 14:00:20 <morphis> and doing that is rather hard and involves some time we currently don't have
Jan 13 14:01:36 <Herrie|Veer> OK fair point. If you see no design problems currently, trust your judgement on that
Jan 13 14:01:46 <Herrie|Veer> C++ stuff is like a black box to me :P
Jan 13 14:05:38 <morphis> Herrie|Veer: I like more apps not working because there is no service they want to talk until we have a proper reimplementation or replacement
Jan 13 14:06:01 <morphis> but unless we have that every app talking to org.webosports.audio should not do that
Jan 13 14:06:23 <morphis> what we can do is to reimplement https://developer.palm.com/content/api/reference/services/system-sounds.html
Jan 13 14:12:26 <Herrie|Veer> That one would be good to have I guess. Specific volume setting as well but like you said that could be done later, wasn't sure about that just wanted to double check
Jan 13 14:25:53 <Herrie|Veer> I'll try to play a bit with the volume issue
Jan 13 14:26:10 <Herrie|Veer> After I get my raid setup sorted tonight I guess
Jan 13 14:31:37 <Herrie|Veer> It's C++ so I might need some help later LOL :P
Jan 13 14:31:46 <Herrie|Veer> But will try to figure out by myself
Jan 13 14:42:05 <Herrie|Veer> morphis: You have objections against having the Enyo 2 sampler app packaged up and included in image? Might be good for some contingency testing?
Jan 13 14:47:46 <DougReeder> We should probably have several versions of Sampler: a bleeding edge, and ones clamped to major versions of Enyo.
Jan 13 14:48:50 <DougReeder> Right now, we’d want bleeding-edge, Enyo 2.5.1.1 and 2.4.0
Jan 13 14:52:14 <GodGinrai> DougReeder: IIRC, there already are Samplers for the major versions of Enyo
Jan 13 14:52:34 <Herrie|Veer> There are I guess
Jan 13 14:52:51 <DougReeder> Hmm, thought there was just one repo.
Jan 13 14:52:59 <GodGinrai> DougReeder: http://enyojs.com/sampler/2.2.0/ http://enyojs.com/sampler/2.4.0/
Jan 13 14:53:08 <Herrie|Veer> But seems like LG is not very consistent in updating appinfo.json at least it's not logical for me with 2.5.1.1
Jan 13 14:53:10 <morphis> Herrie|Veer: no, that is fine
Jan 13 14:54:48 <Herrie|Veer> GodGinrai: Yeah but they might behave differently in browser compared to packaged app
Jan 13 14:54:50 <DougReeder> Certainly we would pull bleeding edge from https://github.com/enyojs/sampler
Jan 13 14:55:11 <Herrie|Veer> morphis: I think DougReeder makes a valid point
Jan 13 14:55:16 <DougReeder> I haven’t checked if that has tags for Enyo versions.
Jan 13 14:55:36 <Herrie|Veer> We'd need to have 2.4 and 2.5.1.1 for sure
Jan 13 14:55:52 <Herrie|Veer> We can drop and old one once we've updated all to latest
Jan 13 14:56:04 <GodGinrai> Herrie|Veer: If they behave differently, then the app or browser renderer needs to be fixed, IMHO
Jan 13 14:56:11 <Herrie|Veer> DougReeder: tags are proper for Enyo, layouts, onyx etc
Jan 13 14:56:46 <DougReeder> Hmm, Enyo etc are submodules.
Jan 13 14:57:02 <Herrie|Veer> For example: Input for 2.5.x works OK in browser but not in apps
Jan 13 14:57:18 <GodGinrai> DougReeder: btw, all the enyo projects have tons of tags
Jan 13 14:57:23 <Herrie|Veer> Browser we can always check and then we'd think we're fine, but then in app it fails :P
Jan 13 14:57:33 <GodGinrai> including sampler
Jan 13 14:57:38 <Herrie|Veer> So having it as packed app is good
Jan 13 14:57:56 <Herrie|Veer> Can you guys look at the appinfo.json? It doesn't make sense to me
Jan 13 14:58:01 <GodGinrai> Herrie|Veer: input?
Jan 13 14:58:42 <Herrie|Veer> onyx.input etc
Jan 13 14:58:45 <Herrie|Veer> Richtext
Jan 13 14:58:57 <GodGinrai> How does it not work?
Jan 13 14:58:59 <Herrie|Veer> In apps we have a vkb issue, for same in browser not...
Jan 13 14:59:03 <DougReeder> https://github.com/enyojs/sampler/blob/master/appinfo.json looks normal to me.
Jan 13 14:59:57 <Herrie|Veer> We'll seeing we're on 2.5.1.1 app version of 2.5.0 looks odd to me but could be OK
Jan 13 15:00:22 <DougReeder> There may not be a git tag saying which version of Enyo Sampler works with, but the field "enyoVersion": "2.5.0" in appinfo.json should tell us.
Jan 13 15:00:30 <Herrie|Veer> xonDeviceSource I guess is something new for TV's same like enyoVersion and the containerJS and containerCSS
Jan 13 15:01:14 <DougReeder> You can throw additional fields into appinfo.json - whatever you like.
Jan 13 15:02:11 <DougReeder> xondevice source may say to pull enyo from the device, rather than the app.
Jan 13 15:02:17 <Herrie|Veer> OK but this looks confusing that's all I want to say :P
Jan 13 15:02:42 <DougReeder> It certainly confuses what version of Enyo & libs are being used.
Jan 13 15:02:48 <Herrie|Veer> I thought purpose of Enyo 2 was that it wouldn't have on device anymore like legacy :P
Jan 13 15:02:56 <DougReeder> So did I.
Jan 13 15:03:06 <DougReeder> Perhaps LG has flip-flopped.
Jan 13 15:03:07 <Herrie|Veer> Where we had stuff in the usr/palm/frameworks etc :P
Jan 13 15:05:12 <Herrie|Veer> Could very well be
Jan 13 15:06:04 <Herrie|Veer> pinged Roy about it
Jan 13 15:08:17 <DougReeder> Sampler has tags “2.5.1.1” and “2.4.0”
Jan 13 15:09:20 <GodGinrai> nah, the TV dev portal definitely has you package your own version of Enyo
Jan 13 15:09:30 <GodGinrai> when you make an app
Jan 13 15:09:51 <DougReeder> The enyo submodule has tag “2.4.0” and “2.5.0”, but no “2.5.1.1” or even “2.5.1”
Jan 13 15:12:23 <DougReeder> LG might have an option for their built-in apps to use Enyo from the device.
Jan 13 15:12:34 <DougReeder> I don’t think we need worry about it.
Jan 13 15:13:02 <Herrie|Veer> Also think so but still want to know :P
Jan 13 15:21:56 <Herrie|Veer> Hmmz packaged 2.5.1.1 Sampler app doesn't have issues. Will upgrade testr to 2.5.1.1 to see if it's gone there too
Jan 13 15:22:35 <Tofe> morphis: do you remember what particular manipulation you did to get that bug?
Jan 13 15:22:50 <Tofe> ( #807 )
Jan 13 15:22:51 <morphis> Tofe: just played with the page stack
Jan 13 15:22:57 <morphis> can't say what exactly
Jan 13 15:23:08 <Tofe> ok
Jan 13 15:23:36 <morphis> trying to get that again
Jan 13 15:29:44 <Tofe> In the meantime, my latest N4 build is finished, so I guess I'll be able to reproduce it too
Jan 13 15:43:31 <Herrie|Veer> Hmmz this vkb input bug is really weird
Jan 13 15:43:43 <Herrie|Veer> Enyo 2.5.1.1 sampler app works OK
Jan 13 15:43:52 <Herrie|Veer> Our memos, testr doesn't
Jan 13 15:43:58 <Herrie|Veer> Using the same kinds :s
Jan 13 15:46:10 <Tofe> Herrie|Veer: the mystery deepens...
Jan 13 15:46:39 <Herrie|Veer> Yeah this makes no logical sense to me...
Jan 13 16:00:19 <Herrie|Veer> morphis: Can you create a repo for the sampler app and give me write access
Jan 13 16:00:55 <Herrie|Veer> How we need to go about different version and the .bb? Can we keep them in the same repo, different branches with 2 different .bb's or ?
Jan 13 16:03:00 <morphis> Herrie|Veer: yes
Jan 13 16:03:23 <morphis> enyo2-sample-2.4.bb enyo2-sampler-2.5.bb
Jan 13 16:06:51 <Herrie|Veer> ok if you create the repo I'll work on the res
Jan 13 16:06:53 <Herrie|Veer> +t
Jan 13 16:08:35 <morphis> Herrie|Veer: which name?
Jan 13 16:10:23 <Herrie|Veer> The official appif in appinfo.json is com.webos.app.enyo2sampler
Jan 13 16:10:32 <Herrie|Veer> We might keep that right?
Jan 13 16:10:41 <Herrie|Veer> Or that convention creates issues?
Jan 13 16:13:08 <DougReeder> I don’t see any problem using that app id.
Jan 13 16:16:00 <DougReeder> FWIW, in bleeding edge Sampler, you can see the version in the UI, in Core > Platform.  In earlier versions (even 2.5.1.1) that’s not there.
Jan 13 16:16:59 <DougReeder> Of course, you can always use the console to examine enyo.version.
Jan 13 16:18:41 <DougReeder> For bleeding-edge Sampler, I would *not* create a repo, I’d pull direct from https://github.com/enyojs/sampler
Jan 13 16:23:01 <Herrie|Veer> DougReeder: I'm not sure we can easily do that, morphis/JaMa know this bb stuff better
Jan 13 16:23:33 <DougReeder> It’s always pulling from somewhere, right?
Jan 13 16:30:41 <Herrie|Veer> Yes it should be OK I guess the only problem is that the bleeding edge ones link to the enyo and other repo's and we require them to be in the same repo
Jan 13 16:30:52 <Herrie|Veer> This is due to build process
Jan 13 16:31:06 <Herrie|Veer> So directly linking wouldn't be possible afaik
Jan 13 16:31:24 <Herrie|Veer> That's why we have webos-lib and enyo in full in each repo
Jan 13 16:33:47 <DougReeder> If the issue is that webos_ports_repo.bbclass references git://github.com/webOS-ports, we just need a different class for enyo, right?
Jan 13 16:35:05 <DougReeder> … which references https://github.com/enyojs instead.
Jan 13 16:36:39 <Herrie|Veer> No, that's not it
Jan 13 16:37:02 <Herrie|Veer> We cannot include repo's currently that link to other repo's
Jan 13 16:37:31 <DougReeder> Oh, it’s the git submodule problem.
Jan 13 16:37:37 <Herrie|Veer> sampler links to enyo @ 0df607c which we don't support
Jan 13 16:37:40 <Herrie|Veer> Yes
Jan 13 16:39:39 <DougReeder> It seems very odd that we’re not able to support that.
Jan 13 16:40:21 <Herrie|Veer> Has to do with the build process, ssstate cache and all that
Jan 13 16:40:28 <Herrie|Veer> morphis explained it sometime
Jan 13 16:50:07 <JaMa> DougReeder: you just need to add SRC_URI entries for all submodules
Jan 13 16:50:54 <JaMa> I can even add small function which will verify that SRCREV for individual modules are correct (matching what .git/modules says)
Jan 13 16:51:06 <Herrie|Veer> JaMa: morphis siad before we couldn't use it like this....
Jan 13 16:51:28 <Herrie|Veer> Would need to look in the channel history as to why exactly again
Jan 13 16:51:52 <JaMa> I don't know what he meant, but this will work correctly with premirror
Jan 13 16:52:15 <JaMa> I even have some code for that already
Jan 13 16:52:26 <Herrie|Veer> OK... I think he mentioned premirror
Jan 13 16:52:40 <Herrie|Veer> I'm happy if we could use it :P
Jan 13 16:53:16 <Herrie|Veer> Would make some stuff a lot easier, it's now quite a pain to need to update each repo with a full new version of Enyo or webos-lib
Jan 13 16:53:35 <Herrie|Veer> If we could use submodules that would make it a lot easier :)
Jan 13 16:53:54 <JaMa> "add SRC_URI entries for all submodules" - just to be clear, you need to add all git repositories and their revisions
Jan 13 16:54:23 <JaMa> so it's easier than maintaining repo, but I wouldn't say "a lot easier" :)
Jan 13 16:56:13 <DougReeder> SRC_URI has to be updated whenever the repository changes?
Jan 13 17:35:10 <JaMa> DougReeder: SRCREVs yes, SRC_URI no (unless modules were added/removed)
Jan 13 17:52:58 <morphis> DougReeder: I am fine with doing that
Jan 13 17:56:38 <DougReeder> Ah, good.
Jan 13 18:22:18 <Herrie|2> morphis: Should we test it with 1 app to see if it's OK?
Jan 13 18:22:27 <morphis> yeah
Jan 13 18:31:34 <JaMa> ping me when you have it and I'll add bbclass for the check
Jan 13 18:32:50 <morphis> Herrie|2: can you create the bb file?
Jan 13 18:34:56 <morphis> Garfonso: ping
Jan 13 18:42:39 <morphis> Garfonso: I am working on a replacement for the window.open approach inside the googleauth app
Jan 13 18:42:46 <morphis> what will be available shortly is:
Jan 13 18:42:54 <morphis> navigator.InAppBrowser.open(url)
Jan 13 18:42:59 <morphis> navigator.InAppBrowser.close()
Jan 13 18:43:16 <morphis> navigator.InAppbrowser.ontitlechanged
Jan 13 18:43:24 <morphis> just set a function to ontitlechanged
Jan 13 18:43:33 <morphis> like
Jan 13 18:43:45 <morphis> ontiltechanged = function(title) { ... }
Jan 13 18:50:23 <morphis> Garfonso: https://github.com/webOS-ports/luna-webappmanager/commit/81abe63cf54e86cce400d7df4c7a71b808d2cf6c
Jan 13 18:56:04 <morphis> will add a test case in the testr app for it so you see how it works
Jan 13 19:05:33 <Herrie|2> morphis: I can try
Jan 13 19:05:50 <Herrie|2> DougReeder seems to know GH better, maybe he can do a PR instead :P ?
Jan 13 19:06:09 <DougReeder> Hmmm
Jan 13 19:06:47 <Herrie|2> MAybe for something "simple" like the Testr app or memos?
Jan 13 19:07:45 <DougReeder> What exactly is needed?
Jan 13 19:09:40 <Herrie|2> This one to be updated so it can use the Enyo 2.4 directly :P
Jan 13 19:09:41 <Herrie|2> https://github.com/webOS-ports/meta-webos-ports/blob/dizzy/meta-luneos/recipes-luneos/apps/org.webosports.app.testr.bb
Jan 13 19:09:54 <Herrie|2> 2.5.1.1 is fine as well for that one by the way
Jan 13 19:10:07 <Herrie|2> Since it only has 1 input field that's non-critical for now
Jan 13 19:10:20 <Herrie|2> Or if JaMa feels like he could do it :P
Jan 13 19:10:28 <Herrie|2> And we can do the other dozen or so apps :P
Jan 13 19:12:01 <DougReeder> Sorry, I’m still not clear on what you’re asking me to do.
Jan 13 19:15:23 <DougReeder> FWIW, I have most of what’s needed to update Contacts to Enyo 2.5.1.1 done.  I’m planning to finish the “Add Contact” dialog first.
Jan 13 19:19:13 <JaMa> EricBlade1: I can look a bit later
Jan 13 19:19:52 <JaMa> Herrie|2: ^, EricBlade1 sorry bad highlight
Jan 13 19:25:04 <morphis> Tofe: I've found the origin of the bug
Jan 13 19:25:17 <morphis> try to create a child window which should then directly be pushed on top of the card stack
Jan 13 19:26:05 <Tofe> ok
Jan 13 19:26:41 <JaMa> anyone needs older testing images?
Jan 13 19:27:27 <Herrie|2> JaMa: Yes: Ehm we need the first release images for the Maguro and Grouper
Jan 13 19:27:33 <Herrie|2> Dated early sept if you have them
Jan 13 19:27:53 <JaMa> no I don't have them
Jan 13 19:32:16 <DougReeder> And switching back to the earlier conversation, JaMa, is supporting git submodules in a recipe as easy as adding SRCREV and SRC_URI lines for every submodule?
Jan 13 19:32:40 <JaMa> yes
Jan 13 19:32:46 * DougReeder nods
Jan 13 19:39:46 <Tofe> morphis: which Account window is the child of the previous one ?
Jan 13 19:54:41 <JaMa> Herrie|2: DougReeder; morphis I wonder if we should let individual recipe to select which enyo submodules are really needed or just unpack all of them in lib and let the app use what it needs from there, what do you think?
Jan 13 19:56:12 <JaMa> https://github.com/webOS-ports/meta-webos-ports/commit/e54cac46b48ae7152b0c1d3f2e32da507e38c05c shows 2 examples, first for moonstone, second for sampler
Jan 13 19:56:23 <DougReeder> Maybe unpack all and get things working.  Then, we could see about only rerieving the ones we need.
Jan 13 19:58:15 <DougReeder> What’s moonraker?
Jan 13 19:59:33 <DougReeder> and where’s moonstone?
Jan 13 19:59:48 <JaMa> and is it reasonable to expect that every app will use them from lib/ directory?
Jan 13 19:59:54 <JaMa> synonym for moonstone
Jan 13 20:00:09 <JaMa> https://github.com/enyojs/moonrake redirects you to moonstone
Jan 13 20:00:48 <DougReeder> Ah.   And g11n is a synonym for i18n ?
Jan 13 20:01:22 <JaMa> no g11n is g11n project
Jan 13 20:01:55 <JaMa> Globalization + Localization library
Jan 13 20:03:26 <DougReeder> Can we not use “git submodule update” in a recipe?
Jan 13 20:03:35 <JaMa> no
Jan 13 20:06:05 <DougReeder> Hmm, last I checked, the Enyo team was pushing enyo-ilib for i18n.
Jan 13 20:09:39 <DougReeder> I guess I don’t know git submodules and bitbake well enough to say whether enyo-submodules.bbclass or eny0-submodules2.bbclass is better.
Jan 13 20:10:21 <DougReeder> Is 2 just 1 with h11n and canvas?
Jan 13 20:10:52 <Herrie|2> g11n was replace with i18n in Enyo I think
Jan 13 20:14:02 <DougReeder> Sampler uses enyo-ilib, and I haven’t seen any of our builtin apps using either.
Jan 13 20:14:26 <JaMa> this is what sampler and moonstone were using about 1,5 years back when I wrote this
Jan 13 20:14:28 <GodGinrai> iLib is i18n
Jan 13 20:15:10 <DougReeder> Ah, from the g11n README: “Starting with Enyo 2.3.0, this is generally deprecated in favor of enyo-ilib”
Jan 13 20:15:21 <JaMa> DougReeder: the only difference is the list of submodules, if we want all submodules to be always unpacked, then there will be just one .bbclass
Jan 13 20:18:55 <DougReeder> For Sampler, we need to support these submodules: canvas, enyo-ilib, extra, layout, moonstone, onyx and spotlight.
Jan 13 20:19:29 <DougReeder> I don’t think our built-in apps will require any others.
Jan 13 20:19:40 <DougReeder> But does that answer your question, JaMa?
Jan 13 20:22:29 <Herrie|2> Most just use Onyx, Layout and webos-lib (which is our own repo)
Jan 13 20:23:02 <Herrie|2> Soem use canvas
Jan 13 20:30:54 <DougReeder> Oh, right, we also need webos-lib.
Jan 13 20:34:47 <JaMa> not this part:
Jan 13 20:34:49 <JaMa> 20:59:50 <+JaMa> and is it reasonable to expect that every app will use them from lib/ directory?
Jan 13 20:35:45 <JaMa> and that we'll be able to use exactly the same enyo release in all included applications
Jan 13 20:36:26 <JaMa> if not, then I'll change the bbclass to do just the check (probably rewrite it as python function for easier usage) and let individual recipes to set the SRC_URI and SRCREVs
Jan 13 20:39:57 <DougReeder> In general, we’d like to be able to use different versions of Enyo for different apps.  It can take several hours of work per app for some version changes
Jan 13 20:40:43 <DougReeder> …and I can see one app needing a feature in a new version of Enyo, and it having a bug that another app can’t work abound.
Jan 13 20:41:14 <JaMa> ok, fair enough
Jan 13 20:41:29 <DougReeder> That’s nearly the siuation we’re in now, with 2.4 and 2.5
**** ENDING LOGGING AT Wed Jan 14 02:59:59 2015