I have filled a bug at launchpad that is related to
c.frame.toggleSplitDirection()
https://bugs.launchpad.net/leo-editor/+bug/580328
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
Current leo defaults to qt, if it can find and successfully import
pyqt.
Since you've got it via bzr, there was no package manager involved,
thus no dependency tracking.
I suggest you to check out if pyqt is installed.
If you will run ./launchLeo.py --help (or python launchLeo.py --help),
you will
On May 13, 5:29 pm, Terry Brown wrote:
> On Thu, 13 May 2010 14:07:13 -0700 (PDT)
>
> tfer wrote:
> > Well, I still really like the ability to put a hook in between the
> > keypress and the printing into what ever widget is the target, there
> > is just too much interesting things that makes do
I've been trying to use the latest leo with ipython and am confused.
I got leo via:
bzr pull http://bazaar.launchpad.net/~leo-editor-team/leo-editor/trunk/
then I read how it needs python2.6 and started it with
python2.6 /opt/leo/launchLeo.py
and tried http://webpages.charter.net/edreamleo/IP
On Thu, 13 May 2010 23:58:39 +0300
"Ville M. Vainio" wrote:
> Such a thing can be supported easily by gui-side hooks. The same
> mechanism that's being used in colorize_headlines.py plugin could
> probably be used for this already (change the text of
> QListWidgetItem).
colorize_headlines.py is
On Thu, 13 May 2010 14:07:13 -0700 (PDT)
tfer wrote:
> Well, I still really like the ability to put a hook in between the
> keypress and the printing into what ever widget is the target, there
> is just too much interesting things that makes doable that a strict
> lock-in would make impossible.
On May 13, 2:43 pm, "Ville M. Vainio" wrote:
>
> Right. In my opinion Leo "knows" too much about the gui. Most of the
> leo should see the editor as a "black box" that contains one string
> per body editor (current contents).
>
> Same should apply for e.g. minibuffer. It should just "sit there" a
On Thu, May 13, 2010 at 10:59 PM, Terry Brown wrote:
> I agree, but at the same time I can see why it's hard to keep the lines
> clear, for example I'd want the gui to hook back leo when you start editing a
> headline so leo can supply actual vs view-only text for my
>
> �...@shadow /home/tbrow
On Thu, 13 May 2010 22:43:49 +0300
"Ville M. Vainio" wrote:
> Same should apply for e.g. minibuffer. It should just "sit there" as
> QLineEdit. If you press "a" in the minibuffer Leo should never know
> about it, it should just result in "a" appearing in the line editor.
I agree, but at the same
On Thu, May 13, 2010 at 9:11 PM, Terry Brown wrote:
> But I wonder about the level at which the abstraction occurs. I think that's
> what bugs Ville. If the gui was responsible for telling leo the body text
> for node n is now s, rather than telling leo that key k has just been
> pressed, th
On Thu, 13 May 2010 11:37:56 -0500
"Edward K. Ream" wrote:
> Text wrappers allow Leo's core to be gui-independent.
I think some level of abstraction is a must have. I'd like to see an AJAX
interface for leo, so you can easily make an argument for at least two
interfaces existing simultaneousl
On May 13, 12:22 pm, "Edward K. Ream" wrote:
> Why would anyone think that writing code from scratch would be a good
> idea? It makes refactoring impossible. It is also the antithesis of
> kaizen, continuous *incremental* improvement.
I am glad I rewrote the Borland C version of Leo to the P
On May 13, 12:17 pm, "Edward K. Ream" wrote:
> On Thu, May 13, 2010 at 12:09 PM, Matt Wilkie wrote:
> >>... It will be *much* easier to understand and adapt
> >> the code than to rewrite it from scratch.
Why would anyone think that writing code from scratch would be a good
idea? It makes ref
On Thu, May 13, 2010 at 12:09 PM, Matt Wilkie wrote:
>>... It will be *much* easier to understand and adapt
>> the code than to rewrite it from scratch.
>
> Seems like a good moment to link to an essay by Joel Spolsky on
> "Things you should never do" wherein he makes a strong argument
> Netscape
>... It will be *much* easier to understand and adapt
> the code than to rewrite it from scratch.
Seems like a good moment to link to an essay by Joel Spolsky on
"Things you should never do" wherein he makes a strong argument
Netscape made "the SINGLE WORST STRATEGIC MISTAKE that any software
com
On Wed, May 12, 2010 at 10:37 AM, Edward K. Ream wrote:
> At last we move on to real documentation. Let's begin by looking at
> leoEditCommands.py.
The following continues the documentation for leoEditCommands.py. The
third and final part will discuss classes one-by-one. This ensures
that I rev
On Thu, May 13, 2010 at 11:05 AM, Ville M. Vainio wrote:
> On Tue, May 11, 2010 at 4:20 PM, Edward K. Ream wrote:
>
>> I don't really need a crystal ball here to write the docs. I've been
>> privately assuming that Ville is the leading choice to be my
>> successor. When appropriate, I'll tailor
On Tue, May 11, 2010 at 4:20 PM, Edward K. Ream wrote:
> I don't really need a crystal ball here to write the docs. I've been
> privately assuming that Ville is the leading choice to be my
> successor. When appropriate, I'll tailor my remarks to him.
This might happen; however, don't take this
On Thu, 13 May 2010 03:55:19 -0700 (PDT)
zpcspm wrote:
> I'm aware of 'initial_split_orientation' setting.
> I would like to change this dynamically, by a command.
Edward answered your immediate question, I just want to
remind people about my wishlist item:
https://bugs.launchpad.net/leo-editor
On May 13, 4:39 pm, "Edward K. Ream" wrote:
> On Thu, May 13, 2010 at 5:55 AM, zpcspm wrote:
> > I would like to change this dynamically, by a command.
>
> c.frame.toggleSplitDirection()
>
> From the minibuffer: toggle-split-direction
>
> Because there is a minibuffer command, the following also
On Thu, May 13, 2010 at 12:05 AM, Matt Wilkie wrote:
> It's confusing that the landing page for leo at launchpad[1] says the
> current release is 4.6rc1 yet 4.7.1-final is out.
> [1] https://launchpad.net/leo-editor
Actually, it says the latest milestone is 4.6rc1.
EKR
--
You received this mes
On Thu, May 13, 2010 at 5:55 AM, zpcspm wrote:
> I would like to change this dynamically, by a command.
c.frame.toggleSplitDirection()
>From the minibuffer: toggle-split-direction
Because there is a minibuffer command, the following also works:
c.k.simulateCommand('toggle-split-direction')
H
I'm aware of 'initial_split_orientation' setting.
I would like to change this dynamically, by a command.
This situation is similar to the one raised recently by Kent (which
led to a new setting IIRC).
Being able to tell leo at startup how to split the window or where to
place the button toolbar is
23 matches
Mail list logo
