Motif
Thomas Orgis
thomas-forum at orgis.org
Wed Mar 4 01:48:55 CET 2009
Am Tue, 3 Mar 2009 21:02:30 +0100
schrieb Joerg Fischer <jf505 at gmx.de>:
> > How tight is the dependency on Motif in nedit, btw? Would it be
> > possible to restructure nedit to work with another toolkit, without
> > killing it's leanness and speed?
>
> You aren't the first one thinking about switching the toolkit.
I am somewhat aware of that. For sure these are not new questions.
> Unfortunately,
> for the pending 5.6 release there is nobody who kicks it out the door.
So somebody needs a kick? Would 20€ donation count as motivation?
> So, migrating, or rather completely rewriting, nedit to another toolkit
> just needs some volunteers. The code is in CVS.
Volunteers could do so much in this world... I don't know if I can
afford this, being busy with too many things already.
For sure I could not justify additional sleepyness at work due to
nights of coding yet-another-editor:-/
I'd trow in a donation, perhaps bet funds on a project on
http://cofundos.org ... And I'm quite sure that I could not resist
hacking in some bits myself once I feel it's going somewhere (at least
I have a patch of myself in use, facilitating different window names
for different nedit servers, giving my window manager better control
over my nedit window groups).
> I also thought about fltk since it uses already parts of nedit's
> text editing widget.
Yeah, and sadly, it seems to be unsure if FLTK 1 or FLTK 2 is there to
stay... unclear development situation.
> Moreover, fltk is small and fast.
What I am trying to get insight on currently is the speed of nedit. For
some reason its text display is extremely fast compared to other
editors.
Medit (gtk) and kate (qt) are scrolling through a 2.5M kernel ChangeLog
a lot slower than nedit, for me at least.
It could be that my current Xorg setup and video driver play tricks
with 2D accerelation features, but the others feel so clearly less
responsive that I am wondering if people just have more patience than
me or if that slowness is inherent in the toolkits or display of
Unicode or using scalable fonts.
At least dillo2 seems to perform quite well with scrolling through the
huge text file... actually slightly faster than nedit.
That is using scalable fonts with anti-aliasing.
So it seems to be possible to get this done right, but strangely other
editor programmers don't seem to care (really, kate is an extreme
example: hold down the page down key for a while, release --- kate
keeps scrolling down, having buffered all those key events, rendering
X11 totally unresponsive until the scrolling is done).
Seeing how nedit and dillo2 get it right (perhaps dillo2 inherited
nedit's code somewhat through fltk?), there seems the others getting
something wrong about display and interaction. And rendering speed at
all.
> Motif/Xt nedit.
Well, rewrite using plain Xt? Do what GIMP did once -- the nedit tool
kit! ;-)
> something like "because there is no console version of nedit".
Though I insist on using it in conjuction with a console -- opening
files via the client;-)
But I know you didn't mean that and indeed you raised an interesting
point, in line with my justification for using a GUI text editor:
Exactly because it has controls beyond the text interface, easing
the manipulation of the text world from the outside.
> But I rather like to answer some real question: Personally I use
> a lesstif checkout with the version number 0.93.95. However this
> isn't the released lesstif version with this number, but was
> grabbed from CVS a few days or so before the "official" release.
If this is such a nice snapshot that has proven to be stable... could
you provide it to me (email is fine, ftp upload whatever)?
I guess one needs to adapt the current patch for libxp we have, but
maybe there's a chance to switch to that lesstif in our distro when I
can justify that it's more stable for the apps that actually use it.
Would solve the problem at hand...
> 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?
Binaries can follow... once I got a stable Motif I could provide some
for Linux/x86, x86-64 and Linux/Alpha ... heck, even Tru64;-) Oh, and
Solaris 9/10 (SPARC, x86-64), too...
> [Seriously, I run a patched (for extra features) version of
> these sources stably since probably years, and I presume
> I'm not the only one doing so...]
That is a bit sad as in those extra features kept in private ... ?
-------------- 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/20090304/fa10615e/signature.bin
More information about the Discuss
mailing list