*checks pocket, finds 2 cents* There's a tension between wanting Leo to gain widespread appreciation and making changes which Edward doesn't consider important. Understandable, Edward has a different relationship with Leo than others.
>I wrote Leo for my own uses, primarily to aid the design, >construction and understanding of complex computer programs >such as Leo itself. It's great if other people use Leo for other purposes, >but I feel no obligation to refocus Leo to such purposes. And he shouldn't feel an obligation, but maybe acknowledge that reaching a wider audience might involve some refocusing. >construction and understanding of complex computer programs Core to this is *clones*, Edward leverages their power brilliantly, I'd be curious how many others are as wed to them. I'm reminded of a developer opining against sophisticated IDEs, he thought they made it *too easy* to manage complexity, resulting in code which was too complex. Using an simple editor tends to enforce smaller files, simpler classes, shorter methods. The need for clones is one of those perennial debates, but I think it may be germane to this thread. As far as branding, direction, that sort of thing, I see Leo as a tool to manage data: nodes, trees, graphs: reflecting the structure of the data whether a file or class (or method, if you're using sentinels) or another representation of structure as defined by a file type, or generated by the user in native nodes. (the degree of structuring is something I sometimes find bothersome, hence my interest in <alt-x>vim-edit-file) So Leo is brilliant at grokking data, wait a second, grokking data is all anyone talks about these days. >From here on out it's pretty hand-wavy, pioneery, envisioning capability which doesn't really have an analogue. Put a database behind Leo, structured according to schemas defining node, file, tree, user, permissions, version etc. Make the database network accessible, not necessarily cloud, but available across machines. Allow me to view and or edit a subtree which Edward commited to the database. Allow me to generate a Leo file from the database resulting from a query, offering a structured view of the data I'm interested in. Maybe generate a file based on the wonderful APIs offered by http://sunlightfoundation.com/ where top level nodes would be 'Senate' 'House' 'Executive' and 'Judiciary', they would be populated (on demand) by the available stats. Create a node 'Tammy Baldwin' dclick, see her voting record, contributers etc. Given adequate perms, make a correction, addition: alerting the stewards of that content. Click to populate a Leo file with the available wifi networks, showing attributes of each in a subtree. On and on. Thanks, Kent On Tue, Aug 18, 2015 at 10:40 AM, Edward K. Ream <[email protected]> wrote: > On Mon, Aug 17, 2015 at 8:17 PM, David McNab <[email protected]> wrote: >> >> I agree - Leo is probably way more than 100% feature-complete. It's also >> been a tremendous comfort to me and my solo programming efforts over the >> years. > > > Glad to hear it. > > >> However, Leo is still imprisoned in the >> standalone-software-installed-on-desktop paradigm, and thus stuck in a >> rapidly-disappearing era. > > > Yes, web-based services are increasingly important, but unless I am greatly > mistaken most programmers still use laptop and desktop computers and Emacs, > vim, Eclipse and the like. > > I don't see that changing anytime soon, and if it does change it will likely > be the result of tools that don't yet exist. Furthermore, security problems > are troubling with any web-based tool. > >> The biggest problems I've had with Leo to date have been: >> >> Gaps in backward incompatibility - serious corruption and data loss issues >> when editing years-old Leo files, something which has tripped me up many >> times > > The work around is to use the old versions of Leo to recover the data, then > copy and paste to a newer version of Leo. I have no plans to retrofit any > further backward compatibility code. > > >> >> Incompatibility with team environments - inability for more than one >> developer to work on files at once >> I can't use Leo on my tablet or smartphone, unless I screenshare in to a >> desktop running it. Unless the tablet is on a LAN near the desktop, and has >> a 10" screen, this is unworkable. > > > Supporting tablets or smartphones requires support for Python and PyQt on > those platforms. Iirc, Ville created a Leo reader for Android, but I could > be mistaken >> >> >> I would suggest that Leo's future lies in a complete rebuild, cloud from >> the ground up. Firstly, a decent API into a cloud-based Leo engine. >> Secondly, decent GUI clients on Web (Ember.JS? Pyjamas? AngularJS?) and >> Android/iOS. > > > What to say about this... > > Perhaps the best analogy for this kind of product is the split of IPython > into the Jupyter project: https://jupyter.org/ > > The IPython/Jupyter project is one of the most successful Python project in > existence. It has received millions of dollars of research funding over the > years, including a large recent grant of over $6 million, iirc. > > There is a huge amount of engineering in this project--far beyond my > ability. In particular, I call your attention to the security model. It's > crucial for this project, and it's crucial that it be absolutely solid. I > am not in a position to undertake any kind of security-related code. > > In theory, one could imaging forking IPython/Jupyter into a Leo-centric > project, but forking other people's projects seldom ends well. And I don't > have any energy for this. > > Alternatively, one could imagine trying to convince the Fernando Perez to > add Leonine feature to Jupyter, but I would not be interested if I were he > :-) There's too little overlap of purposes. > >> The cloud-based paradigm, for me, would do away with the concept of a leo >> "document". Instead, it would focus on a 'view', which may contain one or >> more nodes. Nodes would exist outside of views, and be able to reference >> other nodes recursively. > > > Not a bad idea, but I have no magic wand to make it happen. > > >> The APIs could then be supported by widgets in the main client-side >> toolkits, to allow web apps to embed Leo editing widgets with ease. >> >> Files are where it gets tricky. Non-Leo-users absolutely detest the Leo >> sentinels. But updating a node tree to reflect changes in a file outside Leo >> is a programming task beyond merely painful. > > > And other people's files are what make security so important. > > Weren't you the one who pointed this out years ago? Or maybe it was Paul > Patterson. >> >> However, if Leo is >> made to be as team-friendly as Google Docs (where you can even see >> teammates' cursors in different colours moving around the document), there >> will be virtually no need to edit files from outside the Leo environment. >> >> >> Again - desktop is dying. Leo has to go cloud! > > > Desktops aren't dead yet, and won't likely fade away until well after I > personally am gone. > > I will consider porting Leo in the cloud when easy to use tools for doing so > exists. I don't believe I will long enough to move Leo to the cloud with > the existing tools. > > Edward > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
