**** BEGIN LOGGING AT Wed Aug 24 02:59:58 2016
Aug 24 07:32:34 <Herrie|Pre3> morning
Aug 24 08:06:21 <Tofe> Morning!
Aug 24 08:16:20 <Herrie|Pre3> Tofe: I need some feedback from Andolamin or EricBlade on this first, but I wanted to run this by you anyway.
Aug 24 08:17:39 <Herrie|Pre3> Since we're currently shipping all Enyo libraries with each app, it's a bit cumbersome to update the same bit every time. I was wondering if we could deploy the frameworks similar to legacy is /usr/palm/frameworks etc and add some fields in appinfo.json t
Aug 24 08:17:40 <Herrie|Pre3> o point to the correct version.
Aug 24 08:18:55 <Herrie|Pre3> For example I now want to change a single variable in onyx-variables.less to make the Toggles blue instead of green. This would now need to be updated in each app's onyx lib, while if we'd have it centrally that would work a lot easier.
Aug 24 08:20:40 <Herrie|Pre3> LG does something like this on their TV's with enyoVersion and onDeviceSource in the appinfo.json as per https://developer.lge.com/webOSTV/develop/web-app/app-developer-guide/app-metadata
Aug 24 08:23:55 <Herrie|Pre3> Not sure how complicated this would be to hook up in the luna-webappmgr. Doesn't look too complicated to me at first but you're a better judge. Anyway would like to get some feedback from EricBlade or Andolamin first anyway :P
Aug 24 08:24:04 <Herrie|Pre3> Andolamin:
Aug 24 08:24:13 <Herrie|Pre3> Andolamin: ^
Aug 24 08:24:20 <Herrie|Pre3> EricBlade: ^
Aug 24 08:48:56 <Tofe> Herrie|Pre3: good question
Aug 24 08:50:15 <Tofe> But, if we are to modiify all the apps in question, can't we simply provide several Enyo versions in the frameworks/ folder and have the apps directly refer to it, like for Enyo 1.0 ?
Aug 24 08:53:44 <Herrie|Pre3> Tofe: Yeah that was my idea :P
Aug 24 08:54:17 <Herrie|Pre3> Just not sure how complex that would be in luna-webappmgr to replicate how LG deals with it. Doesn't look too complicated to me, but I might be wrong
Aug 24 09:31:58 <Tofe> No, I mean, why do we have to modify appinfo and/or webappmgr ? How is it done with Enyo 1.0 ?
Aug 24 09:33:37 <Herrie|Pre3> Tofe: Enyo 1.0 apps have a hard reference to /usr/palm/frameworks etc
Aug 24 09:34:42 <Herrie|Pre3> We could do something similar but we would deviate from LG's approach then.
Aug 24 09:35:40 <Herrie|Pre3> We'd need to update index.html (and debug.html) to point to /usr/palm/frameworks/enyo2/x.y.z/ etc
Aug 24 09:36:05 <Herrie|Pre3> Just LG's solution by doing it in appinfo.json is a bit more elegant imho
Aug 24 10:01:52 <Herrie|Pre3> I guess some input from Andolamin and/or EricBlade on this would be helpful :P
Aug 24 10:19:46 <dkirker> I believe, by default, apps get pointed to /usr/palm/frameworks/enyo/1.0/ in legacy, which is a symlink to /usr/palm/frameworks/enyo/versions/whatever/. I *think * you could set your own script tag to /usr/palm/frameworks/enyo/versions/whatevermore/, but I am not 100% sure.
Aug 24 10:21:27 <dkirker> in fact, I believe you had to add:
Aug 24 10:21:33 <dkirker> <script src="/usr/palm/frameworks/enyo/0.10/framework/enyo.js" type="text/javascript"></script>
Aug 24 10:21:42 <Herrie|Pre3> dkirker: Yes
Aug 24 10:21:49 <Herrie|Pre3> That's Enyo 1.0 way
Aug 24 10:22:13 <Herrie|Pre3> For webOS on TV's LG seems to have added 2 fields to appinfo.json
Aug 24 10:22:27 <Herrie|Pre3> With Enyo 2 that is.
Aug 24 10:23:18 <dkirker> I know with local enyo2 apps, you had: <script src="build/enyo.js"></script>
Aug 24 10:23:42 <Herrie|Pre3> Yeah
Aug 24 10:23:59 <Herrie|Pre3> See the link I posted above on what LG did :P
Aug 24 10:24:22 <dkirker> I haven't looked at LG stuff in a while. I assume you just drop the "build/" and it takes enyoVersion and extrapolates? (I am about to click the link!)
Aug 24 10:24:47 <dkirker> Since TVs are huge and don't fit in my pocket, I haven't done much with that new stuff :p
Aug 24 10:25:06 <Herrie|Pre3> dkirker: Same here :P
Aug 24 10:25:45 <Herrie|Pre3> Ah seems LG deprecated it with 2.6 :s
Aug 24 10:25:46 <dkirker> though, with the way smartphones are going, I am going to have to adjust my logic....
Aug 24 10:26:05 <dkirker> yeah, just saw that
Aug 24 10:26:21 <dkirker> means we have to go dig in to how 2.6 works :p
Aug 24 10:26:51 <Herrie|Pre3> Well 2.5->2.7 is a lot of yak shaving according to DougReeder...
Aug 24 10:27:29 <Herrie|Pre3> Main difference is that it uses different tools to pack and it will only pack what's needed from the framework instead of the whole framework + libs
Aug 24 10:27:39 <Herrie|Pre3> Which should make things a lot smaller
Aug 24 11:45:59 <Tofe> Herrie|Pre3: can't we do something with the package installation, and some symlinks? Does that look awful?
Aug 24 11:46:20 <Tofe> (it does look strange)
Aug 24 11:46:57 <Herrie|Pre3> Tofe: Since it seems 2.5.x specific anyway I guess I can just update them once for now. It's not a lot anyway.
Aug 24 11:48:12 <Tofe> Well, on a platform with packages and dependencies, I don't what embedding Enyo into the app does bring
Aug 24 11:53:27 <Herrie|Pre3> Tofe: That's true
Aug 24 12:01:43 <Herrie|Pre3> Let me try something in a bit
Aug 24 16:23:40 <cryptk> Herrie|Pre3, I think we have possibly tracked down the root cause of the DNS issues... it looks like bind9 has issues where the resolution for remote hosts just... stops... when you have dnssec configured
Aug 24 16:23:57 <cryptk> so as a temporary workaround, I have disabled dnssec while I try and figure out a more permanent solution
Aug 24 16:25:24 <Herrie|Pre3> cryptk: OK that's for the issue connecting to miilla?
Aug 24 16:30:43 <ka6sox> Herrie|Pre3, yup
Aug 24 16:30:48 <ka6sox> wait
Aug 24 16:30:59 <ka6sox> no, its the issue with the builder not pushing to milla correctly
Aug 24 16:31:06 <ka6sox> your key issue is something else.
Aug 24 16:34:35 <Herrie|Pre3> ka6sox: OK
Aug 24 17:19:14 <EricBlade> DougReeder: yeah, i thought that might've been the case .. but that doesn't *have* to be the case, right? we could go and make changes to the system. it's not like we have to worry about upstream :-|
Aug 24 17:20:33 <EricBlade> Herrie well, as soon as I see Android 7, which will hopefully be soon (N5 should be receiving it right? if not, I'll have to wait for TouchPad .. but then again, that might actually be out *sooner*) i'll have some more ideas.  I know that they have the ability to respond to SMS directly from a notification
Aug 24 17:21:36 <Herrie> EricBlade: OK that's about the only one I coudl think of currently
Aug 24 17:22:12 <Herrie> cryptk: Can you enable the ParserFunctions on our MediaWiki or I need scoutcamper|away for that? https://www.mediawiki.org/wiki/Extension:ParserFunctions
Aug 24 17:22:29 * cryptk doesn't know much about mediawiki sadly
Aug 24 17:22:34 <cryptk> I am an infrastructure guy
Aug 24 17:25:07 <Herrie> cryptk: OK I'll ping scout for that
Aug 24 17:25:08 <EricBlade> Herrie if you make an app dependent upon an on device version of framework, and then the framework changes, you're basically screwed unless you also have the original version available to it as well.  i'm pretty sure that LG webOS only allows built-in apps to use the on device framework. i could be wrong, i have had sadly little experience with third party apps in LG webOS
Aug 24 17:27:55 <Herrie> EricBlade: Issue we have currently is that most of our apps use Enyo 2.5.1 but we'd need to make some changes to Onyx which would be in all apps. So doing it centrally makes more sense
Aug 24 17:28:00 <Herrie> Fully aware of the issues.
Aug 24 17:28:14 <Herrie> Idea is that you can have multiple versions of the framework on-device
Aug 24 17:28:24 <Herrie> And that's something we can control since we build it :P
Aug 24 17:30:09 <EricBlade> Herrie: i suspect that either webappmanager or the javascript that it loads into each window before hand, is loading the requested enyo version from /usr/palm/frameworks/enyo/x.x.x
Aug 24 17:32:17 <EricBlade> it does say that that's not used anymore, but i don't see what if anything replaces it
Aug 24 17:39:29 <DougReeder> Ericblade, sorry I've lost the context?
Aug 24 17:39:47 <EricBlade> DougReeder: re: keyboard in notifications
Aug 24 17:40:10 * DougReeder nods
Aug 24 17:47:25 <DougReeder> Due to incompatibilities between framework versions, I think oir paradigm should be that each app is responsible for including its own version of whatever framework it uses.
Aug 24 17:48:46 <DougReeder> If we run the numbers, and we can achieve useful savings by sharing framework files, that can be done on an app-by-app basis.
Aug 24 17:51:06 <DougReeder> It seems likely, that the current situation is typical, that one app is on Enyo 2.7 most are on Enyo 2.5, and some are on Enyo 1, will continue
Aug 24 17:51:59 <DougReeder> So, how many copies of Enyo 2.5 could we actually save, by sharing?
Aug 24 18:10:16 <DougReeder> I count only 8 apps on Enyo 2.5.1.1. So how big is a minified copy on Enyo?
Aug 24 18:11:02 <DougReeder> copy *of* Enyo
Aug 24 18:12:38 <DougReeder> Given modern storage capacities, using a shared copy of Enyo appears to be a premature optimization, to me.
Aug 24 18:26:57 <Tofe> DougReeder: I think that Herrie mainly wanted to share it in case we want to modify it a bit
Aug 24 18:27:50 <Tofe> The 300Kb (maybe less) of Enyo is nothing compared to the size of Qt WebEngine otherwise :)
Aug 24 18:42:39 <DougReeder> If we're modifying it, all the more reason for each app to have its own copy.
Aug 24 18:43:38 <DougReeder> We have no automated tests in place to detect if a change for one app causes a regression in another app.
Aug 24 18:44:40 <Herrie> DougReeder: It's mainly Onyx UI stuff to be more like legacy, i.e. the visual of various kinds (i.e. Picker, Toggle etc)
Aug 24 18:44:57 <Herrie> Because the standard Onyx isn't very good UI wise
Aug 24 18:45:18 <Herrie> Currently I'm modifying some files inside of Onyx which would need to be done in each app then.
Aug 24 18:45:26 <Herrie> It's mainly .css and .less
Aug 24 18:45:31 <Herrie> Not sure what's the best way to go about that
Aug 24 18:45:50 <Herrie> Maybe I shouldn't be touching Onyx itself but do it another way.... I'm just not sure, little to no Enyo experience
Aug 24 18:46:04 <DougReeder> I think the best approach to that would be to create a fork of Enyo, then
Aug 24 18:46:15 <Herrie> Hence some input from you or Andolamin, elvispre etc would be useful
Aug 24 18:46:21 <DougReeder> Or, rathr, Onyx
Aug 24 18:46:37 <Herrie> DougReeder: My issue is not the work in pushing the changes to 8 apps, just it makes little sense to do it 8 times
Aug 24 18:46:47 <DougReeder> Apps can point to the fork of Onyx
Aug 24 18:48:35 <Herrie> Changes are likely to be not very big.
Aug 24 18:48:54 <Herrie> DougReeder: Yeah we should see if we can link to repos in our build instead of putting all files there
Aug 24 18:49:05 <novaldex|away> DougReeder: reading through the above, I think a fork of Onyx might be a good idea. With some of the custom controls i've been making i've thought of it myself
Aug 24 18:49:14 <DougReeder> FWIW, that would introduce visual discrepancies between the built in apps and 3rd party Enyo apps
Aug 24 18:49:29 <Herrie> DougReeder: Yeah.....
Aug 24 18:49:31 <DougReeder> ... which may well be acceptable
Aug 24 18:49:47 <Herrie> Well we now have blue toggles in Enyo 1 and green in Enyo 2 for example
Aug 24 18:49:51 <Herrie> And there are more things like that
Aug 24 18:50:06 <Herrie> I'd like to unify that a bit ;)
Aug 24 18:50:19 <Herrie> Picker UI is horrible from UX point of view :P
Aug 24 18:50:22 <DougReeder> Novaldex, new controls should probably go in a new repo
Aug 24 18:51:01 <Andolamin> Still catching up, but wanted to chime in that I'm not personally very concerned about the visual discrepancies. We have quite a bit of work before we can standardize apps to a single look and feel anyway.
Aug 24 18:51:08 <novaldex|away> DougReeder: They currently go in my own library i've got in my Enyo2.7 app, restricted pretty much to just that at the moment
Aug 24 18:51:57 <novaldex|away> but they're a mashup of already existing Onyx ones, like combining GroupBox & Drawer together with appropriate actions already handled
Aug 24 18:52:58 * DougReeder nods
Aug 24 18:53:50 <DougReeder> New Enyo 2.7 Controls definitly belongbin their own repo.
Aug 24 18:54:08 <Andolamin> I, personally, like the idea of creating a framework bundle under /usr/palm/frameworks
Aug 24 18:58:10 <DougReeder> Re discrepancies between Enyo 1 and 2, I'd be inclined to modify Enyo 1 to match 2.
Aug 24 18:58:47 <DougReeder> As all Enyo 1 apps will be using the built in copy.
Aug 24 18:59:01 <DougReeder> ... Well, almost all
Aug 24 19:00:16 <DougReeder> If Onyx doesn't serve our needs, we should consider whether a new lib of Enyo Controls would serve our needs.
Aug 24 19:01:28 <DougReeder> A la https://github.com/DougReeder/enyo-animated
Aug 24 19:10:18 <DougReeder> If we want a better date picker, for example, it should be luneos.DatePicker, not a mutant onyx.DatePicker.
Aug 24 19:11:33 <GodGinrai> Why not use this chance to modify Mochi for your needs?
Aug 24 19:12:15 <GodGinrai> It's the better UI, IMO
Aug 24 19:12:24 <DougReeder> Mochi is also an option (abeit one requiring much morevwork)
Aug 24 19:12:27 <GodGinrai> just needs to be brought up-to-date
Aug 24 19:12:40 <DougReeder> ...and to be finished.
Aug 24 19:12:48 <GodGinrai> lol yes
Aug 24 19:12:57 <GodGinrai> but Onyx isn't exactly very extensive, either :P
Aug 24 19:13:16 <GodGinrai> I'd be interested in helping out with bringing Mochi into line
Aug 24 19:13:30 <GodGinrai> if you are interested in pursuing that option
Aug 24 19:16:16 <DougReeder> I don't want to discourage anyone from implmenting what you're passionate about, but it's not clear that any of this work would easily carry over to Enyo-next.
Aug 24 19:17:47 <DougReeder> ...or whatever framework we end up using.
Aug 24 19:22:00 <GodGinrai> oh sure.
Aug 24 19:23:35 <GodGinrai> I wouldn't expect enyo-next to use mochi, since they would probably make (or modify) their own library like they did with onyx and moonstone
Aug 24 19:24:12 <GodGinrai> Although, with the current focus on serving LG's TVs, I'm not sure if a new ui library is even on the cards for enyo-next
Aug 24 19:24:30 <DougReeder> GodGinrai, you might create a Mochi branch for one of the apps. That would be the best alse pitch.
Aug 24 19:24:59 <DougReeder> Best *sales* pitch
Aug 24 19:25:08 <GodGinrai> DougReeder: sounds good.  I'll give it a shot when I find time. :)
Aug 24 19:26:42 <DougReeder> To everyone, if you're passionate about doing one of these, do it! (in a way that doesn't create more work for others)
Aug 24 19:27:23 <DougReeder> This can be the year of UI experimentation, where things don't have to match.
Aug 24 19:27:34 <Andolamin> https://github.com/Andolamin/mochi
Aug 24 19:27:56 <Andolamin> I've already started implementing mochi for Enyo 2.7
Aug 24 19:28:16 <GodGinrai> Andolamin: perfect!
Aug 24 19:28:32 <GodGinrai> Andolamin: I'll probably fork from you, then
Aug 24 19:28:57 <DougReeder> Just be aware, most of the experiments, along with too much of our existing UI, will fall ny the eayside next year, in the big framework shakeup.
Aug 24 19:29:21 <Andolamin> Yes - I expect that to be the case
Aug 24 19:31:14 <DougReeder> If it doesn't break anything unrelated, or make more work for others, I'll sign off on anything this year.
Aug 24 19:32:35 <Andolamin> I do plan on working on a mochi implementation for enyo-next, though
Aug 24 19:32:42 <DougReeder> It can be a Cambrian explosion.
Aug 24 19:33:09 <Andolamin> I'll probably get started on it as soon as I get to start playing with it, but that would mean working in a private repo for a while
Aug 24 19:33:26 <Andolamin> s/with it/with enyo-next
Aug 24 19:34:35 <Andolamin> Porting the individual mochi UI components to 2.7 is straight forward, but one of the big things that I was going to tackle was the collapsing view
Aug 24 19:34:50 <Andolamin> I also plan to make a bunch of QML components matching the mochi UI
Aug 24 19:35:16 <Andolamin> GodGinrai: All my 2.7 work is in https://github.com/Andolamin/mochi/tree/alan/2.7.0-work
Aug 24 19:38:16 <DougReeder> A collapsing view, using Css Transitions or Animation. would be very useful!
Aug 24 19:40:19 <GodGinrai> DougReeder: The most important thing for me that enyo-next needs is separation from tools
Aug 24 19:40:58 <GodGinrai> the fact that we need a special tool for building or minifying is something I never liked
Aug 24 19:41:26 * DougReeder nods
Aug 24 19:59:36 <Tofe> Andolamin: if you work on QML mochi look, keep in mind morphis did a first attempt in the luneos-components repo
Aug 24 20:19:56 <Andolamin> Will do, thanks
Aug 24 20:20:10 <Andolamin> Will give me a bit of a head start :)
Aug 24 20:24:53 <Herrie> Sorry was out for groceries... DougReeder: UI wise Onyx in Enyo 2 doesn't feel much webOS-y
Aug 24 20:25:04 <Herrie> Palm/HP guys did a lot of things right UX wise
Aug 24 20:25:36 <Herrie> Some of that got lost in Enyo 2 by making it more generic. So I'm not a big fan of modifying Enyo 1 to be more like Enyo 2, but rather the other way around :P
Aug 24 20:29:00 <Herrie> A good example of what's not proper UX wise in Onyx in Enyo 2 is the Onyx.Picker for example
Aug 24 20:32:37 <Herrie> Just feels plain and doesn't have a webOS-y feel to it ;)
Aug 24 20:34:05 <Herrie> Trying to change that a bit, but had limited time this week
Aug 24 20:36:12 <Herrie> But making progress and liking the look. Just struggling a bit with Bindings
Aug 24 20:36:21 <Herrie> I'll put some code up tomorrow or Friday I guess
Aug 24 20:44:45 <GodGinrai> Herrie: most of webOS is still better UX than Android/iOS
Aug 24 20:45:44 <GodGinrai> Also, the onyx picker is probably the most annoying thing ever <.<
Aug 24 20:46:52 <Herrie> GodGinrai: Yeah
Aug 24 20:46:56 <Herrie> So trying to rework that
Aug 24 20:50:43 <GodGinrai> good idea
Aug 24 20:51:54 <GodGinrai> I still wish that Android would just be more blatant in their ripping off like iOS and display a card ui for the recent apps list
Aug 24 20:52:31 <GodGinrai> those little stacked windows that you have to slide horizontally are just so hard to deal with
Aug 24 21:10:16 <DougReeder> Herrie, you're just changing the style of onyx.Picker, a fork of the Onyx library would work well. If you want to change behavior, a new Control in a new library would be better.
Aug 24 21:12:00 <DougReeder> A forked lib can be demoed on desktop browsers, unlike an on-device lib.
Aug 24 21:18:01 <DougReeder> A UI project with a lot of carryover through the Great Framework Transition, would be a cross-app date picker that showed your current appointments.
Aug 24 21:19:02 <DougReeder> ...probably some PalmBus call to com.palm.app.calendar
Aug 24 21:24:22 <Herrie> DougReeder: For now it's only .css and .less
Aug 24 21:24:32 <Herrie> I guess forking would work
Aug 24 21:26:49 * DougReeder nods
Aug 24 21:37:56 <Andolamin> Anyone have any experience creating SVG assets?
Aug 24 21:47:04 <Herrie> Andolamin: I guess Benjamin (our graphics guy) and some other graphics guy might have
Aug 24 21:47:09 <Herrie> I can reach out to them if needed
Aug 24 21:51:30 <Andolamin> Herrie: Thanks, but I think I figured it out, actually.
**** ENDING LOGGING AT Thu Aug 25 02:59:58 2016