Attached Files

Edit 2 - So I am guessing the button is supposed to stick out when highlighted and I didn't fix it?

Yep... Sorry...

Keep smiling while dying

Of course I have gone mad with power! It would be completely ridiculous to go mad without power!And no, this is not a quote from the Simpson's movie, I want it on paper, that I actually wrote that quite some time before the movie came out.

I don't know if I like the bar popping out, It doesn't have the feel the SWF did because it expanded. This just changes, makes it feel like the buttons were not lined up.

2nd The title bar was Annoying (among other things), so I did a quick fix. The main problem with the GUI is I don't know how many pixels I am supposed to have for each object. No matter what I do something gets stretched on end etc. I will have to read through CEGUI to make more changes.

Yes, I know (I had to use that for the new changes), However It doesn't just use the button. For instance the new title bar I changed. It uses a set amount of pixels, so it will stretch what is there. I cannot make it shorter or bigger just by telling it the dimensions. So in order to make it look the best I need to know exact dimensions it is going to make it. I am sure it is all on the site, I just need to track it down later when I have time.

Anyways with the current status of CEGUI#, we really cannot do more than one widget set (buttons) Correct?

Should we start making images of buttons and using that instead? (1 min, 1 hour, 1 day... etc)

EditThis is an example of the problem above, I have redone the title GUI and specified the dimensions. However you can see on the right it gets stretched

Actually, I think CeGui# does support multiple widget sets.Also, this is an interesting problem, I've got a couple of ideas what it might be.Might be anti-alising kicking in, if the size of the buttons we've ask it to draw doesn't match the size of the button template. (But I don't think that's a problem.)Second cause might be bleed through (similar to the 1-pixel border needed in icon sheets.Third problem might be a co-ordinate error in the image set. (If the template is one pixel to long, the drawn button will have the overdraw.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

if the size of the buttons we've ask it to draw doesn't match the size of the button template. (But I don't think that's a problem.)

I'm thinking it might have something to do with a template. This picture is for the title bar. I increased the lenght (added 5 more pixels) and not it seems ok. It would just be nice if something somewhere said the required dimentions for an object. Mostly I just use what is already there and modify it.

Actually, I think CeGui# does support multiple widget sets.

Are you sure? I thought it required Falagard? If this is possible, maybe we can import most of the sets from C++ then? Would make life easier.

if the size of the buttons we've ask it to draw doesn't match the size of the button template. (But I don't think that's a problem.)

I'm thinking it might have something to do with a template. This picture is for the title bar. I increased the lenght (added 5 more pixels) and not it seems ok. It would just be nice if something somewhere said the required dimentions for an object. Mostly I just use what is already there and modify it.

Actually, I think CeGui# does support multiple widget sets.

Are you sure? I thought it required Falagard? If this is possible, maybe we can import most of the sets from C++ then? Would make life easier.

I might be confusing widget sets with image sets, but I'm pretty sure it supports multiple imagesets. For example, IIRC the buttons on the title page are not the same look as the buttons on the geoscape. (Sorry, currently at work so don't have a working copy to confirm.)

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

widgetsets let us use different skins for the same things, button, scroll bar, slider, window etc.

imageset lets us make our own button out of a window. This is how we handle the left right up down arrows on the geoscape. But the main buttons (Research, 5 min, 1 hour, 1 day) are all the same button.

I don't believe we can do different widget sets. If we could, this would be very great.

widgetsets let us use different skins for the same things, button, scroll bar, slider, window etc.

imageset lets us make our own button out of a window. This is how we handle the left right up down arrows on the geoscape. But the main buttons (Research, 5 min, 1 hour, 1 day) are all the same button.

I don't believe we can do different widget sets. If we could, this would be very great.

From what I understood by looking at CEGUI#'s source code: WidgetSet refers to the available controls and their behaviour. ImageSet refers to the appearance of said controls. Thus, you can draw/create/state/whatever different imagesets for the same widgetset. The library provides three widgetsets (Suave, Taharez, Windows) and one imageset for each one.

I tried to find something in the source code. Lack of documentation means that it will be harder to find anything useful without dteviot's experience, but I gave it a try anyway.

The most relevant file I could find was WindowManager.cs, and it makes me think that you can use one and only WidgetSet. Of course, you can customize it to suit your needs, so...?

If I just rumbled, confused you or said things you already know, sorry!

in c++ they created a skin for each screen. Baseview, geoscape, etc. This had buttons and skins etc. and they could call any of them.

With C# we have Taharez and only Taharez (Or maybe 2 more now but can only pick one?). So I can create a skin for Taharez like we have with XenoNew.PNG.

But that is all we can do. We can have 1 button that looks the same no matter what, 1 menu, 1 slider, 1 radio circle etc.

I want to be able to create 5 buttons and call whatever one I want (not using image set like the arrows. just a standard button we can add text to) 5 different sliders etc.

Is this possible?

I think you can load all 3 ImageSets: Suave, Windows and Taharez (if I recall correctly). But, can you load more than 1 widgetset? I believe not, because the widgetset provides the functionality set you use in the GUI system. But, can you implement different kind of buttons? Probably, if someone codes it xD. Can you use more than 1 imageset? I don't know, you definitely can load more than one, but use?

So, technically, I believe yes it is possible (just a conjunction (if that's the right word))... You can inherit the widget class and create different button widgets. You then edit the imageset and include the new widgets.

Although I believe it's an overkill. If you look at ImageSetManager.cs, you can see you can include multiple ImageSets (there's an ImageList type). Now, in said file, I can see that you can load and remove multiple imagesets, but it doesn't include any info on using many imagesets at the same time. If it does, then you could use different imagesets for different buttons. Which also sounds like an overkill, because you can include the different button graphics in the same imageset, non? :S.

After looking some more, I still can't find something relevant enough... grrrrr!

Maybe I'll have a look at the C++ port and compare. I fear that the needed functionality just isn't implemented in CEGUI#. Will have to investigate more.

This is getting out of hand. I see two possible soutions: PezzA could become a recruit, or we open the workshops for everyone...

Keep smiling while dying

Of course I have gone mad with power! It would be completely ridiculous to go mad without power!And no, this is not a quote from the Simpson's movie, I want it on paper, that I actually wrote that quite some time before the movie came out.

Pezza deserves to be a recruit imho. Opening the workshops could bring new people forward, but that would probably not be the case, as everyone will be able to whine about anything and ask for this and that... nasty business.

Pezza deserves to be a recruit imho. Opening the workshops could bring new people forward, but that would probably not be the case, as everyone will be able to whine about anything and ask for this and that... nasty business.

Pezza:=recruit ftw

Out of hand, because it's pretty difficult to keep the discussion threads continuous if one discussion takes place at two different places...

Keep smiling while dying

Of course I have gone mad with power! It would be completely ridiculous to go mad without power!And no, this is not a quote from the Simpson's movie, I want it on paper, that I actually wrote that quite some time before the movie came out.

I agree with Mad, we let people work on this project and then they cannot post in areas.

PezzA should be a recruit, however we are no longer as abundunt as we once were and the more help the better, I believe we should lighten the rules to allow posting. In turn we should just moderate these areas more and delete posts that are not relevent to the subject (besides this current discussion, or take this discussion elsewhere).

On topic I am still confused about imagesets, widgetsets, etc etc.

Let me explain myself better.

right now, we use our XenoNew.PNG, In the imageset file I declare an area to be used for whatever object I have created. Window, Button, Radio Button, Slider, Cursors.

On top of this I can make buttons out of images. This is not the same as a standard button. We cannot apply text like we can the button. We have 1 Main standard button. The standard button while works well with maybe 90% of the menus. But I need different buttons for the other 10 percent - 5 mins, 1 hour, need a small skin that looks better.

I want to be able to use mutiple image sets. I want to say let me use RedSkin.Imageset.Slider and BlueSkin.Imageset.Button and Battlescape.Imageset.window.
I want to have 5 different XenoNew.PNG's and have a skin for each object and depending on the menu, call the one I need to use.

Hey, don't look at me! I've asked Micah and Stewart to make PezzA a member of the Programming team. However, I have no more power than that. (So much for being Head of the Programming Team, more responsibility, but no more authority than any other member of the programming team!)

I want to be able to use mutiple image sets.

Looking into it, I can see two possible solutions.Firstly, at the current time, we're using the Taharez GUI set, which is hard coded to use the TaharezLook Image set.Our use of this builder is set up in Xenocide\Source\UI\Screens\ScreenManager.cs, with the line:private CeGui.GuiBuilder guiBuilder = new CeGui.WidgetSets.Taharez.TLGuiBuilder();However, I see nothing that limits us to a single GuiBuilder, so we could just instansiate a second GUI builder with a New Widget set with the desired controls. (We'd also have to create the new Widget set, probably by doing a cut and paste of the existing Taharez one.)

An alternative option would be to add an new "skinnable" button to the Taharez widget set. The idea is that the existing button control in xenocide\Dependancies\CeGui\CeGui.WidgetSets.Taharez\Source\TLButton.cs, gets it's skin from a set of named areas in the image set e.g.

/// <summary>
/// Name of the image to use for the left end of the button (normal).
/// </summary>
const string LeftNormalImageName = "ButtonLeftNormal";
/// <summary>
/// Name of the image to use for the middle of the button (normal).
/// </summary>
const string MiddleNormalImageName = "ButtonMiddleNormal";
/// <summary>

Instead of directly hard coding these, we instead pass a "skin" value to the button in it's constructor and build them on the fly.e.g.

We then add the relevant skining to the Taharez imageset's .xml and .png files. (Essentially, this is a poor man's Falagard system.)

Note, this only works if Darkhomb only wants the buttons' looks to change, as they will have the same behaviour as the normal buttons.

Thinking about it a bit more, we don't even need to add a new button to the Taharez widget set, as the current button would just be a special case of the "skinable" button, with the skin value set to an empty string.

So, I think all that would be needed is add a new CreateButton() function to the GuiBuilder and TLGuiBuilder classes

add an additional CreateWindow(string type, string name, string skin) to xenocide\Dependancies\CeGui\CeGui\Source\WindowManager.cs that passes the skin down to assembly.createInstance()Note, due to common code in CreateWindow(), should refactor out the common code.

Add an additional constructor to the TLButton class that takes a skin, and change the constants to properties as previously mentioned.

I'm a bit busy with other things at the moment. Does anyone else have time? If not, let me know and I'll see what I can do next weekend.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

add an additional CreateWindow(string type, string name, string skin) to xenocide\Dependancies\CeGui\CeGui\Source\WindowManager.cs that passes the skin down to assembly.createInstance()Note, due to common code in CreateWindow(), should refactor out the common code.

Add an additional constructor to the TLButton class that takes a skin, and change the constants to properties as previously mentioned.

I'm a bit busy with other things at the moment. Does anyone else have time? If not, let me know and I'll see what I can do next weekend.

I can pick that up as my next job, however just as the kitchen is the first thing to go when you move into a new house, is the same true of UI systems in xna-fan-project mergers? Not sure there is any point progressing any UI elements until we know where it's all going.

Well, as part of the merger, I was considering if there's a better C# based UI framework. And I came across an article on using XNA inside WPF. Now, at work we're moving to WPF, all new GUIs are made using it. So, long story sort, if the merger happens, I'd push really hard to replace Cegui# with WPF. Failing that, well, I'd still like to do it, but at the moment, my priority is the battlescape.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

add an additional CreateWindow(string type, string name, string skin) to xenocide\Dependancies\CeGui\CeGui\Source\WindowManager.cs that passes the skin down to assembly.createInstance()Note, due to common code in CreateWindow(), should refactor out the common code.

Add an additional constructor to the TLButton class that takes a skin, and change the constants to properties as previously mentioned.

I'm a bit busy with other things at the moment. Does anyone else have time? If not, let me know and I'll see what I can do next weekend.

I can pick that up as my next job, however just as the kitchen is the first thing to go when you move into a new house, is the same true of UI systems in xna-fan-project mergers? Not sure there is any point progressing any UI elements until we know where it's all going.

Well, as part of the merger, I was considering if there's a better C# based UI framework. And I came across an article on using XNA inside WPF. Now, at work we're moving to WPF, all new GUIs are made using it. So, long story sort, if the merger happens, I'd push really hard to replace Cegui# with WPF. Failing that, well, I'd still like to do it, but at the moment, my priority is the battlescape.

I'd be right with you on WPF if you wanted to go that way, work is also picking this up, so i'd be getting quite a bit of bang for my buck in terms of time spent on the project.

Right before everyone went away we started working on a new UI - WindowsSystem. Red Knight and Supsuper were working on this. I don't know ifs benefits compared to anything else. But I am for a new UI if it can do everything CEGUI can plus more.

Edit, I just compiled it and it looks like it is working. I will try and contact supsuper (He's still on steam) and see if he knows the status.

Looks cleaner and less bulky then CEGUI.

Edit 2 - Looks like it supports multiple skins out of the box. Building screens are pretty simple to. I am actually interested in this.

And with WPF " In Design mode, we use the Canvas class which inherits Game; in runtime mode, we directly target the window. This allows us, in the Visual Studio Designer, to be able to see and modify the UI of our control with the mouse. "

6:53 PM - <chill> SupSuper ?PGD?: yeah windowsystem is dead but it's left us with a pretty clean and easy to extend codebase
6:54 PM - <chill> SupSuper ?PGD?: it works fine, it just needs actual work put into it to port over all the ui and integrate into xenocide and such
6:54 PM - <chill> SupSuper ?PGD?: and i've been swamped with uni work so yeah, but i made sure it all compiled if anyone wanted to pick it up before i left it
6:58 PM - |Ex| Jasin2069: is there anything windowssystem cannot do that cegui could?
6:59 PM - <chill> SupSuper ?PGD?: well cegui comes with a lot more components than windowsystem
7:00 PM - <chill> SupSuper ?PGD?: but windowsystem is much cleaner so you could easily write up your own components for stuff like trees instead of hacking around with big bloaty messy cegui
7:03 PM - <chill> SupSuper ?PGD?: i'm not really familiar with WPF aside from vs 2010 ui being based on it, so whatever works
7:04 PM - |Ex| Jasin2069: either one, i just hate cegui
7:04 PM - <chill> SupSuper ?PGD?: haha yeah

So this is workable. I want whatever is easier for programming dept and whatever is going to stay with us and stay updated. So if WPF is the new standard I'd rather do that. but if windowsystem is easy since its already been built by supsuper and we dont need to worry about updating it. Then lets move to this.

Right before everyone went away we started working on a new UI - WindowsSystem.

OK, I've had a VERY quick glance the code, and my first impression (which may be wrong) is that it's going to take a fair bit of work to get this going, as we'd need to create a grid control, a tree control (for the UFOpedia) and a large area text control.

My preference is to go for WPF, for the following reasons.1. WindowsSystem doesn't seem to have had any progress since 2007. And I don't think many people are using it.2. WPF has been out there for a while, is stable, relatively bug free, and has a resonable number of people familiar with it. (And tutorials/help/tools for using it.)3. WPF is specifially designed to seperate the UI's appearance from functionality. Which means (at least in theory) once the code behind the UI works, a graphics designer can "easily" alter the UI appearance to their heart's content, without needing a programmer's assistance. (I have bad memories of spending weeks tweaking the appearance of the C++ UFOpedia under the direction of our graphic artist/designer. I did not enjoy the experience. No insult to him, it was just lots of tiny, tiny changes.)4. The time spent learning WPF is a potentially useful/marketable skill.5. Because it's standard, we may have more luck getting a Graphic Artist/Designer willing to help work on it.

Of course, it does have a couple of downsides.1. It locks us pretty firmly into the Windows platform. (Although Moonlight may solve that.)2. It may lock us out of the 360, again, until silverlight runs on it. (Not sure if it ever will.)3. WPF has a steep learning curve. (Although there are lots of tutorials on it.)4. We haven't confirmed we actually can get Xenocide up and running under WPF.

So, my thoughts.Darkhomb, do you want to try mocking up some Xenocide screens in WPF, to see what it's like? (I suggest the UFOpedia, and maybe the base inventory screen.)PezzA, do you want to see if you can get xenocide running under WPF? That said, you may want to give Darkhomb a hand to build a stub executible for him to work with. By creating a shell WPF program, and then adding the "Model" part of xenocide to it, so that he's got actual data to work with for the UI.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

Right before everyone went away we started working on a new UI - WindowsSystem.

OK, I've had a VERY quick glance the code, and my first impression (which may be wrong) is that it's going to take a fair bit of work to get this going, as we'd need to create a grid control, a tree control (for the UFOpedia) and a large area text control.

My preference is to go for WPF, for the following reasons.1. WindowsSystem doesn't seem to have had any progress since 2007. And I don't think many people are using it.2. WPF has been out there for a while, is stable, relatively bug free, and has a resonable number of people familiar with it. (And tutorials/help/tools for using it.)3. WPF is specifially designed to seperate the UI's appearance from functionality. Which means (at least in theory) once the code behind the UI works, a graphics designer can "easily" alter the UI appearance to their heart's content, without needing a programmer's assistance. (I have bad memories of spending weeks tweaking the appearance of the C++ UFOpedia under the direction of our graphic artist/designer. I did not enjoy the experience. No insult to him, it was just lots of tiny, tiny changes.)4. The time spent learning WPF is a potentially useful/marketable skill.5. Because it's standard, we may have more luck getting a Graphic Artist/Designer willing to help work on it.

Of course, it does have a couple of downsides.1. It locks us pretty firmly into the Windows platform. (Although Moonlight may solve that.)2. It may lock us out of the 360, again, until silverlight runs on it. (Not sure if it ever will.)3. WPF has a steep learning curve. (Although there are lots of tutorials on it.)4. We haven't confirmed we actually can get Xenocide up and running under WPF.

So, my thoughts.Darkhomb, do you want to try mocking up some Xenocide screens in WPF, to see what it's like? (I suggest the UFOpedia, and maybe the base inventory screen.)PezzA, do you want to see if you can get xenocide running under WPF? That said, you may want to give Darkhomb a hand to build a stub executible for him to work with. By creating a shell WPF program, and then adding the "Model" part of xenocide to it, so that he's got actual data to work with for the UI.

Sure, I'll get weaving. I'll have some background reading to do first.

I was going to make the suggestion over in the other colonization thread, but might as well suggest it here. Regarding colonization, maybe another approach is for you to go 'on secondment' with the colonisation team, who sound like they have quite a lot of devs with 3d/game smarts, and work on a battlescape engine that both projects can use? This will be the lynch-pin of both games so maybe that's where we'll get most bang for our buck in terms of collaboration. It'd also let you focus on that task. Just an idea.

Once we have a very basic build and I can understand what is needed to create objects I will start our UI's from scratch (That is take what we want out of Xenostyle, and scrap the rest) and hopefully be able to break it up into multiple .png's to keep things more organized.

I noticed the changes I made to the UI didn't reflect when I deleted by debug. Found out the CEGui branch was coping their files overtop the Xenocide resource folder. I stopped those from copying and you should now see the changes.

These are just quick fixes because I didn't like the title bar and a few others.

Still building the stub application i'm afraid, getting a few problems with game state when running outside the boundary of an XNA game object. And not really into the meat of the getting the 3D scenes up into a WPF app. What i've been doing is moving all the model logic into a separate XenocideModel assembly which can then be used by any other app. When that's there and i have an interface where a game can be loaded and saved, is to move the geoscape as a scene (possibly from a scene engine assembly) into the form.

It's a bit hard going though, and there is the nagging doubt current XNA/WPF integration techniques are just clever workarounds at the moment, and might not be robust enough a platform for development.

In the meantime you might want to look at this. Neoforce controls are under development at the moment and have a decent set of widgets. No multi-column list box however. (or tree-view). I've not tried adding these controls to xenocide yet. I might if i get totally stumped with the WPF app.

I took atlook at the site is is nice and clean. Installed the application, I'd have to check to see if we can do multiple skins at the same time. Also this requires XNA framework 3.1, we are only at 3 correct? so we would have to change framework again.

I took atlook at the site is is nice and clean. Installed the application, I'd have to check to see if we can do multiple skins at the same time. Also this requires XNA framework 3.1, we are only at 3 correct? so we would have to change framework again.

Well, having according to the changes between 3.0 and 3.1, none of them appear to impact Xenocide. So, in theory, an upgrade should just require installing 3.1, then run the upgrade tool to replace the DLLs and update the project links. (Or it could even be done manually.)That said, I'd consider Neoforce controls (or any other XNA GUI package) as a plan B, to be investigated if WPF is not viable.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.