I just updated my gbui source from SVN and I've gotten a couple of compile errors. I've noticed that BImage has gone from referencing BlendState in version 154 to AlphaState in 159.
Do I have that right? If so, I'm curious why the move back?
hmmm. That may have been my fault. Sfera did the work to update to 2.0, and I was doing work to update other code and I would have overwritten it… it was not an intentional overwrite tho
I'm trying to get Sferas changes merged with mine b/c I checked in on the trunk and not a branch.
It should not have been back.
timo
I'll let you keep working on the merge then: I've found a number of other references to jME 1.0 (BaseTest and TwoWindowTest), plus some I just can't explain.
Good luck!
Yeah, that would be bad. I thought Sferas changes were on a branch as well as my changes… both assumptions were wrong (a$$ out of u n me held true). The project online holds a diff of what he changed so I should be able to just make those changes quickly and they'll be in sync.
http://code.google.com/p/gbui/source/detail?r=154
As you can, and have, seen I've been making a lot of changes including quite a few merges from other sources from submissions from other people as well, so I've been trying to keep them all as sane as I can with the check ins.
I'll get the merge with the 2.0 to trunk tip tomorrow.
I have reapplied the JME 2.0 changes Sfera did and given the GBUI svn tags for jme 11 and jme2.
Jme2 will the trunk tip from now on, I think. Retroactive code changes will be branched from there I would say.
I've run the test changes that were done and they all seem to work just fine locally.
let me know if you have any other issues that come up.
timo
BStyleSheet.java is no longer in the srcjavacomjmexbui directory, so I'm getting a ton of compile errors trying to resolve BStyleSheet. Was that intentional?
Some more info. I updated my entire gbui source to revision 191 so I could start with BStyleSheet.java back in my code tree. BImage had errors since it referenced AlphaState. I knew it didn't have this problem in 192, so updated that file to that level. ImageBackground then threw some errors so I bumped that up to 192 as well. I worked through errors with other files as follows:
- srcjavacomjmexbuibssBStyleSheetUtil.java
revision 160 good
revision 174 not so good
- ImageIcon
revision 192 good
revision 191 not so good
- TwoWindowTest
revision 192 good
revision 191 not so good
- BaseTest
revision 140 good
revision 171 not so good
- GeomViewTest
revision 192 good
revision 191 not so good
- LayoutTest
revision 192 good
revision 191 not so good
- JMEBitmapTextFactory
revision 192 good
revision 191 not so good
- srcjavacomjmexbuiutilTokReader.java at revision 165
revision 177 good
revision 178 not so good
the BStyleSheet.java was actually replaced with BStyleSheet.groovy… you'll just need to update your cp with the groovy lib in the lib dir and that'll fix your compile issue. I wanted to introduce that to remove a few bugs that are in there while I'm rewriting the parser, which will be much faster with Groovy. You won't need the parser jars right now but they're there because I've got the parser working, now I need to plug it in for CSS.
The the issues you have are errors and not warnings?
I get one warning when compiling and that's on getClassTag b/c the getClass() doesn't extend <Spatial> which is a place holder, should have left it null I guess.
Do you have the files for provider and property?.. they were checked in with the change to BStyleSheet. You can most certainly use those versions of BStylesheet and the ones below, but I'll be running with the Groovy version from here on with the changes coming through… all of the unit tests I'm introducing are GroovyTestCases as well.
The reason for ripping out the provider and property classes was two fold (1 because Groovy doesn't support inner classes, and 2 because BStyleSheet didn't need the inner classes to function and the goal is to streamline the parsing so the logic for that has been streamlined)… but shouldn't have any impact on the performance at all. So far, hasn't with all of the tests I've been running (both in speed and rendering performance).
I need to actually do these changes on the branch, I hosed up with the check in as SmartSVN blows up with JDK 16 on my machine right now and IntelliJ hosed me with my creating a branch, so the BStyleSheet change should have been a Java file with the removed inner classes. You should only have to change the extension of BStyleSheet and add some semicolons to the end of lines of the imports. If there's more let me know.
I'll be on later tonight. JIC I don't get a notice while I'm dorking things up, send me a pm as well to let me know, that way I don't forget or some other tragedy, please:)
let me know how this change goes for you.
timo
Hmmm. Apparently I need to learn more about groovy. I saw the BStyleSheet.groovy file, but I don't think Eclipse knew what to do with it, so it just complained about not being able to find the definition for the BStyleSheet class. And the rest of the errors just cascaded from there. So if I add in the groovy lib, the compiler will somehow know what to do with the .groovy file?
I'm just sitting down at my work computer so I don't know whether or not I have the files for provider and property. It'll probably be about 12 hours or so until I can check. It sounds like the lack of groovy is the root of most, if not all, of my problems now so I'll dig more into that issue.
I've got some good news for you. Here's what I did:
- Did some playing around with different revision levels. Found that 158 was happy, but 159 not-so-happy since jME 1.0 references had been re-introduced.
- Did a bit of Googling and ended up installing the Groovy plugin into Eclipse.
- Had to reboot my machine because of the install.
- Changed my default VM to the JDK instead of the JRE, based upon another Google search into the reason I get a JAVA_HOME error trying to run the gbui build.xml. Then had to wait for Eclipse to rebuild my entire workspace.
- Updated my gbui source to the latest revision (192).
- Refreshed my gbui project in Eclipse. At some point it asked if I wanted to integrate Groovy with it. I checked yes, waited a minute, and the project seemed to have compiled without errors. Hmmm… Ran the HoverTest and everything looked good!
- Changed my project to reference the source again and it ran too!
So it looks like the latest revision is good once everything is set up right. The problem right now is that I still don't know what Groovy is or why you're using it, and exactly what did I do by installing the plug-in that made everything work? I don't like that.
But the good news is that it works, and I can get back to my code while I slowly try to figure out Groovy on the side.
hmmm that 158 and 159 change isn't good. I'll look at that was that BImage still?
The Groovy plugin is only for the syntax editor in Eclipse and I am not sure what else the plugin does, but I believe it adds other support for Groovy as well. http://groovy.codehaus.org/Eclipse+Plugin
I've been using Groovy for over 3 years now and if I have a preference I'll take Groovy over pure Java anytime for speed, code size and the additional capabilities and syntactic sugar that Groovy has.
I don't like what you had to do to build with Eclipse tho. That's going to make me rethink some things. I use IntelliJ and have no problems with anything that you had to do. I even run the ant build from the command line often.
I don't like this Eclipse build thing tho, not one bit.
I'm pretty sure that BImage was just one of multiple files in version 159 that had references to jME1 classes. Since I already sort of knew that it was broke though, I didn't worry about it too much. And now that the tip works, I'm even less concerned about 159.
If it's any consolation to you, what I had to do in step 4 (change the JRE reference to JDK), I don't believe had anything to do with your code: as far as I can tell, this is just the fix for a known Eclipse "feature".
So if I understand you correctly: Groovy is "just" another language that shares much in common (in terms of syntax) with Java, but otherwise it is it's own language, not dependent on Java. You're using Groovy because you like it's syntax, but not necessarily because it gives any cool features you couldn't otherwise get from Java. This is no different from using any other language (I'll choose C++ as an example) that, with the right compiler to create the bytecode, can be used to create a library useable by a Java application that I'm writing. The Groovy plug-in lets me easily include groovy code files in the same project as java files, and compiles them all together. Am I close?
Nuts!
Groovy/Eclipse is kicking my butt again. I wanted to be sure I understood what was going on so I could rewrite my tutorial and now it's not working again. I deleted the gbui project and recreated everything from scratch. Whatever magical thing that Eclipse asked me after installing the Groovy plugin, it didn't ask me again. And now most of the project is complaining about lack of definition for BStyleSheet. I notice that if I set the Groovy output directory to bin, that a BStyleSheet.class exists, so I would think everything would be happy, but apparently not. So I'm wondering: does Groovy take the BStyleSheet.groovy and compile it to BStyleSheet.class, or does it take the BStyleSheet.groovy, create a BStyleSheet.java, and then let the compiler treat it just like any other Java file?
The irony is that if I run the dist target from build.xml, it succeeds. I can then reference that jar (and the groovy jar) from my other application, and everything works good. Just Eclipse isn't happy with the gbui project. Hmmm. I'll keep digging.
Groovy uses AST and compiles directly to the class file.
Thx for digging into this… really, you should be coding. If it's that intriguing I guess keep going, but you could just change the extension and change whatever java syntax errors there are (shouldn't be but a few missing semi colons at this point).
I'll look at the 1.0 changes that are in BImage right now.
I know I should be coding, but the way I figure it is that I've been trying to write my "own game" for more than 26 years, with very little to actually show for it. I think I've determined that I probably never will finish anything, but I'm learning a bunch of different things along the way. It's a nice hobby.
I did some more work with Eclipse last night and got everything to work again, but by the time I did I really needed to get to sleep. Then today was one of those days, and then I called my family, and now here I am. :) I've gotten the project to compile and run at version 192, and I've put what I learned into the tutorial rewrite I'm working on. The problem with BImage was in version 159, and it's working again in 192, so I don't think there's even a problem any more for you to look at.