Maybe add the rest of the code in a different branch

Question

Maybe add the rest of the code in a different branch

volcoma opened this issue 8 years ago · 15 comments

I know you are busy but maybe u can add the rest of the code containing the docking/undocking with the cursor in a different branch so people can figure it out for themselves :). The current state is pretty good and i actually already use it but i am hesitant to add changes because u said that you were planning to add the rest of the stuff later on and i don't want to refactor it all again when u do. So seeing your direction would actually help :)

Answer 1 · 2016-09-19T08:49:20.000Z

Not a bad idea.. will do that, have just to remove engine specific stuff and ready for upload.

Answer 2 · 2016-09-23T17:05:51.000Z

@edin-p any development on this issue?

Answer 3 · 2016-09-24T08:50:58.000Z

Sorry, forgot to tell that I wasn't home this week, so I don't have access to the source, but I'm coming home tomorrow or maybe Monday... I will then upload the rest of the code

Answer 4 · 2016-09-24T18:16:43.000Z

Thanks for the info man 👍 . You are the best :). Btw how is your engine going? Mine is going pretty well. Currently focusing more on the editor stuff to make it "easy to use". Here is a preview of your docking stuff in use :)

Answer 5 · 2016-09-26T06:35:34.000Z

Wow, looks really great.. Are you using image button for viewport? and how do you handle rightclicks? ... I'm finally home, will upload the rest of the code today. I'm having little problems over design of my render system because I am using Vulkan for now, right now implementing deferred PBR renderer.

Answer 6 · 2016-09-26T07:13:52.000Z

Its just an image with some logic after that. Pretty much the gist of it is the following

gui::Image(frameBuffer, size, uv0, uv1);
if (gui::IsItemHovered())
{
    if (gui::IsMouseClicked(1) || gui::IsMouseClicked(2))
    {
        gui::SetWindowFocus();
    }
}
if (gui::IsWindowFocused())
{
... handle the camera movement
    if (gui::IsMouseDown(1))
}

Answer 7 · 2016-09-26T14:59:34.000Z

Thanks for the info :) I uploaded the rest of the code, hope it will help..

Answer 8 · 2017-10-02T21:59:11.000Z

Hello @edin-purkovic, have you got around to push your OS window code as well ?
I am going to be looking at supporting an official docking extension for imgui, so I'm interested in looking at the ones already out there. Thanks!

Answer 9 · 2017-10-02T22:17:31.000Z

Hey Omar,
I have been really busy since the release of the docking code and haven't done much to improve it. Current state of the code is not really usable so I wouldn't really recommend using anything from this repository. Maybe if I take few days, I could rewrite it to be more friendly for the integration with ImGui. What do you say?
Cheers!

Answer 10 · 2017-10-02T22:28:24.000Z

Hi,
Maybe don't worry about rewriting/finishing it, I'm mostly looking for inspiration as a first step. It's probably ok if it is doesn't work. I may possibly even rewrite a new one, I'm here first to pick all the good ideas and see how we can design an abstraction interface to allow the user to use their native OS windows/rendering context.
Omar

Answer 11 · 2017-10-02T22:35:29.000Z

Hey guys. I've modified slightly the code to my need, but you can see it working in my repo. Just build my project to see it in use.
Here are the files themselves. Basicly I've noted all that is needed to run this system at the start of the header file. It is better than the other solutions like the lumix engine's one but other ones may be better suited to add in imgui. This system kinda need a lot of ther stuff like handling multi window and rendering onto multiple windows. Having a separate imguicontext per window, a place for the docks and the dockspaces and a way for them to be associated with a specific platform window ... etc.

https://github.com/volcoma/EtherealEngine/blob/master/editor/interface/docks/imguidock.h
https://github.com/volcoma/EtherealEngine/blob/master/editor/interface/docks/imguidock.cpp

Answer 12 · 2017-10-02T22:44:02.000Z

Ohh, I see, hopefully the code will help at least a little bit. As for the ideas if I may suggest, I would recommend using function pointers for the content of tabs. Using Begin/End ImGui style is more consistent but may make it harder for use in more complex scenarios.
I would like to ask you is there any plans/progress of making ImGui multithread ready? Having ctx->BeginChild... etc or something similar would go hand in hand with docks. Using TLS may not be the best solution in lots of cases.

Answer 13 · 2017-10-03T00:38:56.000Z

@edin-purkovic I just got your code to run here! If i'm not mistaken isn't the version on github is lacking a lot of the code? there's no way to drag tabs anywhere (but splitter works).

Answer 14 · 2017-10-03T08:05:37.000Z

That's correct, code on github is missing quite a lot of code and not really suited for an integration with ImGui but that is not hard to add, that would be just undocking from the current dockspace and dock it to the dockspace of newly created window. It would be best to rewrite it from the ground, and it won't take too much time, maybe few hours. Main concept is that Dock struct holds all the data about the dock and Dockspace recalculates the containers. For every dock added it creates a new container with two splits, if the second split is empty - nullptr it draws the first one, otherwise it goes in one level in both of the splits and checks the same thing. That's why the draw function is recursive.

Answer 15 · 2017-10-03T08:15:55.000Z

Deleting docks goes the same way. If we want to delete/undock the first dock we just go up one level to the parent container and assign the second dock to the first split and delete and set to null the second split of the parent container.