On Monday, January 23, 2012 7:22:21 PM UTC+7, Offray Vladimir Luna Cárdenas
wrote:
>
>
> documentation also in the center is required if we want to break the Leo's
> self-fulfilled prophesy about being a "ghetto tool" for programmers only
Usability for clueless noobs is a lot of work, probably harder than the
complex whiz-bang functionality part.
And to take something as powerful and flexible as Leo and make it
accessible for noobs would require "lobotomizing" it to some extent, at
least hiding those features that weren't relevant to the intended
more-mainstream task at hand.
I imagine something like "application mode" flag at launch time
- Leo as a journaling tool (like Rednotebook on steroids)
- Leo as an Evernote-style note-taking brain extension
- with user-accessible tagging, perhaps multiple headings per node?
- Leo as a delicous-replacement (import/export/backup) bookmarks
management tool
- Leo as a single-source multiple-output documentation management
meta-organizer and conversion-supporting tool
etc - very different UX - pane layouts, menu structures etc - for each
mode, but the same underlying code and data structures
but at the end we could not intervene MoinMoin as much as we would like
> because of the server permissions
ACLs is one of DokuWiki's strengths, as they target the corporate world (as
much as a FOSS tool can 8-)
> So far I've found that anything that runs under Linux is inherently
> portable in
>
> > that sense.
>
> Agreed. Having Leo + Fossil + Laptop ( ;-P ) gives me some kind of
> portability, but we need more.
>
Pocket-size portable HDD with USB2 / SATA2 (will soon start converting to
v3 of both, used to use Firewire), booted up using any arbitrary internet
cafe / friend / customer desktop.
ideally would be nice to have something like the self-contained
> multiplatform Pharo's One Click
> Experience[1]
>
> [1] http://www.pharo-project.org/pharo-download
>
Most of the mainstream distros now have easy-to-customize
create-your-own-distro LiveCD/USB+persistent storage projects. I've got a
portable drive that launches a GRUB2 boot menu letting me choose between
various configs of Fedora, Red Hat, Debian, Ubuntu and Slax, all of which
access shared /home and server-data partitions (which gets sync'd with my
central filer). Check out Sardu <http://www.sarducd.it/>, which also
handles all the mainstream recovery/rescue/sysadmin tools like grml,
pmagic, sysresccd - even BartPE, Win7 repair etc all on the same pocket
drive. . .
> integration of web characteristics of GitHub in Fossil (wiki, tickets, web
> interface and so on).
>
> agnosticism/diversity as a valuable thing to preserve.
Personally I prefer using CLI batch/scripts and/or TortoiseXX rather than a
web interface for my VCS usage, and my ticket/project management/GTD system
of choice is Redmine (likely Chili soon).
Both of these integrate well with the important VCSs, so when I finally get
away from SVN and get familiar with the distributed new kids, I can keep my
other tools - Redmine/Chili now has such a custom-infrastructure encrusted
around it sync'ing with gcal, printing pocketmods for my calendar and
@context to-do's that have become indispensable to my day-to-day life
management.
> "dystopic world of everything is a file" (in that world you don't have
> meta-structure, only structure, mostly for storage purposes and the
> intelligence to read/process it is mostly outside the file, in the human
> reader, the compiler or the binary). What Leo does is to create
> self-referentiality in the world of everything is a file by introducing
> outlines that can talk/structure the files and that can talk about
> outlines, i.e outlines that can talk about files and about themselves
> and can reprogram the way Leo itself works, and so Leo is bridging the gap
> between objects and files in a valuable and unique way. But we need still
> to improve, specifically we need a more elegant way to talk about that
> files, specially about their changes in time, because is in that change
> where talking with the distopic world has more problems and
> possibilities, and that way I'm making the Fossil/VCS experiment and also.
>
> To me, the key enabler for that is "everything as a file". . .
>
> For me the enabler is self-referential meta-structure
>
I don't see any conflict between the two, IOW no inherent limitations to
"everything is a file" other than (to me, at least within the personal-use
prototyping context) unimportant factors like relative speed/scaleability -
it's "just" an implementation detail.
The various levels of structural overlays as presented within Leo as
"uber-manager of the metadata" can be as flexible and complex as can be,
and still be stored/distributed as diffed/versionable/convertable files at
whatever appropriate level of granularity to support integration with
outside toolchains. To the extent design choices are made that "lock in" to
a particular "higher level" technology bet, e.g. a specific database engine
or DVCS, then much higher-level programming/sysadmin skills are required in
order to integrate Leo into the thousands of mainstream tools that have
evolved over time to support structured-plain-text.
Look at source code - after all these decades, it's still stored as plain
text in a filesystem. There's a reason for that - any language that
required its modules/functions/objects whatever to be stored in a
"proprietary" database engine for example would have very limited uptake,
because coders would have to put so much effort into infrastructure
overhead work to be able to keep working with their preferred toolset.
Anyway 'nuff said on that.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/l3QdmB7YC8YJ.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
