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. 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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [email protected]


------------------------------------------------------------------------------
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

Reply via email to