A little skin editor

[centipede]

Hello forum.

Making new .imageset-files is quite hard if you do it by hand, which moved me to hack together a small utility that can assist in the process of locating coordinates.

You will need Python, PyGTK and GTK:
Windows Python
Windows PyGTK
Windows GTK

And of course the editor itself:
Crazy Skin Eddietor v0.1

Quick instructions:
http://artcamilla.dk/vaultage/projects/cegui/CrazySkinEddietor_instructions.jpg

<EDIT>The the instructions only matches version 0.1.0. Baxissimo has made some changes which is in 0.1.1. Further changes will come from time to time</EDIT>

[baxissimo]

Very very cool!
What's on your todo list for this?
Right away I think you'll want:
- A file browser button so you don't have to type in filenames. (And for save too)
- The ability to click on a part of an image to select it (rather than select by name)
- A way to show all rects so you can browse over the whole file and see if any are missing
- Tooltips that tell you what widget you're hovering over
- Maybe some basic bitmap editing capability too, but edit externally and hit reload might better in the end, unless you can replicate all of Gimp or Photoshop's functionality. Automatic reloading of externally modified images might be nice though.
- Way to show just the alpha channel
- Checkerboard background option to help reveal what's transparent.

That's all I can think of for now.

[centipede]

..Plus:
- Copy one setup and paste to another which uses the same pixels


Thanks. Do keep thinking. However expect development to be a bit slow as I'll concentrate on making skins for a period

[baxissimo]

Are you interested in contributions?
I've just added the file dialog and the hover hiliting.
After adding the hover I noticed that there are some rectangle specifications in the taharezLook that don't conform to your assumptions. For instance the TabButtonNormal's lower left corner uses a piece of bitmap way over yonder from the others.

Also when you drag something it snaps the from and to lines together, when many of the elements need to have space in between them.

I think it might just be better to give each sub-element it's own rectangle. There's nothing inherent in CEGUI that requires the cells to be arranged in a nice little grid. But then again, it is convenient to be able to drag all the edges together when they _are_ aligned.


[edit]
The changes I've made so far can be found HERE

I redid the coordinate handling so it just saves and manipulates a plain old list of rects per set, rather than assuming that the images will be on a grid. It means you can no longer change all the left edges at once, but it also means that you can actually edit the layout anyway you wish. I made it somewhat easier to edit the individual rects as well by being able to select corners, edges, or whole rectangles.

The open file dialog is in there too.

And I changed the combo for magnification to a slider. That seemed to make more sense to me.

Oh, and it hilites the element you're hovering over with the mouse in blue, and you can select that element by double-clicking.

Now get cracking on those skins! I'll be waiting.

[centipede]

It works GREAT! Thanks a bunch for the many small changes. I originally thought that dragging both start and end points for each area would be too slow, but it seem to work well in your version.

Funny to see one's own code sensibly refactored

I'll work on some skins now (and as you can see my sole time for working/posting on forums/email is before noon, danish time).

From now on I will discuss what to code on the skin editor before doing anything in order that we can better coordinate things between those contributing.

..oh and for the TODO list:
- Support for WindowsLook
- Update to new XML format that CrazyEddie announced in some other thread (probably in some other forum too..)


Regards
-Centipede

[baxissimo]

Hey centipede. Glad you like it.

I just made one more change which will probably be the last I make. Now instead of a big label to display info it uses a TreeView. And I put the left and right things into splitter panes so you can resize.

The url is the same:
CrazySkinEddietor.txt


We're counting on you for some kick-ass skins now!!

[baxissimo]

You will need Python, PyGTK and GTK:
Windows Python
Windows GTK
Windows PyGTK

Just to make things a little easier, here are some direct links to the downloads for the above:
Windows Python 2.41 Windows Installer
Gtk+/Win32 Runtime Environment Installer 2.6.8-rc1
Windows PyGTK (pygtk-2.6.2-2.win32-py2.4.exe)

Hope that helps.

[SuprChikn]

@baxissimo: I just gave your updated version a quick spin, and I found a little problem with it.
Using the file dialog, you can load an .imageset file from anywhere, but it will look for the corresponding .tga file in the same place as the python script, not the same place as the .imageset.
It's coming along nicely though. Good work guys.

[baxissimo]

@SuprChikn, yeh, good catch.
I just fixed it. Download the latest for the fix.

[baxissimo]

I make a binary with py2exe.

CrazySkinEddietor0.11.zip

No installer. Just unzip it to a directory and double click on the exe inside to run it.

Hope it works for you!

[CrazyEddie]

Just a note to say that I think this is pretty excellent stuff

[centipede]

Thanks Eddie, and for a grrreat GUI too

Man, skin creation has become easy. Why the hell didn't we do this much earlier?

As soon as I have made one skin finished (using TaharezLook.dll) the experiences gathered will be put together to make a little tutorial. ... Or perhaps I'll wait until CEGUI 0.4 which should give more control over which areas to stretch, which to tile etc.


@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. My original intent was to make something like this:

Code: Select all

+--------+--------+
|  ...   | .. ... |
| . ._|  | . . ._||
+--------+--------+

The _| things are 'end-markers' which can be dragged independently and
the +- things are 'begin-markers' (except for the last row/column


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):

o) Elements are comprised of subelements, e.g. the Window element consist of the subelements WindowTop, WindowLeft, WindowBottom, WindowRight ...

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.)

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).

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.

How about that?

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"

regards,
centipede

[jacmoe]

This is great!

I just tried the latest script from baxissimo - nice!
Just a small request: when double-clicking on elements, the element in the dropdown doesn't get updated. This needs to be fixed.
Other than that: this rocks!

@centipede: Can't wait for the next release!

[baxissimo]

jacmoe wrote:
This is great!

Thanks! Centipede did most of the hard work. By the way, @centipede: how long did it take you to get that initial version working?

jacmoe wrote:
I just tried the latest script from baxissimo - nice!
Just a small request: when double-clicking on elements, the element in the dropdown doesn't get updated. This needs to be fixed.
Other than that: this rocks!

Yeh, I know. I put a #TODO: comment in the code where that needs to happen, but it was my first time using GTK and I was too tired to figure out how to select an item by name.
The pyGTK documentation definitely leaves a little to be desired. If it were me I would have gone with wxPython.

[baxissimo]

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.