Dead end?

[Thomas Orgis]

Hi folks,

I have been compemplating the lesstif situation for a while and, after at least narrowing down the Menu->ESC->Crash issue to a change between 0.9

[Thomas Orgis]

Am Sun, 22 Mar 2009 11:13:49 +0100

Post by Thomas Orgis
Hi folks,

Sorry, that has been sent prematurely. I startet writing a grave speech
for my nedit usage on linux, due to the neverending trouble with
lesstif. Then I saw a comment on the ESC-menu crash on the lesstif
tracker that showed a hack for that one bug. Then I saw that in xpdf
you still have a similar crash with it's menu. Then I observed again
the focus issues lesstif has (keyboard focus seems to be sort of
random, and generally the control of menus is weird... navigation is
fine, but enter key without function).

I also saw that the folks over at debian don't seem to be overly
concerned about these issues (a fresh sidux install showed the same
focus weirdness, almost certainly the ESC-menu crash, but didn't
check). Possibly because of lack of (numerous) user complaints combined
with developer care...

Now I am not totally decided on my future with nedit, but I am leaning
towards dismissing all Motif stuff on Linux, perhaps continue using
nedit, xpdf and xdvi (really, that's the set of three Motif apps I
use... the other "old" GUI is xfig, and that is Xaw3D, no issue there)
on the Solaris system at work. If suddenly, OpenMotif would be free --
and also would build in my current system without libXp, the case may
be different. But so it combines with the lack of nedit development in
important areas (like encodings) and makes it's use-case difficult for
me.

I am not decided yet, but I am looking out for any worthwhile editors
out there. That could take some time. There is the crazy plan to Hack
My Own Thing(tm), as always, possibly starting with the scintilla
widget (if that can be made less sluggish)... or FLTK. But perhaps I
really find one editor among the hundreds, thousands, out there.

Still, not decided...


Alrighty then,

Thomas.

[Joerg Fischer]

Then I saw a comment on the ESC-menu crash on the lesstif tracker
that showed a hack for that one bug. Then I saw that in xpdf you
still have a similar crash with it's menu. Then I observed again
the focus issues lesstif has (keyboard focus seems to be sort of
random, and generally the control of menus is weird... navigation is
fine, but enter key without function).

Just curious, does this hold also when you revert the changes in
MenuShell.c, too (mentioned in the lesstif tracker)?

There is the crazy plan to Hack My Own Thing(tm), as always,
possibly starting with the scintilla widget (if that can be made
less sluggish)... or FLTK.

Or with Xlib like http://luced.de/ (just kidding...)

Cheers,
Jörg

[Thomas Orgis]

Am Sun, 22 Mar 2009 12:38:17 +0100

Post by Joerg Fischer
Just curious, does this hold also when you revert the changes in
MenuShell.c, too (mentioned in the lesstif tracker)?

Nope. (Plus: Annoying, that sf.net doesn't send me notice about new comments by default).

Post by Joerg Fischer

There is the crazy plan to Hack My Own Thing(tm), as always,
possibly starting with the scintilla widget (if that can be made
less sluggish)... or FLTK.

Or with Xlib like http://luced.de/ (just kidding...)

Hm, actually looks interesting. Kidding? Dunno.


Alrighty then,

Thomas.

[Randy Kramer]

Post by Thomas Orgis
There is the crazy plan to Hack
My Own Thing(tm), as always, possibly starting with the scintilla
widget (if that can be made less sluggish)... or FLTK.

I'm curious--under what circumstances do you find scintilla sluggish?
I've started to play around with scite, and it passed its first test
with flying colors--loading a 10 MB character (also byte in this case)
file, and then scrolling through the file using the elevator
bar--scrolls as fast as I can move the elevator bar.

I've looked into the approach to folding, and, as far as I looked, I
like most of what I see--it does folding, it applies a folding level
number to each fold (so folding can be hierarchical).

On the downside, since I use my own markup language (actually, TWiki
with modifications) I will have to write a lexer for that, and most
lexers are written in C++ :-( although some are written in Lua iiuc.
(And I've now found one lexer for a wiki markup language (haven't tried
it yet), but that may be suitable for me to adapt.

Also, unless I misunderstand, it already works in Unicode, which means
it won't require a conversion at some point down the line--and I'm even
more impressed with the speed I've seen because I was worried that the
conversion to Unicode would slow (nedit, for example) down.

It does have a scripting language named Lua, which might be fine. There
is no keyboard recording of macros :-(

And, of course, it does not use *tif.

Thanks for any additional information you can offer.

Randy Kramer

[Thomas Orgis]

Am Sun, 22 Mar 2009 07:51:07 -0400

Post by Randy Kramer
I'm curious--under what circumstances do you find scintilla sluggish?

I investigated SciTE some years ago because I was interested in code
folding... then used kate, which can also do this.
Not so sure now why SciTE didn't impress me back then, but it
apparently wasn't better than kate.
Now, kate became too fat and slow. It is amazing how long I went with
using KDE and its apps on that Pentium 200 MMX laptop.
Well, we all know that nedit is somehow quicker than others.

But I must also admit that I cannot judge SciTE's speed currently
because of the sad state of Xorg on my machine.
I am cursed with an Intel video chipset, using a driver people seem to
enjoy hacking around with and breaking things.
Something basic with the 2D acceleration is wrong, resulting in nearly
all 2D action like window redrawing and scrolling being really, really
bad.
The funny part is that this does not affect nedit (or dillo2, which
even uses scalable fonts with AA and unicode, if that matters). Nedit
is fast as ever, but all other editors have horrible scrolling behaviour.
So, I have to take care with evaluating editor performance in the
current state. At least SciTE does pass the "seek intertia" test:
When you hold down the page down key for some time and then release, it
stops scrolling shortly after that. Other editors (Kate to the extreme)
continue scrolling until they think they have done enough according to
the keyboard repeat rate, effectively blocking the UI.

Post by Randy Kramer
I've looked into the approach to folding

Not that interested in this feature anymore. What I more and more wish
for is something simpler: A smarter display of dynamic wrap, honoring
the initial indent of the wrapped line (as Kate does, but without the
ugly background texture).

Post by Randy Kramer
lexers are written in C++ :-( although some are written in Lua iiuc.

Lua may actually be a better approach than inventing yet another macro
language.
It has been designed to be an embedded language...

Post by Randy Kramer
more impressed with the speed I've seen because I was worried that the
conversion to Unicode would slow (nedit, for example) down.

Well, regex action has to be slower... but text display as such seems
to work fine&fast for dillo2.
And, there are still simple optimizations for syntax highlighting that
even nedit could still make use of (I think of _not_ updating all
following lines on every keypress, like coloring/decoloring everything
when opening a " and some time later on the same line closing with
another "... better wait for the line to be finished, like mcedit does).

Well, I might give the scintilla engine a try. After resolving that
pitiful state of my X11.


Alrighty then,

Thomas.

[Joerg Fischer]

I startet writing a grave speech for my nedit usage on linux, due to
the neverending trouble with lesstif. Then I saw a comment on the
ESC-menu crash on the lesstif tracker that showed a hack for that
one bug. Then I saw that in xpdf you still have a similar crash
with it's menu. Then I observed again the focus issues lesstif has
(keyboard focus seems to be sort of random, and generally the
control of menus is weird... navigation is fine, but enter key
without function).

My feeling is now you always used Motif. The enter key never worked
in lesstif (use the space key instead). There are also many more
differences, eg., the ESC key didn't close some dialog boxes (there is
code in nedit to handle this). If you come from Motif, you surely
notice these differences, but they are not related to the latest
lesstif versions.

To summarize, you solved two bugs in the latest 0.95. One in
Traversal.c, which trying to fix something else actually breaks its
own tests (as Scott noticed). I don't know, why you call it a hack,
if one reverts a broken fix, btw. The other change in MenuShell.c was
questionable right from the start, and, as xpdf shows, it is wrongly
done, either. (Putting it in with #if 1 is, well ...) So, with the
clipboard fix, you'll have a stable lesstif. The differences you
notice won't go away, because Lesstif isn't Motif. I'm sorry I forgot
to mention this.

Anyway, what you call "focus weirdness", is this just the enter key
not working?

I also saw that the folks over at debian don't seem to be overly
concerned about these issues ...

They should be concerned about the crash reports, otherwise they
belong to the distros I complained about ...

Cheers,
Jörg

[Erik de Castro Lopo]

Post by Joerg Fischer
My feeling is now you always used Motif.

This answer is currently totally unsatisfactory if you care about
Free Software. OpenMotif is free as in beer but definitely not
free according to the OSI:

http://www.opensource.org/docs/definition.php

While I have been happy to jump in and try an fix bugs in Lesstif
(without much success) there is no way I would so the same for
OpenMotif.

Erik

[Thomas Orgis]

Am Mon, 23 Mar 2009 20:29:49 +0100

Post by Joerg Fischer
My feeling is now you always used Motif. The enter key never worked
in lesstif (use the space key instead).

I have been using openmotif, yeah. Just recently the whole issue came
up with the deprecation of libXp in Xorg, which openmotif source
doesn't handle yet (perhaps trivial fix anyway, disabling corresponding
code). And indeed, I rarely used the nedit menus, usually in the
sluggish manner of the mouse pilot.
Well, space key seems to work. Sorry for wrongly assuming that menu
navigation works like ... everywhere else.

What does not work is certain shortcut keys (the underlined characters
in menu entries).
Some work (copy/paste). Some not (right/left shift).

Post by Joerg Fischer
To summarize, you solved two bugs in the latest 0.95. One in
Traversal.c, which trying to fix something else actually breaks its
own tests (as Scott noticed). I don't know, why you call it a hack,
if one reverts a broken fix, btw.

Well, there could still be the original issue people wanted to fix;-)
Generally, the lesstif business feels hackish to me because I didn't
meet someone who actually is familiar with the code. Also, even with
the commercial Openmotif there's talk from the nedit side about newer
versions breaking things.
This just does not sound healthy.

Post by Joerg Fischer
The other change in MenuShell.c was
questionable right from the start, and, as xpdf shows, it is wrongly
done, either.

Hm, so one should also revert the part that made the menu sticky...
Not the case in my build yet.

Post by Joerg Fischer
(Putting it in with #if 1 is, well ...) So, with the
clipboard fix, you'll have a stable lesstif.

Hm. Only my trust in it seems to be someplace else. Perhaps it'll be
fine.

Post by Joerg Fischer
Anyway, what you call "focus weirdness", is this just the enter key
not working?

No, that one is really annoying: Often (after switching to the nedit
window... I switch windows a lot), the search/replace dialog, opened
via Ctrl+F does not get keyboard input.
I have to close it with the mouse, click into the nedit window to make
sure and then open the dialog again to be able to type in it.

You have any idea about that? Without that annoyance, I perhaps could
live on for some time with nedit... until the whole unicode issue gets
me again.
The non-working shortcut keys in the menus I won't miss, but keyboard
input is rather basic.
I just now verified that the whole of nedit does not get keyboard input
(as focused window) unless I click into the nedit window with the
mouse. One could try to blame that one the window manager, but I only
changed in lesstif for openmotif, not changed the window manager.
Interesting that the Ctrl+F works for nedit, but normal keyboard input
not...


Alrighty then,

Thomas.

[Thomas Orgis]

Am Tue, 24 Mar 2009 00:02:17 +0100

Post by Thomas Orgis
No, that one is really annoying: Often (after switching to the nedit
window... I switch windows a lot), the search/replace dialog, opened
via Ctrl+F does not get keyboard input.
I have to close it with the mouse, click into the nedit window to make
sure and then open the dialog again to be able to type in it.

More specific:
- Switch to nedit window, keyboard input works.
- Ctrl+F ... no keyboard input.
- After closing with mouse, nedit window doesn't have keyboard input.
- Mouse click into nedit window: works again.


Alrighty then,

Thomas.

[Joerg Fischer]

Post by Thomas Orgis
Well, space key seems to work. Sorry for wrongly assuming that menu
navigation works like ... everywhere else.

I'm just trying to figure out which issues are new in the last lesstif
release. Also, I forgot to mention the differences between lesstif and
openmotif, which let me use openmotif on linux. Your question however
was if one should contribute to openmotif, which I wouldn't do. Or, to
use the wording from http://www.opengroup.org/openmotif/faq.html,
"Yes, we hope to be able to make a contribution in the future, when
Motif will be made Open Source."

Post by Thomas Orgis
What does not work is certain shortcut keys (the underlined characters
in menu entries).
Some work (copy/paste). Some not (right/left shift).

This would be new, I think.

Post by Thomas Orgis
Also, even with the commercial Openmotif ...

I don't know whether or not Openmotif is commercial - it is maintained
by a company currently, so it may well be. On the other hand, I think
Linux is commercial, too. Please don't make the mistake to translate
free software into non-commercial and commercial (which is all fine)
into proprietary software.

Post by Thomas Orgis

The other change in MenuShell.c was questionable right from the
start, and, as xpdf shows, it is wrongly done, either.

Hm, so one should also revert the part that made the menu sticky...
Not the case in my build yet.

IMO there are only two possibilities: Either do it right or revert it.
Wishful thinking doesn't help.

Post by Thomas Orgis
No, that one is really annoying: Often (after switching to the nedit
window... I switch windows a lot), the search/replace dialog, opened
via Ctrl+F does not get keyboard input.
I have to close it with the mouse, click into the nedit window to make
sure and then open the dialog again to be able to type in it.
You have any idea about that?

This is an old issue, but I vaguely recall this was fixed from inside
nedit. Also, this old issue happened if one simply did a Ctrl+F.
There was nothing more involved. The dialog just didn't have input
focus. One had to click into the text field with the mouse.

Post by Thomas Orgis
I just now verified that the whole of nedit does not get keyboard input
(as focused window) unless I click into the nedit window with the
mouse. One could try to blame that one the window manager, but I only
changed in lesstif for openmotif, not changed the window manager.
Interesting that the Ctrl+F works for nedit, but normal keyboard input
not...

This sounds different. Actually, I'm using lesstif mainly on MS
Windows and can't recall something like this. Perhaps it is indeed a
setting of the window manager (like "sloppy focus" or "click to
focus").

Cheers,
Jörg

[Thomas Orgis]

Am Tue, 24 Mar 2009 00:11:38 +0100

Post by Joerg Fischer

Post by Thomas Orgis
Also, even with the commercial Openmotif ...

I don't know whether or not Openmotif is commercial - it is maintained
by a company currently, so it may well be. On the other hand, I think
Linux is commercial, too. Please don't make the mistake to translate
free software into non-commercial and commercial (which is all fine)
into proprietary software.

Well, I meant "the" Motif, dubbed OpenMotif. The not-really-Free one.
Commercial is not the term...

Post by Joerg Fischer

Post by Thomas Orgis
Hm, so one should also revert the part that made the menu sticky...
Not the case in my build yet.

IMO there are only two possibilities: Either do it right or revert it.
Wishful thinking doesn't help.

That one has been cleared up, see the lesstif bug report.
Well, the "revert" part, not the "do it right".

Post by Joerg Fischer
This is an old issue, but I vaguely recall this was fixed from inside
nedit. Also, this old issue happened if one simply did a Ctrl+F.

My testing suggested taht it helps having switched from/to nedit window before doing Ctrl+F.
But there is a random element.
Perhaps a pointer to the point where this has supposedly been fixed in nedit would be helpful.

Post by Joerg Fischer
There was nothing more involved. The dialog just didn't have input
focus. One had to click into the text field with the mouse.

The focus also being lost on the nedit main window. But then, it's not really gone because the Ctrl+F and friends still work.

Post by Joerg Fischer
Perhaps it is indeed a
setting of the window manager (like "sloppy focus" or "click to
focus").

No, the nedit window(s) has focus. The events are just not treated correctly:-(


Alrighty then,

Thomas.

[Joerg Fischer]

Post by Thomas Orgis
Perhaps a pointer to the point where this has supposedly been fixed in nedit would be helpful.

source/search.c at the end of DoFindDlog()

/* Workaround: LessTif (as of version 0.89) needs reminding of who had
the focus when the dialog was unmanaged. When re-managed, focus is
lost and events fall through to the window below. */
XmProcessTraversal(window->findText, XmTRAVERSE_CURRENT);

At least this is what I meant.

Cheers,
Jörg

[Thomas Orgis]

Am Tue, 24 Mar 2009 00:48:14 +0100

Post by Joerg Fischer

Post by Thomas Orgis
Perhaps a pointer to the point where this has supposedly been fixed in nedit would be helpful.

source/search.c at the end of DoFindDlog()
/* Workaround: LessTif (as of version 0.89) needs reminding of who had
the focus when the dialog was unmanaged. When re-managed, focus is
lost and events fall through to the window below. */
XmProcessTraversal(window->findText, XmTRAVERSE_CURRENT);
At least this is what I meant.

Thanks ... though I wonder how one can split the focus so that the window appears to have focus and accepts shortcut keys but no regular test input.
That may need insight into X11/Motif workings...
Oh, btw: I compiled lesstif-0.91.0 and was not yet able to reproduce this. What I notice is that it needs more time to react to keyboard shortcuts.
I have to press the F in Ctrl+F a bit longer for the dialog to appear, same with Ctrl+Q.
Could be that the speedup in reaction that must have happened has a side effect of loosing focus again.


Alrighty then,

Thomas.