**** BEGIN LOGGING AT Sat Feb 11 02:59:57 2012 Feb 11 16:57:49 anyone tried to port widgets to enyo 2.0 yet? it sucks -.- Feb 11 17:01:39 no i havent Feb 11 17:01:47 since new widgets will be out soon Feb 11 17:03:47 i don't believe in "soon" if an open source projecs hides its progress. Feb 11 17:04:34 hides it progress? Feb 11 17:05:00 i don't see a git repository for the widgets, did i miss somethign? Feb 11 17:06:13 no git repo for them yet, they will probably be pushed to the enyo repo not a new one, but I believe some of the widgets will require the qt/webkit stuff they are going to release this month and want to push out working code for the initial commits Feb 11 17:06:17 just my guess Feb 11 17:06:25 if shit dont work they will get harassed Feb 11 17:06:31 so its like a no win situation Feb 11 17:07:01 as enyo isn't supposed to depend on webkit anymore i don't see why they would wait for qt/webkit stuff Feb 11 17:07:35 and this "if it doesn't work people will only complain" is just not what you do in the open source world Feb 11 17:09:07 when i start a project I usually dont see a repo unless I have something sorta working Feb 11 17:09:17 s/see/seed/ Feb 11 17:09:31 yeah Feb 11 17:09:55 but if it isn't "sorta working" now, when do you expect it to be working? yes, not soon. Feb 11 17:11:56 idk im sure they are working hard with the little resources they have Feb 11 17:11:58 stbuehler, https://twitter.com/#!/_PuffTheMagic_/status/168381571567583233 Feb 11 17:12:54 i did not say i blame some poor devs for not working Feb 11 17:13:32 well we are talking about non-opensource devs in a non-opensource company trying to do opensource Feb 11 17:13:32 cross browser dom js/css is no fun Feb 11 17:13:43 lets just see if they meet their timelines Feb 11 17:14:08 i'm just saying they didn't get what opensource is yet Feb 11 17:15:17 well anyway... Feb 11 17:15:23 lets talk about vkb classes for a min Feb 11 17:15:42 we need to overhaul this mess of css and layouts Feb 11 17:16:17 pre3 needs its own layouts that are different than the rest of the phones Feb 11 17:16:33 and with my experiences from the past they really should push what they have, so they can get feedback early (idk if you remember the Future stuff - it was nice but had some design flaws, which couldn't be fixed anymore as everything depends on it) Feb 11 17:17:02 "Future stuff"? Feb 11 17:17:29 https://developer.palm.com/content/api/reference/javascript-libraries/foundations/foundations-control-future.html Feb 11 17:18:05 the point of opensource is that you get review, and often people can help you to do things better Feb 11 17:18:31 if you only publish your stuff when it is basically done, that isn't possible Feb 11 17:19:05 oh "futures" Feb 11 17:19:48 stbuehler, i dont disagree with you about any of this Feb 11 17:20:02 im just trying to think of reasons why its not out yet Feb 11 17:21:55 mojo was basically thrown together by like 1 guy in a weekend from what I hear Feb 11 17:22:18 by someone who didnt even write js Feb 11 17:23:13 re @css classes: i don't think there is much to refactor Feb 11 17:23:47 you could try to use flex: more often that to specify widths manually Feb 11 17:24:52 and remove unused stuff (like .mod.meta, .mod.super) Feb 11 17:25:03 i dont mean just the css Feb 11 17:25:11 well like, 320px isnt really much space to put lots of buttons a phone, its almost like 2 rows would be good for phones Feb 11 17:25:15 when in portrait mode Feb 11 17:25:22 but then 1 row in landscape Feb 11 17:25:41 and we def need different size buttons for the pre1/pre2/veer Feb 11 17:25:56 the size is not refactorable Feb 11 17:25:56 cause right now they use buttons sized for the pre3 Feb 11 17:26:00 and they loock huge Feb 11 17:26:13 ok refactor is not the right word Feb 11 17:26:22 you just have many combinations, and you have to specify each of them - idon't think calculating sizes is going to help Feb 11 17:26:36 calculating sizes? who said that Feb 11 17:26:59 it woud be the only way to reduce the many classes... Feb 11 17:27:13 i never said he had to reduce the number classes Feb 11 17:27:22 s/he/we/ Feb 11 17:27:39 forget I said anything Feb 11 17:28:27 well, i see your point with phone orientations Feb 11 17:28:57 the question is whether it is worth investing many hours :) Feb 11 17:29:22 well the vkb stuff isnt really that usable on the phones yet Feb 11 17:29:44 kk Feb 11 17:30:06 step 1: add different css classes for the different phone resolutions Feb 11 17:30:37 stbuehler, Matthew McNulty replied to my tweet Feb 11 17:30:38 step 2: allow different layouts for "large" and "small" orientations Feb 11 17:30:49 he said they will be in a new repo Feb 11 17:31:01 once even a small portion is ready Feb 11 17:31:10 s/ready/close Feb 11 17:32:08 i don't know you you interpret that answer, but i'd say they are more than 3 weeks away from something usable :) Feb 11 17:32:43 (i'm just pissed that enyo 1.0 doesn't work with firefox, otherwise i wouldn't care^^) Feb 11 17:33:06 i hear you on that, i want to make a webpage with enyo widgets Feb 11 17:33:14 yep Feb 11 17:40:05 stbuehler, well the large/small distinctions are also sorta backwards because for the TP, the "up" orientation is large, but on phones its small Feb 11 17:40:27 we need to somehow switch to "landscape"/"portrait" Feb 11 17:46:55 well "large" == "landscape", "small" == "portrait" Feb 11 17:47:01 how you name them doesn't really matter Feb 11 17:47:46 naming them "up" and "left" would be wrong imho Feb 11 18:15:31 ya up and left would be bad Feb 11 18:34:50 cryptk|offline, my popper2 came this am Feb 11 18:38:57 stbuehler, ping Feb 11 18:39:22 i was thinking we could pack multiple layouts in 1 file using kbdLayoutLoad() Feb 11 18:39:24 for example Feb 11 18:39:49 right now it justs 2 params: name and layout Feb 11 18:40:04 what if it was name, layout1, layout2, Feb 11 18:40:29 so if layout2 does not exist it uses layout1 for both landscape and portrait Feb 11 18:40:44 but if layout2 exists it uses that for portrait Feb 11 18:40:49 and 1 for landscape Feb 11 18:41:19 sure Feb 11 18:41:49 you shouldn't split landscape/portrait in different files, so your idea sounds fine to me Feb 11 18:42:57 another idea: put the charselect data into the layouts; so a layout can specify multiple "sym" buttons that popup different dialogs Feb 11 18:43:09 i was going to do that :D Feb 11 18:43:24 and support showing "F1" but sending the actual F1 key Feb 11 18:43:40 ? Feb 11 18:44:08 well, making the selection show "F1" is easy Feb 11 18:44:16 but it probably would send "F1" as text right now Feb 11 18:44:28 i have no idea what you are talking about Feb 11 18:44:41 ohhh Feb 11 18:44:41 nm Feb 11 18:44:43 i get it Feb 11 18:44:52 add function keys to the char selector Feb 11 18:44:56 yes Feb 11 18:45:01 ok i get what you are sayiung Feb 11 18:45:07 thats prob a good idea Feb 11 18:45:16 like a "popup" vkb Feb 11 18:45:36 hmmm Feb 11 18:45:40 just that we don't care about things like modifiers, layout, colors and so on Feb 11 19:29:17 stbuehler, im thinking it might clean up the code if we converted the vkblayouts to an enyo kind Feb 11 19:31:44 i mean its already half there Feb 11 19:50:58 ooh Feb 11 19:51:17 enyo.Statefull is perfect for switching between portrait/landscape mode Feb 11 21:39:40 stbuehler, ping Feb 11 21:45:54 PuffTheMagic: pong Feb 11 21:47:41 stbuehler, i in the progress of converting the vkblayouts into enyo kinds based on enyo.Statefull, it still need to fix up the css to work with this, but I just wanted to push the wip into a branch so you could get an idea where im going and provide some input Feb 11 21:47:44 hope you dont hate it Feb 11 21:48:53 https://github.com/RyanHope/wTerm/commit/470e0ec9eaab9ee34362803a27ff6788a6511b9a Feb 11 21:50:25 switching layouts works, and the available layout list is auto-populated like it was before Feb 11 21:52:35 hm Feb 11 21:52:53 a) i think you need a separate namespace for the layouts Feb 11 21:53:12 like vkb. ? Feb 11 21:53:15 enyo.kind({ ... name: "vkbLayout.querty_us" Feb 11 21:53:59 isn't vkb already the class for the vkb? well, not too important. Feb 11 21:54:17 b) i really think only the selected keyboard should be loaded Feb 11 21:54:37 just think about what happens when we add 20 more layouts (and there are way more than that...) Feb 11 21:55:10 i think this will hurt startup performance very quickly Feb 11 21:55:12 but perhaps i'm wrong Feb 11 21:55:40 i havent tested it on a phone yet, but i dont notice anything "sofar" on the TP Feb 11 21:57:54 i have an idea of how to load them on the fly but still leave them as kinds Feb 11 22:02:58 well, i won't care much as i'm only using it on the tp. the async layout loading wouldn't be much different from what it is now, so you could try just using the old code Feb 11 22:03:30 the layout "registers", and the register function invokes the needed callbacks Feb 11 22:04:59 VKBLayoutChange would be something like: loadLayout(name, function() { this.$.vkb.destroy(); this.createVKB(false); this.resized(); }); Feb 11 22:05:49 let me get the css tied into the new statefull stuff and then i will look at what you are saying Feb 11 23:40:18 do not copy/paste a recursive function for rewriting (forwards highlight/backwards highlight) and then leave references to the original recursive function in it Feb 11 23:40:20 bad things happen Feb 11 23:40:51 Brybry, i think i fixed the rotation bug in my rewrite here Feb 11 23:41:02 if (typeof this._rotationLock === 'undefined' || this._rotationLock == 0) Feb 11 23:41:07 ^^ needed a check like that Feb 11 23:41:44 I would have just said scrab the == 0 check entirely Feb 11 23:41:54 as it's something different that we pick up on it'll get overwritten Feb 11 23:42:05 scrap* Feb 11 23:42:10 but that may work as well Feb 11 23:42:11 so just have a final else? Feb 11 23:42:18 with no if Feb 11 23:42:42 it'd work the same as if you did that, I guess Feb 11 23:43:33 or instead of setting it to null to start i can fetch orientation then Feb 11 23:43:39 then check rotation lock and overwrite it Feb 11 23:43:41 or that as well Feb 11 23:43:42 yupyup **** ENDING LOGGING AT Sun Feb 12 02:59:56 2012