ID:1772816
 
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
https://msdn.microsoft.com/en-us/library/windows/desktop/ ms633573(v=vs.85).aspx

I'd like to make a small request in relation to DreamSeeker's interface. I've recently discovered that transparent windows can be created, allowing controls to be layered on top of one another in the UI. Unfortunately there is no good way to layer transparent controls on top of a window and have them stick with the window when it's moved.

The features I am requesting are as follows:

Allowing windows to be parented and docked to one another.

This would integrate one new window property:

dock-bounds

Dock bounds would set the minimum and maximum x and y coordinates that a docked window could be dragged within its parent window.

The format would be: "x1,y1 to x2,y2"

And it would change three existing window properties slightly:

parent

This would require the ability to set a window's parent to another window when it is not in a child panel. It should be noted that currently windows that are not panes do not use the parent property so this won't break any current behavior.

anchor1 and anchor2

anchor1 would become useful for layering windows on top of one another when docked. This would facilitate automatic positioning as normal for an element but clamped within the area specified by dock-bounds. Anchor1 and anchor2 are not currently used by windows that are not panes so again this won't break any current behavior.

It would also add three new callbacks:

on-sizing, on-moving, on-moved

Windows UI supports WM_SIZING, WM_MOVING, and WM_MOVED. Dreamseeker now supports the .winset and .output commands to allow client-side processing of these events. Previously, these windows messages were neglected because of the extra load they would have put on the network. Now that we have the ability to process this information client-side there's no reason to not have them.

All of the required code is compatible with Windows 2000 professional or higher


min-size, max-size, aspect-ratio

Also, a min-size, max-size would be really helpful for a lot of interfaces. Interfaces get really ugly when they are scaled up or down too much. Simply working in a clamp() to the WndProc callback based on the min-size, max-size, and ratio settings would be great.

min-size and max-size would be in the form of pixels: x,y

ratio would be calculated from y/x and set the resizing to have to be a specific aspect ratio.

Here's some bad C++ that demonstrates the suggested code-flow.

void WndDockedChildMove(HWND hwnd,LPARAM lParam) {
//clamp x,y to dock-bounds area
return void;
}

//callback sent to all children of a window
BOOL CALLBACK WndDockParentMoved(HWND hwnd,LPARAM lParam) {
if(hwnd->docked) {
//set x,y,w,h to anchor1, anchor2 properties
//clamp x,y,w,h to dock-bounds area
}
return true;
}

LRESULT CALLBACK WndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {
HWND par = GetAncestor(hwnd,GA_PARENT);
switch(uMsg) {
case WM_MOVING:
if(par!=NULL && hwnd->docked) {
WndDockedChildMove(hwnd,par,lParam);
}
EnumChildWindows(hwnd,&WndDockParentMoved,lParam);
//trigger onMoving event here
return 1;
case WM_MOVED:
//trigger onMoved event here
return 1;
case WM_SIZING:
if(par!=null && hwnd->docked) {
WndDockedChildMove(hwnd,par,lParam);
} else {
//clamp w,h to min-size/max-size here
}
EnumChildWindows(hwnd,&WndDockParentMoved,lParam);
//trigger onSizing event here
return 1;
//do whatever else you already do here
}
To be honest, I really hate the transparent-color feature and wish we didn't have it; it's a legacy thing introduced in Windows 98 that was quickly supplanted by better methods of handling transparent pixels for entire windows. Adding a whole lot of new stuff to make it easier to design interfaces like that--where that kind of thing also forces the renderer into software mode because of drawing issues--wouldn't be high on my priority list.

The webclient is much, much more capable of handling transparency in intelligent ways than Windows.
Where that kind of thing also forces the renderer into software mode because of drawing issues.

This isn't true anymore. The web client handles window transparency in hardware mode. I've tested it in a few conditions now. It doesn't seem to cause any rendering artifacts like I expected either.

I'd just like to be able to use browsers and secondary map controls that aren't completely square over the top of my existing interface. The latter is completely unsupported by the web client at the moment.
Well yes, the webclient doesn't force software mode because it doesn't really have such a thing. But the webclient is a whole lot better about handling transparency in general.
In response to Lummox JR
Lummox JR wrote:
Well yes, the webclient doesn't force software mode because it doesn't really have such a thing. But the webclient is a whole lot better about handling transparency in general.

Sorry, I didn't mean to say web client. The Seeker no longer kicks into software mode when window transparency is active anymore.
Yeah, I made that change a while back. Must have been a Win98 thing.
In response to Lummox JR
Lummox JR wrote:
To be honest, I really hate the transparent-color feature and wish we didn't have it; it's a legacy thing introduced in Windows 98 that was quickly supplanted by better methods of handling transparent pixels for entire windows. Adding a whole lot of new stuff to make it easier to design interfaces like that--where that kind of thing also forces the renderer into software mode because of drawing issues--wouldn't be high on my priority list.

The webclient is much, much more capable of handling transparency in intelligent ways than Windows.

I know you're pushing for people to use the web client, but it's not really fair to force it upon your users. Transparency support in dream seeker is really important for non-square interfaces.

You can't just force the web client on those that do not want to use it. It's also a learning curve people have to overcome. Dropping DS development is a bad idea in my opinion.

If I wanted to create a project that could be ported to web, I'd move to Unity. With all due respect there is no need to reinvent the wheel and I believe you should strive at working on what BYOND does best.
The idea is to allow the webclient to cover the same functionality as DS so it can be used as a modern drop-in replacement for existing games while also giving a lot more UI versatility (and cross-platform support) for new games. When it's done, you won't have to release your game on the web as it will be available in a portable CEF-browser implementation (which could also run a single-player game by hosting the server on another thread). Obviously full compatibility isn't there yet and there are a number of optimization bugs, but that's the goal.
In response to Lavitiz
The reason they're pushing for people to use webclient is because webclient opens a lot of possibilities in the future, it's going to actually allow us to achieve far more than we currently can.

I don't think DS will ever be truely dropped, at least not until webclient becomes better.

That said, webclient is pretty new and because of this problems are experienced with it, it's not just 'bugs' with webclient but also experience, right now there's a ton of libraries, examples and even messy rip sources that to use as reference to many things you want to do but really little work out there that helps you learn the ropes with webclient.

This lack of knowledge of what can be done with webclient is both exciting and frustrating, on one hand you can explore new things you couldn't before, whether via features or the audience you're targeting (mac users can now play games on BYOND via webclient), however, on the other hand being one of the firsts to explore kinda suck, whether the bugs experienced, learning CSS & Javascript or trying to do something you don't know how and have no example to study.

I'm really happy with BYOND's progress and it isn't just the webclient, if you look back a year or two you can really say that concert progress was done, it's really impressive.

I think BYOND is far more simple to use than Unity, it requires so much less code, effort or knowledge, it may feel like now with the webclient things are complicated but it's just because it's new. It falls on the more experienced users to pave the path for the new, in the future I believe it'll be way more simple.

I haven't quite tried but I also believe non-square interfaces are possible to make, except of course the browser window being square, I don't know if you can do much about that.
GatewayRa wrote:
That's false and there's a lot of ignorance revolving around that held belief. Do you think webkit based applications have some os-exclusive interface calls for their functionality? No, they're available to every other program pertaining to the same OS-- how else do you think web browsers came about?

So why haven't they incorporated transparency? Probably because they used the higher level DirectX's apis and never had to learn about shaders, and don't have the patience to create their own controls.

I feel like I need to set the record straight on something: The controls in DS are not hand-drawn, but are standard Windows controls and have been since the beginning. Creating them from scratch would never have been practical. Browsers basically draw everything themselves now, but that wasn't always the case; that's why browsers have styling options, and can handle transparency in ways that Windows controls can't. Windows makes transparency with individual controls nigh impossible; the only way to manage full transparency would be for the entire window to basically be one big canvas and do what browsers do.

Regarding the capabilities opened up by the webclient, they've been discussed at length and I don't think it would add anything to go over them again here.