Jack J. Woehr
This project is very interesting and I am tempted to use JCurses to put a preliminary UI on PigIron (http://pigiron.sourceforge.net) esp. to help with testing.
But I find myself modifying the JCurses code, e.,g., trying to make LayoutManager more polymorphic.
Is anyone interested in further development?
bguild2 "I'm glad to clarify. I don't feel that what I am suggesting is a change of scope, merely an improvement of design."
It's not even a change of scope, it's a new project. You're argument is the same as someone saying 'vi' should be improved to make Microsoft Word i.e. misses the whole point of vi.
Instead of clogging up the forum with your religious points of view about a piece of software that doesn't yet exist, go write the thing. Why do I sound annoyed? Because going through the postings sees you endlessly arguing your point and wasting people's time (unfortunately we don't get to see what's in a posting till we open it).
JCurses does what it says - it's a hook to curses, and a simple one at that. Just what people need.
Anyway, back to the problem that brought me to the forum: under Mac OSX 10.5, the bindings in the .c files to ncurses are not working - I think it's about getting the JNIEXPORT etc. stuff sorted. I'll try to fix this, and report back - if anyone's solved it - could you please post here?
I am interested in further development. Even so, I think this project could use a radically new design.
Since I first looked at JCurses and realized how many problems it has, I have been very slowly working on my own private replacement for JCurses. Since that was just one among many projects, I haven't gotten anything usable yet, but I am still working on it.
If JCurses isn't suited to you, rather than writing your own, you may want to look at CHARVA http://www.pitman.co.za/projects/charva/index.html, which has had reasonably recent development still.
It would be helpful for you to document the things you can identify as problems...
Jack J. Woehr
If you want a really full replacement for JCurses, go to Charva https://sourceforge.net/projects/charva
There is no point in JCurses becoming Charva. JCurses was meant to be a char mode drop-in for AWT. Charva is a char-mode drop-in for Swing. Charva wins the "modernity" competition. I'd use my talent for something else before chasing after that parade.
What JCurses can be is smaller and simpler and easier to use. What it can become is cleaner and higher-performing.
Jack J. Woehr
I'm talking to Andy Lewis about becoming a committer on JCurses. Charva looks more full and more mature, but JCurses is a little simpler which is a big advantage in some ways.
I'm in as a developer!
I hope you will give serious consideration to giving JCurses the ability to operate with Java Toolkits in addition to a native implementations.
It's currently an embarrassing irony that a program using JCurses cannot use Java to port to a system where there is no native support. Since JCurses is written in Java, that should be easiest of all. Unfortunately, because of the way JCurses is written, it would be a major task to modify JCurses to allow a Java-based Toolkit.
I don't think it is necessary for the JCurses project to supply a Java Toolkit implementation, but I think it will have to at least offer the potential for such an implementation before JCurses can really be called mature. It will also be a step above Charva.
I'm not sure I follow you here.
Curses is a native library by nature. That is the point of the project - to provide a Java interface to Curses. I have a hard time seeing that as embarrassing or irony. When you use a native library, you are bound to platforms that support that. There is no way around that.
It sounds like what you are asking for is the ability to code to the JCurses API, which is build on top of ht native Curses API, but have it rendered in a Java based toolkit, such as Swing, which would be in effect writing a terminal emulator. Either that, or you are looking for an all Java implementation of the underlying curses library as well. Neither of these was within the scope of the effort any time previously when I was involved, although there were some who suggested the terminal emulator, but it was never pursued. Either of these two efforts whoever are orders of magnitude more complex than providing a Java-based wrapper around curses.
Please clarify what you are looking for here. Apparently you feel the scope of the project should be different then what it is has been, which is fine. Whoever please refrain from derogatory comments. The project had a purpose, and that is what was written to. If you would like to critique how well the project meets its objectives, great. If you would like to propose a different path for the project than what has been pursued to date, great. But please be constructive rather than expressing displeasure that the project goals have not been what you would have chosen.
I'm glad to clarify. I don't feel that what I am suggesting is a change of scope, merely an improvement of design. You understand me mostly correctly, but with a slight misconception. It should be easy to clear up.
"It sounds like what you are asking for is the ability to code to the JCurses API, which is build on top of ht native Curses API, but have it rendered in a Java based toolkit, such as Swing, which would be in effect writing a terminal emulator."
I do want that ability, but I do not suggest writing a terminal emulator. All I suggest is that JCurses be designed so that people who already have Java terminal emulators can use them with JCurses, instead of having to replace JCurses. My notion of irony may be unusual, but I find it ironic that JCurses does not already have that potential.
My reason for wanting that is for portability. I won't go into detail because my motivations do not help clarify my suggestion.
"Either that, or you are looking for an all Java implementation of the underlying curses library as well."
Oh yes, I'd like that too, but I do not suggest writing one as part of this project. I would simply like JCurses to be designed so that someone who already has a Java implementation of the underlying curses library can use it with JCurses, not instead of JCurses.
"Either of these two efforts whoever are orders of magnitude more complex than providing a Java-based wrapper around curses."
I am sure you are right about that. Still, I am surprised that JCurses was written in such a way as to make it impractical to ever extended it to allow for alternative terminal implementations. I would have designed it so that it would be possible to plug in a Java terminal emulator, especially since that possibility had been discussed.
I'm sure that merely allowing for the possibility of a terminal emulator is not orders of magnitude more complex than providing a Java-based wrapper around curses. Unfortunately, I am also aware that allowing for that possibility at this late date would require a major redesign. I have attempted it, thinking it could not be very difficult, but I was mistaken.
Since it is so difficult to modify the existing JCurses to allow for alternative terminal implementations, I do not seriously expect it to happen. On the other hand, since I see that work on JCurses is beginning again, perhaps there will be some major overhauling of the project.
If that happens, I hope you will keep in mind that curses is not the only possible way to implement JCurses. I don't suggest implementing any alternatives as part of this project; I only suggest keeping an open mind while you do any redesigning.
Jack J. Woehr
Again, if you rewrite jcurses/system/Toolkit.java as anything that works, JCurses will run on top of it.
That's the interface. Does it need anything fancier? Do you need anything fancier?
There could be designed a generalized interface for such a thing.
But one cannot generalize from a sample of one.
Reimplement Toolkit.java any way you like.
If it works and can be tested and is awesome, then maybe we should look at the design of a more generalized interface.
"Again, if you rewrite jcurses/system/Toolkit.java as anything that works, JCurses will run on top of it."
In other words, if you modify JCurses it can be made to fit your needs. It's too bad that it doesn't fit your needs as it is, but I suppose that's beyond the scope of this project. I am quite surprised that I'm the only one who thinks that is a bad thing, but it is your project and not mine, so I'll just go back to my own project.
"That's the interface. Does it need anything fancier? Do you need anything fancier?"
I'm not sure what that means. Are you asking if I need something other than a package that needs to be modified before it can be used? If I didn't need something more then I wouldn't need to modify what I already have. Otherwise, I have no idea what you are asking.
"Reimplement Toolkit.java any way you like. If it works and can be tested and is awesome, then maybe we should look at the design of a more generalized interface."
Ascii27net has claimed that such an effort would be orders of magnitude more complex than the rest of this project. Unfortunately, it seems that the JCurses team cannot imagine allowing for something like that without actually implementing it.
Even worse, when I attempted exactly what you suggest long ago, I discovered that it is far more difficult than you might expect. Just creating a Java terminal emulator is about half the work, while the other half is figuring out how to wedge it into a place where only a native curses wrapper is intended to fit.
(Try it an see, if you doubt. Remembering all the issues and explaining them is beyond the effort that I'll put into a project that has no interest in addressing this problem.)
>but it is your project and not mine, so I'll just go back to my own project
Um, I'm only a developer who just got added. I'm not trying to change the world. I'm trying to get a few changes and finishing touches into the project that I need, and in return, I'm sweeping the back room :)
You haven't enunciated a need. You've enunciated a WIBNI : Wouldn't It Be Nice If everything were Pure Java. Yes, maybe, but that's not what this project is!
You want a project that is Java Terminal Control. Java having a very, very, pale, faint notion of character-mode terminals, none really at all, that's a Large Task. I wrote something like that years ago, a Pure Java remote mainframe record file editor called MEU that's I think still distributed as an Example with JTOpen http://sourceforge.net/projects/jt400 ... I know whereof I speak!
Again, if you want it, welcome to the Open Source World! All you have to do is rewrite jcurses/system/Toolkit.java in pure Java and you have what you're asking for. You want the "JCurses team to plan for it" but the team is, apparently, anyone who is reliable and trustworthy and responsible and wants to do some coding. I'm the only one doing any coding so far in 2008 :) Here are my priorities, and I think ascii27net concurs:
Javadocs ... working on this. Makes me visit all the corners of the code!
Polymorphism in layout mgrs
Various feature requests that make sense.
"You haven't enunciated a need. You've enunciated a WIBNI : Wouldn't It Be Nice If everything were Pure Java. Yes, maybe, but that's not what this project is!"
I don't know if it really serves any purpose for me to comment upon what I've already said here, but it probably doesn't hurt to briefly combat misconception. It would be nice if everything were pure Java, but that is not what this project is, and it's also not what I've been suggesting.
I've tried to clarify my suggestion already and made it quite explicit that I'm not suggesting that JCurses become a pure Java terminal package. I don't know how I failed, so I'm not going to try again.
Jack J. Woehr
>I don't know how I failed, so I'm not going to try again.
Oh, who knows? online conversation essentially sux. We talked past each other. I think no less of you, Brendan.
You have exciting ideas around aspects of computing that have lain in neglect. Character mode interfaces are
very efficient. See suckless.org's dwm window mgr, e.g. If you get into the bigiron, see i/OS formerly called
OS/400 etc. etc. which has IMHO the most advanced character mode UI in the biz computing world.
My goals are very limited. I'm working on a very kewl open source thingy PigIron and I need a char mode UI for
getting other folks testing along with me.
JCurses is great for me not because it's complete or perfect. It's great for me because it's at a level of development
that I can jump in at very comfortably, its original developers could use a hand, bingo. It's win-win.
Thanks for livening up the discussion. Please stay engaged with JCurses.
>I'll just go back to my own project
BTW, what's your project?
If you are going to write a terminal in Java you should look at two projects:
The first is part of, or related to, tn5250.
MEU is mine, the latest (from back in 2000!) is part of the big package http://www.softwoehr.com/softwoehr/oss/index.html#Packages.JTOpen
Those look like interesting projects! I will have to take a closer look at them.
My project is pretty much exactly JCurses with the improvement that I've suggested, plus a bunch of other relatively minor improvements.
It does not include a terminal written in Java, though I expect I will add one eventually.
A project that you might be interested in is lib_jcsi. It's a wrapper around JCurses to add the feature that I've suggested. They realized that it was impractical and undesirable to modify JCurses to be more flexible, so they use it as a primitive back end instead. In addition to all that, they even include a Java terminal emulator.
Also, what we need are TESTERS .. I want to make changes and people who have JCurses-based apps should test build and tell me if I've broken anything!
Oh, as far is JCurses having native components, not pure Java.
Who cares? Embarrassment? That's ideological. It's not that big an inconvenience.
The point of JCurses is and was to find an EASY way to do char and line-drawing on a terminal window. Why break one's butt to do it in pure Java? That's NOT EASY.
Okay, let's say there's a Java OS somewhere. Cool, just write a replacement for jcurses.system.Toolkit and JCurses works instantly in that env.
Does the package compile and run on a solaris server ?
Most of the information that I have seen relates to linux and windows.
Jack J. Woehr
There's only one component that is native. The rest is pure java.
As the README file says:
Steps to compile the library:
Try it on Solaris. I think I did build once on OpenSolaris. It should build. Let me know.