colorize_headlines.py is a good example, but it's called in the wrong
place for changing the text.
Are you sure? If it changes text, does it get overwritten?
Any particular reasons for creating that hook that way (new function on
g) instead of the existing hook machinery?
Can't remember.
For occasions when keypress means something apart from the expected default
action (this doesn't mean commands, they can be handled by QAction/QShortcut),
you would have a dispatch dict that calls your own function. This would be in
the ui layer as well, not core.
Core needs to be asked for
On Mon, May 10, 2010 at 2:54 PM, Edward K. Ream edream...@gmail.com wrote:
Encapsulation of complexity.
I wrote the following in a reply to a post to this thread, before
realizing it wasn't relevant there :-) But it still is worth saying:
Imo, Leo has the proper abstractions for all modules,
On Thu, May 13, 2010 at 2:43 PM, Ville M. Vainio vivai...@gmail.com wrote:
On Thu, May 13, 2010 at 9:11 PM, Terry Brown terry_n_br...@yahoo.com 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
On Thu, May 13, 2010 at 4:07 PM, tfer tfethers...@aol.com 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.
Well, I still really like
On Thu, May 13, 2010 at 4:44 PM, Terry Brown terry_n_br...@yahoo.com wrote:
On Thu, 13 May 2010 23:58:39 +0300
Ville M. Vainio vivai...@gmail.com 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
On Thu, May 13, 2010 at 11:22 PM, tfer tfethers...@aol.com wrote:
I can't remember whether it's you or someone else whose pursuing the vi
emulation, but when does that need to interact with leo beyond the here's
the new body text level? That's a question, not a implied suggestion that
it
On Fri, May 14, 2010 at 2:26 AM, Ville M. Vainio vivai...@gmail.com wrote:
For occasions when keypress means something apart from the expected default
action (this doesn't mean commands, they can be handled by
QAction/QShortcut), you would have a dispatch dict that calls your own
function.
On Fri, 14 May 2010 10:16:24 +0300
Ville M. Vainio vivai...@gmail.com wrote:
colorize_headlines.py is a good example, but it's called in the wrong
place for changing the text.
Are you sure? If it changes text, does it get overwritten?
Yes, it's called from
Qt gui--@thin qtGui.py--Frame
On Fri, 14 May 2010 10:11:36 -0500
Terry Brown terry_n_br...@yahoo.com wrote:
colorize_headlines.py is a good example, but it's called in the wrong
place for changing the text.
Are you sure? If it changes text, does it get overwritten?
Yes
p.s. it works for font / color
Ok terry. Please move it to happen as late as possible :)
- Original message -
On Fri, 14 May 2010 10:11:36 -0500
Terry Brown terry_n_br...@yahoo.com wrote:
colorize_headlines.py is a good example, but it's called in the
wrong place for changing the text.
Are you
On Fri, 14 May 2010 18:55:11 +0300
Ville M. Vainio vivai...@gmail.com wrote:
Ok terry. Please move it to happen as late as possible :)
Alright. So you can't recall why you didn't use leo's general hook mechanism?
I'm leaning towards sticking with that, unless you think it has issues. I
On Tue, May 11, 2010 at 4:20 PM, Edward K. Ream edream...@gmail.com 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;
On Thu, May 13, 2010 at 11:05 AM, Ville M. Vainio vivai...@gmail.com wrote:
On Tue, May 11, 2010 at 4:20 PM, Edward K. Ream edream...@gmail.com 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.
On Wed, May 12, 2010 at 10:37 AM, Edward K. Ream edream...@gmail.com 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
... 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
company
On Thu, May 13, 2010 at 12:09 PM, Matt Wilkie map...@gmail.com 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
On May 13, 12:17 pm, Edward K. Ream edream...@gmail.com wrote:
On Thu, May 13, 2010 at 12:09 PM, Matt Wilkie map...@gmail.com 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
On May 13, 12:22 pm, Edward K. Ream edream...@gmail.com 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
On Thu, 13 May 2010 11:37:56 -0500
Edward K. Ream edream...@gmail.com 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
On Thu, May 13, 2010 at 9:11 PM, Terry Brown terry_n_br...@yahoo.com 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
On Thu, 13 May 2010 22:43:49 +0300
Ville M. Vainio vivai...@gmail.com 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
On Thu, May 13, 2010 at 10:59 PM, Terry Brown terry_n_br...@yahoo.com 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
On May 13, 2:43 pm, Ville M. Vainio vivai...@gmail.com 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
On Thu, 13 May 2010 14:07:13 -0700 (PDT)
tfer tfethers...@aol.com 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
On Thu, 13 May 2010 23:58:39 +0300
Ville M. Vainio vivai...@gmail.com 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).
On May 13, 5:29 pm, Terry Brown terry_n_br...@yahoo.com wrote:
On Thu, 13 May 2010 14:07:13 -0700 (PDT)
tfer tfethers...@aol.com 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
On Tue, May 11, 2010 at 11:46 PM, Gour g...@gour-nitai.com wrote:
On Tue, 11 May 2010 08:28:41 -0500
Edward == Edward K. Ream wrote:
Edward As I reread this remark, I realize that it appears to single
Edward out Knuth for criticism. That was not my intent. My apologies
Edward to him.
On Wed, May 12, 2010 at 9:57 AM, Edward K. Ream edream...@gmail.com wrote:
On Tue, May 11, 2010 at 11:46 PM, Gour g...@gour-nitai.com wrote:
On Tue, 11 May 2010 08:28:41 -0500
Edward == Edward K. Ream wrote:
Edward As I reread this remark, I realize that it appears to single
Edward out Knuth
On May 10, 10:11 am, Edward K. Ream edream...@gmail.com wrote:
In this thread I shall attempt to explain everything my successor will
need know about Leo in order to carry on after I am gone.
Here is, I think, the last of the general comments about this thread.
I wrote it yesterday, along
On May 10, 10:11 am, Edward K. Ream edream...@gmail.com wrote:
In this thread I shall attempt to explain everything my successor will
need know about Leo in order to carry on after I am gone.
At last we move on to real documentation. Let's begin by looking at
leoEditCommands.py. I am starting
On Mon, May 10, 2010 at 3:17 PM, Ville M. Vainio vivai...@gmail.com wrote:
On Mon, May 10, 2010 at 11:11 PM, Edward K. Ream edream...@gmail.com wrote:
some benefits. And its safer. Who can say what gui will be dominant
5 or 10 years from now?
I can. It will be Qt.
What makes you so sure?
On Tue, May 11, 2010 at 1:38 PM, Edward K. Ream edream...@gmail.com wrote:
I can. It will be Qt.
What makes you so sure?
It was something of a joke (me being a Nokia employee, so I'm obviously biased).
That being said, I don't see anything challenging Qt any day soon in
native space (java,
On Tue, 11 May 2010 15:02:53 +0300
Ville == Ville M. Vainio wrote:
Ville That being said, I don't see anything challenging Qt any day
Ville soon in native space (java, c# and web toolkits are a separate
Ville matter, and not something you can really use from CPython). Qt
Ville is the future of
On Tue, May 11, 2010 at 7:43 AM, Gour g...@gour-nitai.com wrote:
Ville That being said, I don't see anything challenging Qt any day
Ville soon in native space (java, c# and web toolkits are a separate
Ville matter, and not something you can really use from CPython). Qt
Ville is the future of
On Mon, May 10, 2010 at 10:11 AM, Edward K. Ream edream...@gmail.com wrote:
As I think about this project, I realize that the documentation will
be unusual in many respects. Indeed, it might be said to be the
antithesis of Donald Knuth's literate documentation.
As I reread this remark, I
On May 10, 10:11 am, Edward K. Ream edream...@gmail.com wrote:
In this thread I shall attempt to explain everything my successor will
need know about Leo in order to carry on after I am gone.
Part of this project will be to go back through previous posts looking
for raw materials for this
On Tue, May 11, 2010 at 8:48 AM, Edward K. Ream edream...@gmail.com wrote:
Part of this project will be to go back through previous posts looking
for raw materials for this project. There is a lot of good stuff
there, but it needs to be found, edited and organized.
Here is a posting about
On May 11, 8:28 am, Edward K. Ream edream...@gmail.com wrote:
On Mon, May 10, 2010 at 10:11 AM, Edward K. Ream edream...@gmail.com wrote:
As I think about this project, I realize that the documentation will
be unusual in many respects. Indeed, it might be said to be the
antithesis of
On Tue, 11 May 2010 08:28:41 -0500
Edward == Edward K. Ream wrote:
Edward As I reread this remark, I realize that it appears to single
Edward out Knuth for criticism. That was not my intent. My apologies
Edward to him.
Here is some interesting thread about Leo/LP...
Otoh, someone in the
Here is a posting about Leo's MVC architecture:
http://groups.google.com/group/leo-editor/browse_thread/thread/6b77a59a3a5c7cbb
...
BTW, there seems to be a bug in google groups:
Bug indeed. I can't find that thread AT ALL by searching for mvc!
I get 13 results[0], one of which is the same
Searching google groups is busted.
while google proper is not,
http://www.google.ca/search?q=leo-editor+mvc shows Re: Leo's MVC
architecture as hits #2 and #3 --- from mail-archive.com no less.
--
-matt
--
You received this message because you are subscribed to the Google Groups
leo-editor
sorry to hijack an important thread, please follow up re: google
groups search in a new one.
-matt
On Tue, May 11, 2010 at 10:33 PM, Matt Wilkie map...@gmail.com wrote:
Searching google groups is busted.
while google proper is not,
http://www.google.ca/search?q=leo-editor+mvc shows Re: Leo's
On 2010-05-12 01:33, Matt Wilkie wrote:
Searching google groups is busted.
while google proper is not,
http://www.google.ca/search?q=leo-editor+mvc shows Re: Leo's MVC
architecture as hits #2 and #3 --- from mail-archive.com no less.
Is Google-groups just not including subjects
In this thread I shall attempt to explain everything my successor will
need know about Leo in order to carry on after I am gone. For the
record, I plan to work on Leo for as long as I am able to do so.
I am particularly interested in explaining why Leo is the way it is so
that those who work on
On May 10, 10:11 am, Edward K. Ream edream...@gmail.com wrote:
In this thread I shall attempt to explain everything my successor will
need know about Leo in order to carry on after I am gone.
Encapsulation of complexity.
Leo's design is driven by encapsulation of complexity. This is
*not* a
On May 10, 2:54 pm, Edward K. Ream edream...@gmail.com wrote:
I think of this as knowing where the bodies are buried. An
essential part of these documents will be explaining why some things
are, and likely must be, complex. Here is a brief overview:
There are other bodies :-) I promise
On Mon, May 10, 2010 at 11:11 PM, Edward K. Ream edream...@gmail.com wrote:
some benefits. And its safer. Who can say what gui will be dominant
5 or 10 years from now?
I can. It will be Qt.
(unrelated to the fact that I work at Nokia these days ;-).
--
Ville M. Vainio
48 matches
Mail list logo
