Current Priority List for NXJ

[meister_steve]

Hi,

it's me again. So, as a signum-function will be part of the next leJos release, I now got 2 other wishes:
First, it would be nice to either have the "%" operator working in the next release or at least a method somewhere which implements the modulo operation (e.g. Math.mod(a,b)).
The second one is more like a question: do you plan to support generic class types in future versions or is this not possible. It would save me a lot of cast instructions.

Unfortunatly, I do not know how to contribute something to solve these problems because I'm not into that low level stuff.

Thanks

Steffen

[gloomyandy]

I'm pretty sure that % already works... what makes you think it doesn't?

Andy
PS 0.8 is out now.....http://lejos.sourceforge.net/nxt/nxj/api/java/lang/Math.html

[meister_steve]

Ups ... I'm sorry, I didn't realize that 0.8 was released 4 days ago. I only had a look at the latest revisions in the SVN.

[gloomyandy]

Oh and generics are also supported in 0.8 along with enums and some of the other latest Java features...

If you are still having problems with the mod operator please post a thread with an example over in the main forum and we will take a look at it...

Andy

[Shawn]

Android support!!!!!!!!!!!!!

What could be more beautiful that using your Android mobile to communicate via bluetooth with your robot??????

[meister_steve]

I'm pretty sure that % already works... what makes you think it doesn't?

It isn't supported for doubles. So that was it what made me think it doesn't work.

[gloomyandy]

OK,
I'm not sure why we don't have it for doubles... We certainly have it in the VM for longs... When I get chance I'll take a look at adding it and removing the restrictions in the linker...

Andy

[pEhrlich]

For TextMenu, how about having it accept a Hashtable rather than a String array? Each menu item would have an associated key, and how you respond to a selection would no longer depend on how you order your menu. Seems like much more the proper way.

Also a confirmation dialog (two options - OK and cancel, just like with javascript) would be nice.

Actually, these might be something I could contribute, although I just tried editing TextMenu and its not working out smoothly for me..

[pEhrlich]

The ability to have multiple virtual screens. That is, some kind of screen class that you make instances of. Then you can have your main screen, pop up dialogs on another without disturbing the screen below, etc.

Good idea, no?

Edit: and I'm going to add here request to be able to remove button listeners.. (and bubble up and down would be nice to, but one thing at a time here...) EDIT 3: I just made this. If anyone wants a class that can add and remove button listeners, compatible with waitforpressandrelease, pm me. Mine just probably isin't as fast.

Edit2: And I'm gonna add that you should be able to turn off that awful default beep that comes with button listeners. Besides, if I want to make my buttonlistener do nothing (seeing as they can't be removed...), it shouldn't beep!

[gloomyandy]

Hi,
The virtual screens is an interesting idea. It is actually a little tricky to do at the moment because we use a lot of static methods. However you could do most of the work yourself by creating a new screen class (with an image included in to) and adding methods for the various types of output. You can use the native bitblt function to do all of the hard work and it is easy to use with your own bitmaps. Finally you can then use bitblt to copy your screen image to the real screen when that virtual screen becomes active...

Andy

[bbagnall]

The ideal way to do this would be through the javax.microedition.lcdui classes. A Graphics object holds a pixel set, and the Screen class is used to display it.

Because we aren't fully Java ME there are some non-standard things with the way this works.

[gloomyandy]

Hi Brian,
I agree that the lcdui classes would probably be a good model for this. However you would have to re-work a lot of the existing code so that you can create an image for each virtual screen and then use the graphics context to draw to it. At the moment it is not possible to obtain a graphics context for an image, nor do the drawing routines in our current implementation (of graphics) support the notion of drawing to an image instead they call the static methods I mentioned earlier that will always draw to the screen...

All of this is fixable there is no difference now between an image and the screen they are both Java byte arrays and we have a low level bitblt implementation that can quickly move data between byte arrays in interesting ways... It just needs someone to clean up the code and remove the special case code that writes to the "screen"...

Andy

[burti]

can someone post an updated priority list ?

[gloomyandy]

See the first post... We are working on it. If there is anything you have a particular interest in, let us know...

[pEhrlich]

Here's a thought (something which I would be up for trying myself if it weren't for time constraints): methods/functions/classes for graphing capability. Scatter plots, bar graphs, waveforms, pie charts - maybe even 3d! It would be great to have, to be able to show data directly on the screen of the brick - I could see this being extremely useful for debugging and during demos and expos with the public. It would also be extremely cool because afaik no other languages support it.

Features & expansions could inclue:
- full or partial screen filling
- (If shades of grey) allow lines to have different darknesses
- trendlines/polyfit
- windowing (max/min)
- Fixed window and moving window, with live updating of data!
- different line and dot styles (as seen in matlab)

Thoughts on implementation? Obviously you would want to be doing other things while the data is drawn. Possibly this could capitalize on the multiple screens idea above?

Cheers!!
--Peter