Re: [royale-asjs] branch develop updated: Removed unselectable selector

[Harbs]

What I really wanted to do here was create some self invoking code which was 
run when the UnselectableElementBead class was loaded.

Is there any way of doing that without writing a static method and invoking 
that?

Thanks,
Harbs


> On Jun 2, 2018, at 11:39 PM, ha...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> harbs pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new b157ecf  Removed unselectable selector
> b157ecf is described below
> 
> commit b157ecff5ea11ff2035e105f266b0925c1970005
> Author: Harbs 
> AuthorDate: Sat Jun 2 23:39:28 2018 +0300
> 
>Removed unselectable selector
> ---
> .../projects/Basic/src/main/resources/defaults.css |  9 -
> .../royale/html/beads/UnselectableElementBead.as   | 22 ++
> 2 files changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css 
> b/frameworks/projects/Basic/src/main/resources/defaults.css
> index ea02120..23a324d 100644
> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
> @@ -26,15 +26,6 @@
>   box-sizing: border-box;
> }
> 
> -.unselectable
> -{
> - -moz-user-select: -moz-none;
> - -khtml-user-select: none;
> - -webkit-user-select: none;
> - -o-user-select: none;
> - user-select: none;
> -}
> -
> Alert
> {
>   IBeadLayout: 
> ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
> diff --git 
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
>  
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
> index 6697472..c80c907 100644
> --- 
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
> +++ 
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
> @@ -34,6 +34,27 @@ package org.apache.royale.html.beads
>   public class UnselectableElementBead implements IBead
>   {
>   /**
> +  * @royaleignorecoercion HTMLStyleElement
> +  */
> + private static function insertRule():void
> + {
> + // only do this once...
> + if(ruleInserted)
> + return;
> + ruleInserted = true;
> + // Inject a new css selector
> + COMPILE::JS
> + {
> + var style:HTMLStyleElement = 
> document.createElement('style') as HTMLStyleElement;
> + style.type = 'text/css';
> + style.innerHTML = '.unselectable 
> {-moz-user-select: none;-webkit-user-select: none;-ms-user-select: 
> none;user-select: none;}';
> + 
> document.getElementsByTagName('head')[0].appendChild(style);
> + }
> +
> + }
> + private static var ruleInserted:Boolean;
> +
> + /**
>*  constructor.
>*
>*  @langversion 3.0
> @@ -57,6 +78,7 @@ package org.apache.royale.html.beads
>*/
>   public function set strand(value:IStrand):void
>   {
> + insertRule();
>   _strand = value;
> 
>   COMPILE::JS
> 
> -- 
> To stop receiving notification emails like this one, please contact
> ha...@apache.org.

Re: [royale-asjs] 01/02: global point should ignore window scrolling

[Harbs]

Good point.

I’ll try to convert these to utility functions.

FWIW, The only difference is "- window.scrollX”.

I’m also pretty sure that the “older browser fallback” which is a major part of 
the code is not necessary. getBoundingClientRec() seems to be supported back 
through IE9.[1] We should probably clean out the “offset” code.

Harbs

[1]https://caniuse.com/#search=getBoundingClientRect 



> On Jun 1, 2018, at 7:22 PM, Alex Harui  wrote:
> 
> For PAYG, should we have a version of the API that worries about window 
> scrolling and one that doesn't?  If your app is designed not to scroll, I 
> would think you wouldn't have to pay for this extra code?
> 
> -Alex
> 
> On 6/1/18, 4:26 AM, "ha...@apache.org " 
> mailto:ha...@apache.org>> wrote:
> 
>This is an automated email from the ASF dual-hosted git repository.
> 
>harbs pushed a commit to branch develop
>in repository 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.com%7C85aafe13907e4728298508d5c7b28caa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634492071894168=upjYhaXnXu4zo0rSp731%2ByM89crQMlK%2BothTSTXQlqA%3D=0
>  
> 
> 
>commit e5328655b9991fe44b92c61d1b18aa7a4cc104b5
>Author: Harbs mailto:ha...@in-tools.com>>
>AuthorDate: Tue May 29 12:25:55 2018 +0300
> 
>global point should ignore window scrolling
>---
> .../royale/org/apache/royale/utils/PointUtils.as   | 28 
> +-
> 1 file changed, 17 insertions(+), 11 deletions(-)
> 
>diff --git 
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/PointUtils.as
>  
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/PointUtils.as
>index 264102c..f96e61c 100644
>--- 
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/PointUtils.as
>+++ 
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/PointUtils.as
>@@ -71,18 +71,24 @@ package org.apache.royale.utils
> var x:Number = pt.x;
> var y:Number = pt.y;
> var element:HTMLElement = local.element as HTMLElement;
>+  if ( element.getBoundingClientRect ) {// TODO 
> take scrollbar widths into account
>+  var rect:Object = 
> element.getBoundingClientRect();
>+  x = x - rect.left - window.scrollX;
>+  y = y - rect.top - window.scrollY;
>+  } else { // for older browsers, but 
> offsetParent is soon to be deprecated from chrome
> 
>-do {
>-x -= element.offsetLeft;
>-y -= element.offsetTop;
>-  if (local['parent'] !== undefined) {
>-local = local.parent;
>-element = local ? local.element as HTMLElement : 
> null;
>-} else {
>-element = null;
>+do {
>+x -= element.offsetLeft;
>+y -= element.offsetTop;
>+if (local['parent'] !== undefined) {
>+local = local.parent;
>+element = local ? local.element as 
> HTMLElement : null;
>+} else {
>+element = null;
>+}
> }
>+while (element);
> }
>-while (element);
> return new org.apache.royale.geom.Point(x, y);
> 
> }
>@@ -119,8 +125,8 @@ package org.apache.royale.utils
> 
>   if ( element.getBoundingClientRect ) {// TODO 
> take scrollbar widths into account
>   var rect:Object = 
> element.getBoundingClientRect();
>-  x = rect.left + x;
>-  y = rect.top + y;
>+  x = rect.left + x + window.scrollX;
>+  y = rect.top + y + window.scrollY;
>   } else { // for older browsers, but 
> offsetParent is soon to be deprecated from from chrome
>   do {
>   x += element.offsetLeft;
> 
>-- 
>To stop receiving notification emails like this 

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Hi Carlos,

I think our wires are still crossed. Rather than me trying to address your 
points below, I think we still need to work on definitions. Let me try like 
this:

A Jewel dependency on “Foundation” is OK for you, but a dependency on “Basic” 
is not. Right?

In your view, which files in the Basic project make it “Basic” rather than 
“Foundation”? Put another way: Which files can we remove from Basic to make it 
“Foundation”?

If we can narrow this down to a list of files which you believe make a 
dependency “bad”, I think that focuses the issue a lot better. We don’t need a 
full list of files at the moment, but a sampling of the files that you view as 
“bad dependencies” would make it much clearer for me (and others). If you 
prefer, I could compose a list of files myself, but I’d like to hear from you 
what you think.

Thanks,
Harbs

> On Jun 1, 2018, at 5:55 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> 2018-06-01 13:07 GMT+02:00 Harbs :
> 
>> 
>> We both agree that Jewel should have a dependency on “Foundation” or
>> “Basic”. The only question is TLCs. What practical difference does this
>> point have?
>> 
>> 
> All thoughts about why not make TLCs and CSS was exposed several times. I
> think you already know what I think about it. Don't think write about it
> one more time have sense.
> I think you don't expose opposite arguments. Maybe this part is in a field
> dominated by a mixture of technical issues and how each of us likes to
> codify things and for this reason is hard to reach consensus. I believe
> that your vision may be correct, but I personally see more benefits in
> which I am defending. If I must to choose only on arguments or evidences, I
> think the way I'm proposing should be the way to go.
> 
> 
> 
>>> 
 
 I’d like to propose the following way forward.
 
 1. Both Basic (Foundation) pieces and Basic TLCs should have the same
 package paths and namespaces.
 
>>> 
>>> Don't think so. If you want to promote reusable pieces, the refactor of
>>> names should make them go to a different package other than Basic. It's
>>> like to propose to put on a jewel package would be a bad decision. In the
>>> refactor I was for "core", since the common pieces was in Core. So I
>> think
>>> it will depend on the name of the library to choose. For me Basic is a
>> good
>>> name for Basic UI Set since clearly states what all the code there do. I
>>> still think Foundation is a good name, but if you don't like, I think you
>>> should propose other one that seems more appropriate.
>> 
>> I really don’t care very much what the project name is. “Base” “Basic” and
>> “Foundation” are all good. To me they all mean the same thing.
> 
> 
> I really see a tangible difference between "foundation" pieces to use all
> over other royale parts and "basic" pieces that are the most basic or base
> representation while express or jewel are more complex and pursue different
> complex scenarios (so is basic vs complex).
> 
> 
>> I’d prefer to stick with Basic because I don’t see a gain in renaming it.
>> Foundation is a “long” name. I don’t see a reason to make the name longer.
>> I feel very strongly that the TLCs should have the same paths and
>> namespaces as the rest of Basic.
> 
> I consider Basic TLCs a part of the Basic concept. Even if Jewel doesn’t
>> end up using it, other component sets likely will. Creating a new package
>> path and namespace serves no function and makes things more difficult. Why
>> go there?
>> 
> 
> ok, for this is not crucial, is only something that the other name like me
> more and fit for me more, but in this part I'm ok if finaly we need to go
> with "basic". In every negotiation we can't get *all*
> 
> 
> 
>> 
>>> 
 2. By doing this, it will be very painless to pull Basic TLCs out of
>> Basic
 into a separate project or merge it back in. (i.e. BasicComponents)
>> (Either
 now, or in the future.)
 
>>> 
>>> I think we must be doing it moving little by little and ensuring after a
>>> little refactor all continues working.
>> 
>> Moving what? I don’t think moving the entire list of TLCs (i.e. what is
>> used in the Basic CSS) is more than a few hours of work.
>> 
> 
> In fact the initial refactor took me 2 days of about 10-12 work hours to
> complete. This will take a time to do it, but it can be done without
> problem with patience and perseverance.
> 
>> 
>> Basic *is* that shared library. To prevent linking to Basic (TLCs), we can
>> move the Basic TLCs out of Basic *at any time*. I don’t see why we need to
>> *do anything* right now (except get everything working for a release).
>> Jewel apps might be slightly larger for a month or two until we get this
>> sorted out, but what’s the rush?
>> 
> 
> Harbs, I completely disagree with that path. Is to come back to insert
> entropy and bad practices again, or go to backwards. For me this point is
> crucial. Again, we must see what points are very important  and for me this
> is not important, 

Re: Descendent selector issue

[Harbs]

Ah.

I did not think of modules. Good point.

> On Jun 1, 2018, at 8:04 PM, Alex Harui  wrote:
> 
> AIUI:
> 
> TitleBar .TitleBarTitle  means "any component with the className 
> "TitleBarTitle" that is a child of a TitleBar.
> 
> ToggleTextButton.selected means "Any ToggleTextButton that ALSO has the 
> classname "selected"
> 
> Without digging through the code, my recollection of the logic says only the 
> last "selector"  is used to determine whether the CSS rules are kept or not.  
> In the first case, the last selector is ".TitleBarTitle" and in the second, 
> it is "ToggleTextButton.selected".
> 
> Should it work this way?  Maybe.  In the general case of multiple module 
> applications, the compiler cannot know if some component will be given the 
> className "TitleBarTitle" and added to a TitleBar that came from some other 
> module.  But it can know that there are no ToggleTextButtons in the current 
> module it is compiling.  So I think that's why it works the way it does.  And 
> maybe that is right.  Don't know.  IMO, just like we are replacing other 
> class selectors with subclasses, the same should be done for whatever is 
> being assigned the className TitleBarTitle.
> 
> HTH,
> -Alex
> 
> On 6/1/18, 2:09 AM, "Harbs"  wrote:
> 
>Of course. That was the distinction I was making. Sorry for not making my 
> point clearer.
> 
>Combination selectors (i.e. no space) work as expected.
>Descendant selectors (i.e with space) do not.
>I have not tested children selectors (i.e. “>”) or sibling selectors (i.e. 
> “+” and “~”). I don’t know whether those are omitted.
> 
>My point is that if the ancestor is not used, the selector is not needed 
> in the app and it should be omitted.
> 
>Hope that’s clearer… ;-)
>Harbs
> 
>> On Jun 1, 2018, at 11:51 AM, Idylog - Nicolas Granon  
>> wrote:
>> 
>> May I remind that the space between two selectors *is* significant.
>> 
>> Hope this helps
>> 
>> Nicolas Granon
>> 
>> 
>> 
>>> -Message d'origine-
>>> De : Harbs [mailto:harbs.li...@gmail.com]
>>> Envoyé : vendredi 1 juin 2018 10:40
>>> À : dev@royale.apache.org
>>> Objet : Descendent selector issue
>>> 
>>> TitleBar has the following CSS in defaults:
>>> 
>>> TitleBar .TitleBarTitle {
>>> font-weight: bold;
>>> padding: 0;
>>> margin: 0;
>>> }
>>> 
>>> This seems to cause the CSS to be always output even if TitleBar is not
>>> used.
>>> 
>>> Interestingly, the following CSS
>>> ToggleTextButton.selected
>>> {
>>> background-color: #d8d8d8;
>>> border: 1px solid #808080;
>>> padding: 4px;
>>> }
>>> 
>>> does get omitted if ToggleTextButton is not used.
>>> 
>>> Is it correct to assume that this is a bug and if the parent/ancestor
>>> the selector is not used, the CSS should be omitted?
>>> 
>>> Harbs
>> 
> 
> 
> 

Re: Need some help with Small Messages

[Carlos Rovira]

HI Alex,

thanks that's definitely sounds like the way to go. I'll try in somedays
since I need to do other things first and see If I get that part finaly
working

thanks for your support! :)

Carlos


2018-06-01 18:28 GMT+02:00 Alex Harui :

>
>
> On 6/1/18, 3:43 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >
> > Now to your main question.  Are you sure that code 168 is an AMF type
> > code?  I could certainly be wrong, but it occurred to me that the 168
> > could just be the first byte in serialized data of the message and
> that the
> > AMF decoding should instantiate the object based on the class alias
> then
> > see if it implements IExternalizable and call readExternal without
> > bothering to examine that byte in the stream.
> >
>
> ok, so if I understand right I must pass the rest of data in
> AMFBinaryData
> to "readExternal" method? If so, readExternal expects an
> IDataInputand
> is not clear to me how as well give that part of the data Array (maybe
> I
> should create a temporal data array that holds data from current
> position
> to the end of the array?
> Sorry but as you is not my area of expertise.
>
> I'm just guessing, but if AMFBinaryData implements IDataInput, then I
> would pass the AMFBinaryData to readExternal.  The readExternal calls
> should grab the next set of bytes out of the AMFBinaryData and use it to
> deserialize and when it returns, the AMFBinaryData should be set so the
> next bytes will be used  to generate the next object, if any.  In theory
> the readExternal of an IExternalizable should not play with the current
> position of the input IDataInput other than pulling bytes from the
> IDataInput.  At least, that's worth a try, IMO.
>
> HTH,
> -Alex
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira