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
