Re: 回复： Thefocus of thepage keyboard trigger led to the top of thenavigation barcan not berestored

[xing zhang]

Can you try to debug by dependency the source code? as  I can not
re-produce the problem here.

2017-12-20 14:55 GMT+08:00 唐波 <765471...@qq.com>:

> Just try to use Weex Playground scan code is no problem, the installation
> to the iOS native app to run there will be just the problem.
>
>
>
>
> -- 原始邮件 --
> 发件人: "我自己的邮箱";<765471...@qq.com>;
> 发送时间: 2017年12月20日(星期三) 下午2:33
> 收件人: "dev"<dev@weex.incubator.apache.org>;
>
> 主题: 回复： 回复： Thefocus of thepage keyboard trigger led to the top of
> thenavigation barcan not berestored
>
>
>
> Iphone 6 plus phone for use, iOS 11, weex sdk version 0.17
>
>
> -- 原始邮件 --
> 发件人: "xing zhang";<zhangxing610...@gmail.com>;
> 发送时间: 2017年12月20日(星期三) 下午2:28
> 收件人: "dev"<dev@weex.incubator.apache.org>;
>
> 主题: Re: 回复： Thefocus of thepage keyboard trigger led to the top of
> thenavigation barcan not berestored
>
>
>
> what's your environment, like iOS version, weex sdk version and  input
> method,  try to update it maybe could resolve it,
> I can not reproduce with your case on iOS 11 , WeexSDK 0.17.0
>
> 2017-12-20 14:14 GMT+08:00 唐波 <765471...@qq.com>:
>
> > like address:
> >
> >
> > http://dotwe.org/vue/af78353d2f73a9881b94e45f6e2f5a42
> >
> >
> >
> >
> > -- 原始邮件 --
> > 发件人: "Adam Feng";<cxfe...@gmail.com>;
> > 发送时间: 2017年12月20日(星期三) 下午2:05
> > 收件人: "dev"<dev@weex.incubator.apache.org>;"dev"<dev@weex.
> > incubator.apache.org>;
> >
> > 主题: Re:回复： 回复： Thefocus of thepage keyboard trigger led to the top of
> > thenavigation barcan not berestored
> >
> >
> >
> > Maybe you should give a demo on http://dotwe.org/vue
> >
> >
> > Thanks.
> > Adam Feng
> >
> > On 20 Dec 2017, 2:00 PM +0800, 唐波 <765471...@qq.com>, wrote:
> > > Not a hot issue, right? The same is true of closed hot spots
> > >
> > >
> > >
> > >
> > > -- 原始邮件 --
> > > 发件人: "Adam Feng";<cxfe...@gmail.com>;
> > > 发送时间: 2017年12月20日(星期三) 中午1:50
> > > 收件人: "dev"<dev@weex.incubator.apache.org>;"dev"<dev@weex.
> > incubator.apache.org>;
> > >
> > > 主题: Re: 回复： The focus of thepage keyboard trigger led to the top of
> > thenavigation bar can not berestored
> > >
> > >
> > >
> > > It looks something wrong happen with the layout while the personal
> > hotspot is open.
> > >
> > > Thanks.
> > > Adam Feng
> > >
> > > On 20 Dec 2017, 1:45 PM +0800, 唐波 <765471...@qq.com>, wrote:
> > > > Due to the inability to add picture attachments, picture link
> address:
> > > > one: https://segmentfault.com/img/bV0xW6?w=639=1136
> > > > two: https://segmentfault.com/img/bV0xXu?w=639=1136
> > > > three: https://segmentfault.com/img/bV0xXL?w=639=1136
> > > >
> > > >
> > > > -- 原始邮件 --
> > > > 发件人: "xing zhang";<zhangxing610...@gmail.com>;
> > > > 发送时间: 2017年12月20日(星期三) 中午11:42
> > > > 收件人: "dev"<dev@weex.incubator.apache.org>;
> > > >
> > > > 主题: Re: The focus of the page keyboard trigger led to the top of
> > thenavigation bar can not be restored
> > > >
> > > >
> > > >
> > > > Did you use weex for navigationBar? Sure, you can attach
> > > >
> > > > 2017-12-20 10:53 GMT+08:00 唐波 <765471...@qq.com>:
> > > >
> > > > > Can I attach a picture?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -- 原始邮件 --
> > > > > 发件人: "我自己的邮箱";<765471...@qq.com>;
> > > > > 发送时间: 2017年12月19日(星期二) 下午2:30
> > > > > 收件人: "dev"<d...@weex.apache.org>;
> > > > >
> > > > > 主题: The focus of the page keyboard trigger led to the top of the
> > > > > navigation bar can not be restored
> > > > >
> > > > >
> > > > >
> > > > > Hi Weex Team:
> > > > > we have a problem . The bottom of the page input trigger keyboard
> > event
> > > > > causes the navigation bar to be top up. After the keyboard is
> > collapsed,
> > > > > the navigation bar is restored, and the overall effect is like the
> > entire
> > > > > page layout being topped up.
> >
>

Re: 回复： Thefocus of thepage keyboard trigger led to the top of thenavigation barcan not berestored

[xing zhang]

what's your environment, like iOS version, weex sdk version and  input
method,  try to update it maybe could resolve it,
I can not reproduce with your case on iOS 11 , WeexSDK 0.17.0

2017-12-20 14:14 GMT+08:00 唐波 <765471...@qq.com>:

> like address:
>
>
> http://dotwe.org/vue/af78353d2f73a9881b94e45f6e2f5a42
>
>
>
>
> -- 原始邮件 --
> 发件人: "Adam Feng";<cxfe...@gmail.com>;
> 发送时间: 2017年12月20日(星期三) 下午2:05
> 收件人: "dev"<dev@weex.incubator.apache.org>;"dev"<dev@weex.
> incubator.apache.org>;
>
> 主题: Re:回复： 回复： Thefocus of thepage keyboard trigger led to the top of
> thenavigation barcan not berestored
>
>
>
> Maybe you should give a demo on http://dotwe.org/vue
>
>
> Thanks.
> Adam Feng
>
> On 20 Dec 2017, 2:00 PM +0800, 唐波 <765471...@qq.com>, wrote:
> > Not a hot issue, right? The same is true of closed hot spots
> >
> >
> >
> >
> > -- 原始邮件 --
> > 发件人: "Adam Feng";<cxfe...@gmail.com>;
> > 发送时间: 2017年12月20日(星期三) 中午1:50
> > 收件人: "dev"<dev@weex.incubator.apache.org>;"dev"<dev@weex.
> incubator.apache.org>;
> >
> > 主题: Re: 回复： The focus of thepage keyboard trigger led to the top of
> thenavigation bar can not berestored
> >
> >
> >
> > It looks something wrong happen with the layout while the personal
> hotspot is open.
> >
> > Thanks.
> > Adam Feng
> >
> > On 20 Dec 2017, 1:45 PM +0800, 唐波 <765471...@qq.com>, wrote:
> > > Due to the inability to add picture attachments, picture link address:
> > > one: https://segmentfault.com/img/bV0xW6?w=639=1136
> > > two: https://segmentfault.com/img/bV0xXu?w=639=1136
> > > three: https://segmentfault.com/img/bV0xXL?w=639=1136
> > >
> > >
> > > -- 原始邮件 --
> > > 发件人: "xing zhang";<zhangxing610...@gmail.com>;
> > > 发送时间: 2017年12月20日(星期三) 中午11:42
> > > 收件人: "dev"<dev@weex.incubator.apache.org>;
> > >
> > > 主题: Re: The focus of the page keyboard trigger led to the top of
> thenavigation bar can not be restored
> > >
> > >
> > >
> > > Did you use weex for navigationBar? Sure, you can attach
> > >
> > > 2017-12-20 10:53 GMT+08:00 唐波 <765471...@qq.com>:
> > >
> > > > Can I attach a picture?
> > > >
> > > >
> > > >
> > > >
> > > > -- 原始邮件 --
> > > > 发件人: "我自己的邮箱";<765471...@qq.com>;
> > > > 发送时间: 2017年12月19日(星期二) 下午2:30
> > > > 收件人: "dev"<d...@weex.apache.org>;
> > > >
> > > > 主题: The focus of the page keyboard trigger led to the top of the
> > > > navigation bar can not be restored
> > > >
> > > >
> > > >
> > > > Hi Weex Team:
> > > > we have a problem . The bottom of the page input trigger keyboard
> event
> > > > causes the navigation bar to be top up. After the keyboard is
> collapsed,
> > > > the navigation bar is restored, and the overall effect is like the
> entire
> > > > page layout being topped up.
>

Re: The focus of the page keyboard trigger led to the top of the navigation bar can not be restored

[xing zhang]

Did you use weex for navigationBar?  Sure, you can attach

2017-12-20 10:53 GMT+08:00 唐波 <765471...@qq.com>:

> Can I attach a picture?
>
>
>
>
> -- 原始邮件 --
> 发件人: "我自己的邮箱";<765471...@qq.com>;
> 发送时间: 2017年12月19日(星期二) 下午2:30
> 收件人: "dev";
>
> 主题: The focus of the page keyboard trigger led to the top of the
> navigation bar can not be restored
>
>
>
> Hi Weex Team:
>we have a problem . The bottom of the page input trigger keyboard event
> causes the navigation bar to be top up. After the keyboard is collapsed,
> the navigation bar is restored, and the overall effect is like the entire
> page layout being topped up.
>

Re: customize request when download bundle js in weex

[xing zhang]

OK ,this subject is held temporarily,  we will try not to make developer
confused about so much render interface, Weex is still flexible and
extendable, and developers can control it.

thank you  for the discussion about it.

2017-11-30 21:42 GMT+08:00 陈泽峰 <chenzef...@ymt360.com>:

> I agree that it's a wide range of demand, and renderWithRequest is
> convenient for developers facing such case.
> But there are alternatives, and some of them may be more 'convenient'
> .Still in my practice,I preload jsbundles when my app starts, that is to
> say, download is separated from render, so I could not use it even there is
> a  renderWithRequest() method.
> What i'm saying is, specific businesses may be far different from each
> others. We could never make everyone 'convenient'.Weex is flexible and
> extendable, that is the power of weex.
>
>
> ------ Original --
> From:  "xing zhang"<zhangxing610...@gmail.com>;
> Date:  Thu, Nov 30, 2017 08:39 PM
> To:  "Weex问题列表"<dev@weex.incubator.apache.org>;
>
> Subject:  Re: customize request when download bundle js in weex
>
>
> Yeah , in most case, we'll add more custom information such as cookie or
> just send post request downloading bundle js code  using renderWithRequest,
>
> certainly, this can be finished by developers own, this can be more
> convenient by providing this interface, so developers don't
>
> care about much more details about session/connection(iOS) callback ,saving
> data and so on.
>
>
>
> 2017-11-30 20:25 GMT+08:00 杨 劭君 <shaojun.y...@outlook.com>:
>
> > If I want to send post request, renderWithRequest is the best option.
> >
> > 在 2017/11/30 20:09，“misakuo”<misa...@apache.org> 写入:
> >
> > We already have the HttpAdapter abstract in native, why is not do
> > customize
> > in here?
> > In fact, the request is not always bound to the WXSDKInstance
> > 2017-11-30 19:55 GMT+08:00 杨 劭君 <shaojun.y...@outlook.com>:
> >
> > > +1, customize request header is useful
> > >
> > > 在 2017/11/30 17:19，“Adam Feng”<cxfe...@gmail.com> 写入:
> > >
> > > +1， adding custom header (such as cookie) to request is useful，
> > it
> > > should be supported both on iOS and Android.
> > >
> > > Thanks.
> > > Adam Feng
> > >
> > > On 30 Nov 2017, 5:16 PM +0800, xing zhang <
> > zhangxing610...@gmail.com>,
> > > wrote:
> > > > Hi all,
> > > >
> > > > According to my observation, you can specify a URL or js
> > content to
> > > > render a page, for URL , then WeexSDK build a request for
> > download
> > > the
> > > > resource and pour into the engine to
> > > >
> > > > render. But in most case, we need customize a request for
> > > downloading a
> > > > resource, and we can setup our request userAgent and headers,
> > our
> > > server
> > > > can receive these header to
> > > >
> > > > customize response for a request from a device.
> > > >
> > > > As for this we can expose a `renderWithRequest` interface for
> > > > WXSDKInstance, is this way convenient ?
> > > >
> > > > comments? please
> > >
> > >
> > >
> >
> >
> >
>

iPhone X adapter about meta module supporting viewport

[xing zhang]

 As we all know, iPhone X  introduce us a safe-area concept, and make it
much more compatible with iPhone X is my aim, all  the iOS developers pay
more attention

on it. By referencing Webkit
 strategy
for iPhone X,  the first new feature is that iOS 11 Webkit includes a new
css function, env(), and set of four pre-defined environment

variables, safe-area-inset-left, safe-area-inset-right, safe-area-inset-top
and safe-area-inset-bottom, this feature can respect the safe areas as
follow.


[image: 内嵌图片 3]

And Weex has supported the four css value now, see the pull request
https://github.com/apache/incubator-weex/pull/916



the second feature is that WebKit
 extends the
existing viewport meta tag called `viewport-fit`, viewport-fit can be cover
or contain,

the left side is `contain` effect, and the right one is the `cover`
viewport-fit effect.

[image: 内嵌图片 1][image: 内嵌图片 2]


What WeexSDK  for iOS  should do is to support view-port module by change
the viewport to be contain or cover mode.

But there is an problem that all the weex view will be added to
WXRootView,  the rootView will always be there, and it is the root tag
element super view.  And the frame of

WXRootView will be the WXSDKInstance frame size.  When the frame of
WXRootView is full screen size, the viewport-fit problem comes, or the
viewport take no effect to it.


Now I have three plans to support this feature

1. add a wrapper view between WXRootView and root tag element , by this way
, we adjust the wrapper view frame to set the viewport of weex container.

  benefits:  there is no need to adjust WXRootView's frame, because not
only the WeexSDK adjust the WXRootView frame, but also developers, there
can be misunderstand,
  if we adjust WXRootView's frame.

  lacks:  the operation for adding subview to WXRootView ,we must re-write
to add to the wrapperView, maybe there are more details we need handle.

2.  Adjust rootView frame directly

3. manually adjust the frame of sub-element such as the fixed element and
others to fit to the viewport-fit mode.

this is what I can think about. Maybe there are more better ideas.


comments, please.

Re: customize request when download bundle js in weex

[xing zhang]

Yeah , in most case, we'll add more custom information such as cookie or
just send post request downloading bundle js code  using renderWithRequest,

certainly, this can be finished by developers own, this can be more
convenient by providing this interface, so developers don't

care about much more details about session/connection(iOS) callback ,saving
data and so on.



2017-11-30 20:25 GMT+08:00 杨 劭君 <shaojun.y...@outlook.com>:

> If I want to send post request, renderWithRequest is the best option.
>
> 在 2017/11/30 20:09，“misakuo”<misa...@apache.org> 写入:
>
> We already have the HttpAdapter abstract in native, why is not do
> customize
> in here?
> In fact, the request is not always bound to the WXSDKInstance
> 2017-11-30 19:55 GMT+08:00 杨 劭君 <shaojun.y...@outlook.com>:
>
> > +1, customize request header is useful
> >
> > 在 2017/11/30 17:19，“Adam Feng”<cxfe...@gmail.com> 写入:
> >
> > +1， adding custom header (such as cookie) to request is useful，
> it
> > should be supported both on iOS and Android.
> >
> > Thanks.
> > Adam Feng
> >
> > On 30 Nov 2017, 5:16 PM +0800, xing zhang <
> zhangxing610...@gmail.com>,
> > wrote:
> > > Hi all,
> > >
> > > According to my observation, you can specify a URL or js
> content to
> > > render a page, for URL , then WeexSDK build a request for
> download
> > the
> > > resource and pour into the engine to
> > >
> > > render. But in most case, we need customize a request for
> > downloading a
> > > resource, and we can setup our request userAgent and headers,
> our
> > server
> > > can receive these header to
> > >
> > > customize response for a request from a device.
> > >
> > > As for this we can expose a `renderWithRequest` interface for
> > > WXSDKInstance, is this way convenient ?
> > >
> > > comments? please
> >
> >
> >
>
>
>

customize request when download bundle js in weex

[xing zhang]

 Hi all,

 According to my observation,  you can specify a URL or js content to
render a page, for URL , then WeexSDK build a request for download the
resource and pour into the engine to

render. But in most case, we need customize a request for downloading a
resource, and we can setup our request userAgent and headers, our server
can receive these header to

customize response for a request from a device.

As for this  we can expose a `renderWithRequest` interface for
WXSDKInstance, is this way convenient ?

comments? please

Re: Use multi context for Weex page

[xing zhang]

I think that this action should be done as soon as possible,  there are so
much problem such as memory issue and context `pollution` for the shared
context.

2017-11-29 21:50 GMT+08:00 wentao shi :

> As we know, Weex is using custom js engine (JavascriptCore) on Android as
> same as IOS. When Weex startup will inject a long js script that we call it
> jsf to JSC. This action could generate many global object which share on
> diff page.
> if one page change that global object, will impact all page. For example,
> we could use this script http://dotwe.org/vue/
> 522f075bbeed1479486c067781c41adc  to change global object, if other page
> use "setTimeout" may throw js exception. So we want use multi context for
> Weex page, that one page cannot  impact other pages.
>
>
> As the picture shows, create globla class on Global Context and transform
> limited & controllable class to Instance Context which each Weex page has
> one.
>
> What do you think fellows?
>
> Best regards, Toretto
>

Re: Use ES6 js framework on Android

[xing zhang]

cool, it is a very good news.

2017-11-29 18:02 GMT+08:00 Hanks Zhang :

> Weex is using custom js engine (JavascriptCore) on Android. Its version is
> new and supports almost all ES6 features, except modules.
>
> I think this is a good opportunity to use ES6 in js framework and remove
> useless polyfills. It can improve the js runtime efficiency on Android.
>
> However, we can't upgrade the js engine on iOS. For compatibility reasons,
> we have to use the js framework in ES5 on iOS. The packaging process may
> need to change too, and how to maintain version consistency is also a
> problem.
>
> What do you think fellows?
>
> Best regards, Hanks
>

Weex accessibility discussion about voice-over in iOS read order

[xing zhang]

   hi, all

   Recently I am researching accessibility in iOS,  developer can write
simple accessible app using weex now.

There is a case for me to be confused，that's the *voice-over navigation
order* , you can just think of how the

voice-over visit view element, we can visit a view tree using  BSF or
DSF,  I find out *that voice-over  **visit its *

*element in horizontal row maybe BSF *, but sometimes we need to make it
column navigation, maybe DSF,

that's to say, voice-over  should visit subviews first, and then its
sibling views using DSF maybe, so I try to search

apple developer document about this, iOS developers can specify
shouldGroupAccessibilityChildren

to
change its

navigation order,  I haven't find  similar way on Android.


here is the dot-we case about test accessible order:

http://dotwe.org/vue/5d43492eb707a797a04efebae93eddd5

default order horizontal order:1->5->2->6->3->4->7->8

expected order is column order: 1->2->3->4->5->6->7->8

The attachment is the view hierarchy in iOS.

[image: 内嵌图片 3]

I expose this shouldGroupAccessibilityChildren

property,
so that weex developers can change the navigation

order in iOS  easily,  *but it is not standard and arbitrary*, I want make
this more practical and last for a longer

timer , actually  there are some related feature in native API but  WAI
 don't  refer to, such as hint,  but we
needs

it to make our app more accessible to everyone. I don't know  whether I
make this clear.

Any suggestion about this?





[image: 内嵌图片 1]

Re: the max-width for css-style should be taken into consideration when drawing text

[xing zhang]

It's related with the algorithm drawing text: consider width first,  if the
css width is not specified, (consider about max-width now ) then we use
`infinite` width as it's width meassuring the height.  But people may don't
know it's text width , the max-width is set.
In a words, calculate text height accords the width input.

As for max-height in mdn:
https://developer.mozilla.org/en-US/docs/Web/CSS/max-height , max-height
overrides height, but min-height overrides max-height.  It behaves more
like `height`. They all clip the content when it's content exceeded,  so
people can now specify height.

We consider max-height/height less when drawing text, people can use
`height` to clip content calculated.

2017-11-05 14:16 GMT+08:00 Adam Feng <cxfe...@gmail.com>:

> Thanks for your contribution,  I have seen the pull request and reviewed
> the code,  it looked good to me,   can `max-height` also be supported?
>
> Thanks.
> Adam Feng
>
> On 5 Nov 2017, 12:22 PM +0800, xing zhang <zhangxing610...@gmail.com>,
> wrote:
> > Hi , I open an issue for support max-width in iOS, as it works well
> both on Android and web.
> >
> > As I test the css for `max-width`, it works well both on Android and Web
> platform except iOS.
> > Here is the test code on DotWe  website:
> >
> > http://dotwe.org/vue/7e556c582a55630518d0bf6336ddde0e
> >
> > When meassuring the width of drawing text , the max-width of css-style
> should take into consideration.It seems that only width for css-style works.
> >
> > The attachment  is the screenshot both on iOS and  web(html5).
> >
> > ..
> >
> >
> >
> > And later, I will open an pull request to resolve this bug.
>

the max-width for css-style should be taken into consideration when drawing text

[xing zhang]

Hi , I open an issue for support max-width in iOS, as it works well
both on Android and web.

As I test the css for `max-width`, it works well both on Android and Web
platform except iOS.
Here is the test code on DotWe  website:

http://dotwe.org/vue/7e556c582a55630518d0bf6336ddde0e

When meassuring the width of drawing text , the max-width of css-style
should take into consideration.It seems that only width for css-style works.

The attachment  is the screenshot both on iOS and  web(html5).

..
[image: 内嵌图片 1]


And later, I will open an pull request to resolve this bug.

Re: Moving Playground & Examples out of Weex repo

[xing zhang]

We should update the Playground App in App Store both on Android and iOS
frequently, so the developers can use it to preview their page using the
new feature, and we can fix the emergency bug at the same time.

2017-10-30 21:59 GMT+08:00 Jonathan Dong :

> Hi Weex folks,
>
> I’m thinking of moving Playground and Examples out of Weex repo to
> simplify our code base, I hope we can fully discuss if it is necessary to
> make this move.
>
> Playground is a good entry to fiddle with the features of basic components
> and debug your pages, but it is kind of heavy if we take it as a demo in
> the Weex repo. As many of the Weex developers tend to create their own
> applications based on the Playground project, I suppose it is necessary to
> create a simpler one, say AppShell, which only contains QR Scan and page
> load functions, it would be sufficient for users to test their Weex pages,
> and much easier for them to take it as an application template to create
> their own project. Playground should be maintained in a separate repo in
> WeexTeam, which can be maintained and distributed separately.
>
> Same things should also happens to examples directory, I suppose what we
> really need is one or few simplified example to demonstrate the usage of
> the main components and the way of implementing app using Weex in the
> simplest way, not to keep those detailed example for each components in
> Weex repo. Instead I think it is a good practice to move them into WeexTeam
> and maintains as a separate repo, and replace the .we implementation with
> .vue as well.
>
> Any thought? I hope we can fully discuss it and bring out a proposal to
> make it happen asap.
>
> Cheers,
> Jonathan Dong
>
>

Re: box-shadow not working correctly

[xing zhang]

hi  陈泽峰
 I open a pull request to fix this issue last week, the pull request is
https://github.com/apache/incubator-weex/pull/791.

2017-10-16 16:28 GMT+08:00 陈泽峰 :

> hi
> i found box-shadow not working correctly in case like this
> http://dotwe.org/vue/617e4fcdb4ec773bb0e3e090d8c4c689 on IOS devices.The
> view was circular but the shadow was rectangle.

Re: Replace Facebook/Yoga with a new implementation.

[xing zhang]

Should we consider about layout percent unit, flex-shrink, flex-grow,
flexBasis, and baseline in align-Items ?

2017-10-12 16:54 GMT+08:00 申远 :

> Dear all,
>
> I’m considering replacing Facebook/Yoga to a new layout system based on
> Google/Flexbox due to Facebook’s additional patent issue. Besides, this new
> layout system will provide some new css style like order, etc.
>
> Any advise for the new layout system?
>
> PS: I need some advise about the name of the layout system.

Re: weex doc update

[xing zhang]

hi  chenzefeng,  we are checking the docs.
For the new feature such as drag-drop and recyle-list, we think they are
not ready for the developers to use it for production environment, and as
soon as they are ready, we'll update the developer documentation.


thanks

by  acton393

2017-09-30 16:29 GMT+08:00 陈泽峰 :

> hi weexteam
>i notice that weex release note was updated to v0.16, there is a lot of
> new features(such as recycle-list、 list drag-drop etc.) and optimizations,
> that' cool.But i find that i can find them at weex docs, and i've no idea
> how to use.So before the next version starts, is it possible to make the
> doc complete first?
>
>
>
>
>
>
>
>
>
>
> 陈泽峰
>
> 一亩田集团/技术部/贸易平台
>
> 15001225725
>
> 北京市海淀区西小口路66号中关村东升科技园B-6号楼A座六层A602A室

[RESULT] [VOTE] New committer gurisxie

[xing zhang]

The vote has now closed. The results are:

Binding Votes:

+1 [TOTAL BINDING +3 VOTES]
 0 [TOTAL BINDING +0/-0 VOTES]
-1 [TOTAL BINDING 0 VOTES]

The vote is ***successful***


Thanks to  shihan Zheng , Adam Feng and Luke Han for this votes.

Re: WXTextComponent view crashes intermittently with EXC_BAD_ACCESS KERN_INVALID_ADDRESS in drawTextWithContext:bounds:padding:view: at _drawGlyphsForGlyphRange:atPoint:. WXTextComponent view crashes

[xing zhang]

hi, we are trying to fix it.  It is because multi-thread draw text using
textkit,  now we are using coreText draw text,  those crashes are less.

2017-09-06 10:38 GMT+08:00 张水生 :

> Hi, Weex Team:
>WXTextComponent view crashes intermittently with EXC_BAD_ACCESS
> KERN_INVALID_ADDRESS in drawTextWithContext:bounds:padding:view:
> at _drawGlyphsForGlyphRange:atPoint:. This happens rarely, Harder to
> reproduce it locally. It is reported via Crashlytics often enough to be
> concerning.
>
> Here is simple stack trace:
> ===
> Crashed: com.taobao.weex.displayQueue
> EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0020
>
> Crashed: com.taobao.weex.displayQueue
> 0  UIFoundation   0x195888ed4 _
> NSGlyphTreeMoveToCharacterIndex + 196
> 1  UIFoundation   0x195889fbc _
> NSGlyphTreeGlyphRangeForCharacterRange + 84
> 2  UIFoundation   0x19589f1f0 -[NSLayoutManager(NSPrivate)
> _drawGlyphsForGlyphRange:atPoint:] + 4512
> 
> I can't reproduce the issue locally, so I don't have a solution. My best
> guess is that NSTextContainer
> is being released while being drawn.
> 
> Weex SDK version: 0.12.0
> Platform: iOS (iOS 10 and up)
> Mac OS 10.12.3
>
> Sincerely sheng.
>
>
>
>
>

Re: Where's the rest?!?

[xing zhang]

Yes, we had guys on Apache conf.I have learn a lot about it from his
presentation after he came back.
Raphael Bircher <rbircherapa...@gmail.com>于2017年6月9日 周五17:40写道：

> Hi xing xhang,
>
> That's great to hear. Did, you have informations about the Apache Way? If
> I'm not wrong, some of you where at the ApacheCon right?
>
> Regards, Raphael
>
> Am .06.2017, 11:33 Uhr, schrieb xing zhang <zhangxing610...@gmail.com>:
>
> > Yeah,you are right, I just ignore this, and will talk more later, do more
> > on mailing list, thx for your support.
> >
> > 2017-06-09 16:16 GMT+08:00 Raphael Bircher <rbircherapa...@gmail.com>:
> >
> >> Hi folks,
> >>
> >> We have the first release out. That's great. But as you all know, we
> >> just
> >> started here. One thing who is really bad at this project, (sorry I
> >> can't
> >> say it otherwise) you don't communicate in public. On the mailing list
> >> it's
> >> more or less a dialog between sospartan end me. I know, there are much
> >> more
> >> people behind this project. At the moment weex is a company project who
> >> stands under a Open Source License, but it's not an Open Source project.
> >>
> >> At the moment, if you come from outside, you miss all the communication.
> >> That's a big issue. Since I'm on this list, I didn't see a single
> >> Proposal.
> >> Only as an example.
> >>
> >> So please come on this list, and talk. I know, it's not easy to learn
> >> the
> >> Apache Way, but we will support you!
> >>
> >> Regards, Raphael
> >>
> >> --
> >> My introduction https://youtu.be/Ln4vly5sxYU
> >>
>
>
> --
> My introduction https://youtu.be/Ln4vly5sxYU
>

Re: Where's the rest?!?

[xing zhang]

Yeah，you are right, I just ignore this, and will talk more later, do more
on mailing list， thx for your support.

2017-06-09 16:16 GMT+08:00 Raphael Bircher :

> Hi folks,
>
> We have the first release out. That's great. But as you all know, we just
> started here. One thing who is really bad at this project, (sorry I can't
> say it otherwise) you don't communicate in public. On the mailing list it's
> more or less a dialog between sospartan end me. I know, there are much more
> people behind this project. At the moment weex is a company project who
> stands under a Open Source License, but it's not an Open Source project.
>
> At the moment, if you come from outside, you miss all the communication.
> That's a big issue. Since I'm on this list, I didn't see a single Proposal.
> Only as an example.
>
> So please come on this list, and talk. I know, it's not easy to learn the
> Apache Way, but we will support you!
>
> Regards, Raphael
>
> --
> My introduction https://youtu.be/Ln4vly5sxYU
>

Re: set border-bottom with scroller component（ios） is not work

[xing zhang]

the unilateral border is not supported on iOS for scroller now,  we are
trying to.

thx

2017-06-04 23:11 GMT+08:00 南 :

> hi all：
>
> I find a bug when i use weex(0.11), set border-bottom with scroller
> component is not work at ios.
> and is ok at android.
>
> this is my code：
> the red border-bottom is not appear at ios.
> 
>   
>  class="scroller"
> scroll-direction="horizontal"
> >
>   
> one
>   
>   
> two
>   
> 
>   
> 
> 
>   .scroller {
> height: 100px;
> width: 750px;
> background-color: #ccc;
> border-bottom-style: solid;
> border-bottom-width: 1px;
> border-color: #f00;
> flex-direction: row;
>   }
>   .item {
> padding-left:20px;
> padding-right: 20px;
>   }
>   .item-text {
> color: #000;
> font-size: 50px;
> line-height: 100px;
>   }
> 

Re: [VOTE]Apache Weex-incubating Release 0.12.0-RC5

[xing zhang]

+1

2017-06-02 15:21 GMT+08:00 jerry.s :

> +1 Best Wishes!
> > 在 2017年6月2日，下午3:16，宁栗  写道：
> >
> > +1
> >
> > 2017-06-02 15:13 GMT+08:00 Tancy Ni :
> >
> >> +1
> >>
> >> sospartan 于2017年6月2日周五 下午3:07写道：
> >>
> >>> Hi Weex PPMC,
> >>> I'll calling a vote for release Weex-incubating 0.12.0-RC5.
> >>> Fix some issues point out by IPMC. Hope this one will have a
> >>> 'full-green' pass.
> >>>
> >>>
> >>> The tag to be voted upon:
> >>> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> >>> ;a=shortlog;h=refs/tags/0.12.0-rc5
> >>>
> >>> The commit hash:
> >>>
> >>> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.
> git;a=commit;h=
> >> dcf9a83360b4403ffbdbfb3e168a68d1ff7a2b38
> >>>
> >>> The source tarball can be found at:
> >>>
> >>> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> >> 0-incubating/RC5/
> >>>
> >>> The fingerprint of key to sign release artifacts:
> >>> 97B9 6598 A6A3 B63C 53BD  77E9 44C5 2286 22B9 7784
> >>>
> >>> Release artifacts are signed with the following key:
> >>> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
> >>>
> >>> Release note about this version:
> >>> https://issues.apache.org/jira/browse/WEEX-26
> >>>
> >>> This vote will remain open for at least 72 hours.
> >>> Please vote on releasing this RC.
> >>>
> >>> [ ] +1 approve
> >>> [ ] +0 no opinion
> >>> [ ] -1 disapprove (and reason why)
> >>>
> >>> --
> >>> Best Regards!
> >>>
> >>> sospartan
> >>> http://weex.apache.org/ 
> >>>
> >>
>
>