centipede wrote:
Man, skin creation has become easy. Why the hell didn't we do this much earlier?
We were just waiting for you, man.
I had no idea pyGUI programming could such a snap. I'm definitely sold on the concept of python for little one-off tools like this. May not be as convenient or solid as a real C++ program to use, but if it's a matter of having a tool in python or not having it at all, I'll go for python every time. You showed me the way, centipede. Thanks.
centipede wrote:
@bax: Your changes are splendid, but I kind of miss working with the grid as a whole. I find myself switching back and forth between your version and the first one. I know the grid-editing concept doesn't fit the original taharezlook, but it would fit 90% of those that I make myself.
Interesting. Well, I'm not really a serious user of this tool, so I'll have to take your word for it. I was planning to use it to just make minor tweeks to taharez, shave a pixel here, expand a pixel there kind of things.
Here is a proposal for uniting both your version and mine(that I might work on in the weekend unless you beat me to it):
Heh heh. Actually I'm pretty much done with it for the time being. Got a friend coming to town today, and I got to get on to other things here at work. Just so happened that you came out with your script a just the time I was wondering how I was going to be able to tweak the taharez look so it didn't smack so much of a monkey's hindquarters.
o) Elements are comprised of subelements, e.g. the Window element consist of the subelements WindowTop, WindowLeft, WindowBottom, WindowRight ...
Sounds reasonable. That's the way the code is set up right now, and it makes sense to me. One thing that is limiting about the current point and click interface I added is that it is possible for multiple things to use identical bitmaps. In that case I'm only hilighting/selecting the first one that's under the pointer right now. The Listbox, for example cannot currently be selected by point and click. You have to use the combobox to select it.
My thinking was that the treeview on the right could actually be used as a treeview, and show all the elements under the pointer, hierarchically with the Element as top level, and subelements underneath.
Still not sure how best to select things that are on top of other things. Maybe cycle through the candidates as you keep double clicking. Or maybe if you double click and it's ambiguious it could pop up a little menu to select from.
o) As you can see right now, I have factored the editing facilities of each element out into the TaharezSkin class' inner elementclasses: ClientBrush, Window, ... (each of them just inherits from the standard GridEditor, but I figure that it would be more foresighted to give each element the chance to implement it's own unique editing workflow.)
So you mean some could be grid-like and others not grid-like? I'm not sure what you mean by "unique editing workflow".
This design should changed so that the Skin class and it's subclasses merely holds the information, i.e. the rectangle values and the properties of those (strech/tile etc).
Yeh, that makes sense. Then some other class can decide how that info is manipulated, rather than calling methods on the Skin elements themselves to handle mouse clicks and such.
o) The editor can run in one of several modes, each with it's own perception of the cell data in the edited skin: GridEditingMode and CellEditingMode.
That seems ok. But if you try to edit an Element that doesn't adhere to the assumptions of GridEditingMode then you've got to prevent that or fail or pop up some kind of warning to the user. Taking some very non-grid like thing such as the Window element and pretending it's a grid as the previous code did is very non-obvious and destructive behavior.
How about that?
Sounds like a good long term strategy. But it's going to be tough if you don't have a serious chunk of time to devote to it. Just before you were saying you're going to leave it as-is because you want to spend your time making skins for now. Is skin-making now so easy that that's not a concern?
More stuff for the TODO list:
I would like to make short descriptions for each element and quick instructions for the artist on the requirements that should be fulfilled when painting it. It is hard to do right now. E.g.
NewTitle: "The NewTitle consists of five subelements. NewTitlebarLeft, -Middle, -Right makes the first half of the titlebar and SysAreaMiddle and -Right the last half. The sysareas are meant for window icons such as closebuttons etc. The NewTitlebarRight cell must contain the transition between the two stretched/tiled cells: NewTitleMiddle and SysAreaMiddle"
Yeh, that kind of thing is probably important for making it usable to a wider range of artist-folk. But I dunno. That would be a fair amount of work, and it's pretty obvious right now that for all the elements the one called "BlahBlahRight" is going to be next to the one called "BlahBlahMiddle" is going to be next to "BlahBlahLeft".
Probably more useful would be a "preview" button that pops up a pyCEGUI/pyOgre window showing how the element will look in action. That is if pyCEGUI is done... [are you listening , Clay?] Then you don't have to tell the artist what they're supposed to do with a big long description. They'll be able to see right away if they're doing the wrong thing.
