I'm glad to announce that I've finally completed the core functionality of GXML, and would like to conduct a public beta to see how the response is like from potential users. If you have some time to spare and think that this library would benefit your needs, I'd be grateful if you could take a look and see if it fulfills its intended purpose. To speed up the dialog creation process in galaxy scripting.
You can find the link to download it here: GXML Download
Any feedback and constructive criticism would be greatly appreciated. :) Just post it here and I'll drop by and read it. Thanks in advance!
Ignore anything below this line, its old
Intro:
I'm considering work on a very basic sub-language of galaxy called GXML. It is intended to be an alternative method for dialog/dialog item creation that uses similar syntax to XML.
What I'd like to know though is whether or not there is a novelty in this. Would the community find it useful?
If the overall response is positive, I will consider making a release for community use. Otherwise, I'd probably just use it for personal developments.
An example syntax is as follows:
"<d w=500 h=500>Test Dialog</d>"
Calling this string into the GXML parser would have it create a dialog with width and height 500.
The GXML parser functions return value is int. This return value is basically the ID of the dialog.
i = GXML("StringHere"); would create a dialog according to the GXML string and store it to integer i.
Support is intended for at least the following when declaring GXML strings:
Opacity, Anchors, Width, Height. And they may be declared in any order.
String/Text input, in the example above. "Test Dialog" is the string which would be converted to text.
Dialogs and Dialog items. (Certain Dialog item types may not be supported in early releases)
Error feedback
Considering support for:
Multiple line GXML strings. Though I'm not sure if there is a string length limit or if this is even possible.
GXML("<d>"+"Item1"+"Item2"+"Item3"+"</d>");
The downfall of this however would be that it would be hard to save the dialogs into variables if need be.
Reasons for development:
Existing functions for dialog item creation have a ridiculous number of input parameters, making for poor readability when scripting.
The alternative method of modifying Dialog items requires manual creation and manual function calls to changes its various properties.
Allows for easier one-shot dialog and dialog item creation, with the option to save them into variables.
GXML handles all the dialog creation, no need to dig the API to check what function is used to set dialog fade transparency, etc.
Dialog objects would be created based on a tag, d = dialog, b = button, i = image and so on, no need to memorize dialog item type constant names.
Downfalls:
It is seemingly redundant
Doesn't work well if dynamic dialogs are needed. (You would have to save the dialogs into variables and modify them later.)
1. XML syntax is horrible. Why do people still insist on using it?
2. Why not just write function wrappers - that is, functions with less parameters that simply put default values in the parameters not given of the full method?
For example, the function foo(a1, a2, a3, a4) can be wrapped by foowrapper(a1,a3) that contains the following code:
foowrapper(a1, DEFAULTA2VAL, a3 DEFAULTA4VAL).
3. Can you write a function that returns the dynamic dialog? If it's rare enough, just generate it anew every time.
1. XML syntax is horrible. Why do people still insist on using it?
Horrible, perhaps. No insistence here. Its the syntax used for data and and UI modifications, so I don't really see why not.
The main advantage I can see with a GXML parser is that it can be designed to allow the freedom to declare parameters wherever you like. It doesn't matter if I write <d w=10 h=10> or <d h=10 w=10>, the result is going to be the same. If need be, I can easily add in extra parameter and the parser will perform the appropriate functions. If I wanted to fade opacity by 50% and change the color to black <d w=10 h=10 f=50 c=000000>
Alternatively <d,10,10,50,000000> could be used, but what each of these numbers mean wouldn't be clear. And it would be input sensitive. (I put it it the wrong order it doesn't work)
So yea.. Parameter declaration freedom is my main motivation here.
Quote:
2. Why not just write function wrappers - that is, functions with less parameters that simply put default values in the parameters not given of the full method? For example, the function foo(a1, a2, a3, a4) can be wrapped by foowrapper(a1,a3) that contains the following code: foowrapper(a1, DEFAULTA2VAL, a3 DEFAULTA4VAL).
Yeah, already did this. Trying to take it to the next level though. Currently my dialog item process consists of something like this:
Create dialog item
Set dialog item color
Set dialog item opacity
Set dialog item tooltip
So rather than have 4 functions, would it not be easier to just have everything in a single string?
Its the difference between "c=000000" and gf_libNtve_DialogItemSetColor(d,PlayerGroupAll(),Color(0,0,0)).
Also, I'm not using the dialog item types creators made by blizzard as its just too messy for my eyes. Too many redundant input parameters.
Quote:
3. Can you write a function that returns the dynamic dialog? If it's rare enough, just generate it anew every time.
I'm not sure if this answers your question. But when I refer to dynamic dialogs, it refers to the ones that need to be regularly updated. Stuff like a label that displays % HP for example. But yes, It would be possible to write such a function. But to do so, I would need to assign every dialog and dialog item to a struct for later recall. It may be painstaking to have to specify where each dialog/dialog item is to be stored in the GXML tag, but if need be, it can be done.
So rather than have 4 functions, would it not be easier to just have everything in a single string?
Then you can make a function which takes a single string and performs whatever actions your preprocessor would have... and it'll work during runtime, too.
Thanks for the feedback. Sorta what I had in mind. I may have mixed my terminology up a little (specifically when I say parser). It is indeed intended to work during runtime. If my description made it sound as if its only intended to work during compilation, my bad >_>
M'kay. Wrapper library it is i guess. I have to disagree with the performance penalty though. Maybe it wasn't clear, but the creation process is intended to be one shot. Any updates are to be handled independent of the dialog creation.
That is:
Leaderboard created
Leaderboard dialog/dialog items handles are saved to integers
Dialogs/Dialog items are modified thereafter with the handles
If this is how it was envisioned from your point of view, could you please explain to me how it would cause a performance penalty? Because it seems perfectly fine in my eyes.
Lets say I don't use XML, are there any suggestions on a better way to have the wrappers done such that I have the freedom to declare parameters in any sequence? It would help development greatly if some feedback could be provided on this.
One-shots are perfectly fine, no performance falls.
The only way for you to declare the variables in any sequence would be to parse a declaration in your format, decide what's what, and then reorder it in order to print it to a .galaxy file.
All in all, too much work just for that feature. Maybe you can plug this feature in into some bigger framework.
Dont you write.... functions to manipulate your dialogs anyways?
I mean if its a dialog thats used alot... its best that it has some kinda function that you call to update it
I dont really see the point of having a specific function to create dialogs seeing as that is how "galaxy" already has it set up. Kinda redundant if you ask me. but then i specifically use GUI.
For each dialog I tend to write its own function for updating said dialog. Because Each dialog tends to be quite a bit different from the next.
Dont you write.... functions to manipulate your dialogs anyways?
I mean if its a dialog thats used alot... its best that it has some kinda function that you call to update it
Yeap.. But the main hassle isn't the updating part. Its the creating part. I play with dialogs quite a lot, thus is the reason why I'd like to come up with a way to declare them much faster than I already do.
Quote:
I dont really see the point of having a specific function to create dialogs seeing as that is how "galaxy" already has it set up. Kinda redundant if you ask me. but then i specifically use GUI.
For each dialog I tend to write its own function for updating said dialog. Because Each dialog tends to be quite a bit different from the next.
I guess its a personal preference for me. Its the difference between creating a dialog or dialog item with 1 line of code as opposed to creating one with 4-6 lines (Manually call all the functions). Sad to say I've been avoiding GUI like the plague since I got poisoned by JASS back in wc3. But yes, I will admit that dialog creation is very user friendly when using GUI.. As for galaxy.. I think the function speaks for itself..
Yeah.. its pretty long. And even longer when I add a tooltip and image. I normally do the creation manually with seperate function calls to specify all the properties cos its more readable.
Well FuzzYD - you can view yourself as a trailblazer. Like with any other programming language, we have raw Galaxy and there are those who will implement all the shorthands and compact calls that make it useable. You're one of them :)
Dont you write.... functions to manipulate your dialogs anyways?
I mean if its a dialog thats used alot... its best that it has some
kinda function that you call to update it
Yeap.. But the main hassle isn't the updating part. Its the creating
part. I play with dialogs quite a lot, thus is the reason why I'd like
to come up with a way to declare them much faster than I already do.
Quote:
I dont really see the point of having a specific function to create
dialogs seeing as that is how "galaxy" already has it set up. Kinda
redundant if you ask me. but then i specifically use GUI.
For each dialog I tend to write its own function for updating said
dialog. Because Each dialog tends to be quite a bit different from the
next.
I guess its a personal preference for me. Its the difference between
creating a dialog or dialog item with 1 line of code as opposed to
creating one with 4-6 lines (Manually call all the functions). Sad to
say I've been avoiding GUI like the plague since I got poisoned by JASS
back in wc3. But yes, I will admit that dialog creation is very user
friendly when using GUI.. As for galaxy.. I think the function speaks
for itself..
control libNtve_gf_CreateDialogItemImage ( dialog dialog, int width, int height, preset anchor, int offsetX, int offsetY, text tooltip, filepath image, preset imageType, bool tiled, color tintColor, preset blendMode )
Yeah.. its pretty long. And even longer when I add a tooltip and image.
I normally do the creation manually with seperate function calls to
specify all the properties cos its more readable.
Hey fuzzy I see where you coming from......
But ok I code in VB mainly... in vb for long text lines I ussueally can do stuff like this
callsomefunction("blah blah blah"&_"continue the same call on another line"&_"blah blah more parameters"
is that not possible in galaxy .... I would think seperating every parameter for a dialog onto a new line would make it much cleaner.
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
I think this implementation is fatally flawed in that you have to do more work to get the IDs of the inner dialog item's by writing more code than potentially, the XML to create it.
I'm glad to announce that I've finally completed the core functionality of GXML, and would like to conduct a public beta to see how the response is like from potential users. If you have some time to spare and think that this library would benefit your needs, I'd be grateful if you could take a look and see if it fulfills its intended purpose. To speed up the dialog creation process in galaxy scripting.
GXML Now in Open Beta!
I'm glad to announce that I've finally completed the core functionality of GXML, and would like to conduct a public beta to see how the response is like from potential users. If you have some time to spare and think that this library would benefit your needs, I'd be grateful if you could take a look and see if it fulfills its intended purpose. To speed up the dialog creation process in galaxy scripting.
The details can be found here: GXML Details
You can find the link to download it here: GXML Download
Any feedback and constructive criticism would be greatly appreciated. :) Just post it here and I'll drop by and read it. Thanks in advance!
Ignore anything below this line, its old
Intro:
I'm considering work on a very basic sub-language of galaxy called GXML. It is intended to be an alternative method for dialog/dialog item creation that uses similar syntax to XML.
What I'd like to know though is whether or not there is a novelty in this. Would the community find it useful?
If the overall response is positive, I will consider making a release for community use. Otherwise, I'd probably just use it for personal developments.
An example syntax is as follows:
Calling this string into the GXML parser would have it create a dialog with width and height 500.
The GXML parser functions return value is int. This return value is basically the ID of the dialog.
i = GXML("StringHere"); would create a dialog according to the GXML string and store it to integer i.
Support is intended for at least the following when declaring GXML strings:
Considering support for:
Reasons for development:
Downfalls:
Thanks for taking the time to read this :)
1. XML syntax is horrible. Why do people still insist on using it?
2. Why not just write function wrappers - that is, functions with less parameters that simply put default values in the parameters not given of the full method? For example, the function foo(a1, a2, a3, a4) can be wrapped by foowrapper(a1,a3) that contains the following code: foowrapper(a1, DEFAULTA2VAL, a3 DEFAULTA4VAL).
3. Can you write a function that returns the dynamic dialog? If it's rare enough, just generate it anew every time.
Horrible, perhaps. No insistence here. Its the syntax used for data and and UI modifications, so I don't really see why not. The main advantage I can see with a GXML parser is that it can be designed to allow the freedom to declare parameters wherever you like. It doesn't matter if I write <d w=10 h=10> or <d h=10 w=10>, the result is going to be the same. If need be, I can easily add in extra parameter and the parser will perform the appropriate functions. If I wanted to fade opacity by 50% and change the color to black <d w=10 h=10 f=50 c=000000>
Alternatively <d,10,10,50,000000> could be used, but what each of these numbers mean wouldn't be clear. And it would be input sensitive. (I put it it the wrong order it doesn't work)
So yea.. Parameter declaration freedom is my main motivation here.
Yeah, already did this. Trying to take it to the next level though. Currently my dialog item process consists of something like this:
So rather than have 4 functions, would it not be easier to just have everything in a single string?
Its the difference between "c=000000" and gf_libNtve_DialogItemSetColor(d,PlayerGroupAll(),Color(0,0,0)).
Also, I'm not using the dialog item types creators made by blizzard as its just too messy for my eyes. Too many redundant input parameters.
I'm not sure if this answers your question. But when I refer to dynamic dialogs, it refers to the ones that need to be regularly updated. Stuff like a label that displays % HP for example. But yes, It would be possible to write such a function. But to do so, I would need to assign every dialog and dialog item to a struct for later recall. It may be painstaking to have to specify where each dialog/dialog item is to be stored in the GXML tag, but if need be, it can be done.
Then you can make a function which takes a single string and performs whatever actions your preprocessor would have... and it'll work during runtime, too.
@grim001: Go
Thanks for the feedback. Sorta what I had in mind. I may have mixed my terminology up a little (specifically when I say parser). It is indeed intended to work during runtime. If my description made it sound as if its only intended to work during compilation, my bad >_>
In an event-heavy map, the performance penalty might matter - imagine a DOTA where you had X times the computation when updating scores.
I think this pretty much sums up to a wrapper library, maybe a small preprocessor to allow easier declaration of variables. Please don't use XML.
@moshewe: Go
M'kay. Wrapper library it is i guess. I have to disagree with the performance penalty though. Maybe it wasn't clear, but the creation process is intended to be one shot. Any updates are to be handled independent of the dialog creation.
That is:
If this is how it was envisioned from your point of view, could you please explain to me how it would cause a performance penalty? Because it seems perfectly fine in my eyes.
Lets say I don't use XML, are there any suggestions on a better way to have the wrappers done such that I have the freedom to declare parameters in any sequence? It would help development greatly if some feedback could be provided on this.
One-shots are perfectly fine, no performance falls.
The only way for you to declare the variables in any sequence would be to parse a declaration in your format, decide what's what, and then reorder it in order to print it to a .galaxy file. All in all, too much work just for that feature. Maybe you can plug this feature in into some bigger framework.
@moshewe: Go
Alright, thanks for the feedback moshewe. I'll see if anything can be done to make this worth it. Otherwise it'll probably b scrap :P
Dont you write.... functions to manipulate your dialogs anyways?
I mean if its a dialog thats used alot... its best that it has some kinda function that you call to update it
I dont really see the point of having a specific function to create dialogs seeing as that is how "galaxy" already has it set up. Kinda redundant if you ask me. but then i specifically use GUI.
For each dialog I tend to write its own function for updating said dialog. Because Each dialog tends to be quite a bit different from the next.
Yeap.. But the main hassle isn't the updating part. Its the creating part. I play with dialogs quite a lot, thus is the reason why I'd like to come up with a way to declare them much faster than I already do.
I guess its a personal preference for me. Its the difference between creating a dialog or dialog item with 1 line of code as opposed to creating one with 4-6 lines (Manually call all the functions). Sad to say I've been avoiding GUI like the plague since I got poisoned by JASS back in wc3. But yes, I will admit that dialog creation is very user friendly when using GUI.. As for galaxy.. I think the function speaks for itself..
Yeah.. its pretty long. And even longer when I add a tooltip and image. I normally do the creation manually with seperate function calls to specify all the properties cos its more readable.
@FuzzYD: Go
Well FuzzYD - you can view yourself as a trailblazer. Like with any other programming language, we have raw Galaxy and there are those who will implement all the shorthands and compact calls that make it useable. You're one of them :)
@moshewe: Go
Why thank you, I appreciate the thought :)
Hey fuzzy I see where you coming from......
But ok I code in VB mainly... in vb for long text lines I ussueally can do stuff like this
is that not possible in galaxy .... I would think seperating every parameter for a dialog onto a new line would make it much cleaner.
@SouLCarveRR: Go
I think this implementation is fatally flawed in that you have to do more work to get the IDs of the inner dialog item's by writing more code than potentially, the XML to create it.
ie. a mess.
I'm glad to announce that I've finally completed the core functionality of GXML, and would like to conduct a public beta to see how the response is like from potential users. If you have some time to spare and think that this library would benefit your needs, I'd be grateful if you could take a look and see if it fulfills its intended purpose. To speed up the dialog creation process in galaxy scripting.
The details can be found here: GXML Details
You can find the link to download it here: GXML Download
Any feedback and constructive criticism would be greatly appreciated. :) Just post it here and I'll drop by and read it. Thanks in advance!