DarkMonkey Dev Blog - [Completed]

##02/13/15 How to Make a Cool Netbeans Module Description##

On the Programming Side and Artistic sides, wouldn’t it be cool to have an awesome looking plugin description for when you contribute? It’s okay to have the one liner description… just sayin’. I touch upon a lot of things to consider when deploying a netbeans module, but the key thing I’m focusing on is The Netbeans Long Description.

On to the video!

edit: oh wow, I just found an “easier way” :chimpanzee_facepalm: see below

So things to take away from this video:

  1. bundle.properties is the key file to focus on for making things look cool. and the long description is the one to heavily customize.
  2. the rest is pretty much educated guesses: I’m still learning. … see below
  3. including this statement: Keystores are stored on servers and certificates are verified upon the servers. for .nbms it may be called tokens… see below…
    4: including this statement: It’s probably easiest to set your project license in the project properties window… from somewhere… edit: found it… see below…
  4. including this statement: localization is more done with something like:
    OpenIDE-Module-Long-Description_fr=Something with french fries…

Supporting Links referenced in Video:

https://vellum.googlecode.com/svn-history/r377/wiki/blog/swing/Webstart.html

and below,

… yeah, project properties… probably easier, and more reliable. oh well, I learned me something new…

Next up, I think I’ll tackle correct reference for Modules vs normal app. edit: scratch that I’ll just give a heads up on the uberest cool thing that I learned for java so far… edit: double scratch that I’ll just put it here.

edit: now that I’ve rested from my coding/video producing bing I have a bit more brains to add to this blog post. Ok so in the following code, I went with a public static method, because it serves as a utility function that is specifically geared to netbeans class loader system. In netbeans, every module gets its own class loader. I think that the Lookup is mostly an openIDE class… I think. So, to cover both Netbeans and non-open IDE situations this method takes the calling object’s class loader as the base refObj, and uses the classloader, instead of a typical lookup. This is especially useful for LookAndFeels which need the ability to run in a non-netbeans environment, yet this one will support additional modules to be able to be tacked on. In other words, this is part of the architecture for the modification page slated for future dev. Read: I may make an API for Darkmonkey where folks can override w/e drawing components that they want.
Typical Simple Usage envisioned: Image overridenCloseIcon = DMUtils.loadImagefromJar(this, “resources/myCloseIcon.png”).getImage.getScaledInstance(myDesiredWidth, myDesiredHeight, Image.SCALE_SMOOTH);
Processing Result: It will look in the jar file of the refObj, and look for a folder in that classes package… so if the refObj is for example: com.jumpy.herp.derp.DerpyLaFIconFactory.class…
it would look for: com.jumpy.herp.derp.resources.myCloseIcon.png. And then with the .getImage(), convert from BufferedImage to Image, and then with the getScaledInstance(), create a new Image scaled down to w/e size is in myDesiredWidth, myDesiredHeight, and finally assign it to the Image overridenCloseIcon.
Yay! I love having some sleep n rest! LOL

public static BufferedImage loadImagefromJar(Object refObj, String fileName){
    BufferedImage bi = null;
    try {
        bi = ImageIO.read(refObj.getClass().getResourceAsStream(fileName));
    } catch (IOException e) {
        // File is probably referenced wrong... lol.
        e.printStackTrace();
    }
    return bi;
}

and done… I’m heading back to code now… I want to keep going on learning draw calls so I can show off the processing for that image…

##02/20/15 - palletSwapARGB8 is finally functional…##

though I consider it’s behavior to be buggy/incomplete. The work around that I have going on at the moment is to send a “clear to” color alongside the pallette of colors, for better blending purposes. The main problem seems to stem from my usage of a Method that I believed would return the Alpha value that was set along with the color… this is not the case… it defaults to 1f. grrr. oh well.

So, the first half of the vid is showing @nehon how his artwork got processed, and some of the immediate “tweaks” that I could suggest. The second half is a breakdown of the palletSwapARGB8 method.

On to the Video!

And the two things I forgot were:

  1. to show the bug in action with the blending… the demo was with workaround active. Thus, my problem was not viewable.
  2. oh, right… the “done once” … it stores a copy of the final result before painting on the factory level. so draw calls after that first processing…is only called for the already processed result… It will reprocesses when told to by a null constructor call (UIResource Interface)

##02/27/15 Talkin’ bout Netbeans FAC and modules.##

Premumble:
So, when I thought of the whole “Dark Theme” I knew that I would be covering the LAF for the major interactions and the FAC for Netbeans editor to profile the full theme for the upcoming SDK. So, though the LAF could be detached from the project and used in other java programs through proper class pathing and the --laf switch from the command line… The FAC only applies to Netbeans and it’s Editor. So, when i went to find an example in module form, @venkatram_akkineni’s ez-on-da-ice plugin was the only one I found that did so. He did it very well, and this is more a comment on the form. I studied his source and saw that it was his learner’s project: Something that you do in a form that retains errors and artifacts for people to learn from. Clean design is best for a community project and relies upon heavy documentation so others can “get up to speed” and “pick up the ball” with what you had in mind. However, you can’t really learn from that type of format (which is why it HAS to have heavy documentation). So, let’s get more specific about FAC, now.

FAC themes can be shared by users by exporting netbeans settings in a .zip file. That was the form that I originally received obsidian in. It is also the form that I received @nehon’s latest color corrections for the FAC side.

This is not the form that a module wants to try to accept, however. The Fonts and colors api for editor settings is a “friend” status or better type thing over at netbeans. Most likely because the settings has two sides as well… the FAC side and the Keyboard Shortcuts side…(@normen I can help ya out with that proper emacs shortcut declaration if you haven’t got it already taken care of). So yeah, they probably didn’t want the public running around making inadvertent architecture calls on a forming system.

So, here is the best way to include a complete FAC in a nebeans module, atm.
include a layer.xml file to your project and simply place the appropriate FontColors-for-editor.xml files in the right spots and make sure to add the appropriate attr tag for the editor module’s benefit (it’s token, highlight, or annotation, atm) Token is based upon the idea of a “word” or assemblage of characters to represent a full idea. Highlight is based more upon positions in the document. Annotation is based more upon “stuff that gets sent to other modules from the editor” like the editor’s sidebar, ant, pom, debugging, git, subversion… etc. So that’s the rough structure of FAC and how it goes into netbeans, if it made any sense.

That pretty much wraps up the text bit… onwards to the video that you don’t really want to do midproject because you look kinda stupid afterwards but also is the best time to show why certain decisions are being made! ← worst sentences… me.

-Yeah, I realized that I had an error in code… lol. After watching the video… (I also saw where I seriously “derped” and got derailed… It’s a bit of the balancing beam act to present the knowledge as fast and as sensibly as possible…) I had forgotten to remove an ‘s’ from the:
file name=“DarkMonkeyFAC-text-x-java-tokens.xml” url=“fac/DarkMonkeyFAC-text-x-java-tokens.xml”
so… uh… yeah…
file name=“DarkMonkeyFAC-text-x-java–token.xml” url=“fac/DarkMonkeyFAC-text-x-java–token.xml”
and fixed.

2 Likes

Hey

Thanks for the tip. I knew that there is no need for specific directory structure inside the code. What you are looking at is what netbeans calls a file system, specifically XMLFileSystem. It has more than one file system. Look at File System APIs for more detail.

However I created those directories to make my life easier. I developed the theme inside my development IDE, I mean, I would go to the Options window and change colors save, verify inside the editor & repeat the process until I was done with all the colors.

Then I would export it, unzip it & then just paste it inside the source directory, that’s all I had to do. If I used just one file, with each iteration of improvement of the theme I would have to manually add those colors to that one XML file which is a massive pain. So, once I had that directory structure in place, I would never have to touch it again, or the xml file. I would merely fix the colors in the Dev-IDE export-unzip-paste into source directory.

Nice, your laf seems to be coming along nicely. I see you have used NimROD. ez-on-da-ice used NimROD in the beginning. I had to take it out because it has some compatibility problems with Netbeans. Hoping you realized that and fixed them.

Goodluck
Venkat

3 Likes

Amen to this:

IKR!?

yeah, that’s the biggest advantage of single responsibily / single author projects… We can get stuff (<- may not be the actual word I used) DONE, and we know what we’ve done. Sigh, hopefully I prep this project correctly with javadoc and readme so that this “one-shotter” is easily community maintainable. Well, here’s to the “hoping I get it right” adjustment to code n stuff.

But yeah! glad you enjoyed the tip!

edit: oh, almost forgot!

yes, I have. The big solution can be found in the DMUtils loadImageFromJar method. I mention it in one of my other dev blogs ^up there somewhere^ to adapt resource calling properly in a multi classloader system. I figure the rest is some area draw calls that doesn’t take GridBagLayout into account, like metal does, on an override. I’ll be sharing that solution with Nilo, as well.

2 Likes

##03/03/15 Talkin’ bout some Font testing, Github pull requests, and an Eye-Gouging nbm that is probably best left on video.##

Howdy Folks,

I’ve been in communications with some helpful people here at the jMonkeyEngine forums and I am now “learned up” on a convenient way (for me) to work with Github and the Github client.
I’ve also been working on Font code for installing an included ttf file into the JRE without installing it on a computer. That way, if the font is not actually wanted… it won’t hang around, and glare at you the next time you go to change fonts in your word processing program of choice.
To test it out, I’ve made a special nbm (which I’ve tagged for folks who are masochists) as a way of having fun, and sending a special nod to the cute Gooseface.png I received:


“aaawwww… sooo cuuuute!” :smile:

So with that in mind, I present… The Video! (safer this way)

Mainly because you probably don’t want to use this:

If you are a severe masochist, here’s your link:

03/04/15 Project ready for community contribution:

Okay, so I’ve got all the base functionality that I believe I need finished up, and I’ve got things documented nicely… I think. :sweat_smile:
I just have one big bug hunt to go and I can call this project done!
So, I’ll be opening up this project to the jMonkeyEngine community to poke, prod, and play with, in the mean time. It’ll work with the latest ver. of Netbeans, as that the Downloadable SDK I got a hold of (Netbeans 7.3.1) doesn’t have the LookAndFeel tab in Appearance. So, woooo! We are ramping up to 3.1! yay!

And as always, The Video:

and the quick link to this build:

1 Like

@nehon: just a quick side note: I’m going to play a little dwarf fortress and then get started tomorrow… I know that this one will toast my brain. Initial eta: 4-6 days. It depends upon how quickly I can find the guilty Override.

WHAT???
You mean you are actually gonna spend your spare time to entertain yourself instead of coding for others???
How dare you???

Have fun :wink:

1 Like

Yay DF, if only it had a better user interface (i can bear the grafics) never managed to get a actually reliable working military squad:)

1 Like

@Empire_Phoenix

Yo, dis how I roll on my Dwarf Fortress! Yo. My Dwarf Fortress is Pimpin’, Yo. Cribz fo’ shizzle.

Edit: This has nothing to do with DarkMonkey… I am abusing my privilege as main Dev for this project… and after playing today… I am heading back to serious posts n stuff.

Yo.

Yay i’m getting mentiond :slight_smile: Must watch in peace complete later, and then I will probably sink the next day in a d̶e̶a̶t̶h̶ ̶t̶r̶a̶p̶fortress.

03/07/15 - The Final Bug Hunt, part 1##

Hi all,

This video just shows me during my process of a typical bug hunt and reflects some of the logic I use to locate and troubleshoot. I was about to enact my first series of tests / fixes upon the included nimROD source files… And I realized that I’d better show what the bugs are… before I squish them. The next video will be the “after” where I discuss my solution.

So… Here’s the bugs! woot!:

My initial guess to the solution at this point in time relies upon these known tidbits:

  • The “bugs” all involve a common problem of proper sizing for display. ← functionality clue
  • The “bugs” may contain “container” within “container” situations. <— logical clue, possibly associated
  • The “bugs” start with the introduction of NimROD on top of Metal. <— location clue
  • Previous personal experience: Java architecture is heavily event driven due to consideration for threads… Things can go wrong due to “timing” of calculations for rendered area. <— logical clue… most likely “cause” of bug.

Extra known “tidbits”

  • The class UIDefaults is essentially a Hashtable<Object,Object> due to two modes, default and localized… it has an interface declared that is called UIDefaults.LazyValue, This may bear upon the circumstances directly due to Netbeans
  • Netbeans extends some JComponent classes and derives new UIDefaults through inheritance and adds “nb.” prefixes to the several new UIDefault entries… this inheritance probably requires LazyValues to function properly. AKA the Timing issue…

There may be a deeper systemic issue involved… so I just wanted to list the bugs “just in case” I’m right… cause its tough to show something that is no longer there… yeppers

04/11/15 It’s Spring and I’m Distracted

I’ve been playing with Lightworks/CleaningHouse/Taxes/OtherStuff/Etc/Etc/Etc

and not DarkMonkey debugging… So… I’m trying to get back on track. Here’s my vid… back to staring at my screen and trying to get enthused.

Ugh… I’ve found like 15 things that don’t work so far, though… :hankey:

2 Likes

05/01/15 Registering Arbitrary Actions with Netbeans

Ok, so I’ve proven to myself that I have horrible googlings skills, and I can’t seem to focus for anything to hunt down these silly bugs. So, I’ve made an action to help me figure out where these bugs might be stemming from. Github is updated for those folks wanting to grab a snapshot of the project in it’s current state. I’m not doing a release or anything until I get this figured out and solved… still the action is handy for this type of thing so grab a copy if ya want.

I am putting, at most, two more weeks on this hunt. If I can’t figure it out, by then… I will be sad, on top of frustrated with myself. Good luck to me, I’ll probably need it.

Game on,
Charles

1 Like

Have you tried pinging @venkatram_akkineni for help? He might have run into similar issues before.

Hiya @erlend_sh,

That’s an excellent idea.

@venkatram_akkineni, if you have some free time, could you glance at the code? I know the problem is probably some small thing… but I’m just not seeing it, atm. It’s located somewhere here:
https://github.com/Relic724/DarkMonkey/tree/master/src/com/nilo/plaf/nimrod
This shout out is also for anyone who knows Netbeans. I need to find that crucial forgotten thing, that Netbeans is looking for, which has been forgotten in Nimrod.

LOL, I will keep on bashing my brain at it, at any rate. Back to poking it with a stick for me… :grimacing:

Bug #2 located: Stabilized but not fixable.

Wow, Bug #2, “The disappearing search box” is one of those feedback loops from two sets of sources. I was chatting with a friend about it and he noticed a phrase that I didn’t: “incremental search sidebar”. So, a few google searches later, I found:

http://grepcode.com/file/bits.netbeans.org/maven2/org.netbeans.modules/org-netbeans-modules-editor-search/RELEASE80/org/netbeans/modules/editor/search/SearchComboBoxEditor.java?av=f

and oh, It looks like JComboBox and JTextfield are both extended… and sizing values are altered. I’ve stabilized the situation from the Nimrod side, but I don’t have the experience to be able to easily fix what the sidebar is doing.

Now I just need to find the locations for bug #1 and bug #3… erg…

Game On,
Charles

2 Likes

Hitting up the Netbeans forum for Bug #3

Bug #1 is low priority at this point, the shrinking toolbar is not a “functionality killer” like bugs #2 and #3. So, I’ve chosen bug #3: the “no-show value table” to focus on next.

I’ve located the main repository for Netbeans:
http://bits.netbeans.org/nexus/content/groups/netbeans/org/netbeans/modules/

And, to be honest, I’m pretty intimidated by the volume of modules that it looks like I’ll need to sort through. To reiterate the problem, I’ve got a few screenshots of the problem in action.

How it is supposed to work (Metal):

During a debug, you can hover over a variable and a “hinter” pops up that you can click on to expand…

And then … what looks to be a table … appears for interaction.

What is happening in DarkMonkey:

During a debug, you can hover over a variable and a “hinter” pops up that you can click on to expand…

And then … not so much…

I just need to locate the source for that particular class so that I can figure out which UI elements are being instantiated or, most likely, extended… and see what I can do on my end to make sure that the Nimrod source supplies what it needs.

If anyone on this forum happens to know the name of that class, I would love the “heads up” on it. I am cross linking this request over to the Netbeans forum, as well.

Game On,
Charles

What is bug#1 already?

I use dark monkey for several month now and 2 and 3 are indeed the most annoying issue. But, they can be worked around though.
2 is annoying because you don’t see your search query, but you still can search the file…
3 can be worked around by going to the “variables” tab when debugging…

Of course, those workarounds are very inconvenient, but they exists :stuck_out_tongue: