Re: No Touch support?

Hi Carlos, The "CSS" that handles which beads to load is not conforming CSS and is handled by custom code, similar to Apache Flex. So we could extend media query similar to how Flex Mobile did it, or people will figure out queries that pretty much tell the same. Some combination of screen

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

ok, I can revert this changes in the next few days, so you don't have to deal with this. 2018-07-06 11:39 GMT+02:00 Harbs : > > but don't you think we can save time and > > resources and left this for 0.9.4 with more refactors we already planned? > > My motivation is to not release undocumented

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

> but don't you think we can save time and > resources and left this for 0.9.4 with more refactors we already planned? My motivation is to not release undocumented breaking changes — especially since they might be changed further or reverted in the next release. I’d like to keep the breaking

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi Harbs 2018-07-06 10:27 GMT+02:00 Harbs : > Here’s what I’d like to do so we could just get out a release: > > * Postpone any final decision on package and project refactoring until > after the release. > Ok for me, although I think this was one of the things we all agree. But I think you

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi Olaf, 2018-07-06 10:19 GMT+02:00 Olaf Krueger : > > I am interested in two points: > - If we decide to decouple Jewel from Basic and introduce a Core and/or > Foundation package: Is there any volunteer out there who will do this work? > Yes, I said I'll work on that. Harbs said as well that

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Here’s what I’d like to do so we could just get out a release: * Postpone any final decision on package and project refactoring until after the release. * Make sure (for the current release only) that the package names match the previous release (even if they could use changing). * Leave the

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi Carlos, you are right, the title "Jewel Refactoring" is misleading, sorry. It should mean the SDK refactoring in favour of the Jewel development. Anyway, I was absent the last few weeks and probably not up-to-date. But it seems to me that you all are still searching for a solution? So, even

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi Olaf, I think the topic is no more "Jewel Refactoring", since many of the refactors I think where ok, but "UI sets dependency on actual Basic", and if we want to make that grid, the points to evaluate should be "Processing of non used CSS " (or "non CSS default" as you posted, "have lots of

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi Carlos, I just saw post after posting the matrix example. I don't want to trigger another discussion but I am not sure if all others know about all the details which were discussed in the past. I am also not sure if it is possible to find a consensus by going the current path. So, having such

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi, I've just created an example of such an evaluation matrix [1]. Please notice that this is really just an example which could be a starting point if you find it helpful. The assumptions I've already done may be wrong. Basically, the idea is to list goals/criteria and assign a weight/priority

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi Olaf, you're right. But what I'm trying to say is that we discussed long over various things. That was very positive since we found many bugs and problems, so discussion brings many positive things. Not the final thing where I think we are stuck is in something that technically I think is

Re: No Touch support?

Hi Alex, how this would be with media queries? FWIK, media queries gives you the possibility to make for example changes depending on screen size, but screen size does not say anything about if you are on Desktop or Mobile right? or is another approach that I'm not aware. For what I see seems

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi, >fixed things could make people not be happy at all with the solution, and end leaving I prefer to don't speak all the time about leaving. Anybody is free to leave at any time, same as in the real world. But leaving because of technical decisions is completely incomprehensible for me... as

Re: No Touch support?

Hi Carlos, Of course you can combine a MouseController and a TouchController into one bead. Aggregations are supported throughout Royale and probably never prohibited. Aggregations are often not PAYG so that's why the current plan is to support runtime loading of the mouse or touch controller

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

Hi Piotr, I think Core or Core + Foundation should have all the reusable pieces for the rest of UI sets (Basic, Jewel, Express, and more) and those combine regarding their objectives. Basicaly core classes, interfaces, supportClasses and beads. For example almost all *Base.as classes should be

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

I remember that Harbs asked your for list of files which should be part of Core yes ? You said that you will do this and discussion died in that place. czw., 5 lip 2018 o 11:39 Carlos Rovira napisał(a): > I think the discussion was mainly done and that we agree in almost all > things but one:

Coming back to discussion over separating libs (Was Re: No Touch support?)

I think the discussion was mainly done and that we agree in almost all things but one: Should Jewel link Basic? For me it's clear that no. Should Jewel use code in basic, clearly yes. So that left us with only 3 options: 1.- Make Jewel link Basic. But I against this solution due to many points I

Re: No Touch support?

Hi, Someone could start work on DataGrid, but the discussion about not using Basic/Express in Jewel has not been finished. I don't see how actually is create that sophisticated component without inheriting those one from Express. Piotr czw., 5 lip 2018 o 10:30 Carlos Rovira napisał(a): > Hi

Re: No Touch support?

Hi Alex, as I said, maybe the solution is not turn off the actual controller and put a touch one. Mouse controller does many things already. I must to investigate more over this since I see this more like to "add" controllers than to switch one for other. Can we configure more than 1controller

Re: No Touch support?

Hi Harbs, 2018-07-04 18:26 GMT+02:00 Harbs : > Hi Carlos, > > Touch support is a can of worms. > that's for sure, I think touch gestures can get complex quickly. > > Basic touch support comes for free from Mouse Events. Anything more than > that, gets very complex very quickly. > Right, I

Re: No Touch support?

Hi Alex, 2018-07-04 18:19 GMT+02:00 Alex Harui : > Hi Carlos, > > You can use negative words like "flaw" if you want. But really, the fact > is that nobody has had time to work on Touch support. Mainly because the > folks interested in migrating to Royale from Flex have not required it yet. >

Re: No Touch support?

@harbs could that become a blog entry? On Wed, Jul 4, 2018, 2:19 PM Harbs, wrote: > Possibly. > > The way Hammer.js works is that you attach it to an element and create an > instance of it or a controller. The specific touch events need to be > specified. > > > On Jul 4, 2018, at 7:34 PM, Alex

Re: No Touch support?

Possibly. The way Hammer.js works is that you attach it to an element and create an instance of it or a controller. The specific touch events need to be specified. > On Jul 4, 2018, at 7:34 PM, Alex Harui wrote: > > Harbs, > > Can we wrap Hammer.js into more easily reusable TouchControllers

Re: No Touch support?

Harbs, Can we wrap Hammer.js into more easily reusable TouchControllers in Royale? IMO, it doesn't matter if it is a can of worms. Royale hopefully makes it easy to replace TouchControllers. So you can write one that mostly works and if someone offers a better one at some point, you can

Re: No Touch support?

Hi Carlos, Touch support is a can of worms. Basic touch support comes for free from Mouse Events. Anything more than that, gets very complex very quickly. I use Hammer.js in my own app to handle touch, and it works very well. https://hammerjs.github.io/ Harbs >

Re: No Touch support?

Hi Carlos, You can use negative words like "flaw" if you want. But really, the fact is that nobody has had time to work on Touch support. Mainly because the folks interested in migrating to Royale from Flex have not required it yet. Drawer is cool, and new, but I don't know that migrating