Future of NEdit?

Tim Hubberstey myredirector at gmail.com
Tue Nov 27 11:20:16 CET 2007


On 2007-11-26 15:37, Erik de Castro Lopo wrote:
> Aaron Hsu wrote:
> 
>> Why does low market  
>> share on the toolkit for Open Source communities indicate a bad  
>> toolkit or a problem?
> 
> Because if there are a large number of people relying on a piece
> of software bugs get found and fixed.
> 
>> One thing I think should be done is to provide proper resource files  
>> to help "integrate" the look and feel of NEdit into various systems.
> 
> In comparison to having a stable, reliable editor, I really couldn't
> care less about how it looks. I'm rather surprised you even bring
> up look and feel issues in a thread where I've been talking about 
> nedit segfaulting left, right and center.
> 
> Erik

I run NEdit 5.5 on Win32 with Cygwin and a commercial X-server. I 
haven't had a segfault in ages.

I am not an application software developer (I occasionally do embedded 
systems programming and firmware) so I don't know the ins and outs of 
packages, dynamic linking, etc. and I may say something really stupid.

 From what's been said, the issue seems to be primarily with a 
particular flavor of Linux. Would it be possible to statically link 
NEdit to the commercial release of Motif? I would be willing to 
contribute to acquiring a license for the NEdit project if it would 
solve these kind of problems. I know it would make the image file larger 
but NEdit is still tiny compared to many of the bloated applications out 
there.

Or, how about adopting one of the least buggy versions of Lesstif for 
static linking and figuring out how to work around the bugs, possibly by 
writing "wrappers" for troublesome calls. After all, the feature set of 
Motif is "carved in stone" so there's no need to worry about 
enhancements -- all it needs to do is work.

Or, is it possible to emulate Motif with wrappers making calls to the 
toolkit(s) of choice? Speed of execution is no longer an issue given 
today's processor speeds.

My point is that there must be ways of dealing with these problems that 
don't require scrapping huge chunks of the code base. I know it won't be 
clean of pretty but we users really don't care much about that, we just 
want it to work.

Tim



More information about the Discuss mailing list