Re: reply：How to improve the animation in weex
since the obvious overhead to change to weex module, it seems direct JS-Binding make sense to any C operations to improve performance :) RequestAnimationFrame was used to coordinate multiple operation/animation in the same page, while setTimeout focusing on specific one, looks they are two dimension of a question...could discuss in a different mail thread. On Fri, Apr 7, 2017 at 11:41 AM, Adam Feng wrote: > Excellent work for the new native timer. > > I have reviewed the PR https://github.com/apache/ > incubator-weex/pull/228/files. > > Maybe `setTimeoutWeex` is a proper intermediate name, but not a final > name. There are already several `setTimeout` implementations in our > SDK(e.g. global setTimeout and timer module), thus make them hard to > maintain. > > How do you think about the name evolution, When will be the most suitable > time for the new timer to rule them all ? > > Thanks. > Adam Feng > > On 2017年4月7日 +0800 AM11:03, wrote: > > > > nativerequestAnimationFrameimplementation >
Re: 回复：support record qr code scan history for weex playground in iOS
if people test app on his own laptop, the generated url always changing; but for fixed app locating on remote server, this function brings great convenience... On Fri, Mar 31, 2017 at 10:55 AM, 张星 wrote: > I save the newer one to the first cell, the maximum amount is 8 now, the > oldest one will be deleted automatic > > 2017-03-31 10:50 GMT+08:00 杨胜涛 : > > > Sometimes, some of the connection is overdue, whether can filter some > > useless links > > > > 2017-03-31 10:39 GMT+08:00 Adam Feng : > > > > > @sospartan, the android CI has failed a lot of times, please check if > > it > > > has some problems. > > > > > > Thanks. > > > Adam Feng > > > > > > On 2017年3月31日 +0800 AM10:36, Adam Feng , wrote: > > > > Excellent! We have been looking forward to this feature for a long > > > time, scanning the same code again and again was really annoying. > > > > > > > > > > > > Thanks. > > > > Adam Feng > > > > > > > > On 2017年3月30日 +0800 PM9:31, 宋海波(齐山) , > > wrote: > > > > > Very good > > > > > > > > > > > > > > > 来自阿里妹 iPhone版 --原始邮件 --发件人：张星 < > > > zhangxing610...@gmail.com>日期：2017-03-30 21:28:19收件人：dev@weex. > > > incubator.apache.org 主题：support record > qr > > > code scan history for weex playground in iOSHi I try to add record on > iOS > > > playground for people who use weex > > > > > playground scanning qr code to preview weex page, so they can click > > > > > history to preview the page immediately instead of scanning the qr > > code > > > > > again > > > > > > > > > > here is the pull request https://github.com/apache/ > > > incubator-weex/pull/193 > > > > > > > > > > Anyone can help me to review and merge the pr into 0.12-dev branch > > > > > > > > > > Thanks > > > > > > > > > > by xing zhang > > > > > >
Re: Sorting out Weex APIs and tools
As a follow-up decision, "weex init" was used specifically to setup H5 project, it will build vue project by default, option "--type=we" will create weex project. “weex create" command was used to create a complete project with native (android/iOS) platform files, app code canbe written by vue or .we, all following commands like "weex platform add..." "weex plugin add..." "weex run android/ios"... will detect the source file type (vue or weex) automatically and run. thanks On Tue, Mar 21, 2017 at 12:26 PM, Wenhong Wu wrote: > Thanks for your comments. > 1. yes, weex "init" and "create" has different purpose at the very > beginning, "init" was used to quickly setup H5 project for frontend > engineer, while "create" would create a complete project with native files. > These two commands will be consolidate to have same result in near future. > > 2. We started to use Vue from Jan this year. But tools haven't fully > support vue yet. Next formal release in near future, vue will be supported > by default, and .we project would be supported with option like "--type=we" > as maintenance. Thanks for your cool advices. If you interested, pls refer > to "vue2.0" branch in weexpack project. Your contribution was warmly > welcomed. > > Thanks > > > On Mon, Mar 20, 2017 at 10:48 PM, Tiago Alves wrote: > >> Thanks for the replies! >> >> I am glad to see the tools being bundled into one! Can someone help me >> with >> the following doubts? >> >> 1) When we create a vue project (`weex init my-project`) then we cannot >> add >> the native platforms (`weex platform add android`). This seems to work >> exclusively with "weex projects" (`weex create my-project`), the type that >> still uses .we files. >> >> I have searched all the branches in the weexpack project and couldn't find >> a way to add native platforms to a "vue project". >> Is there someone working on this? If so, where? If not, should I >> contribute >> directly to the weexpack project, or that discussion should occur here? >> >> 2) I think that the commands `weex init` and `weex create` are there >> mostly >> for historical reasons, but will be confusing for the developer. How about >> adding a parameter to `weex init` so it canl create a legacy .we project? >> E.g. `weex init my-project --type=we` would do the same as `weex create >> my-project`. >> >> Thanks in advance. I apologise if this discussion should be occurring >> elsewhere. In that case, please redirect me to the right place :) >> >> Tiago >> >> >> >> On Mon, 20 Mar 2017 at 06:48 蒲欢(拈笑) wrote: >> >> > We have >> > recently sorted out our tools. >> > Weex-toolkit >> > are playing an import role in out development chain.Developers >> > doesn't care about weexpack or weex-devtools. You could create, debug >> and >> > build >> > a Weex project via one cli command tool: >> > weex-toolkit(https://github.com/weexteam/weex-toolkit). >> > >> > And we >> > have updated some details about weex-toolkit, just go >> > https://weex.apache.org/guide/tools/toolkit.html >> > to have a deep understanding about weex-toolkit. >> > >> --发件人：Wenhong >> > Wu 发送时间：2017年3月15日(星期三) 11:40收件人：dev < >> > dev@weex.incubator.apache.org>主 题：Re: Sorting out Weex APIs and tools >> > Hi, Tiago, >> > >> > Thanks for your valuable points. >> > Weex cli command has just unified to toolkit, which means you don't >> need to >> > use weexpack or devtool separately. All comes to a simple way, after npm >> > install weex-toolkit. You just call weexpack subcommand after weex like >> > "weex create xxx" "weex platform add XXX" "weex run xxx"...which will >> > automatically launch and execute weexpack. The same happens to >> > weex-devtool, you call "weex debug xxx" instead of "weex-devtool xxx". >> > For details, pls refer to https://github.com/weexteam/weex-toolkit. And >> > we're now working on official toolchain document, try giving weex >> > development an easy experience. >> > Pls feel free to comments or submit issues in toolkit github :) >> > >> > Thanks >> > >> > On Wed, Mar 15, 2017 at 12:58 AM, sospartan >> wrote: >> > >> > >> > > I'm totally agree
Re: Sorting out Weex APIs and tools
Thanks for your comments. 1. yes, weex "init" and "create" has different purpose at the very beginning, "init" was used to quickly setup H5 project for frontend engineer, while "create" would create a complete project with native files. These two commands will be consolidate to have same result in near future. 2. We started to use Vue from Jan this year. But tools haven't fully support vue yet. Next formal release in near future, vue will be supported by default, and .we project would be supported with option like "--type=we" as maintenance. Thanks for your cool advices. If you interested, pls refer to "vue2.0" branch in weexpack project. Your contribution was warmly welcomed. Thanks On Mon, Mar 20, 2017 at 10:48 PM, Tiago Alves wrote: > Thanks for the replies! > > I am glad to see the tools being bundled into one! Can someone help me with > the following doubts? > > 1) When we create a vue project (`weex init my-project`) then we cannot add > the native platforms (`weex platform add android`). This seems to work > exclusively with "weex projects" (`weex create my-project`), the type that > still uses .we files. > > I have searched all the branches in the weexpack project and couldn't find > a way to add native platforms to a "vue project". > Is there someone working on this? If so, where? If not, should I contribute > directly to the weexpack project, or that discussion should occur here? > > 2) I think that the commands `weex init` and `weex create` are there mostly > for historical reasons, but will be confusing for the developer. How about > adding a parameter to `weex init` so it canl create a legacy .we project? > E.g. `weex init my-project --type=we` would do the same as `weex create > my-project`. > > Thanks in advance. I apologise if this discussion should be occurring > elsewhere. In that case, please redirect me to the right place :) > > Tiago > > > > On Mon, 20 Mar 2017 at 06:48 蒲欢(拈笑) wrote: > > > We have > > recently sorted out our tools. > > Weex-toolkit > > are playing an import role in out development chain.Developers > > doesn't care about weexpack or weex-devtools. You could create, debug and > > build > > a Weex project via one cli command tool: > > weex-toolkit(https://github.com/weexteam/weex-toolkit). > > > > And we > > have updated some details about weex-toolkit, just go > > https://weex.apache.org/guide/tools/toolkit.html > > to have a deep understanding about weex-toolkit. > > > --发件人：Wenhong > > Wu 发送时间：2017年3月15日(星期三) 11:40收件人：dev < > > dev@weex.incubator.apache.org>主 题：Re: Sorting out Weex APIs and tools > > Hi, Tiago, > > > > Thanks for your valuable points. > > Weex cli command has just unified to toolkit, which means you don't need > to > > use weexpack or devtool separately. All comes to a simple way, after npm > > install weex-toolkit. You just call weexpack subcommand after weex like > > "weex create xxx" "weex platform add XXX" "weex run xxx"...which will > > automatically launch and execute weexpack. The same happens to > > weex-devtool, you call "weex debug xxx" instead of "weex-devtool xxx". > > For details, pls refer to https://github.com/weexteam/weex-toolkit. And > > we're now working on official toolchain document, try giving weex > > development an easy experience. > > Pls feel free to comments or submit issues in toolkit github :) > > > > Thanks > > > > On Wed, Mar 15, 2017 at 12:58 AM, sospartan > wrote: > > > > > > > I'm totally agree with you. The weex tooling is confusing, even for > me, as > > > a team member, use/dev weex everyday. > > > > > > I'd like in some day, we can use one single tool to manage all these > > > things. > > > > > > This thread may take some time for rest of team, since it's midnight in > > > china. 😅 > > > > > > Thanks for the feedback. > > > > > > Tiago Alves 于2017年3月14日 周二下午9:40写道： > > > > > > Hello all! > > > > > > I am a newcomer that is still trying to wrap his head around the > project. > > > And hey, maybe it's good thing to have an outsider's perspective! > > > > > > After some days experimenting with Weex, the Hackernews project, > weexpack > > > and weex-toolkit, I still have this question: How will people use Weex > in > > > the future? The success of open source
Re: Sorting out Weex APIs and tools
Hi, Tiago, Thanks for your valuable points. Weex cli command has just unified to toolkit, which means you don't need to use weexpack or devtool separately. All comes to a simple way, after npm install weex-toolkit. You just call weexpack subcommand after weex like "weex create xxx" "weex platform add XXX" "weex run xxx"...which will automatically launch and execute weexpack. The same happens to weex-devtool, you call "weex debug xxx" instead of "weex-devtool xxx". For details, pls refer to https://github.com/weexteam/weex-toolkit. And we're now working on official toolchain document, try giving weex development an easy experience. Pls feel free to comments or submit issues in toolkit github :) Thanks On Wed, Mar 15, 2017 at 12:58 AM, sospartan wrote: > I'm totally agree with you. The weex tooling is confusing, even for me, as > a team member, use/dev weex everyday. > > I'd like in some day, we can use one single tool to manage all these > things. > > This thread may take some time for rest of team, since it's midnight in > china. 😅 > > Thanks for the feedback. > > Tiago Alves 于2017年3月14日 周二下午9:40写道： > > Hello all! > > I am a newcomer that is still trying to wrap his head around the project. > And hey, maybe it's good thing to have an outsider's perspective! > > After some days experimenting with Weex, the Hackernews project, weexpack > and weex-toolkit, I still have this question: How will people use Weex in > the future? The success of open source projects depends more on the > developer experience (that includes APIs, docs and tools) than the > technical quality of the solution. > > So my question is: where are we heading? As far as I could learn from the > docs, the workflow would be: > > 1. Create the app: > > weexpack create my-project // weexpack > or > > weex create my-project // weex-toolkit > or > > vue init weex my-project // vue-cli > ? > > 2. Configure native platforms in the config.xml > > 3. Add platforms > > weexpack platform add android/ios // weexpack > or > > weex platform add android/ios // weex-toolkit > ? > > 4. Debug platforms using weex-toolkit: > > weex debug dist/index.weex.js > > 5. Run/deploy natively: > > weexpack platform run > > I would like to see 3 things happening to this project: > 1) A definition of the experience we want for the developer. > 2) weexpack and weex-toolkit should have a clearer scope. Their docs should > have a distinction of what is deprecated, with special care for overlapping > features. > 3) A "getting started" doc that guides the developer from 0 to having a > Vue2.0 Weex debuggable app. > > Weex is under heavy development and I get that. The worrying part is that I > don't see where Weex's developer experience is heading to. > > So, how will developers us weex in the future? > > Thanks! > Tiago > > -- > sospartan > https://weex-project.io >
Re: Support all top-level DOM APIs in Vue 2
En, so Vue2.0 change should be above SDK/jsfm? If API was called between JS and native with high-frequency like "addElement", moving it to top-level will save some time. I prefer other APIs be assessed in this way :) Thanks On Tue, Mar 14, 2017 at 1:16 PM, Hanks Zhang wrote: > Yes, we have already support "addElement" for a long time, but not include > the other methods, such as "updateAttrs". > > By the way, we have refactored Weex runtime to use "TaskCenter" and > "CallbackManager" to manage the render tasks. The Vue.js 2.0 should have a > slight change to adapt it. > > 2017-03-13 15:41 GMT+08:00 wenhong.wwh : > > > I remember we already support “addElement” long time before as a > top-level > > API on both android/ios. So it would be easy to add others as well. > > My question here is what else need to do to support Vue2.0. Won't Vue 2.0 > > use js framework? :) > > > > Thanks > > Wenhong > > > > > > > > >
Re: Hi my name is ...
hi, there! My name is Wenhong Wu. It's my pleasure to be working on weex toolkit (including devtools, weexpack etc. [1]) for the past few months. As an old Webkit committer, I hope to be able to contribute to weex as well in future. I'm new to Apache project, seems a lot to learn :) [1] https://github.com/weexteam Thanks Wenhong On Thu, Jan 5, 2017 at 1:08 AM, Bono Lv (Ali ZiKuan) < zikuan...@alibaba-inc.com> wrote: > Willem have written two greate articles about Mail List and Apache Way in > Chinese [1], [2], I think them are Must Be Read to all of weex team member. > PS:I have translated Apache Code of Conduct into Chinese[3] which have > been mentioned in Willem's article. > [1]: https://willemjiang.github.io/blog/2016/why-we-use-mailing-list/ > [2]: https://willemjiang.github.io/blog/2016/ > opensource-code-of-conduct/[3]: https://github.com/weexteam/ > article/issues/115 > --From:Willem > Jiang Time:2017 Jan 4 (Wed) 16:06To:dev < > dev@weex.incubator.apache.org>Subject:Re: Hi my name is ... > Hi, > My name is Willem. My Apache journey started from Apache CXF in 2006, and > I also worked on Apache ActiveMQ, Apache Camel and > Apache ServiceMix. It's > my pleasure to join the Weex project as a mentor. > My interesting is reactive programing and the backend service stacks. > > BTW, I'm living in Beijing :) > > Regards, > > > > Willem Jiang > > Blog: http://willemjiang.blogspot.com (English) > http://jnn.iteye.com (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Jan 4, 2017 at 2:30 PM, 大诗胸 wrote: > > > wow~~ '200 meters', means you two are available to yell to each > > other literally. 😀 > > > > On Wed, Jan 4, 2017 at 1:49 PM, Niclas Hedhman > wrote: > > > > > Hi, > > > My name is Niclas and I have been involved in Apache > software since ~1997 > > > (JServ), and I am here to help you guys to understand what is > > #TheApacheWay > > > and how to navigate the various resources available > to projects. So, I am > > > one of 4 Mentors, and our role has nothing to do with > the codebase, only > > > the community. > > > > > > It may also help that I have lived in Malaysia more > or less since 1986, > > > except 5 years in Shanghai from 2010 to November last year. > > Coincidentally, > > > 200 meters from Luke Han, also a Mentor on the project. > > > > > > Cheers > > > > > > On Wed, Jan 4, 2017 at 9:24 AM, Edward J. Yoon y...@samsung.com> > > > wrote: > > > > > > > Hi weex devs, Happy new year! > > > > > > > > My name is Edward J. Yoon and I'm on the Apache > Hama, Bigtop, Incubator > > > > PMC. > > > > Recently my interests moves from batch based data-driven backend > > systems > > > to > > > > real-time event-driven and serverless architecture, > and edge computing > > + > > > > multi-devices applications' frontend. :) > > > > > > > > If you wish to introduced yourself we can use this same thread. > > > > > > > > -- > > > > Best Regards, Edward J. Yoon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Niclas Hedhman, Software Developer > > > http://polygene.apache.org <http://zest.apache.org> - New Energy for > > Java > > > > > > > > > > > -- > > sospartan > > Phone:13588488290 > > HangZhou > > > >
