On Wed, 01 Nov 2017 18:27:51 +0000 Andrew Williams <a...@andywilliams.me> said:

> Hi,
> 
> Whatever rendering technologies we use within Edi is probably out of scope
> for this thread which was (in part) about using a more portable
> documentation format to allow folk to access the docs outwith the E website
> context.
> Markdown is working well for the documentation team as they can use their
> own editors before adding to the wiki for any final tweaks / links etc.
> I don't know about others but I think we're about out of reasons not to
> support this going forward.

well let's see. i still dislike us now having 2 markdown formats on our main
site.

> Thanks,
> Andy
> 
> On Wed, 1 Nov 2017 at 00:53 Carsten Haitzler <ras...@rasterman.com> wrote:
> 
> > On Tue, 31 Oct 2017 10:01:43 +0000 Andrew Williams <a...@andywilliams.me>
> > said:
> >
> > > Hi
> > >
> > > Ideally yes - but then images are part of the spec anyway - and tables
> > are
> > > pretty standard these days.
> >
> > ok. so then it'd have to be a mixed bag of textblocks/entries + tables or
> > boxes
> > containing them with tables done outside of these widgets. more involved to
> > create a display widget/layout at any rate.
> >
> > > Andy
> > >
> > > On Tue, 31 Oct 2017 at 08:37 Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> > >
> > > > On Tue, 31 Oct 2017 08:18:37 +0000 Andrew Williams <
> > a...@andywilliams.me>
> > > > said:
> > > >
> > > > > In the case of method/symbol documentation that is indeed correct
> > and no
> > > > > markup language is my first port of call for that. The first pass was
> > > > done
> > > > > with clang which is pretty good thus far - .eo is going to be much
> > more
> > > > > help once the interfaces become more commonly used.
> > > > >
> > > > > However what your email misses is all the other documentation that
> > we are
> > > > > hoping to reference - the helpful context documents (mainloop / alpha
> > > > > blending) and examples or walkthroughs that would make a much better
> > hand
> > > > > holding experience. Like I said before this is intending to help
> > folk get
> > > > > started with EFL - the steep learning curve is due to much more than
> > > > method
> > > > > parameter order and bounds.
> > > >
> > > > ok. i was just thinking reference
> > (struct/enum/func/method/property/class
> > > > info)
> > > > stuff. not things like tutorials and whatever. edi needing this
> > tutorial
> > > > land
> > > > stuff seems more fringe. reference docs - absolutely. i can see this.
> > like
> > > > tooltips and completion info as you type telling you about what you are
> > > > writing
> > > > and the limits/sage and so on.
> > > >
> > > > i mean... at a stretch i can see edi showing these docs, but then
> > doesn't
> > > > it
> > > > also have to handle inlined images (diagrams, screenshots and so on?).
> > > > tables,
> > > > and what not... right?
> > > >
> > > > > Thanks,
> > > > > Andy
> > > > >
> > > > > On Tue, 31 Oct 2017 at 07:36 Carsten Haitzler <ras...@rasterman.com>
> > > > wrote:
> > > > >
> > > > > > On Tue, 24 Oct 2017 13:39:14 +0000 Andrew Williams <
> > > > a...@andywilliams.me>
> > > > > > said:
> > > > > >
> > > > > > > On Tue, 24 Oct 2017 at 13:09 Carsten Haitzler <
> > ras...@rasterman.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, 23 Oct 2017 11:57:56 +0000 Andrew Williams <
> > > > > > a...@andywilliams.me>
> > > > > > > > said:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I will try to provide as much insight as I can:
> > > > > > > > >
> > > > > > > > > As many of the community are aware I started the Edi project
> > to
> > > > help
> > > > > > get
> > > > > > > > > people into coding on EFL - the learning curve is very steep
> > and
> > > > the
> > > > > > > > > tooling was basically commandline based. Documentation is a
> > big
> > > > part
> > > > > > of
> > > > > > > > the
> > > > > > > > > solution and we've come a long way both with the wiki and
> > with
> > > > the
> > > > > > .eo
> > > > > > > > > format for defining functionality. However this is set up to
> > > > deliver
> > > > > > only
> > > > > > > > > on our website which a) is online and b) is external to the
> > IDE.
> > > > > > > > > To make a more integrated experience I started to think about
> > > > how the
> > > > > > > > > documentation could be more portable - so that it could be
> > > > rendered
> > > > > > in
> > > > > > > > Edi
> > > > > > > > > or other documentation browser online or offline, in the
> > > > workflow of
> > > > > > > > > someone's coding. Dokuwiki is a challenge here as the only
> > > > renderer
> > > > > > is
> > > > > > > > the
> > > > > > > > > dokuwiki web ui so reading the files off the filesystem is
> > not
> > > > > > really a
> > > > > > > > > possibility without coding up a new render implementation.
> > > > > > > >
> > > > > > > > i was actually thinking of the docs always being online... :)
> > then
> > > > > > changes
> > > > > > > > and
> > > > > > > > improvements are immediately accessible to all users/devs ...
> > :)
> > > > yes
> > > > > > yes.
> > > > > > > > hard
> > > > > > > > to refer to docs while on a plane ... i know. :)
> > > > > > > >
> > > > > > >
> > > > > > > In it's current form not only do you have to be online you have
> > to
> > > > have a
> > > > > > > browser window open alongside your code. To be worried about
> > > > immediate
> > > > > > > propagation of improvements implies a lot more documentation
> > activity
> > > > > > than
> > > > > > > we see - and once the API has a solid release would important
> > > > changes to
> > > > > > > them not be less common?
> > > > > > >
> > > > > > > > A few conversations later and I was chatting to Cedric about
> > what
> > > > we
> > > > > > can
> > > > > > > > do
> > > > > > > > > to make the documentation cleaner and he mentioned that
> > Samsung
> > > > was
> > > > > > also
> > > > > > > > > interested in this - and that they may be willing to finance
> > some
> > > > > > > > technical
> > > > > > > > > writers to help. So he managed to get some professionals
> > signed
> > > > up
> > > > > > and
> > > > > > > > now
> > > > > > > > > have people raring to go with documentation - but they don't
> > know
> > > > > > > > dokuwiki
> > > > > > > > > and honestly I don't think that spending all day editing text
> > > > files
> > > > > > in a
> > > > > > > > > browser window is the best way to write reams of
> > documentation. A
> > > > > > markup
> > > > > > > > > format with external editors would mean higher productivity
> > and
> > > > also
> > > > > > > > > increased portability.
> > > > > > > > >
> > > > > > > > > And so here we are. It looks like Markdown is a format that
> > > > provides
> > > > > > a
> > > > > > > > lot
> > > > > > > > > of additional benefits in terms of contributors, portability
> > and
> > > > > > future
> > > > > > > > > proofing.
> > > > > > > >
> > > > > > > > ok. so here's a question. edi. how do you plan to display docs
> > in
> > > > edi?
> > > > > > > > going to
> > > > > > > > write a madkrown parser/formatter in "c" and then use
> > textblocks
> > > > > > (entries,
> > > > > > > > efl.ui.text) to display? nothing else exists at the moment. or
> > > > > > planning to
> > > > > > > > add
> > > > > > > > "markdown handling" directly to efl.ui.text/textblock etc.
> > (like
> > > > > > markup is
> > > > > > > > supported)? going to write an "exporter" that uses the wiki php
> > > > cod to
> > > > > > > > parse
> > > > > > > > markdown but instead of html - generate textblock etc. markup?
> > > > > > > >
> > > > > > >
> > > > > > > Ideally we would have a native markdown component for speed
> > purpose
> > > > - it
> > > > > > > would make a nice editor as well as a way to view the docs and
> > > > > > dynamically
> > > > > > > link in context.
> > > > > > > However that is a reasonable amount of work - due to the
> > commonality
> > > > of
> > > > > > > this format we can get there faster by using a pre-built parser,
> > > > hooking
> > > > > > in
> > > > > > > whatever clever linking we want and preview through something
> > > > currently
> > > > > > > available like HTML. Not the perfect solution but much quicker
> > to get
> > > > > > > working.
> > > > > > >
> > > > > > > > I hope that helps,
> > > > > > > > > Andy
> > > > > > > >
> > > > > > > > --
> > > > > > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > > > > --------------
> > > > > > > > Carsten Haitzler - ras...@rasterman.com
> > > > > > >
> > > > > > >
> > > > > > > Not sure if that helps with the context you were looking for?
> > > > > > > Andy
> > > > > >
> > > > > > more context.
> > > > > >
> > > > > > but if you want files for docs inside something like edi shouldn't
> > they
> > > > > > have far
> > > > > > more semantic info -not markdown? like literally something like:
> > > > > >
> > > > > > class colors {
> > > > > >   property {
> > > > > >     name: color
> > > > > >     modes: RW
> > > > > >     type: int r (0-255), int g (0-255), int b (0-255), int a
> > (0-255)
> > > > > >     description {
> > > > > >       "This is the premultiplied RGBA color with values fro 0 to
> > 255
> > > > per"
> > > > > >       "component"
> > > > > >     }
> > > > > >   }
> > > > > >   func {
> > > > > >     name: clear
> > > > > >     description {
> > > > > >       "Clears the color from the target so no color is applied."
> > > > > >     }
> > > > > >   }
> > > > > > }
> > > > > >
> > > > > > my point being edi would want a LOT more semantic info so it can do
> > > > things
> > > > > > like
> > > > > > complain if a parameter is out of min/max bounds and so on... ?
> > like
> > > > edi
> > > > > > really
> > > > > > needs the eo file info etc. etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > > --------------
> > > > > > Carsten Haitzler - ras...@rasterman.com
> > > > > >
> > > > > > --
> > > > > http://andywilliams.me
> > > > > http://ajwillia.ms
> > > >
> > > >
> > > > --
> > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > --------------
> > > > Carsten Haitzler - ras...@rasterman.com
> > > >
> > > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - ras...@rasterman.com
> >
> > --
> http://andywilliams.me
> http://ajwillia.ms
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to