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