**** BEGIN LOGGING AT Tue May 21 02:59:58 2013 May 21 04:22:51 GodGinrai: still around? May 21 04:23:02 yep May 21 04:24:32 any suggestions why my published properties wouldn't be getting set with the getters/setters that should be getting created? May 21 04:25:07 are they in your list items? May 21 04:26:02 yes May 21 04:26:29 like when you were trying to use setFill in your setupItem? May 21 04:26:32 but prior to any list items being created May 21 04:26:33 right May 21 04:26:52 well, not precisely, this is at count: 0 May 21 04:27:02 hrm? May 21 04:27:23 at count 0, you wouldn't have any elements to set, would you? May 21 04:27:40 I've got something that's setting a published property in the declared element before the list is populated May 21 04:28:01 the getters/setters are working, just not actually making the change May 21 04:28:06 probably locking, I guess May 21 04:28:36 can you show me a pastebin so I can see what you're doing? May 21 04:29:09 hold on May 21 04:33:51 http://pastie.org/7937581 May 21 04:34:12 questionPicked() is what get's called prior to populating the list, and setType() is specifically what I'm talking about May 21 04:34:57 ah May 21 04:34:59 I see May 21 04:35:16 That's an interesting idea you have there May 21 04:35:44 I don't want to have to create/destroy components all over the place May 21 04:36:05 does "interesting" mean bad? May 21 04:36:47 Interesting means "I can see the benefit that this would have if you could do this, but I don't think it works this way" May 21 04:37:26 meaning flyweight locks in the rendering prior to actually populating, presumably on declaration May 21 04:37:38 probably May 21 04:38:13 I'm not even sure the components block you defined ever actually becomes something you can use. I have a feeling that the methods that allow it to do so are probably overridden in the List definition May 21 04:38:41 or rather in the Flyweight definition May 21 04:39:01 however May 21 04:39:10 I think it is still possible to do what you want to do May 21 04:39:35 but instead of doing it before rendering, It may be possible to change the type after rendering and then rerender? May 21 04:39:42 for each element in the list May 21 04:40:37 that seems like an efficiency overhead May 21 04:41:08 true, that was just a quick and dirty solution I came up w/ May 21 04:41:19 btw May 21 04:41:38 couldn't you just set the type in setupItem? By that point, the item is created already, isn't it? May 21 04:41:43 then you don't have to rerender May 21 04:43:44 hrm, I thought I tried that, but I'll see May 21 04:45:01 no, I think there's a rendering issue May 21 04:45:13 oh really? May 21 04:45:15 I don't think you're allowed to change the way something renders in setupItem May 21 04:45:22 hrmm May 21 04:45:25 because of flyweight pattern May 21 04:45:45 that would make sense May 21 04:45:55 they did mention that it tries to just stamp everything out May 21 04:46:54 well, it maintains a singleton of the list item May 21 04:47:15 yea May 21 04:49:45 although, if you break encapsulation, the components of the list item aren't locked, seeming May 21 04:49:48 seemingly* May 21 04:50:08 hrm? May 21 04:51:41 if you refer to the item directly, in setupItem, and don't try to use the setters, but instead something like this.$.oItem.$.input.setType(); seems to work, ish. May 21 04:53:14 oh wait May 21 04:53:18 I see your problem May 21 04:53:20 lol May 21 04:53:33 I can tell you why that works May 21 04:53:40 In your create May 21 04:53:49 you set the type May 21 04:53:58 however May 21 04:54:14 the item is already past "create" in your setupItem May 21 04:54:21 when you are trying to set the type May 21 04:54:30 oh May 21 04:54:34 and since you are setting the type of the EditableListItem May 21 04:54:36 and not the input May 21 04:54:40 yeah May 21 04:54:45 you don't have any way of conveying that to the input May 21 04:54:54 duh, that makes sense May 21 04:54:56 do this May 21 04:55:01 add this function: May 21 04:55:13 typeChanged: function() { May 21 04:55:15 this.$.input.setType(this.type); May 21 04:55:16 } May 21 04:55:26 and then call that instead of "this.$.input.setType(this.type);" in your create May 21 04:55:39 and that should allow you to treat it the way you've been wanting to May 21 04:57:41 yep, already there May 21 04:57:47 this may even make your initial method work, but I still think that working is unlikely May 21 04:57:54 But let me know if it does May 21 04:58:11 although truthfully May 21 04:58:23 I think changing it in setupItem is the right way to do it May 21 04:58:33 rather than trying to do it beforehand May 21 04:59:44 it does seem to, mostly May 21 05:00:00 now each list item is indented one "radio input" width, seemingly May 21 05:00:17 o_ô May 21 05:00:22 http://cl.ly/image/0H0a1K310V3D May 21 05:00:32 lol May 21 05:00:47 so it is getting indented further as it goes down? May 21 05:01:23 what's your CSS for it? May 21 05:02:44 also May 21 05:02:52 why are you using a FittableRows for this kind? May 21 05:03:31 no, no CSS May 21 05:03:41 oh, also, another thing May 21 05:03:54 FittableRows ensures the text stays next to the input May 21 05:03:58 you don't need to use display none styling May 21 05:04:19 how do I get it to trigger the flip between text and the text input? May 21 05:04:19 enyo.Control has show() and hide() functions May 21 05:04:24 oh May 21 05:04:28 that makes sense May 21 05:05:12 Also, I'm not sure how FittableRows is supposed to make things sit next to each other May 21 05:05:21 that's what enyo.ToolDecorator is for May 21 05:06:18 try changing it from enyo.FittableRows to enyo.ToolDecorator and tell me how it turns out May 21 05:08:18 nope, new lines May 21 05:08:34 newlines? o.o May 21 05:08:51 not newlines, they just separate the radio input from the text component May 21 05:09:18 how so? May 21 05:09:20 pic? May 21 05:09:32 also, did that fix the stepped problem? May 21 05:09:35 http://cl.ly/image/2q282M0e0P2x May 21 05:09:40 it did May 21 05:09:52 ok May 21 05:09:55 to fix that May 21 05:10:12 remove the float: left on the checkbox May 21 05:12:07 did that fix it for you? May 21 05:12:35 no May 21 05:12:47 did anything change? May 21 05:13:51 if I move ToolDecorator to the wrapper div, not the kind overall, it works May 21 05:14:04 hrmmmm May 21 05:14:19 oh lol May 21 05:14:24 I forgot you had a wrapper div May 21 05:14:30 just get rid of the wrapper div May 21 05:14:41 and make the kind an enyo.ToolDecorator May 21 05:14:46 that will simplify things May 21 05:16:02 yes, thanks May 21 05:16:34 ToolDecorator is one of the most simple kinds, but it is really useful :) May 21 05:17:35 Also, unless you need something to expand to fill an area, there's no need to use Fittables May 21 05:18:04 unless you are lazy and are planning to use the expanding area to force the things around it to the edges :P May 21 05:18:23 well, that's a fair point, but at this point, I don't care May 21 05:18:33 lol May 21 05:19:09 so, everything seems to be working nicely now? May 21 05:19:58 yes, thank you May 21 05:20:09 now I need to move the "add new list item" thing down to the bottom May 21 05:20:11 but yes May 21 05:20:21 cool cool May 21 05:20:36 Well, I gotta head off to bed. I'll be on sometime tomorrow if you have any more questions May 21 05:20:37 :) May 21 05:21:15 thank you for your help May 21 05:21:31 you're welcome :) May 21 05:21:34 g'night May 21 13:41:38 morning May 21 13:43:25 if I have a couple of apps being renderInto(document.body), is there a best practice I should follow for instantiating? May 21 13:44:12 meaning, does it matter if I do new App1.renderInto(document.body); then later on replace it with new App2.renderInto(document.doby) May 21 13:44:35 should I be destorying App1 or setting App1.destroyed = true explicitly? May 21 13:44:45 before App2 May 21 14:05:19 morning May 21 14:12:37 good morning May 21 14:13:54 have much knowledge when it comes to doing multiple Apps rendering into the body? May 21 14:14:14 wondering if I need to explicitly call destroy() before doing renderInto on a new instance of a differentapp May 21 14:17:21 well, I don't know for sure if Enyo checks to see if anything is rendered there May 21 14:18:42 but I'm almost certain that rendering the new app would not destroy the other object, so you should call destroy on the old app to save memory May 21 14:18:53 yeah that's what I was thinking May 21 14:20:23 about half-way down this page there's a Note: about using this.destroyed May 21 14:20:25 https://github.com/enyojs/enyo/wiki/Object-Lifecycle May 21 14:20:46 wasn't sure if I should be using this.destroyed or destroy() May 21 14:23:41 I'm pretty sure that setting this.destroyed doesn't do anything on its own May 21 14:24:08 or at least, that's the way it sounds to me May 21 14:26:17 I'll have yeah I was a little confused May 21 14:26:26 I'll post to the forums May 21 14:29:15 pmarsh: if you want to obliterate a component, use destroy()…destroyed gets run at the end of that, so you can override it to do other cleanup, etc. May 21 14:31:16 ok great thank you May 21 15:10:36 sugardave: I like how you described that... I don't get to hear people use the term obliterate often. :) May 21 15:13:35 OMG you can hear me?!? May 21 15:13:38 :P May 21 15:28:33 hi all, I've got a list in a drawer, that gets items added to it dynamically, and it seems like the drawer is holding 2x as much space as there are items in the list http://cl.ly/image/0S3h2d1z3V44 May 21 15:28:44 is this just a resize issue? or is there something else going on? May 21 15:29:47 bbl, gotta make phone calls, and my Pre3 can't do net and phone at the same time May 21 15:58:57 sugardave: came across a post on the forums that describes deviceReady() being picked up and fired twice when using PhoneGap May 21 15:59:11 happen to have packaged with phonegap before? May 21 15:59:41 I am right now on an internal project…it's only happening once for me, though May 21 16:00:07 ha, ok thanks May 21 16:00:43 pmarsh: how are you intercepting it? May 21 16:01:23 have a Signal kind as one of my App's components listening for ondeviceReady: "deviceReady" May 21 16:01:36 "deviceReady" being a method on App May 21 16:01:49 followed the doc on the site,going to double check May 21 16:01:57 what version of cordova? May 21 16:02:08 I am using 2.6 May 21 16:02:33 2.7 here, just grabbed the latest May 21 16:03:07 hmm, when I downloaded that the other day it didn't have the webos lib May 21 16:04:39 pmarsh: another thing, I am using MVC/enyo.Application and I have it set to renderOnStart: false, I have my Signals listen for ondeviceready, which then kicks off a service call which finally renders the main view as a callback in the success handler for my service call May 21 16:05:03 pmarsh: I'd be interested to see if it only fires once with 2.6 May 21 16:05:25 I'll give it a shot, I had packaged up the Sampler just to see if it was something I was doing May 21 16:05:33 I'll package up the sampler with 2.6 May 21 16:05:39 is it doing it there, too? May 21 16:11:37 (the Sampler) May 21 16:12:13 yes sorry was just confirming May 21 16:12:28 all I'm doing is an enyo.log('phonegap ready'); May 21 16:16:47 sugardave: any thoughts on weird spacing with a List? May 21 16:17:02 don't see anything about webos in the changelog of 2.7 May 21 16:17:14 summatusmentis: this is a random thought, reflow()? May 21 16:17:55 I'll try with 2.6 in a bit and confirm May 21 16:19:15 summatusmentis: somewhere I experimented with Repeater -> Drawer -> Repeater….and I remember I had to do a lot of wrangling and made a lot of .resized() calls May 21 16:20:02 I'd just use a repeater so I don't have to much around with row locking, but I need re-orderability May 21 16:20:51 it's probably going to be a question of either resizing or rerendering as you open the drawer May 21 16:21:01 but there's no reason why it shouldn't work May 21 16:22:50 hrm May 21 16:24:23 does resized() propagate? May 21 16:25:50 .resized() should tell a container to make its children render and then resize itself based on their dimensions May 21 16:26:29 I'm looking at my code now….it seems I managed to make it work (embedded Repeaters) without the resized() calls….I think May 21 16:27:19 but now github has dies May 21 16:27:23 s/dies/died/ May 21 16:31:32 if I resize the list, the component below it shifts down with every add May 21 16:31:43 if I don't, it just holds, and the list hides underneat it May 21 17:19:12 this is more of a javascript scope problem, but I'm a bit confused. May 21 17:24:05 summatusmentis: now that I think about it more, I tried to use List in the Drawer, but never could get it work properly. So, I resorted to using Repeater with the hope my Drawers wouldn't get past an insane number of Repeater items May 21 17:25:09 http://jsfiddle.net/pmarsh/5y3bK/1/ May 21 17:26:01 in that code I'm just having a heck of a time trying to figure out how to get App.confirmed to be called as the callback on the notification.confirm() May 21 17:26:40 pmarsh: try this one http://jsfiddle.net/5y3bK/2/ May 21 17:27:45 thanks Dave May 21 17:27:59 I pulled the drawer out, but I'm seeing the same issue May 21 17:28:01 also: this.bindSafely("confirm") would work May 21 17:29:41 summatusmentis: fiddle it up while I do a reboot….8GB on this Mac gets eaten up rather quickly these days :/ May 21 18:29:34 this is really grinding ma gears May 21 18:35:16 I'm back May 21 18:35:28 Did anyone answer your question, summatusmentis? May 21 18:41:37 GodGinrai: Dave helped a bit, asked him to throw it up on fiddle May 21 18:42:35 GodGinrai: what pmarsh May 21 18:42:37 said May 21 18:42:54 this fiddle is simplified, but you can see the issue http://jsfiddle.net/SZA6Z/4/ May 21 18:47:11 summatusmentis: I have your answer, if sugardave hasn't given it yet May 21 18:55:37 well, he's not back after a reboot May 21 18:56:02 ah May 21 18:56:07 in a meeting atm May 21 18:56:13 will talk w/ you after May 21 18:59:32 kk May 21 20:19:21 GodGinrai: still meeting? May 21 20:30:52 hey summatusmentis. I'm out of the meeting May 21 20:31:01 and currently tracking down your problem May 21 20:31:14 oh, I thought you said you had an answer May 21 20:31:22 which made me think it was something obviously stupid I'd missed May 21 20:34:52 you don't need to spend very much time on it, I'll keep playing with it May 21 20:40:56 well May 21 20:41:06 at first I had thought that May 21 20:41:30 because I thought it was related to the fit: trues that are rampant in the code May 21 20:41:46 but it actually seems to be a problem w/ your List May 21 20:49:20 right May 21 21:06:49 summatusmentis: I think this is a bug introduced into List May 21 21:07:14 I would check the blame to see who introduced it, but I can't :/ May 21 21:09:52 GodGinrai: nothing has changed in terms of enyo and this wasn't happening before May 21 21:10:08 this is a problem caused by the updateMetrics method May 21 21:10:26 when did it start? May 21 21:11:06 AFAICT, it looks like this will happen with any list that has rows smaller than 100px high when they are reset May 21 21:11:22 just last night May 21 21:11:32 after I figured out the input stuff properly May 21 21:11:43 hrm May 21 21:11:51 let me try making a fiddle May 21 21:39:17 summatusmentis: simple as it gets: http://jsfiddle.net/cgTHM May 21 21:39:18 I just want the height of my list to grow with each item, until it starts to overflow, then scroll, with the "add" controll hanging off the bottom May 21 21:39:56 Notice how my simple list there is too large? May 21 21:40:12 It's a problem with the way lists set height May 21 21:40:13 yeah May 21 21:40:27 ugh May 21 21:40:42 This needs to be filed as a bug report May 21 21:42:05 you seem to know more about the internals, can you file it, and add me? May 21 21:44:23 Sure. I'm not sure how I would add you May 21 21:44:27 tho May 21 21:46:01 well, link it here, and I can watch it, or something May 21 21:47:44 Will do. I'll do it after I get back from work May 21 21:49:07 cool, I'm gonna head out, I'll be idling though May 21 21:50:53 alright May 21 21:51:14 I'm heading back, too. I'll be on when I'm back **** ENDING LOGGING AT Wed May 22 02:59:58 2013