Thanks for keep me posted about your experiments. I would like to know where the current interface doesn't suit your needs/tastes and how easy was to use/extend the tool. I think that mind mapping problem would be particularly well suited for your GUI approaches.
Cheers, Offray On 26/08/17 14:53, Dimitris Chloupis wrote: > mind mapping is an interest of mine too, though i never tried to make > one app for it yet. Ok will see if I will go down the Grafoscopio > route and will keep you posted. I was thinking using it as an in-image > interface for the wiki. > > On Sat, Aug 26, 2017 at 10:15 PM Offray Vladimir Luna Cárdenas > <[email protected] <mailto:[email protected]>> wrote: > > That would be pretty interesting and yes, it is under MIT. > > On custom GUI's I have thought about a mind mapping interface for > Grafoscopio, for presentations. I would like to stretch the > tree/graph metaphor so it can make what we do with different > metaphors right now on "offimatics" (writing, calculation and > presentation), so this custom metaphors are interesting to me. > > Cheers, > > Offray > > > On 26/08/17 12:28, Dimitris Chloupis wrote: >> How would you feel if I took grafoscopio and made a custom GUI >> for it, mainly for personal usage ? Does it use the MIT license ? >> >> On Sat, Aug 26, 2017 at 6:56 PM Offray Vladimir Luna Cárdenas >> <[email protected] <mailto:[email protected]>> wrote: >> >> No it can't. Grafoscopio Markdown nodes just plain text boxes >> with Markdown code inside, but I would like to have at least >> syntax hightlighting for it. What Grafoscopio can do is to >> traverse a tree and process node headers as markdown titles, >> footnotes and others to produce a flat Markdown file to be >> processed by Pandoc. Also, thanks to special %metadata nodes >> in the tree, Grafoscopio can control & feedback the Pandoc >> command line options *inside* the notebook, increasing >> reproducibility, just by using plain Pharo dictionaries and >> dynamic arrays. Then, you can use the Notebook menu to export >> as PDF by running such options from the GUI. >> >> Cheers, >> >> Offray >> >> >> >> On 26/08/17 10:31, Dimitris Chloupis wrote: >>> Grafoscopio can display markdown files ? >>> >>> On Sat, Aug 26, 2017 at 5:38 PM Offray Vladimir Luna >>> Cárdenas <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Dimitris, >>> >>> I understand your practical reasons to have Markdown >>> over Pillar and in fact I have advocated several of >>> them. As I have said, Markdown ubiquity for complete >>> documentation workflows (including complete books) is >>> similar to git ubiquity for code. Despite having other >>> personal preferences in markup and DVCS, I think is >>> strategic to give them support in Pharo, without >>> precluding any work on our own tools (Monticello, >>> Metacello, Pillar, etc.). >>> >>> I'll try to make some experiments with integration of >>> Documenter in Grafoscopio and Markdown. They'll advance >>> slowly, because time constrains now that I'm trying to >>> finish my thesis, but once a week I'll try to show >>> advancements and make questions. >>> >>> Cheers, >>> >>> Offray >>> >>> >>> On 26/08/17 01:55, Dimitris Chloupis wrote: >>>> As I said the format is not so important for me, the >>>> reason why I chose markdown instead of pillar is >>>> because you can edit it using github web interface >>>> making it easier. The books will continue to use >>>> Pillar, because making a book is obviously a lot more >>>> sophisticated than creating a wiki that mainly has web >>>> links to various internet locations. Pillar already can >>>> export to markdown , latex, html and through latex it >>>> can also export to pdf. >>>> >>>> After Stef requested it, I moved the wiki inside the >>>> pharo git repository here >>>> >>>> https://github.com/pharo-project/pharo >>>> >>>> I also added a link to it inside the git wiki of pharo >>>> >>>> https://github.com/pharo-project/pharo/wiki >>>> >>>> >>>> On Sat, Aug 26, 2017 at 2:17 AM Offray Vladimir Luna >>>> Cárdenas <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> So, we're going to have Markdown for the wiki and >>>> probably for documentation (via GitBooks)..., which >>>> is not surprising considering the vast amount of >>>> support such documentation format has and the >>>> extensions for a complete documentation toolchain >>>> and features. As I said, I think that is an >>>> important syntax and we should put Scholarly/Pandoc >>>> Markdown in the radar for documentation support in >>>> Pharo. Is what I'm doing with Grafoscopio and now >>>> that Pillar support is again taking momentum, the >>>> infrastructure there (parsers, highlighters, >>>> editors) could be extended to support Pandoc's >>>> Markdown. >>>> >>>> I'll keep you posted. >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> >>>> On 24/08/17 17:59, Dimitris Chloupis wrote: >>>>> >>>>> >>>>> On Thu, Aug 24, 2017 at 11:32 PM Stephane Ducasse >>>>> <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> You have Netstyle/Workflow too. >>>>> >>>>> >>>>> done >>>>> >>>>> "Why are you using markup documents to create the >>>>> wiki when you could >>>>> use Github wiki itself? >>>>> >>>>> For portability?" >>>>> >>>>> good question. Yes for flexibility , another >>>>> reason however is that Github wiki is a separate >>>>> repo and I did not want that because in the very >>>>> back of my head I am considering the option of >>>>> creating software to allow access to wiki from >>>>> inside Pharo and I wanted to be all (content and >>>>> code) in the same repo. Its a very low priority >>>>> for now. >>>>> >>>>> Also Github wiki is basically the same as I am >>>>> doing with some extra format (table of contents) , >>>>> in my case I dont care because Github allows me to >>>>> define HTML templates that will format the wiki >>>>> webpage and make it look a a lot more polished >>>>> that pharo wiki looks like. Generally there are >>>>> some cool stuff you can do with Markdown and >>>>> Github , plus the fact that markdown can embed >>>>> HTML etc. >>>>> >>>>> There is also the option of Gitbook which has some >>>>> nice features for generating polished and well >>>>> structured documentation. >>>>> >>>>> So I like to keep my options open. For now I am >>>>> focusing 100% on content. >>>> >>> >> >
