Hi,
El 08/07/11 08:34, Edward K. Ream escribió:
[...]
>
> Many thanks for these links. On my walk yesterday I had many new
> thoughts. One was that Leo's leaders, including you, are likely to
> come up with the way forward. That's been true many times in the
> past: I had a vague idea and so
On Sat, 9 Jul 2011 17:22:22 -0500
Kent Tenney wrote:
> fixed on free_layout, which I think was merged back into trunk, but
> I still get this with current trunk:
>
> "RuntimeError: underlying C/C++ object has been deleted"
It hasn't been merged into the trunk yet.
We need to decide if the gutt
On Sat, 9 Jul 2011 15:01:45 -0700 (PDT)
Largo84 wrote:
> Unfortunately, at least for me anyway, most of the new 'cool' color
> palettes make it more difficult for my old eyes to distinguish
> contrast. Increasing the font size helps in some cases but sometimes
> the font/background color pairs ar
rclick -> remove 1 right:
fixed on free_layout, which I think was merged back into trunk, but
I still get this with current trunk:
"RuntimeError: underlying C/C++ object has been deleted"
Thanks,
Kent
--
You received this message because you are subscribed to the Google Groups
"leo-editor" g
Unfortunately, at least for me anyway, most of the new 'cool' color
palettes make it more difficult for my old eyes to distinguish
contrast. Increasing the font size helps in some cases but sometimes
the font/background color pairs are practically unreadable at all but
the largest font size. Not su
Thanks. Your change eliminated the error message.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups
Hi,
El 08/07/11 08:43, Edward K. Ream escribió:
[...]
>
> Rather, the problem is one of data synchronization. Of source, that
> would be the point of, say, a bzr commit hook: it would ensure that
> "helper" files get committed along with the "main" file.
>
> At first blush, this seems like a s
Hi,
Thanks Edward for your concern on this. I want to know if I have a node
and I want it to be the one that creates external files if they don't
exist (and the proper directory locations) if I must use @file and that
is or there is some other directive and hand that is better for that.
After the
On Sat, 9 Jul 2011 10:29:51 -0700 (PDT)
SegundoBob wrote:
> Whenever I enable the quickMove.py plugin, I get the
> "menu already exists: Move" error message in the log pane on start
> up. Enabling/disabling the quicksearch.py plugin does not affect
> this. I have not noticed any ill affects.
=
Whenever I enable the quickMove.py plugin, I get the
"menu already exists: Move" error message in the log pane on start
up. Enabling/disabling the quicksearch.py plugin does not affect
this. I have not noticed any ill affects.
Version: revision 4413
OS: Ubuntu Studio 11.04 (natty)
Log Pane on
On Jul 9, 4:25 am, "Edward K. Ream" wrote:
> If it's a bug it is a minor one.
OK.
> The workaround is to use the
> double-click-icon-box command. Of course, you will want to bind a key
> to this command.
Thanks.
I discovered another workaround that is probably also a hint to the
minor bug.
S
On Sat, Jul 9, 2011 at 9:25 AM, Edward K. Ream wrote:
> There have been enough comments about Leo's default look to convince
> me that it could be improved. I would welcome suggestions for a more
> uniform/standard look.
>
> The ball is in your court, Amigos.
gpick is pretty cool, generates sets
On Sat, 9 Jul 2011 07:25:17 -0700 (PDT)
"Edward K. Ream" wrote:
> There have been enough comments about Leo's default look to convince
> me that it could be improved. I would welcome suggestions for a more
> uniform/standard look.
Does it need to specify any colors / styling? If as little styl
On Sat, Jul 9, 2011 at 5:25 PM, Edward K. Ream wrote:
> There have been enough comments about Leo's default look to convince
> me that it could be improved. I would welcome suggestions for a more
> uniform/standard look.
I suck at color design, but the trend is currently favoring plain,
spacy U
There have been enough comments about Leo's default look to convince
me that it could be improved. I would welcome suggestions for a more
uniform/standard look.
The ball is in your court, Amigos.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor"
On Sat, Jul 9, 2011 at 9:20 AM, Ville M. Vainio wrote:
> Easy to set up and use completions for normal text and typical
> programming languages. I'm not necessarily saying this should be on
> *your* list, I could start doing it once I have a good uninterrupted
> timeslot available.
Oh joy. Than
On Wed, Jul 6, 2011 at 3:21 PM, Offray Vladimir Luna Cárdenas
wrote:
> I can confirm this bug for 4.8. I lost a lot of @file content in the
> nodes because the external files doesn't exist when I move my .leo file
> to a new laptop.
What you are talking about now is an entirely different bug fro
On Sat, Jul 9, 2011 at 4:53 PM, Edward K. Ream wrote:
> I'd be happy to change the default color scheme. Proposals gratefully
> accepted.
>
> As to the autocompleter, there is nothing left on my list. What
> exactly do you want to improve about it?
Easy to set up and use completions for norma
On Sat, Jul 9, 2011 at 8:08 AM, Ville Vainio wrote:
> What Leo needs to "make it " big time is polish on ui level... well working
> autocompleter etc. Perhaps a more modern color theme.
I'd be happy to change the default color scheme. Proposals gratefully accepted.
As to the autocompleter, t
I think it's a good idea to focus on small things. Leo backend is already
powerful enough for most users, probably more powerful than what average user
will ever need. What Leo needs to "make it " big time is polish on ui level...
well working autocompleter etc. Perhaps a more modern color them
A few weeks ago Kent dropped in on me, and we discussed what's next
for Leo.
At that time I indicated that I thought Leo was essentially complete.
Despite my recent posting about re-visioning Leo, I think what I told
Kent is correct, namely that it would be good to declare a one-year
moratorium on
On Fri, Jul 8, 2011 at 2:18 PM, SegundoBob wrote:
> @url links that invoke the web browser always work.
>
> @url links that should invoke the file browser only work when
> "single_click_auto_edits_headline = False".
>
> When "single_click_auto_edits_headline = True", double clicking a @url
> node
22 matches
Mail list logo
