Hello,
WidgetSlider and accompanying modules have been committed to CVS.
WidgetSlider is basic and doesn’t have a lot of features yet. It has minimum, maximum, and value, it can also notify Observers of a value change.
TestWidgetSlider demonstrates WidgetSlider.
While developing WidgetSlider I made some changes to the Widget rendering that eliminates the need to add a method to Renderer for every unique Widget. A Widget now supplies a WidgetRenderer that knows how to render the Widget on a specific platform. WidgetRendererFactory instantiates the appropriate WidgetRenderer for a Widget.
I also started using a texture that contains transparency for rendering the slider thumb which required adding the ability to detect an alpha channel to TextureManager.
I made several discoveries and architectural changes in the GUI that will ultimately lead to the implementation of ‘look and feel’.
I touched a lot of Widget modules. If you have any problems with anything let me know.
Thanks,
Gregg
Great job Gregg. Sliders are incredibly smooth and precise. I love them. You said you got the look and feel going? Do you think could write up a test on chaning the look?
P.S. Eric could you update the webstart with the latest build, I’d like to get the slider demo up on the demo page right away.
Actually look and feel isn’t going yet. I just figured out a way I can do it. 
Look and feel for the entire GUI will take a while to implement. I intend to implement new Widgets with look and feel capability and retrofit the existing ones as I get time.
Gregg
Ah, I see, cool. No hurry, just misread it.
One more note. I do like the new system for rendering. But do you think that WidgetRenderer should go in the Renderer package or remain in the widget package? This is mostly a question, as I’m not sure myself. Either way, it really cleaned things up.
A post on the front page about it’s addition and soon to be added demo would be good. Would you like the honors?
I’m leaning towards leaving it in widget for now. But I’m like you, I’m not sure which place is best. I might change my mind after I think about it some more.
As far as posting the announcement, I don’t have the url here at work. I don’t mind doing it, but it will be this evening before I can get to it. So, if you want to go ahead and do it, it won’t hurt my feelings. What ever works for you.
Gregg
I’ll wait until Eric has the latest webstart up, so that will probably be this evening anyways. So you’ll be able to do it still.
I’ll rebuild and upload the new version just as soon as I get home. I anticipate that’ll be around 6PM my time. I’ll also update the demo page with the slider widget. (Unless you’ve done it already?)
Hi Gregg.
Slider doesn’t work with webstart because the graphic for the pointer is not being loaded with the class loader. Also, the image is in the source code itself and that “might” prove to be an issue but I’m not sure yet. But in order to get webstart working on it, the image needs to be loaded via URL. The link for the slider demo is on the page though.
Howdy,
So far I’ve been blissfully ignorant of WebStart requirements. I guess that needs to change. ://
I tried to load the graphic with TextureManager the way I saw it being done in some of the other test apps. I put the image where I did, comjmewidgetlookandfeeldata, because I thought the classloader could get to it, since it’s in the same package path as the class files.
I’m not particularly keen on putting it where I did, but DefaultLookAndFeel.png, like Default.glf, are core GUI files, meaning they have to be there for the GUI to work.
I’m not comfortable putting path references to the jmetest package from the com.jme package. For instance I have the path jmetest/data/font/ hard coded in com.jme.widget.font.WidgetAbstractFont to load the font file. I’m not sure how to get around this issue but I would like to avoid modules in the com.jme package having dependencies in the jmetest package. Maybe there is a way to externalize path references for core files. We’ll have to think on it.
In the mean time, I’ll move DefaultLookAndFeel.png to jmetest/data/lookandfeel, if you think that’s an appropriate spot, and change the code to point at it.
Sorry for the inconvenience.
Gregg
I changed the path to jmetest/data/lookandfeel for loading the slider graphic.
Let me know if I need to change anything else.
Gregg
Gregg, I think you are absolutely right. We don’t want GUI API relying on the JmeTest module. That makes no sense. So, I agree, both Default font and Default pointer files should be in the main source tree. However, you’ll still need to use the class loader getResource method to load them for webstart. But, putting it in a default lookandfeel directory is a better idea than putting it in test.
Mark,
Do you mind taking a look at the code in com.jme.widget.renderer.WidgetAbstractRenderer that loads the graphic to make sure that I am doing the way I need to? I tried to follow the example of some of the other apps but I may not be doing it correctly.
Thanks,
Gregg
Gregg, loading was just fine, but I changed the directory back to com/jme/widget/lookandfeel/data/
as discussed earlier. I went ahead and checked that in, the test works fine. Next build it should also work via webstart. I hope.
You should probably go ahead and put the Defaul.glf file into the same directory and modify the font loader to look at that directory. We can keep all the default lookandfeel stuff in that same directory.
Thanks Mark.
I’ll move the font file tonight.
Gregg
I went ahead and took care of the Font move Gregg. So, everything for a default look and feel is in com/jme/widget/lookandfeel so you can just put in new default images in there.