a more controversial suggestion?
Peter Bienstman
Would it be possible to also allow the @tags as the first line in the
node body, as opposed to just in the headline?
The reason I'm asking is that right now in my case 40% of all
information in the tree outline is not really relevant and distracting
(all the @shadow tags).
By moving these tags to the first line of the body, we can concentrate
more in the outline on what is really relevant, as opposed to storage
technicalities.
I don't know anything about the internals of Leo to be able to judge
the ramifications of this, but my naive guess would be that the
following algorithm would work:
* if there is @ in the headline, keep the old behaviour (backwards
compatibility)
* if not, look at the first line of the body for an @ directive
What do people think?
Peter
Kent Tenney
+1
>
> Peter
> >
>
Edward K. Ream
<Peter.B...@ugent.be> wrote:
> Would it be possible to also allow the @tags as the first line in the
> node body, as opposed to just in the headline?
You are talking about Leo directives. It is indeed possible to define
your own directives, but I am not enthusiastic about defining @thin,
@file, @shadow, @auto, etc in body text. These are extremely
important markers and should not, imo be hidden.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > Would it be possible to also allow the @tags as the first line in
> > the node body, as opposed to just in the headline?
>
> You are talking about Leo directives. It is indeed possible to define
> your own directives, but I am not enthusiastic about defining @thin,
> @file, @shadow, @auto, etc in body text. These are extremely
> important markers and should not, imo be hidden.
A similar issue came up with "@url". Rather than see
+-@url http://blah.blah.net/
+-@url http://blah.blah.net/
+-@url http://blah.blah.net/
I wanted to see
+-Site name
+-Site name
+-Site name
and got there with the @bookmarks node type
+-@bookmarks
+-Site name
+-Site name
+-Site name
where the url was the first line of each node.
But for @shadow et. al implementation would be a big deal, I think.
What might be easier is formatting the text of the nodes so that it
still says
@shadow myFile.py
but "@shadow" is in a lighter colored smaller font, and myFile.py is in
the normal darker larger font.
This could also be a big deal implementation wise, but not likely to
mess up a tricky and important mechanism like the @file nodes.
An interface could even render "@shadow myFile.py" as
"<icon indicating @shadow> myFile.py" such that the icon is shown
unless you're editing the node head string, in which case you see
"@shadow myFile.py" as usual. That's probably more doable and more
appealing than the font formatting idea above.
Cheers -Terry
Peter Bienstman
> "<icon indicating @shadow> myFile.py" such that the icon is shown
> unless you're editing the node head string, in which case you see
> "@shadow myFile.py" as usual. That's probably more doable and more
> appealing than the font formatting idea above.
Peter
Peter Bienstman
> You are talking about Leo directives. It is indeed possible to define
> your own directives, but I am not enthusiastic about defining @thin,
> @file, @shadow, @auto, etc in body text. These are extremely
> important markers and should not, imo be hidden.
People who like to focus on the contents, as opposed to the
technicalities of the storage, could benefit from such a change.
Peter
Randy Kramer
Randy Kramer
--
"I didn't have time to write a short letter, so I created a video
instead."--with apologies to Cicero, et.al.
billp9619
text given in the body.
Any editing would need to switch to the "real" node text (besides just
different syntax coloring).
Likewise, I would like to be able to express user attributes in the
body as directives, so that they are more accessible to non-technical
users and also that they could be exported to the MORE format.
bill p
On Aug 22, 9:21 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> On Fri, Aug 22, 2008 at 11:08 AM, Peter Bienstman
>
Edward K. Ream
> Likewise, I would like to be able to express user attributes in the
> body as directives, so that they are more accessible to non-technical
> users and also that they could be exported to the MORE format.
It is possible for a plugin or script (including @button and @command
scripts) to add entries to g.globalDirectiveList. This tells Leo to
write such lines as special sentinels when writing to derived files.
This will work, I suppose, provided that the new directives don't
conflict with any Python decorator.
In general, though, I don't recommend this approach. Another approach
would be to define your own special kind of comment, like Emacs and
vim do. Depending on what you are trying to do, it might make sense.
Clearly, your options are limited if you are going to write MORE files.
Edward
Terry Brown
billp9619 <bill...@gmail.com> wrote:
> My thought would be to have the headline remain as it is but display
> text given in the body.
I think there's a possibility for customizing the presentation of
headlines - as long as the "real" text is always loaded into the widget
when you go to edit mode, what the widget actually displays in
"navigation mode" should be fairly flexible.
There's some potential for confusion if someone's writing a script to
find the node "some.py", and the script refuses to work even though the
scripter can see the node write there, because as far as Leo's
concerned the node is "@shadow some.py". But I think most people would
resolve that kind of thing quite quickly.
> Any editing would need to switch to the "real" node text (besides just
> different syntax coloring).
I'm guessing by "syntax" you mean "highlight" in this instance? I.e. a
headline being edited has different highlighting etc. - but would also
need to switch to the real text - I think this is doable.
ALTHOUGH - for some reason my experiments with the override of
setUnselectedHeadlineColors etc. that exist in cleo were failing
because w.delete('1.0', Tk.END) didn't seem to do anything.
Cheers -Terry
Edward K. Ream
> ALTHOUGH - for some reason my experiments with the override of
> setUnselectedHeadlineColors etc. that exist in cleo were failing
> because w.delete('1.0', Tk.END) didn't seem to do anything.
w.delete deletes only the text on the screen. You must also tell Leo
that corresponding body text has changed. Ville asked about this
recently in another context. You have to call something like
onBodyChanged or p.setBodyString.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > ALTHOUGH - for some reason my experiments with the override of
> > setUnselectedHeadlineColors etc. that exist in cleo were failing
> > because w.delete('1.0', Tk.END) didn't seem to do anything.
>
> w.delete deletes only the text on the screen.
That was the only text I wanted to change.
Tk.Text.delete(w, 1.0, Tk.END)
print 'Y',w.get("1.0", Tk.END)
w.insert("1.0", p.headString().replace("@test ", ""))
print 'X',w.get("1.0", Tk.END)
etc. - the 'Y' print statement always showed the original headString in
full, I retried various permutations:
Tk.Text.delete(w, "1.0", Tk.END)
w.delete("1.0", Tk.END)
etc. - the insert also had no effect.
Cheers -Terry
Terry Brown
headline of all the @shadow nodes (ditto for @file, @url, @auto,
etc.). I would certainly prefer not to see it, and it seemed that the
approach of having headStrings rendered as
<icon indicating @shadow> file.py
until you tried to edit them, in which case the real text would appear,
was an easy way to get there. I think the other approach was to put
the @shadow directive in the bodyString, but Edward didn't like that?
I'm not keen on that either, it just moves visual clutter from one
place to another.
Anyway, cleo overrides setUnselectedHeadlineColors which should be a
good place to try this, but for some reason my attempts to change the
text widgets content are failing. The outline is just 10 nodes which
all say "@test text". Here's my experimental code:
Tk.Text.delete(w, 1.0, Tk.END)
Tk.Text.delete(w, "1.0", Tk.END)
w.delete("1.0", Tk.END)
print isinstance(w, Tk.Text)
print type(w)
print 'Y',w.get("1.0", Tk.END)
w.insert("1.0", p.headString().replace("@test ", ""))
print 'X',w.get("1.0", Tk.END)
w.configure(state="disabled",highlightthickness=4,
highlightbackground='black', fg=fg,bg=bg)
I know it's affecting the widget (w) because all but the current node
are rendered with a 4 pixel black border. So the codes working and
active. The isinstance print prints 'True', although the print type(w)
prints 'instance'.
But both the 'Y' and 'X' prints print '@test text', i.e. the delete and
the insert methods silently do nothing. How can that be?
Cheers -Terry
Edward K. Ream
> Recall the discussion about not showing the "@shadow " text in the
> headline of all the @shadow nodes (ditto for @file, @url, @auto,
> etc.). I would certainly prefer not to see it, and it seemed that the
> approach of having headStrings rendered as
>
> <icon indicating @shadow> file.py
>
> until you tried to edit them, in which case the real text would appear,
> was an easy way to get there.
I am not a big fan of icons for important stuff.
> But both the 'Y' and 'X' prints print '@test text', i.e. the delete and
> the insert methods silently do nothing. How can that be?
What is 'w'? Are you sure that it is the same as c.frame.bodyCtrl?
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> What is 'w'? Are you sure that it is the same as c.frame.bodyCtrl?
I don't think so, it's one of the headline widgets in the tree panel.
Struck me as odd at first that those are Tk.Texts but makes sense I
guess. Anyway, I'm sure it's the right widget because the adjustments
to the border manifest.
Cheers -Terry
Edward K. Ream
>
> On Sun, 7 Sep 2008 16:16:14 -0500
> "Edward K. Ream" <edre...@gmail.com> wrote:
>
>> What is 'w'? Are you sure that it is the same as c.frame.bodyCtrl?
>
> I don't think so, it's one of the headline widgets in the tree panel.
Then it won't stick when the tree is redrawn unless you take care.
You could try just doing p.setHeadlineString(), but that probably
won't work if you are editing the headline. You might have better
luck with c.frame.tree.setHeadline(p,s)
Edward
Edward K. Ream
You probably should look at (or trace) these methods:
Code-->Gui Base classes-->@thin leoFrame.py-->class leoTree-->Must be
defined in base class-->head key handlers (leoTree)
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> >> What is 'w'? Are you sure that it is the same as
> >> c.frame.bodyCtrl?
> >
> > I don't think so, it's one of the headline widgets in the tree
> > panel.
>
> Then it won't stick when the tree is redrawn unless you take care.
Actually I think it will stick, or at least appear to stick, because
setUnselectedHeadlineColors is called for every drawing of a headline.
The problem was why .delete and .insert seems to have no impact at all:
Tk.Text.delete(w, 1.0, Tk.END)
Tk.Text.delete(w, "1.0", Tk.END)
w.delete("1.0", Tk.END)
print isinstance(w, Tk.Text)
print type(w)
print 'Y',w.get("1.0", Tk.END)
w.insert("1.0", p.headString().replace("@test ", ""))
print 'X',w.get("1.0", Tk.END)
The 'Y' and 'X' prints always print '@test text', whereas I'd expect
them to print '' and 'text' respectively.
However some of the other functions you pointed out are probably more
appropriate than setUnselectedHeadlineColors for this styling, so I'll
look at those.
Cheers -Terry