Vote for bugs you urgently want fixed
Edward K. Ream
https://bugs.launchpad.net/leo-editor/+bugs
that is causing you *severe* and *practical* discomfort. Please don't
list your priorities: they won't be useful, but if there is something
that you really need fixed right away let me know.
Edward
TL
Bug 498692: Undo deleted node renames current node's headline
Bug 498688: Undo back to last saved content still shows file as
modified ("*" in title)
Bug 362950: during body text undo selection goes nuts and view moves
TL
Terry Brown
TL <t...@tltools.net> wrote:
> Bug 362950: during body text undo selection goes nuts and view moves
+1
Cheers -Terry
zpcspm
GUI because of it.
I've also complained about it in this thread:
http://groups.google.com/group/leo-editor/browse_thread/thread/07cdbb9ce1d3dba4#
Rob Sheppard
I'd really like to see the @auto-rst problems fixed.
I'm not able to import many of the example rst files I've come across.
Sometimes I can figure out what changes to make to the file to get it to
import, other times it's not worth the effort. I just open it in another
editor.
Rob S
Ville M. Vainio
> My biggest annoyance is the invalid bug 409442, I have to use the tk
> GUI because of it.
I feel your pain.
Please try this workaround (run with ctrl+b):
tree = c.frame.tree.treeWidget
tree.setColumnCount(2)
--
Ville M. Vainio
http://tinyurl.com/vainio
zpcspm
> Please try this workaround (run with ctrl+b):
>
> tree = c.frame.tree.treeWidget
> tree.setColumnCount(2)
This works.
Ville M. Vainio
>> tree = c.frame.tree.treeWidget
>> tree.setColumnCount(2)
>
> This works.
Jolly good. We might want to package this as a plugin at some point....
zpcspm
> On Mon, Dec 21, 2009 at 10:39 AM, zpcspm <zpc...@gmail.com> wrote:
> >> tree = c.frame.tree.treeWidget
> >> tree.setColumnCount(2)
>
> > This works.
>
> Jolly good. We might want to package this as a plugin at some point....
Not sure I understand.
Isn't it possible to stick this tree.setColumnCount(2) into some
constructor in the leo qt GUI plugin so the outline pane would have
the horizontal scrollbar by default?
Ville M. Vainio
>> Jolly good. We might want to package this as a plugin at some point....
>
> Not sure I understand.
> Isn't it possible to stick this tree.setColumnCount(2) into some
> constructor in the leo qt GUI plugin so the outline pane would have
> the horizontal scrollbar by default?
Yes, but it's not sure we want to have 2 columns in the tree widget -
and it would create scrollbar on many occasions when it's not
necessary.
So this is not a simple fix for your problem, it has implications
beyond your problem.
Edward K. Ream
Thanks for your recent votes. I'll fix these bugs first, after
completing the leo3k work. I hope this will happen today.
Edward
Edward K. Ream
On Dec 21, 5:16 am, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> Yes, but it's not sure we want to have 2 columns in the tree widget -
> and it would create scrollbar on many occasions when it's not
> necessary.
Rev 2540 of the trunk uses this hack. It appears to work properly in
the urgently-desired cases, and does not appear to create an
horizontal scrollbar unnecessarily.
As noted in the checkin message, this appears to be a workaround for a
QTreeWidget bug. Indeed, w.setHorizontalScrollBarPolicy
(QtCore.Qt.ScrollBarAlwaysOn) creates a scrollbar, but it is useless!
Anyway, given the pain this bug causes some, I think we can live with
the apparently minor inconvenience it might rarely cause. We can
revisit this conclusion later, after more real experience.
Edward
zpcspm
> On Dec 21, 5:16 am, "Ville M. Vainio" <vivai...@gmail.com> wrote:
>
> > Yes, but it's not sure we want to have 2 columns in the tree widget -
> > and it would create scrollbar on many occasions when it's not
> > necessary.
>
> Rev 2540 of the trunk uses this hack. It appears to work properly in
> the urgently-desired cases, and does not appear to create an
> horizontal scrollbar unnecessarily.
I can't see this. Commit message for r2540 looks for me like "updated
to-do list".
Edward K. Ream
>> Rev 2540 of the trunk uses this hack. It appears to work properly in
>> the urgently-desired cases, and does not appear to create an
>> horizontal scrollbar unnecessarily.
>
> I can't see this. Commit message for r2540 looks for me like "updated
> to-do list".
The commits got a bit confused due to a strange reversion, possibly
due to an external edit. Anyway, the actual change was made in rev
2539. Use qlog for more details.
Edward
zpcspm
> The commits got a bit confused due to a strange reversion, possibly
> due to an external edit. Anyway, the actual change was made in rev
> 2539. Use qlog for more details.
Found it, thanks.
While you are at it, you might want to do something else.
Ville correctly pointed out that this hack is a hard one, it might
have other implications.
A way to mitigate them could be to allow the user to change this
behavior instead of hardcoding it.
Luckily, there is a real reason to make this optional. As I have
pointed in the initial complaint, there is a boolean setting called
'outline_pane_scrolls_horizontally' which defaults to True and has
effect only for the Tk GUI.
If you decide that it is worth modifying the qt GUI to handle this
setting the same way, it looks like a double win:
- user will be able to turn this hard qt GUI hack off by simply
switching the setting in myLeoSettings
- the qt and Tk GUIs codebase will share the same logic (setting-
related) regarding the horizontal scrolling of the tree
Edward K. Ream
> While you are at it, you might want to do something else.
> Ville correctly pointed out that this hack is a hard one, it might
> have other implications.
Let's deal with these other implications if and when they become real.
Right now, there are four urgent bugs to attend to :-)
Edward
Edward K. Ream
On Dec 21, 3:01 pm, zpcspm <zpc...@gmail.com> wrote:
> While you are at it, you might want to do something else.
> Ville correctly pointed out that this hack is a hard one, it might
> have other implications.
> A way to mitigate them could be to allow the user to change this
> behavior instead of hard coding it.
I've completely changed my mind about this. The hard-coded behavior
is much worse than I originally thought: I detest losing about half
the outline pane: many of my headlines now end in ...
I plan to implement your suggestion today.
Edward
Edward K. Ream
Done in the trunk at rev 2544. The @bool
outline_pane_scrolls_horizontally setting now controls whether the two-
column QTreeWidget hack is in effect. I set it to False. YMMV.
Edward
>
> Edward
Edward K. Ream
On Dec 20, 9:19 am, TL <t...@tltools.net> wrote:
> Bug 362950: during body text undo selection goes nuts and view moves
This one has been controversial for a long time.
I'll be glad to fix it, but I need a clear description of exactly how
to reproduce the problem.
Thanks.
Edward
P.S. I just upped a minor change: u.undoRedoText now calls
w.seeInsertPoint, so the insertion point should always be visible
after undo/redo of a text operation. I suspect this change is not
going to matter much...
EKR
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> I'll be glad to fix it, but I need a clear description of exactly how
> to reproduce the problem.
Thanks for having another crack at this, it's tricky because it mostly works.
Hmm, the only way I'm getting it now (just pulled the trunk prior to trying) is to use mouse select / drag editing.
- Paste some paras into the body
- Select some text with the mouse
- click-drag the text somewhere else with the mouse
so, I guess that particular kind of editing isn't interacting with the undo system the same way other editing does.
But undo is working, its just its recreation of the selection / insert point that's missing. So it's picking up the changes, but perhaps only as whole text changes?
Maybe, and I'm trying to be as helpful as possible here because I'm sure you'll want to curse all mouse users and leave it as is :-), maybe, if I'm right that this style of editing looks like atomic whole text changes to the undo system, and that can't be addressed directly, and the situation can be detected (one way would be that the selection is the whole text and the cursor position is the beginning of the body), a best attempt at not confusing the user would be to (a) not select the whole text, because it never was wholly selected, and (b), move the insert point to the first difference between the new and old text.
> P.S. I just upped a minor change: u.undoRedoText now calls
> w.seeInsertPoint, so the insertion point should always be visible
> after undo/redo of a text operation. I suspect this change is not
> going to matter much...
Probably worth having that in there, as you wouldn't want the insert point to be not visible after an undo.
Cheers -Terry
Terry Brown
Terry Brown <terry_...@yahoo.com> wrote:
> > I'll be glad to fix it, but I need a clear description of exactly how
> > to reproduce the problem.
I've posted a small movie of the problem here:
http://131.212.123.124/~tbrown/tmp/out.avi
not that great because there's no sound, but there's some editing, and then I start undoing it, and when the whole text becomes selected (which never happened during the editing), that's the problem.
Note, this was done with the editor window detached to make the video small, although I suppose having the rest of the leo window in frame would make no difference if it doesn't change, frame compression wise.
Cheers -Terry
Ville M. Vainio
> I've completely changed my mind about this. The hard-coded behavior
> is much worse than I originally thought: I detest losing about half
> the outline pane: many of my headlines now end in ...
The problem is that you ran setColumnCount too early. If you only do
it when the tree has been fully populated, it works much better.
Ville M. Vainio
> The problem is that you ran setColumnCount too early. If you only do
> it when the tree has been fully populated, it works much better.
Note 2: it seems that the @setting is set to True by default (you
didn't push your change to leoSettings.leo).
Ville M. Vainio
> On Tue, Dec 22, 2009 at 12:24 PM, Ville M. Vainio <viva...@gmail.com> wrote:
> Note 2: it seems that the @setting is set to True by default (you
> didn't push your change to leoSettings.leo).
Note 3 (reg. bad column sizes):
http://www.google.fi/search?sourceid=chrome&ie=UTF-8&q=QTreeWidget+column+size
Edward K. Ream
> Note 2: it seems that the @setting is set to True by default (you
> didn't push your change to leoSettings.leo).
I did that on purpose.
Actually, a new setting would be best, one that applies only to the qt
gui. People may want one setting for tk, an the reverse for qt.
Edward
uve...@gmail.com
Hi,
that is not a bug. A scrollbar is only useful if the content of the
scroll area and the viewport have different widths. If they have the
same width (as it seems to happen in leo outline pane) the scrollbar
is just a useless decoration. Although the 2 columns hack works fine I
think that a much better solution is to add:
self.treeWidget.resizeColumnToContents(0)
at the end of setItemText method in qtGui.py. This way the content
width is updated every time the tree content changes. I've tested it
in my local installation (rev. 2453) and it works like a charm.
Vicent
PS: I've not thought in depth about my proposed solution. If you find
it has some serious problem just reject it.
Ville M. Vainio
> is just a useless decoration. Although the 2 columns hack works fine I
> think that a much better solution is to add:
>
> self.treeWidget.resizeColumnToContents(0)
>
> at the end of setItemText method in qtGui.py. This way the content
If that indeed works, it would be best to call it after every tree
redraw (not every setItemText), to avoid performance hit.
uve...@gmail.com
As you wish. As I said I've not thought in depth about my proposal so
I'm sure it can be optimized.
Vicent
Edward K. Ream
> self.treeWidget.resizeColumnToContents(0)
Hurray, this works! Many thanks, Vincent, for this suggestion.
The new code is in the trunk at rev 2550. I put this line leoQtTree.repaint.
The debate about preferences is now moot, as this appears to have no
negative side effects.
Edward
uve...@gmail.com
Great!
Edward K. Ream
On Dec 21, 7:14 pm, Terry Brown <terry_n_br...@yahoo.com> wrote:
> I've posted a small movie of the problem here:
I am getting an "empty stream" message on Ubuntu.
Edward
Edward K. Ream
On Dec 21, 6:47 pm, Terry Brown <terry_n_br...@yahoo.com> wrote:
> Hmm, the only way I'm getting it now (just pulled the trunk prior to trying) is to use mouse select / drag editing.
>
> - Paste some paras into the body
>
> - Select some text with the mouse
>
> - click-drag the text somewhere else with the mouse
>
> so, I guess that particular kind of editing isn't interacting with the undo system the same way other editing does.
>
> But undo is working, its just its recreation of the selection / insert point that's missing. So it's picking up the changes, but perhaps only as whole text changes?
>
> Maybe, and I'm trying to be as helpful as possible here because I'm sure you'll want to curse all mouse users and leave it as is :-), maybe, if I'm right that this style of editing looks like atomic whole text changes to the undo system, and that can't be addressed directly, and the situation can be detected (one way would be that the selection is the whole text and the cursor position is the beginning of the body), a best attempt at not confusing the user would be to (a) not select the whole text, because it never was wholly selected, and (b), move the insert point to the first difference between the new and old text.
Thanks for these hints. I'll see what I can do.
Edward
Edward K. Ream
I believe the relevant code is in qtGui.py: onBodyChanged
This method appears to be properly saving the selection range and
insert point for the undo code. The problem may be that at the time
this method is called there is no selection range at all. At least
that's the case as I have dragged text around with the mouse.
To repeat, I have not been able to look at the movie. Unless I can
see in detail what is going wrong I'll have to defer work on this
project.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> I believe the relevant code is in qtGui.py: onBodyChanged
>
> This method appears to be properly saving the selection range and
> insert point for the undo code. The problem may be that at the time
> this method is called there is no selection range at all. At least
> that's the case as I have dragged text around with the mouse.
I've made two more versions of the movie:
http://131.212.123.124/~tbrown/tmp/out.avi # didn't work
http://131.212.123.124/~tbrown/tmp/out.mpg
http://131.212.123.124/~tbrown/tmp/out.ogg
all work for me in firefox in Ubuntu, but it probably depends which video drivers you've installed in the past.
But it sounds to me (speculating) like the problem is that moving text with the mouse results in an "onchanged" event with (a) no selection, (b) the insert point at the beginning of the file or some other nonsense place, and (c) a whole text changed kind of message (perhaps that's a given if there's no selection). So, I suspect the best that can be done is to not set the selection when undoing one of these edits (currently its being set to the whole text) and to set the insert point to the first difference between the old and new text.
Cheers -Terry
zpcspm
I have to assume you've tried to use the default media player that
comes with Ubuntu. It's called Totem IIRC. You might want to consider
installing MPlayer, it saves lots of people from headaches related to
video files, because in most cases it just works.
Edward K. Ream
> I've made two more versions of the movie:
The .ogg file works for me. Thanks.
> But it sounds to me (speculating) like the problem is that moving text with the mouse results in an "onchanged" event with (a) no selection, (b) the insert point at the beginning of the file or some other nonsense place, and (c) a whole text changed kind of message (perhaps that's a given if there's no selection). So, I suspect the best that can be done is to not set the selection when undoing one of these edits (currently its being set to the whole text) and to set the insert point to the first difference between the old and new text.
I'll see what I can do.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > I've made two more versions of the movie:
>
> The .ogg file works for me. Thanks.
heh, just noticed a really easy way to invoke:
- double click select a word
- middle click paste it somewhere else
- undo -> whole text is selected, insertion's at start
Cheers -Terry
Edward K. Ream
> - double click select a word
> - middle click paste it somewhere else
> - undo -> whole text is selected, insertion's at start
Thanks for this. This happens for me, but after a second paste, not the first.
Edward
Edward K. Ream
On Dec 23, 6:20 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> On Tue, Dec 22, 2009 at 5:16 PM, Terry Brown <terry_n_br...@yahoo.com>
>
> > - double click select a word
> > - middle click paste it somewhere else
> > - undo -> whole text is selected, insertion's at start
>
> Thanks for this. This happens for me, but after a second paste, not the first.
The fix may be on the trunk at rev 2555. There was an obvious sign
blunder in the computation of oldSel in onBodyChanged. Please let me
know how the code works for you.
At present, the code works as well as can be expected. There is not
enough information to reconstitute what the actual selected text was
when onBodyChanged is called as the result of a middle-button paste.
The code uses the only information it has, which will usually be out-
of-date. But I don't think this is a big problem. Certainly, it is
not as big a problem as that caused by the sign blunder.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> The fix may be on the trunk at rev 2555. There was an obvious sign
> blunder in the computation of oldSel in onBodyChanged. Please let me
> know how the code works for you.
It's better, but I think there may still be some issue with the insertion point disappearing from view, probably because it wasn't set by the change from mouse based editing. Let me evaluate it. Always the problem has been not that undo is not working, but that the odd highlighting and insert positioning makes it hard to see how much you've undone. This should be better now the highlighting's not nuts anymore, but will see about the insert position and part of text that's visible.
Cheers -Terry
Kent Tenney
it's tagged 'medium' and I consider it urgent
https://bugs.launchpad.net/leo-editor/+bug/488894
I find @path and the active_path plugin very important for my workflow
and to Leo's future, this bug renders it useless, since a
save can trigger a long series of unnecessary,
misleading dialogs which can't be escaped from.
Thanks,
Kent
> --
>
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
>
>
Edward K. Ream
> I think there may still be some issue with the insertion point disappearing from view, probably because it wasn't set by the change from mouse based editing.
Now might be a good time to review the division of labor in the code.
Let u = c.frame.undoer. The callers of u.setUndoTypingParams are
responsible for setting the oldSel and newSel arguments. These
selections will be equivalent to the insertion point if there is no
actual selection range.
u.undoRedoText handles undo/redo of body text. This is a complex
method, but its effect on the selection range is straightforward:
sel = g.choose(tag=='undo',u.oldSel,u.newSel)
i,j = sel
w.setSelectionRange(i,j,insert=j)
So there is no need for separate "oldIns" or "newIns" arguments to
u.setUndoTypingParams.
The main undo/redo methods u.undo and u.redo, call w.seeInsertPoint
after saving and restoring the selection range.
So it looks the undo/redraw code itself is not to blame.
There is still a possibility that leoQtTree.onTextChanged can be
improved. In particular, it plays some games with p.v.insertSpot,
p.v.selectionStart and p.v.selectionLength.
Hmm. setBodyTextAfterSelect uses these ivars. it's possible that
there could be a clash. The only way to know for sure is to do a
trace...
Ok, tracing shows that setBodyTextAfterSelect is called *before* the
code at the end of u.undo or u.redo, so that code will likely have no
effect at all.
There is one other possibility, namely that leoQtTree.onTextChanged
would be better advised not to set the p.v ivars at all.
I just tried that. It may be that there are subtle differences, maybe
even a subtle improvement, but nothing to write home about.
So I'm about at the end of my ideas. You might try disabling the
following code in onTextChanged to see if it is better for you:
p.v.insertSpot = newInsert
i,j = newSel
i,j = self.toGuiIndex(i),self.toGuiIndex(j)
if i > j: i,j = j,i
p.v.selectionStart,p.v.selectionLength = (i,j-i)
Edward