I begin to test it and it seems you have a problem with the resizable windowsElements. when you drag a resizeBorder you can create an odd panel when you go in the opposite direction of the resizeBorder.
I can’t make a video right now…If you not seeing what i say, i’ll make one tonight.
PS : one suggestion, when we create a button for example, we have 7 override methods which appear…why not let us the possibility to choose what method we needs to override rather spam all everytime…when we create 6-7 buttons at the same time the code quickly becomes messy ;)…not a priority…just a question.
I begin to test it and it seems you have a problem with the resizable windowsElements. when you drag a resizeBorder you can create an odd panel when you go in the opposite direction of the resizeBorder.
I can’t make a video right now…If you not seeing what i say, i’ll make one tonight.
No need to. This will be taken care of soon. I’m not enforcing minimum size atm which allows you to invert the window.
@haze said:
PS : one suggestion, when we create a button for example, we have 7 override methods which appear...why not let us the possibility to choose what method we needs to override rather spam all everytime...when we create 6-7 buttons at the same time the code quickly becomes messy ;)...not a priority...just a question.
I see your point for sure… I was more concerned with people not having to fishing for method names. Suggestions for how to meet both?
Indeed, it’s the case in JAVA with the mousePressed etc…it take a few time to become familiar with them :p. I have no ideas atm to satisfy both…i’ll meditate on it ^^.
Else, i’ve played a little this afternoon with the lib and i have found few issues and 2-3 questions/suggestions.
So,
we can specify the layout of elements text…center…right…left…Ok, but we can’t access to the title element text…windows shouldn’t have their title center by default? Or add a getter to permit to manage it?
indicators class have some problems :
No getCurrentValue and no getMaxValue methods as the doc says
indicators text is hidden when we specify a texture
when we not specify an image ( just need a color bar…useless but you never know ^^) indicators take the window style inside the element like if we add a window inside the indicator element, you have that too?
in the most common case i think people center the text in their gui, maybe set this parameter by default…I quibble i know :s
And to conclude the first try, can you add 2 effects i think very popular in nifty…
Move effect…from a screen border to its final location maybe or to generalize (screen border by default) permit to move an element from a vector3f to another.
Shake effect wich can use the vector3f move effect (i’ve made a login screen in nifty where the two buttons connect and quit came to the left and the right at the same time and when they clash themselves i shake the connection panel…and i like it
That’s all.
EDIT:
PS: With a few appstates to manage the differents screen…i associate one appState by “nifty layer” i need and it just work really well. Thanks for your job !
This accesses the Element directly and gives you access to all getters/setters; or, optionally, you can copy the Window.xml file and set the defaults to anything you like. Though this is a bit on the difficult side atm since the sources were not added to this release (they’ll be available after the pre-alpha. Though, for the time being you can hit up the repo for the XML files:
Though, in the future, I’ll probably add passthroughs for the title into the window class just to make it more obvious.
Indicators are sort of in their infancy stage atm. I’ll be sure to add the getters for both current and max as they should have been included already.
These will eventually change a bit to allow for setting an image under the indicator, the indicator itself and an overlay image so they can be configured in anyway you see fit.
As for the indicator text, I overlooked the usage of this and the text would be written to the base element (hidden by everything else). I’ll be adding methods for setting text (to ensure that it is written to the overlay element and always visible.
Should text for this be centered by default?
I agree that window titles should be centered by default and will update the base xml to reflect this.
Now, if I am lucky, I can get these put together for you and uploaded before tonight’s build.
I just had a thought about the indicator text. Is the purpose to display the maxValue / currentValue ? Like you see in a lot of games? I can set this as a toggle-able option that will do this for you (which was the plan to begin with… it just hadn’t been implemented yet).
@haze
Done, done and done. Text is aligned center / center by default
[java]
ind.getCurrentValue(); // added
ind.getMaxValue(); // added
ind.getTextDisplayElement(); // Return the text element for formatting purposes
ind.setDisplayValues(); // Display value in format: current/max or 10/100
ind.setDisplayPercentage(); // Displays percentage: 82% etc
ind.setHideText(); // removes display text (default)
[/java]
At a minimum, I’ll be adding a SlideIn and SlideOut effect which will take care of your first request. I hadn’t added them yet due to the issues I was having with placement (which I resolved yesterday). So, short answer: You will be able to slide elements in from the sides/top/bottom… potentially corners if you like… or for that matter, from any vector you define if you think that better. I guess I could also add arc sliding
Let me see what I can do about a shake effect as well. Sounds like a cool idea!
As for compound effects… I am not completely sure yet, though I will try and make this happen. It is possible to do, no doubt… however right now I limited it to a single effect for another unrelated reason. I could probably rectify that issue another way which will free up the current need for single effects. I’ll be looking into this for sure!
This accesses the Element directly and gives you access to all getters/setters;…
Ow, stupid boy am i !
indeed, it will be more simple but for now it works…sorry.
2. Indicators are sort of in their infancy stage atm. I’ll be sure to add the getters for both current and max as they should have been included already.
These will eventually change a bit to allow for setting an image under the indicator, the indicator itself and an overlay image so they can be configured in anyway you see fit.
As for the indicator text, I overlooked the usage of this and the text would be written to the base element (hidden by everything else). I’ll be adding methods for setting text (to ensure that it is written to the overlay element and always visible.
Ok, Good.
Should text for this be centered by default?
Yes, like i said, i think it's that people want in the most common cases...if someone doesn't agree with me...
@t0neg0d said:
I just had a thought about the indicator text. Is the purpose to display the maxValue / currentValue ? Like you see in a lot of games? I can set this as a toggle-able option that will do this for you (which was the plan to begin with.. it just hadn't been implemented yet).
Yes it is. I use that kind of control for two things now, progress bar and cast bar which just show you a progress with a simple percentage value
and for player health bar/resource bar which show a formatted string like that:
currentValue + “/” + maxValue + " " + (currentValue/maxValue)*100 + “%”
I can set this as a toggle-able option that will do this for you (which was the plan to begin with.. it just hadn’t been implemented yet).
Why not but it should be customizable...because I do that but other people can use it in other way...
@t0neg0d said:
@haze
Done, done and done. Text is aligned center / center by default
[java]
ind.getCurrentValue(); // added
ind.getMaxValue(); // added
ind.getTextDisplayElement(); // Return the text element for formatting purposes
ind.setDisplayValues(); // Display value in format: current/max or 10/100
ind.setDisplayPercentage(); // Displays percentage: 82% etc
ind.setHideText(); // removes display text (default)
[/java]
Nice.
@t0neg0d said:
Forgot about your Effect related questions.
At a minimum, I’ll be adding a SlideIn and SlideOut effect which will take care of your first request. I hadn’t added them yet due to the issues I was having with placement (which I resolved yesterday). So, short answer: You will be able to slide elements in from the sides/top/bottom… potentially corners if you like… or for that matter, from any vector you define if you think that better. I guess I could also add arc sliding
Let me see what I can do about a shake effect as well. Sounds like a cool idea!
As for compound effects… I am not completely sure yet, though I will try and make this happen. It is possible to do, no doubt… however right now I limited it to a single effect for another unrelated reason. I could probably rectify that issue another way which will free up the current need for single effects. I’ll be looking into this for sure!
Nothing to add…satisfy me a lot.
And for compound effect it will be interesting but i think simple effect(one effect for each Effect.EffectEvent) are sufficient for now
Sorry to be a bother, but I want to revisit the abstract methods for event handling to get rid of the “spam” aspect of the button class.
Let me reiterate how you think this should be done, and tell me if I have this correct:
Remove “abstract” from these classes and allow people to simply override what they will use. I’ll just add the methods available via the documentation here to make them easier to locate.
This sound about right?
I doubt I’ll get this squared away before tonight, but within the next day or so at a max.
Sorry to be a bother, but I want to revisit the abstract methods for event handling to get rid of the “spam” aspect of the button class.
Let me reiterate how you think this should be done, and tell me if I have this correct:
Remove “abstract” from these classes and allow people to simply override what they will use. I’ll just add the methods available via the documentation here to make them easier to locate.
This sound about right?
I doubt I’ll get this squared away before tonight, but within the next day or so at a max.
Oh… I meant for all classes with event callbacks
Yeah, that’s it.
It’s less convenient at the beginning but with somme practice we will have a cleaner code. In general when we have a similar spam of abstract methods, we need to implement all of them whereas here we can just need only one
it’s my own opinion, i may be wrong…
i just update the plug in and i see basic indicators (with a simple Background texture) works fine but if i set an alphmap the text is still hidden when the progress bar grows up.
EDIT: after a second glance, the text appears well in some cases … but it is rendered below the alphamap … that is annoying: p
And an other problem with the resizing windows, the minimum size works pretty well, however, if we add a childElement with setlockToParentBounds(true); this element has the same odd behaviour than yesterday (even if i set min size) when i reduce the windows at a smaller size.
@zarch said:
Wouldn't a listener interface (potentially with adapter class for convenience) be the traditional way to handle this in GUI.
That’s the way it is set up right now, however… between the way I broke up mouse events and the number of listeners the Button class in particular implements… and the fact that I abstracted the callbacks so you wouldn’t have to go fishing for them, it makes the button class a bit overbearing. I’m strugling with which approach to take…
Do I ditch abstracting these methods and make people fish through the documentation?
Or leave it be?
So you don’t have to go back through the docs to see it:
[java]
Button makeWindow = new Button( screen, “Btn1″, new Vector2f(15, 55) ) { @Override
public void onMouseLeftDown(MouseButtonEvent evt, boolean toggled) { } @Override
public void onMouseRightDown(MouseButtonEvent evt, boolean toggled) { } @Override
public void onMouseLeftUp(MouseButtonEvent evt, boolean toggled) {
createNewWindow(“New Window ” + winCount);
} @Override
public void onMouseRightUp(MouseButtonEvent evt, boolean toggled) { } @Override
public void onStillPressedInterval() { } @Override
public void onButtonFocus(MouseMotionEvent evt) { } @Override
public void onButtonLostFocus(MouseMotionEvent evt) { }
};
[/java]
And this is me condensing it down… Netbeans supplies a much more verbose version
Imo i’d rather fish in documentation than have 10 methods declared even if I want to use only one.
I’m all for Tim’s suggestion, it’s a very classic but solid way to handle this.
@nehon said:
Imo i'd rather fish in documentation than have 10 methods declared even if I want to use only one.
I'm all for Tim's suggestion, it's a very classic but solid way to handle this.
That’s person number 3… no arguments from this side!
Yeah, ButtonListener interface, ability to add listeners to the button - then empty ButtonAdaptor class that implements all the methods in the interface doing nothing.
Nice.
