Re: defaults x, y in UIBase
A nice Christmas present: most of the work is already done. On Sat, Dec 28, 2019 at 2:57 PM Carlos Rovira wrote: > Hi, > > while making te copy/paste of the code for width/height, I see we already > has implemented defaults for x and y. > making a git blame reveal it was me around 2 years ago. I completely forgot > about that. Seems I already had the same problems for x,y > I can move that code to StyledUIBase too, I suppose it the most coherent if > no one oppose. > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Andrew Wetmore http://cottage14.blogspot.com/
defaults x, y in UIBase
Hi, while making te copy/paste of the code for width/height, I see we already has implemented defaults for x and y. making a git blame reveal it was me around 2 years ago. I completely forgot about that. Seems I already had the same problems for x,y I can move that code to StyledUIBase too, I suppose it the most coherent if no one oppose. -- Carlos Rovira http://about.me/carlosrovira
Re: Trying an implementation "inheritWidth" function on StyledUIBase
Hi Alex, El sáb., 28 dic. 2019 a las 2:46, Alex Harui () escribió: > > Yes, it is fine to change them to protected. > ok will try to do > The original discussion included the topic of higher-level abstractions vs > platform-specific APIs. It seems you really want Jewel users to use a > platform-specific API, so you are welcome to allow NaN in Jewel. > after looking other ways I think is the best option, although it defeats a bit to extend from UIBase, since I'll need to copy/paste almost 80% of the code in that class. Maybe could be better to extend HTMLElementWrapper instead. > > If I were to implement something similar in Basic, I would first try to > understand how often it is needed and where it is needed because I would > not want to implement something on UIBase "just-in-case". The problem is that JS platform (and one day other ones too) will requiere to deal with its particularities. I don't like the way browsers works using "strings" and having default strange options, but doing serious work with styling reveal you need manage width and height to its defaults some times to make sizing adapt in the right way. So I have clear in mind that this particularity in browsers must to be solved. I think the NaN check is something right, since is the nature of the platform. I understand you and Harbs about the ideal concepts, but sometimes ideal concepts does not work, since others make things in a weird way, like in browsers. I think what we need to do is to try to manage singularities as best as we can, and for using NaN to default to browsers is the right way. Moreover: If you have a width not set in Royale, _width is NaN. That means in JS element.style.width does not exists, and that means width is "auto". Then setting width to 200 makes _width = 200 and this sets element.style.width = "200px". Then setting width to NaN makes element.style.width = "NaNpx" what is a wrong value. I think you guys should fix that in some way or another. That implies introduce more code, now it's a matter if you make that code useful for users or just signal an ilegal state. > If it was primarily needed on, say, a TitleWindow/Panel thing, that > TitleWindow might get a higher-level API like 'displayState" which could > have the values "minimized, maximized, sizedToContent". The underlying > code behind displayState would call the sizeToContent utility function. > And then it could be used in ternary expressions. And I might implement > that on a subclass of TitleWindow (TitleWindowWithDisplayState) so that not > all TitleWindows/Panels carry that API. > I think that seems to me lots of code, and not PAYG. As well seems to me something users could never reach to it, since people coming from JS will search for a away to remove "element.style.width" > > One of the things I think you are running into with inheritWidth (which > doesn't actually get set to inherit when you set to null, IMO, so I'm not a > fan of the name), is that in Royale we have elected to make width a Number > where in the browser it is a String. Yes, I think using Number is the right way to go. Using Strings is what browsers do under the hood, and we need to translate in an efficient way. > If you want to expose browser APIs to Jewel users, you may want to come up > with a whole new set of base classes that more directly mimic the browser > API. Then setting width to NaN or null wouldn't be a factor. Folks would > be setting the value to a string like "auto" instead. but that will be unaligned with _width value. If a user makes element.style.width = "auto", (or = null that is the same), _width still is in a incorrect value (maybe 50, 100, 200 or NaN). We should try to avoid make users to change browsers values bypassing royale official way to manage it. > However I think there are good reasons for most other Royale components to > make width a Number. I think there are way more calculations of width > based on Numbers, although I can imagine a component set where width is > always determined by constraints and not values. I think it is very rare > for folks to need to switch random components from sizeToParent to > sizeToContent, and that the components that need that more frequently can > expose that choice in subclasses for those who need to manage that value > via expressions. > I think most of the times this problems is for advanced users trying to make components. But we are to young to say 95% of the users will not need to remove width or height. But anyone trying to do serious development with Royale will find this sooner or later, then you and Harbs will have this conversation again talking about is not right to put " isNaN(value) ? null :" since is not legal, and that will make that users try to go the same I use, that is change underlaying browser style width values and making royale components state not aligned to it. HTH Carlos > > My 2 cents, > -Alex > > El vie., 27 dic. 2019 a las 14:00, Harbs () >
Re: Routing and deep linking
Hi, rounting/deep linking is something is used I ASDoc, but we still does not have a library with some API to integrate. It should not be nothing specially difficult, but someone must to take it and do it, maybe using the ASDoc as a way to learn how it works. El sáb., 28 dic. 2019 a las 12:40, Andrew Wetmore () escribió: > Hi: > > One of my to-do's for the Royale documentation is to provide a page about > routing. The first-application tutorial also has a placeholder page about > routing. > > I believe routing was called deep linking in Flex. Is there documentation > anywhere, or running examples, to show what is different between routing > and deep linking, aside from the name? > > Thanks. > > Andrew > > -- > Andrew Wetmore > > http://cottage14.blogspot.com/ > -- Carlos Rovira http://about.me/carlosrovira
Re: Jewel ButtonBar and DataGrid first iteration! :)
Hi all, just want to share a tweet about the latest iteration of Jewel DataGrid. This covers scrolling and other issues with dimensions and sizing. Will try other examples in the next days adding combos, checks and more item renderer visualizations. https://twitter.com/ApacheRoyale/status/1210870204001116160 As always share, retweet and enjoy!! :) Carlos El vie., 13 dic. 2019 a las 1:20, Greg Dove () escribió: > That looks awesome! Great work, Carlos :) > > > On Fri, Dec 13, 2019 at 1:15 PM Carlos Rovira > wrote: > > > Hi Andrew, > > > > you can see a new version of TDJ uploaded with the current examples : > > https://royale.apache.org/tourdejewel/# > > > > Enjoy! :) > > > > Carlos > > > > > > > > El vie., 13 dic. 2019 a las 1:12, Andrew Wetmore () > > escribió: > > > > > This is great news! I can't wait to play with them. > > > > > > On Thu, Dec 12, 2019 at 8:05 PM Carlos Rovira > > > > wrote: > > > > > > > Hi, > > > > > > > > just committed my work on Jewel ButtonBar and DataGrid. I think these > > > > components was long awaited and finally we have it here! :) > > > > > > > > Just let you know that I tried my best to have this iteration as most > > > > stable as possible, but consider that I still need to do some work in > > > some > > > > areas. > > > > I wanted to try to have the API stable so don't need a change when > > > > completing next iterations, but this is nothing I can guarantee ;) > > > > > > > > ButtonBar supports typical emphasis styles in Jewel Buttons as well > > other > > > > things from Jewel Layouts. I think I'll need to make its own > extension > > of > > > > the model > > > > and I'm still thinking about the different width types from Basic > > > version. > > > > I must see if the current ones are sufficient of I need to implement > > > more. > > > > > > > > About DataGrid, I wanted to have a first version where: > > > > > > > >- roll over is supported (this will do with a change of styles to > be > > > >more flexible and can be controlled not only by hover with the > > mouse) > > > >- Have a default width like in flex where columns are sized to 1/n > > > >columns of the total available space > > > >- Have a layout based on columnWidths > > > >- Get an initial Jewel look and feel that as well have the things > in > > > >ButtonBar like emphasis color > > > > > > > > Still to do most important: > > > > > > > >- sorting of columns > > > >- resizing of columns > > > > > > > > Other things that should come (depending on how important are this > > ones): > > > > > > > >- editable cells > > > >- reordering of columns > > > > > > > > Tour De Jewel has a few initial examples, and I hope to add more like > > > > ButtonBar with icons in the buttons or other kind of renderers like > > > > ToggleButton? will see... > > > > > > > > A couple of things more: > > > > > > > > > > > >- Since this components comes from the work in Basic, many of the > > > design > > > >is from there, but while transforming to Jewel I could see some > > things > > > > that > > > >I could fix that maybe could be good to make as well in Basic > > > versions, > > > > for > > > >example, Basic DataGridView creates most of the things in > > initComplete > > > >handler, while in Jewel all is done in the strand - createChildren > > > > method. > > > >There's some methods and events in Basic version not used that > could > > > be > > > >cleaned, and many events for "layoutNeeded" dispatched that seems > > can > > > be > > > >removed, and other things that could be compared to try to improve > > > Basic > > > >one. > > > >- I know she things in Jewel versions to be fixed from tomorrow, > so > > > >think that this is a first version of complex components, so I'll > > > > continue > > > >to work on this in the next days to continue improve things. For > > > > example in > > > >some configurations refreshing the component will not do what we > > > > exepect... > > > >just give some more days to go over it. > > > > > > > > Hope you like it! :) > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > http://about.me/carlosrovira > > > > > > > > > > > > > -- > > > Andrew Wetmore > > > > > > http://cottage14.blogspot.com/ > > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > -- Carlos Rovira http://about.me/carlosrovira
