Once again about resources...
...we discussed that resource should have a keyword like
path=res("path/image.png")I think it doesn't make sense in this file (UI file), this should be implemented in Gui Builder itself. It would be nice if parser can provide list of all files, so Gui Builder will be able to create list of resources according to extension. If it's ok, I'll update Resource section in wiki. Thus, there is only snippets syntax improvement left. Besides that document is ready. Yakov On 04/04/2016 06:11 PM, Yakov Goldberg wrote: > On 04/04/2016 02:42 AM, Carsten Haitzler (The Rasterman) wrote: >> On Sun, 03 Apr 2016 17:37:16 +0300 Yakov Goldberg <[email protected]> said: >> >>> Tom, Raster thanks for comments. >>> >>> Wiki: https://phab.enlightenment.org/w/ui_builders_format/ >>> Changes: >>> - first letter of widget is now lower case; >>> - fixed indentation - 4 spaces everywhere; >>> - fix Resource description; >>> - other minor updates. >>> >>> The reason I put resources separately is that I was still thinking in >>> Erigo scope. >>> You are right - resources should be right in the text. >>> And then gui builders should be able use API to get list of resources, >>> so GUI_BLDR'S own project files can be created to handle resource aliases. >>> As for format I like: >>> >>> res("path/layout.edj") >>> or >>> @"path/layout.edj" >>> or >>> ₪"path/layout.edj" >>> :) >>> ...can be decided a little bit later >> well i started work on this being done at runtime with "magic file paths" in >> efl. so far i have: >> >> "/path/to/whatever" <- normal >> "./path/to/whatveer" <- normal >> "../path/to/whatever" <- normal >> "path/to/whatever" <- normal (same as ./path/to/wahtever) >> >> and new ones: >> >> "~/path/to/whatever" <- like in shell >> "~username/path/to/whatever" <- like in shell >> "@key/path/to/whatever" <- new "magic location" where key is set at runtime >> >> so it's buried inside the path string itself. what they keys are will work >> out >> over time. i'm starting with some basics: >> >> @home <- same as ~/ >> @tmp <- /tmp (or TMPDIR or other env vars pointing to where tmp should be) >> @data <- XDG_DATA_HOME = ~/.local/share >> @config <- XDG_CONFIG_HOME = ~/.config >> @cache <- XDG_CACHE_HOME = ~/.cache >> @run <- XDG_RUNTIME_DUR - depends likely set to /var/run/user/UID >> >> also likely: >> >> @download <- ~/Download >> @desktop <- ~/Desktop >> @documents <- ~/Documents >> @music <- ~/Music >> @pictures <- ~/Pictures >> @templates <- ~/.Templates >> @videos <- ~/Videos >> >> i am THINKING of app specific keys like: >> >> @app.dir/ (prefix) >> @app.bin/ (prefix/bin) >> @app.lib/ (prefix/lib) >> @app.data/ (prefix/share/appname) >> @app.locale/ (prefix/share/locale) >> @app.config/ (@config/appname) >> @app.cache/ (@cache/appname) >> @app.local/ (@data/appname) >> >> ... maybe some more. then we get to the problem that efl itself should use >> this >> too so i think over time efl should centralize data in PREFIX/share/efl (and >> binaries, libraries etc. go int he same dir anyway due to efl building as a >> single unit) so i am expecting to have: >> >> @efl.dir/ >> @efl.bin/ >> @efl.lib/ >> @efl.data/ >> @efl.locale/ >> @efl.config/ >> @efl.cache/ >> @efl.locale/ >> >> ... >> >> the same code CAN in theory do: >> >> file:/// ..... (but i have to write a uri parser/converter first) >> http://.... (but then i have to write a whole http fetcher, downloader, >> cacher) >> ssh://.... (like with http - but need to use libssh etc.) >> >> the api is designed to be async out of the box, able t be extended by apps to >> customize special path handling of their own etc. ... once i have basics >> working i have to go over efl everywhere in eo api it takes a file... and >> make >> it use this. >> >> then we'll have a single place in efl to handle path redirection (magic >> paths) >> and this will save so much complexity in apps and even efl and make our lives >> so much better. we can drop http handling in elm_image for example but now it >> works everywhere out of the box. >> >> so there are 9in my dir here) eo classes that let you create a file object >> from >> an input path and resolve the resulting location. here is the important bit >> - i >> wasn't going to add any api to list files for you. i really don't think that >> belongs in this api imho. > Of course not. I meant: parser will have API to list all resources. > The rest is great! >> i think that requires you to use this api to resolve >> the path AND then to list the content yourself. :) this will require that you >> perhaps do something special lin erigo and convert erigo's @app.xxx/ >> namespace >> to fake/match the target application "current data/resources directory" and >> erigo setsup its own personal namespace for its own bin/data/whatever virtual >> paths (you can register special meta locations with vpath core) >> >> it'll make sense soon. :) >> >>> As for alignment in my example, I'd stick with indentation related to >>> parent. Don't know if it complicates implementation of generator... >>> >>> part["short_name"]: table(id = "table2") >>> pack[0, 1, 1, 1]: image(file = "logo2.png") >>> part["very_long_part_name"]: table(id = "table2") >>> pack[0, 1, 1, 1]: image(file = >>> "logo2.png") >>> >>> >>> Snippets: >>> I don't like my own suggestion either :) Need to re-think. >>> >>> Yakov >>> >>> On 03/30/2016 05:48 PM, Tom Hacohen wrote: >>>> You're a bit inconsistent on the wiki page. >>>> In some places you use lower case letters at the beginning of class >>>> names, in others upper case. In some cases you put a space after a >>>> class, in some not. Please take care of that. >>>> There are even more spacing mistakes/confusions all around, for example >>>> in the last example in snippets there is an extra space before Box. >>>> >>>> Content format: I know we talked about describing the "packing" in >>>> Eolian. We said we'd just mark functions/properties with @packer or >>>> something, right? Maybe mention it in the wiki. >>>> >>>> snippet: I feel like there should be a better name for that. No need to >>>> use the Android naming. >>>> >>>> I really don't like the way you suggested to customise snippets. I >>>> really don't like it. There must be a better way. Also, using the "id" >>>> as a type all of sudden is weird and confusing. I really dislike all of >>>> this, I think we need to get back to the drawing board for this one. >>>> >>>> I don't get why resources are done this way. I much prefer >>>> res("path/layout.edj") or even just a list of resources, why the >>>> "images" and "edje"? I guess for embedding edje compilation. I think >>>> that's wrong putting it in this tool. >>>> >>>> Looking at the format example at the end of the wiki page, it's >>>> inconsistent and outdated, please update it with the definitive format. >>>> >>>> >>>> As a side note, I don't like the way the discussions over this are being >>>> done. We just get random rewrites once every few weeks. Version 1, 2 and >>>> 3 are very different, and there's no explanation to why things were >>>> changed or done in the ways they were done. I have seen no comments from >>>> anyone on the ML or anything, just completely new versions that improve >>>> in some aspects are get worse in others without any specific comments or >>>> discussions. I expect to see something like: "we changed it to this >>>> because X, Y and Z. Unfortunately there was an issue with our previous >>>> idea that this one solves, but there are new caveats, bla bla bla." >>>> >>>> >>>> Other than the above (and the comments below), it looks good and is >>>> getting better, I'm just asking for an easier to follow process and some >>>> corrections. Sorry if it comes across a bit bitchy. :) >>>> >>>> >>>> Answers to your questions: >>>> >>>> On 28/03/16 16:04, Yakov Goldberg wrote: >>>>> Hello, >>>>> I'd like to initiate last call discussion on UI syntax. >>>>> >>>>> Wiki is here:https://phab.enlightenment.org/w/ui_builders_format/ >>>>> >>>>> If you have any objections or ideas, please share. >>>>> >>>>> >>>>> Also some notes: >>>>> >>>>> As I understood from previous discussion, most like 4-spaced indentation. >>>>> But maybe we shouldn't stick with exact number? Think of case like this: >>>>> >>>>> window >>>>> layout >>>>> part["part1"]: box(id = "box1") >>>>> button(text="button") >>>>> part["long_part_name"]: table(id = "table2") >>>>> pack[0, 0, 1, 1]: image(file = >>>>> "logo.png") part["short_name"]: table(id = "table2") >>>>> >>>>> Should user be able to align text like this? >>>>> >>>>> window >>>>> layout >>>>> part["part1"]: box(id = "box1") >>>>> button(text="button") >>>>> part["long_part_name"]: table(id = "table1") >>>>> pack[0, 0, 1, 1]: image(file = >>>>> "logo.png") part["short_name"]: table(id = "table2") >>>>> pack[0, 1, 1, 1]: image(file = >>>>> "logo2.png") >>>> Decide, either: >>>> part["part1"]: Box >>>> Button >>>> >>>> Or: >>>> >>>> part["part1"]: Box >>>> Button >>>> >>>> Don't allow both. The second one is probably better, though a bit >>>> over-indented. >>>> >>>> I'd avoid things like you second suggestion, that is, aligning box and >>>> the tables to the same column, adds so much manual maintenance without >>>> any benefits. >>>> >>>>> --- >>>>> Snippets: >>>>> As I said before snippets should be customizable, so user could check >>>>> properties, add callbacks., etc. >>>>> Thus updated suggested format is: >>>>> >>>>> box(id="mybox") >>>>> button(id="but1") >>>>> image(id="img1") >>>>> >>>>> window >>>>> layout >>>>> part["a"]: snippet.mybox (id="mybox1") >>>>> but1(text = "text", img1.file = >>>>> "logo.png") >>>>> on("clicked", "func_name") >>>>> img1(file = "logo.png") >>>> See my comments above, I hate this. >>>> >>>>> --- >>>>> Should all files(paths) be defined as resources, so generator will be >>>>> able to generate paths properly? >>>>> >>>>> resources >>>>> images >>>>> "bg":"images/background.png" >>>>> "logo":"images/logo.png" >>>>> edje >>>>> "edje_res":["path/layout.edj", "path/layout.edc"] >>>>> >>>>> window >>>>> layout(file=res("edje_res")) >>>>> part["a"]: button(icon = res("logo")) >>>>> >>>> I don't understand this question, but I have commented on resources above. >>>> >>>> >>>> -- >>>> Tom. >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Transform Data into Opportunity. >>>> Accelerate data analysis in your applications with >>>> Intel Data Analytics Acceleration Library. >>>> Click to learn more. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 >>>> _______________________________________________ >>>> enlightenment-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Transform Data into Opportunity. >>> Accelerate data analysis in your applications with >>> Intel Data Analytics Acceleration Library. >>> Click to learn more. >>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 >>> _______________________________________________ >>> enlightenment-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
