githubuser0xffff / qt-advanced-docking-system Goto Github PK

1. Run ads_example
2. Undock "Label 2" widget - make it floatable
3. Close "Label 2" by pressing "Close window" button
4. Raise "Label 2" by pressing "View->Label 2"
   Now "Label 2" can't be docked anywhere.

Workaround to fix this is to call hide() inside closeEvent():

void CFloatingDockContainer::closeEvent(QCloseEvent *event)
{
    d->setState(DraggingInactive);
    hide();
    event->ignore()
}

Hi,
Changing all the dynamic_cast to qobject_cast would make the lib working when the RTTI is disabled and avoid to have RTTI everywhere when not needed.

Hi,

I have found an issue where I dock a window and then undock it quickly, it will crash. I have tried to reproduce in the demo app, but was unable to. I believe this is related to timing (I will explain further below) - my application is much more complex and has more interconnected signals/slots etc.

I am building in MSVC 2015, and have tested this in DEBUG and Release x64.

The crash occurs in the DockAreaTabBar::mouseMoveEvent, on the following lines of code:

if (d->FloatingWidget)
{
    d->FloatingWidget->moveFloating();
    return;
}

While debugging I see that d->FloatingWidget is non-null, but is a deleted pointer (the crash occurs on the moveFloating() call).

While tracing through the code, I see that the FloatingWidget is subject to a "deleteLater()" call when it is docked. I (temporarily) connected a slot to the FloatingWidget "destroyed()" signal, and using tracepoints was able to determine that there are rare instances when the signal is emitted that the widget is not yet null. These instances resulted in the crash on the lines above.

Here are 2 potential fixes to this:

1. connect a slot to the FloatingWidget "destroyed()" signal which will check for null, and if it isn't it should disconnect the slot and set the pointer null. (I have tested this approach and no longer got any crashing).

void CDockAreaTabBar::onFloatingWidgetDestroyed(QObject* obj)
{
   if (d->FloatingWidget)
   {
      CFloatingDockContainer* floatDock = dynamic_cast<CFloatingDockContainer*>(d->FloatingWidget);
      if (floatDock)
      {
         disconnect(floatDock, SIGNAL(destroyed(QObject*)), this, SLOT(onFloatingWidgetDestroyed(QObject*)));
      }
      else
      {
         CFloatingOverlay* floatOverlay = dynamic_cast<CFloatingOverlay*>(d->FloatingWidget);
         if (floatOverlay)
         {
            disconnect(floatOverlay, SIGNAL(destroyed(QObject*)), this, SLOT(onFloatingWidgetDestroyed(QObject*)));
         }
      }
      d->FloatingWidget = nullptr;
   }
}

2. Change the functions which call "deleteLater()" to pass the floating widget pointer by ref (or as a double pointer) and assign the FloatingWidget null after calling delete later.

I should also note that it is possible that other widgets that get "deleteLater()" called on them may be subject to a similar timing related crash, so it may be worth looking at making them robust as well.

Thanks,

Jon

Hello,
I have downloaded sources and tried to build and run library and demo application.
Here are few problems that I had:

Build:

1. I'm using VS2012 so not all C++11 features are supported. So I moved all initialization like " zOrderIndex;// = 0;" to constructor's initialization list
2. Although there is "DEFINES += ADS_EXPORT" in pro file, it wasn't used anywhere. So I added "ads_api.h" with ADS_EXPORT_API definition and added it to classes that are imported in "demo". Without those definition ".lib" file wasn't even created

Run

1. First attempt to drag a window resulted in crash in "CFloatingDockContainer" code because only first constructor initialized member "d" with "new FloatingDockContainerPrivate(this)". Two other constructors didn't do it
2. Next crash happens because if I understand correctly I also need to "d->DockContainer = new CDockContainerWidget(DockManager, this);" also in other two constructors (foolowed by signal/slot connection?)

I just want to ask if my understanding of these problems is correct and I am doing correct changes in the code.
Also, will accept these changes if I commit them into my forked repository? (Currently I am only doing local changes)

Thank you!

Hello,

This library looks fantastic.

I am building a project that will require a lot of this functionality, and on top of that it will be a frameless window, allowing our own titlebar to be used.

To achieve this, our titlebar would normally live in the central widget and would be fixed to the top. Would this library support similar behavior?

Thanks,

Joe

Can you add removeDockWidget feature?

In DockContainerWidgetPrivate::restoreDockArea() if a child widget of a dockarea can't be found with findDockWidget(), and that is the ONLY child of the dockarea :

if (!DockArea->count())
{
	delete DockArea;
	DockArea = nullptr;
}
else
{
	DockArea->setProperty("currentIndex", CurrentIndex);
}
CreatedWidget = DockArea;
DockAreas.append(DockArea);

DockAreas now contains a null pointer.

When control returns to CDockManager::restoreState() :

for (auto DockContainer : d->Containers)
{
	for (int i = 0; i < DockContainer->dockAreaCount(); ++i)
	{
		CDockAreaWidget* DockArea = DockContainer->dockArea(i);
		int CurrentIndex = DockArea->property("currentIndex").toInt();
		if (CurrentIndex < DockArea->count() && DockArea->count() > 1 && CurrentIndex > -1)
		{
			DockArea->setCurrentIndex(CurrentIndex);
		}
	}
}

At some point DockArea will be a null pointer, and the program will crash when it is dereferenced.

Hi,
can someone explain me the difference between State and Perspective?
I tried the demo but didn't really noticed any differance.
My second question would be also related to the demo. Is there is any important reason, i should consider when writing my own application, to use this MainWindowPrivate struct like in the demo project or just write everthing into the main window (CMainWindow) directly?

The adsConfig.cmake refers to adsTargets.cmake which is not present in the repository. This makes it not possible to add ADS to my project using find_package.

First, thank you for the quality library!

Suppose a CDockContainerWidget instance contains five CDockAreaWidget object, how can I get the last active CDockAreaWidget object. (let's say, this CDockAreaWidget object is the Last click user make.)

Add a config option for fixed size tabs unsing the following two options

• resreve spave for invisible close button
• show close button for all tabs

The CDockWidget::toggleView signal is not triggered with the Open argument to false when a CDockWidget gets closed due to a call to CDockManager::restoreState.

The signal is triggered correctly with the Open argument to true for the CDockWidgets that get opened as a result to the CDockManager::restoreState call. So the issue is just for the CDockWidgets that get closed.

I also tried with the CDockAreaWidget::viewToggled signal and the behaviour is the same. I don't know if it is supposed to work this way.

Hi,
The minimize button of detached window is disabled.

Hi, I was trying out your docking system, amazing job.
It works perfectly in Windows, but in OSX there is this issue that while dragging floating widgets they go to the background of the application for some reason. It is a deal breaker for me.

I recorded a video and attached it in a zip file.
osx_issue.mov.zip

I hope you can see the problem in the video recording.

Some widgets always have their reasonable width or height. However, when I use addDockWidget to add my widget, it seems too wide. Any ideas to make it in the correct width?

In example

#include "MainWindow.h"
#include <QApplication>
#include <QFont>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QApplication::setFont(QFont("ubuntu", 20));
    MainWindow w;
    w.show();
    return a.exec();
}

result:

I'm currently replacing the docking system for an existing application and I have a few questions:

1. From what I understand you are supposed to add all the docks at the start, right? But do I then have to hide them manually since I don't want them to be visible until the user toggles them on?

2. Lets say I'm making a photo gallery. The user can open an unlimited amount of pictures each in its own dock. In this case I would create and add the docks as requested. When the user closes a dock, is there any way to remove it?

3. Some of the docks I am working with are used to edit data. When the user tries to close a dock with unsaved changes the application used to show a pop-up letting the user choose if he wants to save the changes or not before closing it. Is there any way to mimic this behaviour with ADS?

Thanks in advance :)

Thank you for your efforts; the docking system rewrite is brilliant. Can you tell me how I can Tabify?

I have two docks: dockStepDetails and dockLib.
As you know in the original QT docking I can stack a newly created tab onto an existing one like so:

MainWindow::tabifyDockWidget(dockLib, dockStepDetails);

To stack the dockLib onto the existing dockSequencMan I tried to use your insertDockWidget:

dockSequenceMan->dockAreaWidget()->insertDockWidget(dockSequenceMan->dockAreaWidget()->count(), dockLib, false);

Although it initializes the docks correctly, I get an application crash if I try to drag tabs. Did I find a bug? Is this the proper way to tabify?

Thanks much

Hi,

I just found your advanced docking system and I have to admit I'm excited. It is really great and I searched for an improved Qt docking system for a long time. I had already thought about trying an implementation myself. I would like to say a big thank you for this great gift - I really like it.

The only thing that is missing for me is grouped dragging like it is suported by Qt since Qt 5.6. Maybe I will try to implment it myself and contribute it back.

Best regards,

Uwe #

I would like to emulate the exact behaviour that Visual Studio has in that opening a file will always open it in the same area and just adds tabs there. I tried emulating this behaviour, but CDockAreaWidgets seem to close or be deleted once all the tabs are removed from it.

if (dock_area == nullptr) {
	dock_area = dock_manager->addDockWidget(ads::RightDockWidgetArea, dock_tab, dock_area);
} else {
	dock_manager->addDockWidget(ads::CenterDockWidgetArea, dock_tab, dock_area);
}

It seems like it's impossible to have this behaviour.

Currently, we do something like this after initializing the dock system at app startup:

void setDockAreaButtons(ads::CDockAreaWidget *dockArea)
{
    auto closeButton = dockArea->titleBarButton(ads::TitleBarButtonClose);
    closeButton->setIcon(ToolButtonSvgIcon(ICON_CLOSE));
    auto undockButton = dockArea->titleBarButton(ads::TitleBarButtonUndock);
    undockButton->setIcon(ToolButtonSvgIcon(ICON_DETACH));
    auto tabsMenuButton = dockArea->titleBarButton(ads::TitleBarButtonTabsMenu);
    tabsMenuButton->setIcon(ToolButtonSvgIcon(ICON_DOWN_ARROW));
    tabsMenuButton->setToolTip(tr("List All Tabs"));
    for (auto tabCloseButton : dockArea->findChildren<QAbstractButton*>("tabCloseButton"))
    {
        tabCloseButton->setIcon(ToolButtonSvgIcon(ICON_CLOSE));
    }
}

This isn't ideal as any new dock areas created during run-time will then not have the correct icons. Our hacky solution is to react to certain ADS signals and call the above code again for newly-created dock areas.

So it would be nice to be able to set the button icons once at startup and have them apply for all dock areas - possibly via CDockManager?

Also, the same applies for the tooltips.

I have encountered almost the exact same issues as was reported in #52 #53. That is, if you start dragging certain windows (in my case it only happens with Qt3D windows) the movement is laggy. But if you release and start moving the window again the movement is smooth. However, if you dock that window somewhere and then try undock it by moving it the application crashes.

I can reproduce this issue on both Windows and Linux with both Qt 5.13 and 5.14. I think it has something to do with windows that are bit demanding to draw. Since it only happens with Qt3D windows with some contents and it easier for me to trigger with debug builds.

Patch that adds a Qt3D window to the demo application that triggers the issue for me:
Qt3D.txt

Valgrind output from Qt 5.14 from one crash:
valgrind.txt

Hi:
I disable DockWidgetFloatable feature, but when I double click the titlebar, the widget will be floating. It's on "linux_experimental" branch and my Qt version is 5.12.3.

Hi,

How can I bring an existing dock to front/set focus?
I can query the dock manager for docks with the findDockWidget but with the dock in hand how can I set it to be the current?

My use-case is:

• I have button that creates a dock and gives it a name...
• If I press this button again I don't want to create a new dock but instead bring to front or somehow set the active tab to be the existing dock.

Thank you!

Hi,
I would like to integrate this awesome layout that you have created into my QML project.

Do I use your code as a backend and make my QML front end or use QQuickView -> QWidget -> and add it to the dockmanager?

I tried using the latter but it seems buggy and crashes. Maybe I went wrong somewhere.

I was wondering why classes: CDockAreaTabBar, CDockAreaTitleBar, CElidingLabel are not exported into the DLL.
I was trying to get ads::CDockAreaTabBar::currentTab() and found out the class is not exported into the DLL, causing linker errors.

It would be nice to be able to cancel an in-progress opaque dock-drag by either pressing ESC or right-hand clicking the mouse.

QToolButton offers better styling for hover state

Hi, your fork of original docking system is realy great, thank you very much for pushing it further, and making new features.

I'am working on tool that can has variable amount of windows, like text/image editors. I trying to use child/parent relations for semi automatic memory handling as much as possible. At some point i found, that closed tabs/windows, are just hidden, and not realy closed/deleted. It would be realy cool to have option to pass some setting parameters into docking manager, that will define close tab behaviour. For example like that:

    _dockManager = new ads::CDockManager(this);
    _dockManager->setConfigFlags(CDockManager::DefaultConfig | CDockManager::DeleteWidgetOnTabClosed);

As i understood, main philosophy behind this docking system, is create all windows at start, and than restore state from *.ini file. My proposal may break this behaviour, cause at runtime we must always have the same list of created dock widgets, otherwise it wont work. It is ok, in some apps, but on other it is a limit.

So, what do you think about it? Is it possible to implement that behaviour, or it will requier a lot of work?

p.s. Is there some high level docs about project architecture? I may try to implement it my self, if you have no anough time...

Im trying to style the grey tab area and I know it works if I directly use set stylesheet on it where its created, but that makes it style after the default.css and layers over it.

I try some styles:
ads--CDockAreaTabBar { background: #cccccc; } CDockAreaTabBar { background: #cccccc; }

Can you please tell me how to style it?

PS: This library is incredible, I cant believe its this good.

In constructor of CDockWidget, object name and window title are the same, which cause the problem that different translation will not share one dock state saved by CDockManager

When I try to build the code I get "C1001: An internal error has occurred in the compiler" for line 56 in ads_globals.cpp

So I have a default perspective set up to load on start if my app sees this is the first time the user has opened the app ever. I also have some panels not a part of this default perspective.

I add all the panels on start to the docking manager, then load the default perspective. After that, if a user opens a non default panel, the panel starts floating rather than docked where I originally told it to dock in code. Is it possible to have a panel open docked the first time opening it?

Thanks,

Joe

This is pretty easy to reproduce, and I was able to reproduce it in the advanced demo.

In demo, add webenginewidgets to the demo.pro, and then import the header #include <QWebEngineView> in MainWindow.cpp

Then in createContent() add the following below:

    QWebEngineView* test = new QWebEngineView();
    test->setUrl(QUrl("https://www.google.com"));
    ads::CDockWidget* web = new ads::CDockWidget("Web");
    web->setWidget(test);
    ViewMenu->addAction(web->toggleViewAction());
    DockManager->addDockWidget(ads::CenterDockWidgetArea, web);

With this code added, now follow these steps:

Steps to Repro:

1. Move Main Window to a 2nd monitor.
2. Undock the Web panel.
3. Close the Web panel via the windows close button.
4. Move Main Window to your 1st monitor.
5. Attempt to re-open the Web panel via the view menu.

In debug, you will see the below. I was able to reproduce this in QT 5.12.3 and 5.13.0. Please note that if the floating panel is closed via the action in the view menu in place of step 3 above, the crash does not occur.

Hi,
On my non-hiDPI 1080p monitor the "close tab" and "detach group" icons look blurry. The "close tab" icon looks like the sizing is a bit off compared to the example images in this repo. Here's a screenshot of the demo app running on my Windows 10 machine (using Qt 5.11.1 x64):

Hi,
If you detach a dock widget and stay clicked and move around, the floating window is moving very laggy. When you release the click, so the detached window doesn't move anymore, and then move the floating window again, it's not laggy anymore.

Would be useful for people who use Python

Hello, I recently discovered this awesome library which really completes Qt's dokcing system.
I am planning on using it for my next project. My question is, if there is a way to create a dark theme like the one shown in the README? I understand it is a commercial product, so i just want to know if there are any styling options. I have tried tinkering with the provided style sheets but these do not make the dock overlays dark. Is there any way to style the docking overlays with a dark theme?

I've test demo on ubuntu 16.04 unity、ubuntu 18.04 gnome/kde，they all have this problem. My Qt version is 5.12.2

Move a detached window gives a jump on the window position. At the end of the move the window doesn't stay at the position where you released the click.

Hi,

Is there a stateChaged (and/or perspectiveChanged) signal? The use case is that either if we keep track of perspectives internally (using the existing perspective API) or externally (saving and loading state externally), it would be neat to be able to track the changes in state for reasons:

• To implement undo/redo stack
• To put a star * in the current perstective to mark it as dirty, until the perspective state is saved again.

If there is something in the API I can use for that please let me know, or if you could give me some pointers on where in the source code I could start hacking to implement such signal, would be apreciated.

Thanks,

Since ${ads_INCLUDE} is a list, CMakeLists.txt:88-91 should be:

target_include_directories(qtadvanceddocking PUBLIC
    "$<BUILD_INTERFACE:${ads_INCLUDE}>"
    $<INSTALL_INTERFACE:include>
    )

as noted in this stack overflow answer

I need to be able to change the objectName of CDockWidget, and so the name they are "registered"with. The problem is that DockWidgetsMap inside CdockManager is private and I can not rename the entry without removing the CDockWidget (and losing its position) and re-adding it.

How can I properly create floating widget?

Hello,

This might be a stupid question, but how would you go about resizing a dock widget via code?

Thanks,

Joe

For my application I need the ability to create multiple copes of a type of dock and want the close button to actually delete them and have all signals and slots disposed of. I can destroy them manually but I don't know how to tell if a dock is being hidden due to that button press or if it's for another reason.

Hi. I've found in your code:

bool DockContainerWidgetPrivate::restoreDockArea(QXmlStreamReader& s,
	QWidget*& CreatedWidget, bool Testing)
{
	...
		s.skipCurrentElement();
		CDockWidget* DockWidget = DockManager->findDockWidget(ObjectName.toString());
		if (!DockWidget || Testing)
		{
			continue;
		}

That means, to restore CDockManager I have to add all CDockWidgets with right names first, but I can't determine which widgets should I add.

Is there any functionality to get all CDockWidgets names before call restoreState?

Have you found that the update of the windows is a bit of slow when I resize the window. And I can see the twinking on the edge of the window.

Is the skin style in the video in readme open source?If it is not open source, can you tell me how to change the color of icon in DockAreaTitleBar to white