fenrian1

While making my veliouse UI, I was stumped by the contradiction in needs of pet class characters between raiding and grouping. In an effort to make a mod that would work for both casual usage when pets dont have many bufs and raiding where all 30 need to be visible, I stumbled on an interesting solution.

The pet window is short and wide with a scrollable buf window that displays 6 accross and 5 down, this is fine for casual usage. There is then a window that is positioned in the upper left corner of the screen that displays all 30 bufs, this window can be minimized when not needed.

What I did was create a set of nested windows. Since buttons will only work when they are within the physical bounds of the parent window, the minimize button for the hovering buf list is in the pet window. The minimize button position is hard coded so it always appears in the title bar as well.

I started by makeing a custom window template using an clear corner of window_pieces01 for the title bar, then made a screen item using this template and sized it to about 15x10, this is about as small as you can make the window and still display the minimize button. I then created another window using WTD_Def2 that had the buf list in it. I set the <RelativePosition> to false, I could then position the list any where on the screen using the X and Y locations. The buf list is nested inside the custom screen, and the custom screen is nested inside the pet window. The minimize box in the custom screen will minimize the buf list screen. All the code is part of the pet window and since the element is outside the bounds of the parent, you can click through it.

After I was done I realized this could be used in many ways to improve UI moding, I have no plans to start another UI atm, so I thoght I would share some of my ideas in hopes that others will use of think of ideas of their own.

A portal style UI could be fashoined using only the EQMain window as the parent to hold all the graphics, you would then have a frame for your UI that you can click through.

Stats could be minimized or poped up depending on the group and class needs. Backgrounds for the pop ups could be made to fit with existing static windows so the UI would grow or shrink as needed.

Click through maps.

It might be possible to position things like the con indicator, flashing attack indicator and ooc icon inside another window with out complicated window layering(I plan to try this for next release of Veliouse to get rid of the xml error).

Pretty much the entire UI can be reduced to a set of button holders with click through elements to display infos.

Hope some people feel some inspiration from these ideas, they have me feeling a bit excited.

Fen

shillingworth

Add in a Style_Tiled to the master screen list and you have a killer way to create a UI. Once I get my account renewed I was planning to test something like this.

Screen PlayerWindow
Style_Border = false
Style_Tiled = true
Style_Transparent = true
Pieces:
RealPlayerWindow
GroupWindow

Screen RealPlayerWindow
Style_Border = true
Style_Closebox = false
Style_MinimizeBox = true
Style_MaximizeBox = true
Style_Transparent = false
Pieces:
Hp, Mana, End, Title, Name, Surname, Level

Screen GroupWindow
Style_Border = true
Style_Closebox = false
Style_MinimizeBox = true
Style_MaximizeBox = true
Style_Transparent = false
Pieces:
Invite, Disband, Follow, Decline, GMember2 through GMember6 HP/PetHp/Name

Depending on if that worked or not, I'd expand from there, even work on the EQUI.xml and the Screen Element names until I figure out if EQ code looks for the element name or the file name. Could really make for flexible UI code if it works how I'm thinking it does.

Edit: NVM on Style_Tiled, it was removed sometime in the last 5 months. Wierd, however Horizontal Layout Box and Vertical Layout Box could be used instead.

__________________

myxiplx

If that works how I think it works, it's a stunning idea. Didn't know click through worked for windows, but that's got potential to make some really unique UI's.

shillingworth

Your click-through technique should work on anything that inherits from Control, that's the base class that defines behavior, can see the inheritence in SIDL.xml. superType is the element to inherit from (it'll inherit all of the base element's children).

myxiplx

Oh god, you mean I'm actually going to have to read through sidl.xml and really think about this.... o_0

*sigh* I sure hope I think of something to do with this and the end of it! lol

Now this has been pointed out I'm starting to think how many limitations of sidl are just there because I've not dug deeply enough... Great detective work fenrian, working this out is gonna be fun