Motif (getting nedit to work with lesstif)

[Thomas Orgis]

Am Wed, 4 Mar 2009 16:37:11 +0100
schrieb Joerg Fischer <jf505 at gmx.de>: 

> I heard this proposal before, too. But again, for lack of time even
> a source release is pending, so who is talking about switching toolkits
> or developing just another one?

Yeah, let's talk about Unicode support again;-)
Actually, does Motif pose a problem with that or is it only a matter of nedit pulling the right strings for text display (apart from the internal handling)?

> So, perhaps someone (you?) could trace the crash, and perhaps find
> out that it's just a typo or a missing check for null pointers?

I found the same bug report for xmgrace... but there a report pointed me to interpret the debugging output of lesstif with regard to the names of the menus being popped up/down.
Thing is, nedit crashes because it tells to pop something down that is not down.

XmRowColumn fileMenu: _XmMenuEscape()
XmRowColumn fileMenu: _XmMenuEscape()
XmRowColumn fileMenu:     Menu      fileMenu (XmMENU_PULLDOWN)
XmRowColumn fileMenu:     Menu      fileMenu (XmMENU_PULLDOWN)
XmRowColumn fileMenu:     must be a popup
XmRowColumn fileMenu: activeChild: (nil)
Speicherzugriffsfehler

There is no active child of fileMenu to pop down, because in that case I have been in the edit menu instead.
Pressing ESC kills nedit for every menu _except_ the file menu... you get the idea already, I'm sure.
Let's look what happens when opening the file menu (hotkey or mouse, does not matter):

XmRowColumn fileMenu: MenuFocusIn
XmRowColumn editMenu: MenuFocusIn
XmPushButton paste: FocusIn()
XmRowColumn fileMenu: _XmVirtKeysHandler
XmRowColumn fileMenu: _XmVirtKeysHandler

... and later, on closing with ESC:

XmRowColumn fileMenu: _XmMenuEscape()
XmRowColumn fileMenu: _XmMenuEscape()
XmRowColumn fileMenu:     Menu      fileMenu (XmMENU_PULLDOWN)
XmRowColumn fileMenu:     Menu      fileMenu (XmMENU_PULLDOWN)
XmRowColumn fileMenu:     must be a popup
XmRowColumn fileMenu: activeChild: (nil)

Well... that should editMenu, or shouldn't it? Could that be nedit's fault?
What would cause the fileMenu to get focus when popping up the edit menu?
(I am posting these questions rather here than on the lesstif bug tracker as here somebody might actually care. We can copy over conclusions later... for historic reference.)

I don't have time now to investigate more... perhaps someone here has an idea already.

The issue preventing any nedit usage (avoiding ESC in menus, even) for me now is that one:

NEdit warning:
XmClipboardCopy() failed: XmClipboardStartCopy not called or too many formats.
NEdit warning:
XmClipboardEndCopy() failed: XmClipboardStartCopy not called.

...every time I try to copy something with Ctrl+C . Middle-mouse copying works.
Those messages somewhat imply a failure on the application side (API usage)... is this correct?
Could it be that copying worked only by chance before?
I must add that someone on x86 with ArchLinux (nedit 5.5 and lesstif 0.95) did not have trouble with copying stuff.
Perhaps this bug is only surfacing on x86-64 Linux or with my specific set of modular Xorg versions. 

Oh, and generally... try to run nedit with valgrind and you see _lots_ of conditionals that depend on uninitialized variables inside lesstif. Someone more familiar with the lesstif source would be far quicker than me in tracing these.
But, looking at the lesstif bug tracker... I wonder if there is anyone familiar with lesstif source and still caring.
Oh, and I fixed a memcpy() with overlapping memory in my local copy... 

> > > Actually, the sources you got is the
> > > stable nedit by now.
> > 
> > So one can just name it as such and put out a source tarball?
> 
> You know the license. It's just a matter of wording whether to call
> it beta, under development (and scare users away) or to find some
> more neutral terminology which doesn't claim the thing would be
> unstable so you couldn't use it for real work.

So, please, can someone with access to the nedit website just edit the version bit (5.6-beta ... or just 5.6!) and put up a tarball? 10 Minutes of precious free time for free software?
As I said, our distro wants to give people the stable upstream default if possible. The nedit-latest tarball is an official URL but it is volatile (we like to check for file integrity automatically), same goes for direct CVS.
I just verified again that any CVS snapshot cannot be worse than nedit 5.5 for my system ... it won't start up at all. Some X FillRectangle bad parameter thingy, being fixed in CVS.
If it is really impossible to fix up some kind of beta/rc tarball at least, I will have to grab a snapshot and upload it on my own to our mirrors, leaving upstream, which is plainly defunct for my current system.

> > That is a bit sad as in those extra features kept in private ... ?
> 
> Come on, there is a patch tracker on SF, don't you know? It isn't 
> unusual, if you don't get things in a release to patch the sources
> to your liking and use that instead. Come on, I'm sure you know
> it's free software ;-)

Well, of course I can hack stuff together, but as distro packager I care for users who want to have features in the release version eventually. As long as patches are either included or discarded after some time, it's fine, but I don't think it's good to keep patches around forever as a development model as mutt does (after a certain number of patches you have to encounter some conflicts at least, patches getting stale with newer releases ... ).
And also, as a user on different machines, managed by different admins, I'd like the version of nedit installed there to work with an acceptable feature set by default... while of course I have a patched nedit running atm. at work in my $HOME, too.
I see a danger of developers always using their hacked very own nedit (with their very own stable lesstif snapshot) and so forgeting about anyone trying to use the actual offifical version of nedit (and lesstif).
Soon there could be noone trying anymore... nedit is already obsolete enough because it cannot do Unicode, why make it worse by not releasing numerous fixes (and potentially well-tested added features) already in CVS?

Alrighty then,

Thomas.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://www.nedit.org/pipermail/discuss/attachments/20090305/8c9e341a/signature.bin