**** BEGIN LOGGING AT Wed Jun 10 02:59:59 2015
Jun 10 06:37:18 <Tofe> morning
Jun 10 06:37:35 <Tofe> Herrie|2: ok, I'll work on that
Jun 10 07:14:06 <Herrie|Veer> Morning
Jun 10 07:14:23 <Herrie|Veer> Tofe: Enter key hides the vkb but it's not very intuitive :P
Jun 10 07:14:36 <Herrie|Veer> Tapping outside of vkb should hide it too
Jun 10 07:14:52 <Herrie|Veer> Because vkb is over the next button :P
Jun 10 07:19:15 <Herrie|Veer> The filter itself works great though!
Jun 10 07:19:23 <Herrie|Veer> Nice work on that!
Jun 10 07:22:46 <Tofe> Herrie|Veer: thanks thanks :) So, tapping outside of text entry should unfocus it. I'll look into that.
Jun 10 07:24:50 <Herrie|Veer> Tofe: Well anywhere outside of VKB itself that's what is does elsewhere in OS?
Jun 10 07:38:47 <Tofe> usually yes
Jun 10 07:39:04 <Tofe> Actually I'm surprised it doesn't do that here
Jun 10 07:39:33 <Herrie|Veer> Well it seems vkb Z is on top of firstuse while with other apps it resizes?
Jun 10 07:40:16 <Herrie|Veer> The app I mean. I guess that's on purpose because we don't want FirstUse to "card"?
Jun 10 07:40:29 <Herrie|Veer> So that might need to be fixed in some other way?
Jun 10 07:41:00 <Herrie|Veer> I mean in other cases it resizes the app windows and here it doesn't
Jun 10 07:51:17 <Tofe> it doesn't exactly resize the app window, it just allocates space at the bottom of the WebView so that it doesn't overlap the keyboard
Jun 10 07:58:19 <morphis> Garfonso: ping
Jun 10 08:39:36 <Herrie|Veer> Tofe: It looks like it's resized because the bottom of the app moves up ;) But since you wrote it I'm not doubting you judgement :P
Jun 10 08:40:11 <morphis> Herrie|2: btw. did you hear anything new about the Telegram app?
Jun 10 08:42:06 <morphis> Herrie|Veer: its listed on the pivotce feed (http://preware.pivotce.com/package/de.pattyland.telegram-webos) but does that one already have a category for LuneOS?
Jun 10 08:44:46 <Tofe> Herrie|Veer: yes, the bottom of the app moves up, giving the impression the card is resized, but in fact it's only the content of the card that is adjusted so that the vkb doesn't overlap the webapp
Jun 10 08:45:56 <Herrie|Veer> morphis: Not sure didn't hear anything from Soren lately
Jun 10 08:46:09 <Herrie|Veer> It should work I guess when you install the app
Jun 10 08:46:11 <morphis> Herrie|Veer: can you follow up with him on this?
Jun 10 08:46:25 <morphis> would like to have the pivotce feed listed in our preware
Jun 10 08:46:31 <morphis> disabled but ready for the users to take it
Jun 10 08:46:48 <Herrie|Veer> I can sort that, that's easy
Jun 10 08:47:11 <Herrie|Veer> What Soren needs to do? Mark compatible apps as 3.5 as max version?
Jun 10 08:47:30 <morphis> depends
Jun 10 08:47:46 <morphis> easiest would be to put in a list for luneos apps
Jun 10 08:48:33 <morphis> Herrie|Veer: but I am right that pivotce doesn't host the feed and packages themselfs?
Jun 10 08:49:39 <Herrie|Veer> Not sure...
Jun 10 08:50:07 <Herrie|Veer> Well they scrape other feeds it seems somehow
Jun 10 08:50:09 <morphis> hm, telegram app is on http://feed.pivotce.com/files/de.pattyland.telegram-webos_0.4.4_all.ipk
Jun 10 08:51:00 <Herrie|Veer> They have their own feed too
Jun 10 08:51:04 <morphis> ok
Jun 10 08:51:33 <Herrie|Veer> Their Preware Catalog site is a combination of Preware + own feed and maybe others
Jun 10 08:51:35 <morphis> we already extended the feed format on http://www.webos-internals.org/wiki/Packaging_Standards some time ago
Jun 10 08:51:58 <morphis> as generally I think the max version might be not enough
Jun 10 08:52:11 <morphis> as we need a clear indicator to differentiate from legacy
Jun 10 08:52:43 <Herrie|Veer> morphis: 2.6 was a draft I mocked up a while ago
Jun 10 08:54:13 <Herrie|Veer> But problem with that is that webOSNation is not willing to update their data in the feed, not even if we'd provide them a bulk update to do at once in db
Jun 10 08:54:25 <morphis> hm
Jun 10 08:55:06 <Herrie|Veer> At least that's what Derek told me. They're not spending a minute for any kind of development. Could be that someone else (ka6sox?) might be able to pull some strings
Jun 10 08:55:17 <morphis> not sure where we defined the webOS version ...
Jun 10 08:55:54 <Herrie|Veer> We have 3.5.0 somewhere...
Jun 10 08:56:17 <Garfonso> morphis: pong
Jun 10 08:58:31 <morphis> Garfonso: you have somewhere soon time for updating the updater?
Jun 10 09:00:37 <Garfonso> I'm working on it right now.
Jun 10 09:01:20 <Garfonso> been a bit busy the last few weeks. But decided I need to take more time for LuneOS again. :)
Jun 10 09:01:59 <morphis> Garfonso: great :)
Jun 10 09:02:21 <morphis> Herrie|Veer: ok, found it
Jun 10 09:02:35 <morphis> Herrie|Veer: we could bump it to 4.0.0
Jun 10 09:03:20 <morphis> however we would diverge from webOS then
Jun 10 09:03:31 <morphis> as that might use a higher number than 3.5.0 too
Jun 10 09:04:01 <Herrie|Veer> You mean TV webOS or...?
Jun 10 09:05:31 <morphis> for example
Jun 10 09:06:34 <Herrie|Veer> Either way anything above 3.0.6 should work? 3.0.6 was the last legacy version to make it out to the wild somehow on a select few TP (Go's)
Jun 10 09:06:56 <Herrie|Veer> So 3.1.0, 3.5.0 or 4.0.0 would work.
Jun 10 09:07:24 <morphis> right
Jun 10 09:07:28 <Herrie|Veer> Just we'd need to test legacy apps, determine which ones work and bump their supported max version to our version
Jun 10 09:07:42 <Herrie|Veer> Or drop the requirement for a max version altogether?
Jun 10 09:07:44 <morphis> but if an app now declares being compatible with 4.0.0 and works on an webOS device
Jun 10 09:07:51 <morphis> that doesn't mean it works on LuneOS too
Jun 10 09:07:55 <morphis> as the APIs are different
Jun 10 09:08:13 <morphis> so both could say they are 4.0.0 but have completely different APIs
Jun 10 09:09:02 <morphis> we could say 3.5.0:luneos:<release version> is our version number
Jun 10 09:09:09 <Herrie|Veer> morphis: I don't know, I haven't seen TV's. Don't know what LG has in the works or has released. They've been very limited in providing any info. OWO GH has been dead for almost a year or so
Jun 10 09:09:39 <morphis> Herrie|Veer: I am just trying to design this right from our point of view
Jun 10 09:09:42 <Herrie|Veer> So I have no idea at all what they've been up to and how compatible we are or not
Jun 10 09:09:56 <morphis> think we're not
Jun 10 09:10:16 <Herrie|Veer> morphis: Yes understand. Still quite some legacy apps would work on LuneOS based on my tests
Jun 10 09:10:31 <Herrie|Veer> Lots are TP only resolution though
Jun 10 09:10:35 <morphis> so are those feeds filtered by version?
Jun 10 09:10:45 <morphis> or do I get all displayed in preware independent of the verison?
Jun 10 09:11:02 <Herrie|Veer> I'm not sure I haven't tested that
Jun 10 09:11:38 <Herrie|Veer> I've just been going through my IPK dump, identifying Enyo apps and testing those
Jun 10 09:12:23 <morphis> ok
Jun 10 09:14:03 <morphis> Herrie|Veer: http://feed.pivotce.com/Packages
Jun 10 09:14:25 <Herrie|Veer> Problem is that 765 gets in the way of me properly testing the apps
Jun 10 09:15:15 <Herrie|Veer> I.e. One app doesn't launch, which could be due to a previous app not launching or closing properly. Reboot is only solution, sometimes LNC restart helps but mostly not
Jun 10 09:15:46 <Herrie|Veer> So it's very time consuming to get reliable test results and I have like 500 apps or so to test and get stuck every few
Jun 10 09:16:33 <morphis> Herrie|Veer: looks like we don't have any other chance then staying at 3.5.0
Jun 10 09:16:56 <morphis> and then adding additional version specifies to cover LuneOS specifics
Jun 10 09:17:12 <morphis> so we end up with 3.5.0:lunoes:<stage number> or so
Jun 10 09:17:25 <morphis> as 3.5.0 is what we forked from
Jun 10 09:17:30 <Herrie|Veer> morphis: Well we have... PivotCE guys are flexible, we just need to make sure legacy Preware deals with it properly
Jun 10 09:17:40 <morphis> right
Jun 10 09:18:44 <Herrie|Veer> But that shouldn't be too hard
Jun 10 09:18:54 <Herrie|Veer> We can simplify the 2.6 feed spec then
Jun 10 09:19:07 <Herrie|Veer> Drop the min/max LuneOSVersion
Jun 10 09:19:17 <morphis> so in luneos we only support 3.5.0 and 3.5.0:luneos:<stage number>
Jun 10 09:19:57 <Herrie|Veer> morphis: Yes, this is something that Garfonso or Aressel can sort ;)
Jun 10 09:20:06 <Herrie|Veer> Shouldn't be rocket science
Jun 10 09:20:19 <morphis> so 3.5.0 needs to work on both legacy webOS and LuneOS and 3.5.0:luneos:<stage number> only on LuneOS
Jun 10 09:20:22 <morphis> ok
Jun 10 09:21:02 <morphis> and if a 3.5.0 only app doesn't work we need to update our APIs to cover those things
Jun 10 09:23:39 <Herrie|Veer> Yeah but I doubt there will be much of those
Jun 10 09:24:13 <Herrie|Veer> For issue 341 we want this added to FirstUse still?
Jun 10 09:28:26 <Herrie|Veer> Garfonso: Were you able to sort 737?
Jun 10 09:28:48 <Herrie|Veer> Might be related to the relationship field issue?
Jun 10 09:29:28 <Garfonso> no, it's not related to that.. the relationship field issue should be solved
Jun 10 09:30:38 <Garfonso> issue here is that the vcard conversion in webos is a bit outdated... did not manage to wrap my head around updating it,  yet... because the new stuff might break some of the concepts that the conversion currently uses.
Jun 10 09:30:55 <Garfonso> I'll have to find time to think about that.
Jun 10 09:32:26 <Garfonso> morphis: that is one thing you wanted, right? https://github.com/webOS-ports/org.webosports.update/pull/14
Jun 10 09:32:55 <Garfonso> and image download should still go to a new branch?
Jun 10 09:39:11 <morphis> Garfonso: yeah, PR looks good
Jun 10 09:39:22 <morphis> Garfonso: yeah imge download on new branch would be good
Jun 10 09:39:28 <morphis> until all those bits are ready to land
Jun 10 10:15:58 <Garfonso> morphis: currently "bash-4.3# nyx-cmd OSInfo query webos_imagename" returns "luneos-dev-image" (on emulator and mako), but that's not what is in the url
Jun 10 10:30:09 <morphis> Garfonso: yesah that output is correct
Jun 10 10:30:32 <morphis> the .zip we have has output is just wrapped around that image
Jun 10 10:30:40 <morphis> so you have to do a slight coversion
Jun 10 10:30:51 <morphis> luneos-dev-image -> luneos-dev-package
Jun 10 10:31:10 <morphis> Garfonso: but for the image-based updates you should use http://build.webos-ports.org/luneos-testing/device-images.json
Jun 10 10:31:19 <morphis> that directly points you to the right images
Jun 10 10:32:26 <Garfonso> ah, ok.
Jun 10 10:33:37 <Garfonso> and about the path.. you mentioned "/userdata/luneos-data/system-update.zip" ... that is not in the luneos root, is it?
Jun 10 10:37:00 <morphis> it will be soon
Jun 10 10:37:32 <Tofe> morphis: are we going to support tenderloin update too?
Jun 10 10:38:02 <Garfonso> or emulator? ;)
Jun 10 10:39:27 <morphis>  /userdata will be mounted from initramfs
Jun 10 10:39:39 <morphis> Tofe: yes, tenderloin will be supported
Jun 10 10:39:49 <morphis> Garfonso: emulator will get tricky
Jun 10 10:39:57 <morphis> but might work as well
Jun 10 10:40:33 <morphis> changes are on https://github.com/webOS-ports/meta-webos-ports/commits/morphis/dizzy
Jun 10 10:40:45 <morphis> https://github.com/webOS-ports/meta-webos-ports/commit/88e799e7a0b2b7ba6083737681ca59244b4f3d56 and  https://github.com/webOS-ports/meta-webos-ports/commit/957224e0e61a733f8918d6e99637284bed23b34d
Jun 10 10:40:53 <Garfonso> hehe, probably not really necessary. Just like emulator for testing..
Jun 10 10:41:23 <morphis> Garfonso: it would be really nice to have
Jun 10 10:41:31 <morphis> so you don't have setup the emulator over and over again
Jun 10 10:42:00 <Garfonso> right.
Jun 10 10:48:19 <morphis> but devices are the primary target for this atm
Jun 10 10:54:03 <Garfonso> the /var/preferences/system-update/update-to-version file is unnecessary with the new system?
Jun 10 10:54:48 <Garfonso> it was used to ignore manifest.platformVersion and update to a newer stage.
Jun 10 10:55:15 <Garfonso> not sure if that is possible with our current system at all..?
Jun 10 11:16:49 <morphis> Garfonso: we still have the stage numbers
Jun 10 11:17:04 <morphis> and we know always the current version from /etc/lunoes-release
Jun 10 11:17:20 <morphis> so I think we can safely drop that
Jun 10 11:25:27 <JaMa> can I push small meta-qt5 upgrade to testing branch?
Jun 10 11:28:20 <morphis> JaMa: sure
Jun 10 11:33:32 <JaMa> one commit to meta-webos-ports
Jun 10 11:35:26 <Garfonso> morphis: can I just use the image url behind the highest stage number in device_images.json?
Jun 10 11:35:52 <morphis> Garfonso: you should check manifest.json first
Jun 10 11:35:56 <morphis> for the current platformVersion
Jun 10 11:36:11 <morphis> then take that number and select the device image from the device-images.json
Jun 10 11:36:12 <Garfonso> ok.
Jun 10 11:38:45 <morphis> would be good to have a download manager for that already
Jun 10 11:38:51 <Garfonso> Can I write that to a file in checkUpdateAssistant (because it does all the work already) and read that file in downloadUpdateAssistant?
Jun 10 11:40:43 <morphis> which file?
Jun 10 11:41:15 <Garfonso> a fully backward compatible downloadmanager would take quite a lot of work, still... but I can get the stuff that I already did there into something that can at least download files for us but does not offer all the advanced api stuff that legacy had. ;)
Jun 10 11:43:01 <Garfonso> not sure.. something in temp? Just to transport stuff from checkupdate to download assistant. Because between checkupdate and the request to download the update the service might be restarted.
Jun 10 11:43:22 <morphis> Garfonso: ah
Jun 10 11:43:32 <morphis> yeah, you could put something for that into /tmp
Jun 10 11:43:58 <morphis> Garfonso: but better would be a persistent storage somewhere
Jun 10 11:44:07 <morphis> or do we care if the device is rebooted in between?
Jun 10 11:46:17 <Garfonso> not really.. the file would be written, if the user presses "check for update" in settings and be required, if the user presses "download update" in settings. Download button will be there only after check for updates, anyway.
Jun 10 11:47:58 <Garfonso> the button press could be replaced with some activity, but still check for update would be run before anyway. Think it is not a big deal to forget that after a reboot.
Jun 10 12:11:35 <JaMa> morphis: is this correct? scripts/update-manifest.py -n 1 -r luneos-testing-${BUILD_VERSION} manifest.json
Jun 10 12:11:45 <JaMa> it looks like "testing" is twice in -r
Jun 10 12:12:01 <morphis> JaMa: I thought I fixed that already
Jun 10 12:12:44 <morphis> JaMa: https://github.com/webOS-ports/jenkins-jobs/blob/master/jenkins-job.sh#L304
Jun 10 12:12:55 <JaMa> ah you did, sorry
Jun 10 12:53:44 <morphis> Garfonso: btw. you my discussion with Herrie|2 on the feeds for LuneOS and how we differentiate those only being able to run on legacy from those which can run on LuneOS?
Jun 10 12:56:09 <Garfonso> parts of it... I think 3.5.0:luneos + stage or so is the way to go.
Jun 10 12:56:17 <Garfonso> we should be able to process that in preware.
Jun 10 13:07:14 <morphis> ok
Jun 10 13:07:29 <morphis> just wanted someone to second me so that we don't forget any detail
Jun 10 13:20:11 * DougReeder waves good morning
Jun 10 13:20:35 <Herrie|Veer> morphis/Garfonso: I updated 2.6 draft based on discussion
Jun 10 13:21:20 <Herrie|Veer> DougReeder: morning
Jun 10 13:21:52 <Garfonso> DougReeder: morning
Jun 10 13:22:45 <morphis> Herrie|Veer: thanks
Jun 10 13:23:04 <Herrie|Veer> Check if you're happy with it like this
Jun 10 13:23:09 <morphis> so we just need to update any apps which are specific for LuneOS and otherwise can use the pivotce feed as it is
Jun 10 13:23:45 <morphis> Herrie|2: looks good
Jun 10 13:25:06 <Herrie|Veer> morphis: Yeah just need to make sure that Mojo apps have max version populated with something < 3.5.0 and that Enyo apps that work don't have a max version
Jun 10 13:25:12 <Herrie|Veer> But that's doable
Jun 10 13:26:31 <morphis> no
Jun 10 13:26:45 <morphis> we should differentiate mojo apps somehow differently
Jun 10 13:28:24 <Herrie|Veer> Why? Since we don't support Mojo (though theoretically it might work when you copy over the copyrighted frameworks from legacy?), why would we bother?
Jun 10 13:30:13 <Herrie|Veer> I initially had the idea of a field called DevelopmentFramework or something which could be Mojo, Mojo2, Enyo1, Enyo2, pdk, hybrid
Jun 10 13:31:34 <morphis> right
Jun 10 13:31:48 <morphis> but we could simply let people run into this and the app would refuse to start
Jun 10 13:32:26 <DougReeder> If we want to include that, I don’t think it should be an enum
Jun 10 13:32:49 <Herrie|Veer> Yeah also true might be good to just provide a popup when the framework is not supported?
Jun 10 13:32:50 <DougReeder> THe JS framework is distinct from whether it uses the PDK
Jun 10 13:32:57 <Herrie|Veer> Shouldn't be too hard?
Jun 10 13:33:26 <DougReeder> I think you’d want a separate flag for “requiresPDK”
Jun 10 13:34:09 <DougReeder> Maybe a flags for “requiresMojo” and “requiresEnyo1”
Jun 10 13:34:51 <DougReeder> It was possible to package a Mojo version and an Enyo version in one package.
Jun 10 13:35:31 <DougReeder> Feed format should focus on what the app needs from the system to run.
Jun 10 13:38:13 <DougReeder> If the app includes its framework, like Enyo2 apps do, the feed doesn’t care.
Jun 10 13:38:49 <DougReeder> I expect to see Famo.us, React, and many others used. We don’t need to keep track of that.
Jun 10 13:40:54 <DougReeder> As an example, Zap Photoshare includes a plugin (making it a hybrid), but it runs without the plugin, so you wouldn’t want to exclude it from LuneOS, which doesn’t (yet) support the PDK.
Jun 10 13:41:07 <Herrie|Veer> DougReeder: Ideally yes but we also have the Precentral legacy feed to take into account that one cannot be really updated I think?
Jun 10 13:41:24 <Herrie|Veer> Not 100% sure how that feed is generated, maybe ka6sox knows?
Jun 10 13:43:10 <DougReeder> The Precentral feed does not include the necessary info.  I don’t think we should be including in the bundled-but-disabled fields in Preware2.
Jun 10 13:43:37 <DougReeder> If people want to add it, fine, but many of the apps there just won’t work.
Jun 10 13:46:05 <Herrie|Veer> Just trying to see how we can boost our app eco system a little without too much effort :P
Jun 10 13:46:11 <DougReeder> Yeah.
Jun 10 13:46:40 <DougReeder> Preware needs to do something reasonable when a feed has incomplete data.
Jun 10 13:47:07 <DougReeder> So, any new fields would be undefined.
Jun 10 13:48:28 <DougReeder> I suppose we could have a pref “show possibly incompatible packages” or some such
Jun 10 13:50:07 <DougReeder> If you really want to include the PreCentral feed in the bundles-but-disabled, we could add “most apps are incompatible” to the feed name.
Jun 10 13:51:30 <Herrie|Veer> There are different ways to deal with it. I think it's fairly straight fwd in the webappmgr to check if Mojo/Mojo2 are available and if not when app tries to use it, it will feedback something to user.
Jun 10 13:51:56 <Herrie|Veer> Not doing anything and no feedback besides journalctl isn't very user friendly :P
Jun 10 13:52:56 <DougReeder> Yes, the webappmgr should deal gracefully with apps that require Mojo.
Jun 10 13:54:41 <Herrie|Veer> I should retest what happens if I were to manually copy over the frameworks from legacy. I had someone report that worked on OWO
Jun 10 14:16:58 <morphis> DougReeder: sounds like a good idea
Jun 10 14:17:12 <morphis> all modern style apps shouldn't depend on a system provide framework like mojo or enyo1
Jun 10 14:18:04 <DougReeder> Which of my ideas is good? :-) Flags for things required from the OS?
Jun 10 14:20:31 <morphis> yes
Jun 10 14:20:37 <morphis> flags for those special things
Jun 10 14:24:05 <Herrie|Veer> morphis: Anything re the wallpaper change you mentioned a while ago? What you have in mind? It might be good to tackle issue 721 as well
Jun 10 14:24:25 <morphis> Herrie|Veer: I would like to have something fresh
Jun 10 14:24:52 <Herrie|Veer> Which could be done with a symlink probably? Users are familiar with placing their stuff in media/internal
Jun 10 14:33:48 <morphis> symlink?
Jun 10 14:36:53 <Herrie|Veer> Currently wallpapers on the N4 are stored somewhere not accessible for user via USB. Don't remember where exactly while legacy had them in media/internal/wallpapers or so
Jun 10 14:37:11 <Herrie|Veer> Which the user could access via USB
Jun 10 14:37:17 <morphis> they can be in /media/internal and /usr/share/wallpapers
Jun 10 14:37:31 <morphis>  /usr/share/wallpapers are the default ones
Jun 10 14:38:20 <Herrie|Veer> Legacy had media/internal/wallpapers. We currently don't have that folder. Also not sure it would pick up files from there in FilePicker in case we'd create it.
Jun 10 14:39:08 <morphis> mediainexer indexes /media/internal completely
Jun 10 14:39:14 <Herrie|Veer> Ah ok
Jun 10 14:39:24 <morphis> so no difference if any wallpapers are in a specific folder or somewhere else
Jun 10 14:39:45 <Herrie|Veer> So just creating the folder might be enough. I just don't like to clutter a "root" folder with files
Jun 10 14:43:29 <ka6sox> Herrie|Veer, which feed are you asking how its generated?
Jun 10 14:44:13 <Herrie|Veer> precentral app feed
Jun 10 14:49:01 <ka6sox> that is an aggregation of metadata from the pre central repository
Jun 10 14:49:32 <ka6sox> it does an xml scrape
Jun 10 14:50:00 <Herrie|Veer> Ah I think I've seen the script for that somewhere
Jun 10 14:50:19 <ka6sox> ya
Jun 10 15:02:21 <Herrie|Veer> it's on webos-internals/build/scripts right?
Jun 10 15:05:02 <ka6sox> should be
Jun 10 15:05:18 <ka6sox> thats the sources for the actual builder - the admin scripts
Jun 10 15:06:08 <Herrie|Veer> OK
Jun 10 16:00:09 <Herrie|Veer> morphis: We have anything specific for the Enyo guys to work on? Bluetooth bits in Settings which will be quite a bit?
Jun 10 18:00:57 <morphis> Herrie|2: I would really like to get a media app some day
Jun 10 18:01:01 <morphis> one that can handle images, music and video
Jun 10 18:01:15 <morphis> through the std. html5 interfaces
Jun 10 18:08:32 * DougReeder nods
Jun 10 18:13:29 <morphis> basically querying the media database we have already in db8 and display that
Jun 10 18:13:45 <morphis> we could also do different apps for each type
Jun 10 18:14:13 <morphis> I am not really the user interface guy so anybody who knows that better should decide :)
Jun 10 18:16:40 <DougReeder> I think the TP Photos & Videos is a good model to follow.
Jun 10 18:17:18 <DougReeder> Flat list of libraries & albums in the left pane, thumbnail browser in the right.
Jun 10 18:19:35 <DougReeder> Enyo has a nice ImageCarousel which uses ImageView - but ImageView doesn’t support video nor audio.
Jun 10 18:20:04 <DougReeder> We probably need to build new Controls based on those.
Jun 10 18:24:11 <DougReeder> Though, maybe someone in the Enyo community already has.
Jun 10 19:06:20 <Herrie|2> DougReeder: Didn't you create this for VIdeo? http://hominidsoftware.com/enyoVideo/
Jun 10 19:06:58 <DougReeder> I did, but that’s for environments where you might need Flash to play videos.
Jun 10 19:24:29 <Herrie|2> Ah ok
Jun 10 20:08:39 <Herrie|2> Tofe: https://github.com/webOS-ports/webos-keyboard/pull/66
Jun 10 20:40:33 <Garfonso> morphis, DougReeder, Herrie|2: could we use the package depency mechanism somehow to identify required frameworks?
Jun 10 20:40:46 <Garfonso> I know that preware supports it..
Jun 10 20:42:07 <Garfonso> and some old feed had an enyo1 package, so apps could already depend on that.
Jun 10 20:43:09 <Garfonso> for mojo one could make an empty package for legacy and just not have it for luneos, so packages can not be installed.
Jun 10 20:43:19 <Garfonso> Maybe if someone then leaks a mojo package for LuneOS... just thinking. ;)
Jun 10 20:56:35 <DougReeder> That sounds clever, but I’m not familiar with the package dependency mechanism.
Jun 10 21:08:37 <ka6sox> they never released mojo as I really believe they wanted to leave it behind..not that it wasn't good…it just wasn't what they wanted to support anymore.
Jun 10 21:09:01 <ka6sox> I asked quite a few times and even said the community would be responsible for supporting it...
Jun 10 21:09:17 <ka6sox> "This isn't the direction we want people going" was the response.
Jun 10 21:48:51 <DougReeder> That’s usually a problem when one entity controls a key resource.
Jun 10 21:**** ENDING LOGGING AT Thu Jun 11 02:59:59 2015