hack: Canonical outline so UNLs don't break
HansBKK
mdb
created and modified tags (attributes).
With this idea, you would create the node in a tree position, and then
use an alternative view and ordering of nodes based on the dates, and
any editing from this view would show correctly in the regular tree
view .
Here is a possible alternative 'view'
Headline vnodeID Date created Date Modified
Node1 xxxxx 12/7/2011 12/8/2011
Node2 xxxxx 12/8/2011
Might also add columns with
Clone Mark (Yes/No) Parent node, Number of Children, Language, Body
Size
> leo-screen1.png
> 15KViewDownload
HansBKK
I wasn't actually interested in the creation data as data, it's just a means to assign an arbitrary value that isn't going to change - the headline string is just a temporary placeholder, possibly to be pasted within the body if it's relevant.
Re your implementation - are you referring to using what I call Leo's "internal meta" data structures (p/t/v whatever, all greek to me) ?
It's true the cloning mechanism is also based on "internal meta" - ideally I'd prefer something actually stored (ideally discreetly) in my plaintext content, but at least the clone mechanism is clearly visible and open to manipulation in Leo's UI without programming; I don't know from python.
I've seen reference to a type of "tagging" using those internal meta data, but have no idea how to implement that. I do plan to investigate other tagging implementations, particularly in finding a migration path for my 20K+ bookmarks currently hostage to the vagaries of del.icio.us - I believe the most "mainstream" method at this point uses the quickmove plugin? And I'm assuming that also uses cloning. . .
Finally, in this case my primary objective is to ensure tree-path stability for UNLs - does your proposal accomplish that?
HansBKK
I've just begun browsing the wiki, and came across this (I've seen it elsewhere as well)
> A dangerous delete is a deletion of a node so that all the data in the node is deleted everywhere in an outline. The data is gone, to be retrieved only via undo or via backups. It may not be obvious which deletes are dangerous in an outline containing clones. Happily, there is a very simple rule of thumb:
> Deleting a non-cloned node is *always* dangerous. > Deleting a cloned node is *never* dangerous.
A side benefit of the SOP I outlined is preventing accidental "dangerous" deletions - all important content is already cloned as of creation time. Actually deleting the last instance of a node requires an extra step, and a somewhat inconvenient one at that, and in fact the only reason I can think to do so is to save disk space, which I think unlikely to be a real issue for most.
----------------------------------------
Side note - the Wiki contains quite a bit of outdated information. I'd be happy to volunteer to clean it up in those areas I'm au fait with, but as of yet have no idea what terms like @root, tangling etc might mean in the context of the current version.
I could post for clarifications here in order to do so, but fear I've stepped over the verbosity edge, I reckon a few of you probably feel I'm already hogging bandwidth on the list. If there is someone who has some level of "ownership" over or at least interest in the wiki's content who would be willing to exchange say one daily email from me with a specific question or two, I'll take it on as a project to get the wiki up to date best I can. Of course it might just be more efficient for someone more knowledgeable than me to just go through and clean it up herself, whatever works. . .
If not, I'd question the rationale behind having it at all, as there seems to be a reasonable amount of decent docs on the website and the .leo files, and at least they have "owners" who try to keep them current.
mdb
- versus using descriptive titles -- would not help most people better
understand the document or the process that the outline represents or
organizes.
Leo lets you embed custom created attributes to each node, besides the
title and body text, but this takes some programming and LEO
experiences. Trying to get around the programming by embedding
attributes or tags in the title is probably a dead end -- at least for
developers that want greater power and flexibility. Data 'stored
(ideally discreetly) in my plaintext content' is inferior to data
stored internally that can be displayed and accessed anyway you want
it. I.e. you will have a had time convincing a programmer to use the
less-than-the-best tools available for the job.
I suggest working through a python tutorial. It sounds like what you
need are programming scripts to pull out and re-use/re-format data
from '20K+ bookmarks currently hostage to the vagaries of
del.icio.us'. Sounds like a perfect job for a program-- not manual
manipulation.
My favorite Python book
The Quick Python Book by Daryl K. Harms and Kenneth M. McDonald.
Second edition by Vernon L. Ceder
See http://www.manning.com/ceder/
And there are numerous online tutorials. Google search 'Python
tutotial' and see http://wiki.python.org/moin/BeginnersGuide/NonProgrammers
Another option is to 'contract' out the work. You just need to
describe the job well and be very specific about the output you
expect. There are numerous sites devoted to freelance
programming.
Terry Brown
mdb <mdbo...@gmail.com> wrote:
> It sounds like what you
> need are programming scripts to pull out and re-use/re-format data
> from '20K+ bookmarks currently hostage to the vagaries of
> del.icio.us'.
del.icio.us only ate about 30 bookmarks of mine, but that was enough to inspire
http://groups.google.com/group/leo-editor/browse_thread/thread/b17d140b7ceb8fc9
Cheers -Terry
HansBKK
> I think your SOP to give headlines titles that are just Dates+Time --
> - versus using descriptive titles -- would not help most people better
Yes, perhaps I should have just used "node A" "node B". In my case I'm
also planning a "journaling" tree, which will basically clone the
"canonical" tree, but only include that subset of the nodes that fall
into "talking to myself / misc analysis / stream of consciousness"
that I'm currently doing with RedNotebook.
> Leo lets you embed custom created attributes to each node, besides the
> title and body text, but this takes some programming and LEO
> experiences. Trying to get around the programming by embedding
> attributes or tags in the title is probably a dead end -- at least for
> developers that want greater power and flexibility. Data 'stored
> (ideally discreetly) in my plaintext content' is inferior to data
> stored internally that can be displayed and accessed anyway you want
> it. I.e. you will have a had time convincing a programmer to use the
> less-than-the-best tools available for the job.
Of course everything you say is true - but relevant to programmers.
It's obvious that Leo is primarily targeted to that context, but I
would argue that its potential is no less revolutionary out in the end-
user world, and that is where my interest lies. For example, I am a
teacher, and would love to have my students learn to organize their
thoughts for essay writing in Leo, getting beyond the usual outlines
method I learned from Mrs Arbuckle in the third grade.
And my own use-case, managing single-source lightly-marked-up
plaintext for output to various publishing formats, while more
technical, is also not an area limited to programmers only, and Leo
seems (so far to me) to have the potential to be a best-of-breed tool
in that arena as well.
> I suggest working through a python tutorial. It sounds like what you
> need are programming scripts to pull out and re-use/re-format data
> from '20K+ bookmarks currently hostage to the vagaries of
> del.icio.us'. Sounds like a perfect job for a program-- not manual
> manipulation.
I wasn't planning on doing anything manual with that data set believe
me. On the other hand I **don't** want it to end up stored in yet
another opaque format. I intend the end result to be lightly-marked-up
plaintext files in a dirstruc, most likely OPML. Of
Leo is just one possible element of the toolchain, the data is stored
as XML and also in SQLite DBs, so more mainstream import/export/
reporting/data conversion tools exist - the only difficult piece I see
is if I decide to try to preserve my "tag bundles".
As with any such project, if I can accomplish what I'm trying to do
without having to become a programmer I will, as unfortunately my
current situation doesn't give me that much free time.
Thanks very much for the learning Python resources, and I'm sure if I
stick it out with Leo I'll continue to be nudged in that direction,
and maybe before I get too old and doddery I'll have the time to dig
in. . .
> Another option is to 'contract' out the work. You just need to describe the job well and be very specific about the output you expect. There are numerous sites devoted to freelance programming.
If I had the money to pay someone to do it for me, I'd invest it in
"free time" to learn how to do it myself. In my introductory thread I
ended with
> If I were rich I'd learn to become a programmer
To Terry - believe me I'd already got excited by that post, it's been
tagged as 2followUp in delicious, which I will do once my basic Leo
knowledge is in place. Thanks much for the encouragement to me, as
well as of course all your contributions to the community.
Edward K. Ream
>> I propose a "canonical tree", which is simply
>> structured by date - YYYY / MM / DD (possibly HHMM, but I wouldn't). All
>> content gets created there as nodes there first, and that location never
>> changes. Clone nodes from there to "where they belong", by topic, function
>> whatever, but always us the master hierarchy location when creating UNLs.
There are many interesting ideas in this thread. Many thanks for your remarks.
A few quick comments now. More later.
1. All Leo nodes have a "gnx" (Global node index) that is guaranteed
to be immutable and unique. It is easy to access a node's gnx, using
p.gnx.
2. I had forgotten about AutoHotKey. Using it is a clever solution
for non-programmers. Nothing to apologize about. However, Leo's own
scripting language is considerably simpler for programmers.
Edward
HansBKK
> There are many interesting ideas in this thread. Many thanks for your remarks.
And thank you for your patience as I continue to clarify my needs and
goals with Leo - I hope to take advantage of the tool's flexibility to
be able to "push the envelope" toward more functionality for and
usability by non-programmers.
I realize my needs are edge cases relative to the current typical Leo
user, but ATM I'm looking at it as a black box, a processing and
organizing tool **between* the specific endpoints outlined at the end
of this post. At every point in it's journey from one stage to the
next, the data must remain (a huge pile of) lightly marked-up
plaintext.
I am realistic in that I and our users are not creating many
"finished"/published large works, 99% of the data will remain "in the
process" of being added to, incrementally better organized, re-
drafted, but used for our own reference as a somewhat chaotic but
nonetheless valuable knowledge base.
My goal is to recognize that both myself and Leo won't be around one
day, to create a knowledge management/processing system contingent on
the working premise that either or both can disappear **at any given
point in time** without affecting the "fully open and transparent"
nature of the data itself; it should remain at every stage fully
accessible and usable to other relatively non-technical writers/
readers/editors/format-processors, and whatever common tools they are
familiar with.
I **do not** want Leo's XML to become "yet another storage format" for
anything other than temporary working data for a specific transform
process, because then the usability of the data itself becomes
dependent on that specific tool. I would also prefer use relatively
simple and open transform methods
> 1. All Leo nodes have a "gnx" (Global node index) that is guaranteed to be immutable and unique. It is easy to access a node's gnx, using p.gnx.
Easy - for programmers.
>> "internal meta" data structures (p/t/v whatever, all greek to me)
>> I'd prefer something actually stored (ideally discreetly) in the plaintext content
>> clearly visible and open to manipulation in Leo's UI without programming; I don't know from python.
UNLs seem to be a better fit for my needs at the moment.
> 2. I had forgotten about AutoHotKey. Using it is a clever solution for non-programmers. Nothing to apologize about. However, Leo's own scripting language is considerably simpler for programmers.
Yes - for programmers.
==============================
What follows is simply repetition and clarification of my current
specific use case - feel free to skip.
Stage A - a huge pile of lightly marked-up plaintext data
This requires continuous editing and markup, transforming over time
into better structured "single-source master" - stage B - plaintext
data. By better structured, I mean containing markup that allows for
things like internal cross-references, footnotes and glossary entries,
and most importantly, topic indexing, both for traditional end-matter
indexes and (somehow) backlinking "anchors" visible to the reader
close to the inline source content to show what terms apply to the
current "chunk" of text - AKA "tagging".
Another aspect is the granularity of "chunking" for content re-use,
the ability to create different entry points and navigation paths
through the content for different context/purposes, e.g.
- intro/overview for noobies vs systematic reference for experts vs
specific howtos, tips, FAQs
- different product/software versions
- core vs plug-ins
- business rules vs user input vs presentation formatting
I then want to be able to (relatively automagically) process these
texts into various output target publishing formats, getting as much
of the above functionality as possible out of each output structure.
Examples - DocBook XML, HTMLhelp, EPUB/mobi ebooks, website, PDF and
of course beautifully formatted dead-tree hardcopy - stages C1 to
infinity and beyond.
Matt Wilkie
> this in AutoHotKey - any tool snobs just consider what I've pasted below as
> pseudocode, in the hope that it might inspire or otherwise help someone.
Anyone who can figure out how to write AHK macros can write python
with at _least_ equal facility. Really.
I hear echoes from parts of my own journey in what you've been talking
about. You are clearly an experienced and accomplished technical
person, just not from the same background as most of those in this
room. I too am a squarish peg in a roundish hole hereabouts.
I am not a programmer, though I've been making small movements, slowly
over years, in that general direction. Learning python is truly a joy
compared to the hours and hours I've spent labouring over various
macros in other tools, including AHK. Though on a days when I just
can't understand X I curse it mightily! It's the yearly average I'm
talking about.
I humbly proffer that what you need is to stumble across a python
example of immediate personal utility, solves a real problem you face,
that is also self contained and small enough to grasp in at least it's
broad strokes, and thereby crack the programming wall asunder.
Unfortunately "stumble upon" seems to the operative phrase, at least
in my experience. Still, this project has the kind of environment
where such happy accidents do in fact happen. :)
cheers,
--
-matt
Offray Vladimir Luna Cárdenas
First Hans, is really nice to read your interaction here. We need
"newbies" like you. I'm kind of an "old eternal newbie" on Leo, using it
more and more, but without proper knowledge of python or proper
meaningful context to modify it. I'm also primarily a teacher/researcher
and now I believe that I need to create that meaningful context by
making my students to use more Leo explicitly. I tried once before but
installation of a non-stable version went wrong and I have not a
compelling user story yet to create that context with my undergrad
students. Now I have it. I'm writing myself my Ph.D thesis with Leo and
my students are primary post-graduate students who are also writing
their thesis. So I plan to teach solve with them how to create a
Personal Learning Environment[1] which includes Leo as a tool for their
thesis and so they can take advantage of the several layers of depth
that a tool like Leo can bring to the writing experience and export
their work in common formats like pdf or libreoffice's. Because their
context is different of mine (they primary use Windows and I use
Gnu/Linux) this gap creates a proper teaching/learning opportunity for
us. I think that we're alike in our interest with teaching, writing and
a non-programmer background, and of course, we have differences also. I
would like to comment your post taking that into account.
[1] https://en.wikipedia.org/wiki/Personal_learning_environment
On 12/10/11 17:59, HansBKK wrote:
>
> I realize my needs are edge cases relative to the current typical Leo
> user, but ATM I'm looking at it as a black box, a processing and
> organizing tool **between* the specific endpoints outlined at the end
> of this post. At every point in it's journey from one stage to the
> next, the data must remain (a huge pile of) lightly marked-up
> plaintext.
For me lightly marked-up text is also the key for data sharing and
editing with other people who are not Leo users. I would prefer txt2tags
markup over others because of lightness and easiness to learn and to
create custom exporters, but the of support for references (footnotes,
biographical data and others) keep me in reStructuredText which is still
nice with some minor glitches solved by Leo (like underline as a markup
indicator). So reST will be my format for writing text in various
infrastructures and exporting from it to several formats That being
said, the more I live in Leo, the more I see plain text with markup and
files in general as a "degradation" of the meta-structure that Leo
provides to the plain files world. Now I'm trying to add even more
structure to that flat-word with Leo + Fossil. The first one gives files
flat word structure in space, the second one in time. I don't see myself
going back to flat world, but I know that I need to communicate with
people who is still there, so I degrade the Leo metastructure to this
kind of minimal comfortable standard for communication.
>
> My goal is to recognize that both myself and Leo won't be around one
> day, to create a knowledge management/processing system contingent on
> the working premise that either or both can disappear **at any given
> point in time** without affecting the "fully open and transparent"
> nature of the data itself; it should remain at every stage fully
> accessible and usable to other relatively non-technical writers/
> readers/editors/format-processors, and whatever common tools they are
> familiar with.
>
[...]
> I **do not** want Leo's XML to become "yet another storage format" for
> anything other than temporary working data for a specific transform
> process, because then the usability of the data itself becomes
> dependent on that specific tool. I would also prefer use relatively
> simple and open transform methods
My approach is different. I think that Leo, like Smalltalk, is trying to
solve a fundamental problem in dealing with computers and both will be
around for long time (well Leo has a less prominent users/mind-share so
it could be less likely to survive, but I don't think so). The problem
is that most people see or use the "degraded" flat world. And that
brings a related problem: how to communicate with that world and how to
make more people use and understand the meta-structure of non-flat world
and move to that place. Trying to put metadata on flat-world and make
connections on it, would be almost as reinventing Leo or xml (which, by
the way I don't like either) or adding a lot of helper files to put
metastructure in flat files, and still you would lose the viewing
capabilities of trees, seeing only the "flat leafs of files". So how
that potential users who would come after you or me, and who are
unfamiliar with Leo will deal with the advantages that Leo provides
while make connections with their tools/data? This for me is related
with the context where that users will find Leo and that possible
connections. The immediate one for me is the classes of next semester in
which I will try to make a better encounter of new Leo users and develop
that potential and document the experience. I have thought in future
problems/opportunities of this scenario, this are some of them:
a. Installing Leo, which is specially difficult for non-programmers like
my students. I will try to prepare my classes dealing previously with
that problems using alternative installing strategies not found here
until now like pyinstaller[2] and/or Zero Install[3]
[2] http://www.pyinstaller.org/
[3] http://0install.net/
b. Integration with external file systems, specially the ones that
produce pdf output like LaTeX/MikTeK or rst2pdf and the ones that deal
with versions; for that one I will use fossil SCM.
I imagine a world where deconstructing textual computer interaction the
Leo way would be the standard. We're far away, specially with Leo
self-fulfilled prophesy of being a developer's tool for developers, but
carrying Leo to new contexts will be a way to explore the path to
futures like that one.
I will keep you posted.
Cheers,
Offray
HansBKK
Your message was a nice holidays present for me, thank you.
On Wednesday, December 28, 2011 11:59:54 PM UTC+7, Offray Vladimir Luna Cárdenas wrote:
Personal Learning Environment[1] which includes Leo as a tool for their
If not I think you will need to provide a "canned" pre-installed environment (see below), including pre-populated .leo files, along with some detailed how-to's and examples to get them started, if at all possible actually walking them through hands-on demos with them following on their own desktops. Is it a big group? Do you have access to a computer lab?
Without such hand-holding you might get some blowback over "forcing" them to use a tool with such a steep learning curve.
Maybe even if they are CS such an approach would IMO probably be a good idea.
For me lightly marked-up text is also the key for data sharing and editing with other people who are not Leo users. I would prefer txt2tags
markup over others because of lightness and easiness to learn and to create custom exporters, but the of support for references (footnotes, biographical data and others) keep me in reStructuredText which is still nice with some minor glitches solved by Leo (like underline as a markup indicator). So reST will be my format for writing text in various infrastructures and exporting from it to several formats
Note I'm only using txt2tags for the "snippet/chunk" level, it converts to AsciiDoc once the topic domain becomes a target for a large structured work - in real-world terms, when you get beyond a collection of articles and want to compile something approaching a book.
There really isn't any downside to using Leo to manage whatever arbitrary markup, text is text after all. Using independent tools to assist with writing the codes and to generate previews is just "nice to have", not necessary. And keyboard macros, scripts that snap-convert @ <file>s to html with scripting is easily done at the OS level and integrated with Leo. I hope to figure out how to render node content directly, independently of @ <file> output, but that's just a convenient gee-whiz maybe-one-day possibility.
That being said, the more I live in Leo, the more I see plain text with markup and files in general as a "degradation" of the meta-structure that Leo provides to the plain files world. Now I'm trying to add even more structure to that flat-word with Leo + Fossil. The first one gives files flat word structure in space, the second one in time. I don't see myself going back to flat world, but I know that I need to communicate with people who is still there, so I degrade the Leo metastructure to this kind of minimal comfortable standard for communication.
However I do need to dispute your use of the term "flat" - the output formats allow for different sequence "views" for different purposes and audiences, each with their own linking ToC's, extensive cross-reference hyperlinking, including to and between glossaries, multiple topic indexes (tag pages) etc. as well as of course external citation and live-link URLs. A well-designed CHM file or Tiddlywiki is much more useful than dead-tree hard copy, and in fact I would argue much more useful than a .leo file in most contexts.
BTW please post some details as to how you're implementing such cross-reference links and or tagging views, I'm not currently implementing these within Leo, only in the target output, via "snippets" interleaved with the main source texts.
Keeping the master source data as easily-accessible plain-text is essential to me, and not because I think Leo will disappear. Or at least I know it will, just as I will too one day, but that's not the main reason. The more immediate reality is that I'm only actively re-working a tiny fraction of the data at a time, and often leave off from one topic area and move on to another without "finishing", i.e. generating polished output to a target format. In the meantime, all of the content needs to remain readable and open to others and whatever tools they use.
By the time I get back to a given topic domain (set of folders), it is likely some elements of my toolchain has changed, or perhaps other developers/content editors need to be able to pick up where I left off, and I'm not in a position to dictate tool choices to them.
a. Installing Leo, which is specially difficult for non-programmers like my students. I will try to prepare my classes dealing previously with
that problems using alternative installing strategies not found here until now like pyinstaller[2] and/or Zero Install[3]
Get both a regular Python installation (say to C:\Python27\) and "Python portable" installed to an external hard drive (for me "E:\PortableApps\Common\Python27). Use whatever recursive diffing tool you prefer (mine is winmerge) to get the two trees in sync, apparently wiping non-matching .pyc files is fine, confirm everything is OK on both trees - best to confirm the portable side by running it on another PC without Python - here's where you create batch files modifying your %Path%, setting %HOME% and others your tools may need (I'm also incorporating cygwin and MinGW for the windoze-native build/compiler toolchain (make will automate my text-processing toolchain).
Now for any pre-requisite packages that don't ship with a "non-installing" zip package (= "portable"), just run the regular .MSI or setup.exe installation routine to your hard-coded python location (C:\Python27) and replicate it over to the portable side with your diff tool.
Since the portable side is the one you'll be working in, keep that as your "master source" for configuration, and remember to keep each side in sync if you update a program on the other.
The portable installation can simply be copied and used to any location on any drive on any other windoze PC. If you're planning on sharing files between the various instances, I highly recommend Unison as a sync'ing tool, in combination with a good diffing tool this will allow any-to-any updating - most manageable via a hub-and-spoke topology, but ad-hoc any-to-any "mesh" is also do-able - they key is doing the sync'ing frequently enough to keep the changeset manageable. And of course you can only merge easily diffable files, which rules out the Leo outlines themselves unfortunately.
Or you could use fossil for managing the program folders as well as the data, why not?
I imagine a world where deconstructing textual computer interaction the Leo way would be the standard. We're far away, specially with Leo
self-fulfilled prophesy of being a developer's tool for developers, but carrying Leo to new contexts will be a way to explore the path to
futures like that one.
However in any context, I believe that communicating complex ideas requires both tailoring the content for, and using an easily accessible carrier medium appropriate to the target audience.
Leo appears to be "the tool" for me ATM for managing my master source data and helping getting it into various target formats, but can't see my way to actually using it as the message carrier medium itself.
But if I'm ever trying to communicate a complex message to programmers, it would be a fun experiment! 8-)
Edward K. Ream
<off...@riseup.net> wrote:
Many thanks for these comments. You have touched on the big picture
of Leo more clearly than I have. It's all too easy to get bogged down
in the minutia: file formats, bugs, commands, etc.
> the more I live in Leo, the more I
> see plain text with markup and files in general as a "degradation" of the
> meta-structure that Leo provides to the plain files world.
This is the heart of the matter. Leo is attempting to raise the level
of discourse, so that structure is first-class (intrinsic) data. But
our existing tools are all oriented to the "degraded" (flat) world.
Thus, Leo must do a lot of heavy lifting in the background. It's easy
to forget that there is something besides the heavy lifting that is
the real point of Leo.
> Leo, like Smalltalk, is trying to
> solve a fundamental problem in dealing with computers...The problem is that
> most people see or use the "degraded" flat world. And that brings a related
> problem: how to communicate with that world and how to make more people use
> and understand the meta-structure of non-flat world and move to that place.
> Trying to put metadata on flat-world and make connections on it, would be
> almost as reinventing Leo or xml (which, by the way I don't like either) or
> adding a lot of helper files to put metastructure in flat files, and still
> you would lose the viewing capabilities of trees, seeing only the "flat
> leafs of files".
This is an excellent summary of Leo's history, and *many* discussions
of sentinels. The inescapable conclusion is that sentinels (metadata)
*must* be part of external files. Or more generally, there is *no*
real possibility of simulating Leo outlines in the "degraded world".
> So how that potential users who would come after you or me,
> and who are unfamiliar with Leo will deal with the advantages that Leo
> provides while make connections with their tools/data?
Leo could survive in two ways. First, as a standalone tool. This may
or many not happen after I am gone. It will depend entirely on Leo's
users.
Second, as something that stimulates better ways of using data. In
this possible new world, the "flat" data would be entirely hidden from
ordinary users; just like assembly language is hidden from C++
programmers, or .pyo files are hidden from ordinary Python
programmers.
Obviously, this new world would require some kind of support *outside*
of Leo. Perhaps some kind of standard for embedding metadata in
(text) files. Perhaps something else. I don't see this happening,
and I certainly am not in a position to make it happen. But it
*could* happen, if the right organization got behind it.
> I imagine a world where deconstructing textual computer interaction the Leo
> way would be the standard. We're far away, specially with Leo self-fulfilled
> prophesy of being a developer's tool for developers, but carrying Leo to new
> contexts will be a way to explore the path to futures like that one.
Exactly.
Edward
Matt Wilkie
> students. I will try to prepare my classes dealing previously with that
> problems using alternative installing strategies not found here until now
> like pyinstaller[2] and/or Zero Install[3]
>
> [2] http://www.pyinstaller.org/
> [3] http://0install.net/
Here is a recipe for how I configure a portable Leo on Windows. It
leverages an environment designed for GIS work and uses a tree
structure similar to linux, so it won't taste right for some. However
it's simple-ish compared to some other approaches and works for me. On
a 7yr old 1.4ghz laptop with a reasonably fast internet connection the
whole thing takes about 15 minutes.
{{{
Download the latest apt-rxx.exe from
http://download.osgeo.org/osgeo4w/release/apt/. If you like rename to
apt.exe. Open a CMD shell and:
SET OSGEO4W_ROOT=D:\portable
apt setup
apt --mirror=http://download.osgeo.org/osgeo4w/testing/ update
apt install shell python pyqt4 sip
Download a Leo snapshot from http://www.greygreen.org/leo/ and unzip
as D:\portable\apps\leo-editor
Run D:\portable\OSGeo4W.bat to update path for the newly installed
python and friends. And now finally:
python apps\leo-editor\launchLeo.py
}}}
There will be a new Start Menu link called "OSGeo4W Shell" which can
be freely deleted. All it does is call D:\portable\OSGeo4W.bat, which
we want to keep, but can be renamed as wished.
The D:\Portable folder and contents can now be moved from computer to
computer or usb stick as desired. For simplicity add "python
%OSGEO4W_ROOT%apps\leo-editor\launchLeo.py" to the end of the
Osgeo4w.bat file in place of "@cmd.exe".
References:
http://trac.osgeo.org/osgeo4w/wiki/pkg-apt/AptFromScratch
http://trac.osgeo.org/osgeo4w/wiki/pkg-apt
--
-matt
Matt Wilkie
> be freely deleted. All it does is call D:\portable\OSGeo4W.bat, which
> we want to keep, but can be renamed as wished.
The `shell` package is the only one which touches the host system
outside the D:\Portable tree. It includes some updates to system dll's
as well as the aforementioned start menu and desktop links. It can be
omitted from the `apt install ...` stage but then you'll need to
create your own batch file to set up the python environment (look at
etc\ini\*.bat).
The upstream project only has python 2.5 & 2.7 at present (not likely
to change for some time).
--
-matt
HansBKK
My more involved scenario above is only needed when maintaining a more complex "portable Python" dev environment, where some packages have Windows-specific tools that rely on the registry and/or environment variables e.g. for auto-updating, cross-app integration like the ipython shell.
And all of this is only to allow for "portable" mode, not at all necessary if you just want to set things up in a fixed location on one machine - just using the regular setup routines provided for Windows is dead easy.