DarkUI status?

[chriscalef]

Does anyone have any feedback re: what I'd have to do to merge DarkUI into a current T3D build? I sat down and tried to do it yesterday, but even compared against 3.6.1 the merge was practically all changes, so for any of the script files I have very little way of knowing what was actually modified by DarkUI. Obviously I don't want to just overwrite my new T3D script files with the DarkUI versions from 3.6.1 either, so any insights from anyone would be most appreciated. I would love to get DarkUI into MegaMotion ASAP, it really does look a million times better.

[Jason Campbell]

I'm not at my computer right now but I think WinMerge would work to find the differences and just copy them over. It is a great and free tool.

[chriscalef]

Thanks, but that's what I was using when I said the merge was nearly all changes. It wasn't just whitespace, it looked like the code had been all rearranged, so it was nearly impossible to tell where the relevant details were. I'm comparing the Full template from 3.6.1 against what was reportedly the 3.6.1 version of DarkUI, maybe I should have used Empty? Checking that next.

EDIT: Ah, yes, Empty template is looking a lot better.

[Jason Campbell]

Wow, yeah, what a jumble. It's too bad, Nils was going to make a commit but understandably got busy. I noticed JeffR was using the Dark UI in his demonstrations of new features. Maybe Dark UI is default in 4.0, if it isn't, it really would revamp the UI with a little sleeker look.

[Timmy]

Dark UI works ok with the latest devhead build, only mod i had to make was to the menubar to hide that hideous thing that is enabled when using SDL.

[Duion]

I use the dark UI as well and it was no problem, most changes are just colorchanges.

Of course since with SDL2 the menubar works now, you can skin the top menu bar as well, which did not work previously.

[chriscalef]

Nice, thanks guys, I'll see if I can merge it in today. Yeah, seeing it in JeffR's videos got me off my butt again, it really does look good.

[chriscalef]

Ah, okay, well that went great, except I see what you mean about the menubar. What do I have to do to reskin it?

http://opensimearth.org/images/darkUI_oldMenubar_.jpg

[Duion]

Search for PlatformGenericMenuBar

[chriscalef]

Hm, sorry for being slow, but I've generally stayed as far as humanly possible from things like gui profiles, so I still don't really know that well how they work... I found the guiPlatformGenericMenuBar.ed.cs and .gui files in tools/gui though. They're not very big and the changes seem to all be occurring in the profiles, but I can't find actually find a definition for the referenced "GuiMenuBarProfile" anywhere in the project, or even the more generic "MenuBarProfile" which is referenced in several other guis.

I tried changing the reference for PlatformGenericMenuBar to a new profile called "GuiDarkMenuBarProfile", and then making a profile of that name, by copying one of the other profiles in profiles.ed.cs, using the DarkUI values for fillcolor, textcolor, etc - but nothing changed. I'm not sure what specifically menu-related stuff the actual GuiMenuBarProfile is supposed to have.

[Duion]

My GuiMenuBarProfile:

 

singleton GuiControlProfile( GuiMenuBarProfile )
{
  fillColor = "32 32 32 255";
  fillColorHL = "72 72 72 255";
  fillColorNA = "18 18 18 255";
  borderColor = "98 163 229";
  borderColorHL = "122 177 232";

  fontColor = "196 196 196 255";
  fontColorSEL = "212 212 212 255";
  fontColorHL = "255 255 255 255";
  fontColorNA = "128 128 128 255";

  border = 0;
  borderThickness = 1;
  opaque = true;
  mouseOverSelected = true;
  category = "Editor";
  bitmap = "tools/gui/images/checkbox-menubar";
};

[chriscalef]

Eek! Now I remember why I never mess with Torque GUI profiles. :shock:

Not sure what's going wrong, but I copied your code into my profiles.ed.cs and made sure my menubars were using that profile. When I run it, I can verify that the gui created in guiPlatformGenericMenubar.ed.cs was indeed created, and that it thinks it is visible, and that it is indeed using GuiMenuBarProfile as its profile, and that the profile it says it is using has font color and fill color matching those of DarkUI, not stock Torque.

However, the appearance of the menubar is unchanged.

I figured there must be some competing menubar profile somewhere, but I found and replaced "menubarProfile" and "editorMenubarProfile" to no avail.

Is SDL2 something automatic or do I have to ask for it in CMake?

[Duion]

You have to switch it on in Cmake of course.

[chriscalef]

Ha, sorry, temporarily forgot what SDL even was in my single minded devotion to purpose. But yay, menubar works now! Thanks for the help.

Any other great things I might notice now that I'm using SDL? Or is it all just invisibly smoother and better?

EDIT: uh oh, first new thing I noticed is a bug! I'm running a few weeks behind now in my T3D build, I'll check to see if a brand new build has this fixed yet, but do you notice that with SDL turned on your window docking no longer works properly in the editors? I get windows docking at about a menu bar's thickness below where they should be. In the shot below, the scene and inspector windows on the right are "docked".

http://opensimearth.org/images/SDL_bad_docking.jpg

[Duion]

The SDL flag probably should be enabled by default in Cmake.

[chriscalef]

I think it might have been, once I updated to current HEAD. I do still see that docking behavior on a vanilla build with SDL, though. Anybody else seeing it?

[Duion]

I never noticed any docking behavior at all in any of the versions, did I miss anything?

[chriscalef]

I mean window docking, when you're in the world editor, and you drag the Inspector window over near the bottom of the Scene window, and it snaps to the bottom - that's worked forever, but now in my SDL version it snaps to about the width of the menu bar below where it is supposed to be.

Not a critical mission fail bug, but definitely something likely to be noticed. I suppose I should make an actual post about it or file a bug report instead of hijacking my DarkUI thread...

[Timmy]

Yes chris you are correct, this is another small bug with sdl enabled. I personally don't think the T3D implementation of sdl is ready to replace the winAPI just yet, there are numerous other small bugs with it too (nothing overly dramatic but bugs none the less). If it were my decision it wouldn't be the default on windows just yet.

[JeffR]

Can't say I'd spotted that issue before. but thanks for pointing it out. I'll definitely have a look at it.