In our application, we have a variable number of dockwidgets because some of them are added by plugins that are loaded at runtime. Not all dockwidgets need to be visible at the same time necessarily. This depends strongly on what the user is working on and what plugins are active.
However, if too many dockwidgets are added programmatically with addDockWidget(...), they start to overlap each other (not in terms of tabs, but in terms of content of one being painted on the area of a different one, which obviously looks broken).
The user can move the dockwidgets to dockareas that still have space left, but the layout/main window successfully prevents (untabbed) re-addition to the "crowded" dockarea.
We do allow tabbed docks to allow the user to arrange the dockwidgets a required, but we don't want to enable QMainWindow::ForceTabbedDocks since this would constrain the number of simultaneously visible dockwidgets too much (one per dock area).
How can I prevent this or better control how dockwidgets are added?
Not answering your question directly but it might be worthwhile to actually forget about Qt and actually think of how the whole interaction should work. What are the user expectations? What should actually happen if 10 different plugins become active? Should they be docked or should they be floating or should they become pin-able docking windows with initial state as a small button on the MainWindow edges? I think once you do that ground work and come up with user interface mock-ups, you can then start looking at Qt and figure out if Qt provides a direct way to develop that interface and if not what additional components you will need to develop to get that interface working.
From my own experience, I had developed a similar interface long back but in MFC. The way we did it was that some of the docked windows were deemed to be must have and they would come up as docked. Then there were a set of windows that didnt need to be visible always but should be quickly available and their initial state was as hidden pin-able dock window which meant they came up as buttons on the MainWindow edge. Finally there was a third set that was not required by the user always and could be called in from File->View Menu. Once the user made it visible, the user typically would assign it to one of the first two groups or keep it afloat. This whole configuration was saved in a config file and from there onwards whenever the plugin was loaded/became active the last used state of the associated docking window was used. It though involved quite a bit of extra work but the end result was to the satisfaction of all users.
Have you tryed setDockOptions(QMainWindow::AllowNestedDocks)? I can't test it now but it may help.
By default, QMainWindow::dockOptions is set to AnimatedDocks | AllowTabbedDocks so you would want something like
setDockOptions(QMainWindow::AllowNestedDocks | QMainWindow::AnimatedDocks | QMainWindow::AllowTabbedDocks)
EDIT:
If you are having too many problems, you may be going about this the wrong way. Instead of using docks, you may want to try using QMdiArea with QMdiWindow. This may not work for your program, but its something to think about.
This is the solution I tried:
I created in QTCreator an empty project with a window, a minimalistic menu labelled "New Dock" and a DockWidget named dockWidget
This is the triggered() handler for my menu item:
void MainWindow::on_actionNew_Dock_triggered()
{
QDockWidget* w = new QDockWidget("Demo", ui->dockWidget);
this->addDockWidget(Qt::LeftDockWidgetArea,w);
this->tabifyDockWidget(ui->dockWidget,w);
}
tabifyDockWidget(QDockWidget* first, QDockWidget* second) is a QMainWindow method that stacks the second dockwidget upon the first one. Hope it helps...
Related
I need to make multiple enable/disable changes to a main menu in a C++ Builder VCL application.
When the application changes state, I loop through disabling and enabling visibility of multiple menus.
This issue I have is that when looping occasionally during the loop there are more menus visible than what will fit on the screen, causing a wrap, which then causes everything on the main form to resize, and resize back resulting in slowness and a huge flicker.
I have tried the Disable and Enable align on the main form, doesn't have any impact.
I have done the WM_SETREDRAW trick on the main form, however while it stops it drawing, calling invalidate afterwards, doesn't get some of the children controls to redraw correctly. An example of what won't redraw is the tabs on a TPageControl.
An other point that may be of relevance, is that code is called from a TTabSheet::OnShow callback.
Ideally I would like to find a BeginUpdateMainMenu and EndUpdateMainMenu method, however I can't find on in the VCL documentation or the Win32 documentation.
Any help is much appreciated. Thanks.
This is not a technical answer but I'm thinking from an end user "useablilty" point of view : how easy would it be for him/her to use "more menus visible than what will fit on the screen"
Do you have the possibility to group the menu items in some way so that they could be dysplayed in sub-menus ?
I'm rather new to C++, I have a bit of experience with MCV programming in Java. im using GTKmm on C++
What I'm trying to do is writing an application for teaching assistants to submit and edit applications to various positions, and administrators to come in view, and accept these applications.
What I'm trying to do at the begging is create 3 'frames' (I'm working on the submitting application for students only at the moment)
This first will have 2 buttons 1 for selecting if you're a student/admin
Upon clicking you're a student I want to hide this frame and show my second frame
The second frame will have another 2 buttons one for creating an application, and the other for editing applications
My core problem is that I don't understand how to switch between the frames, I've written all the code for my Model, and understand everything I want it to do however I cant seem to find how to do this...
My only idea would be to create windows for each of these, make them look all nice w/e, then when a button is pressed have that window close and a string written to file I can access to see which button has been pressed, then open a new window accordingly. Should I do it like this or is there a better way?
I think I can suggest a better/more idiomatic option for any version >= GTK+ 3.10 - which, to be fair, arrived about half a year after the accepted answer.
If you want to switch between widgets one-at-a-time without any accessories like tabs, then a Gtk::Stack seems like a better option. Because it's specifically geared for one-at-a-time presentation, without any redundancy and (theoretical) overhead from a Notebook's manual tabbing features, which you'd just be disabling straight away! It's a container with multiple children, with one visible at any given moment, and of course methods to change the active child.
You can hook up your own widgets and/or events to manage which of the Stack's children is shown. Alternatively - albeit possibly just restoring the redundancy in this case - there's a StackSwitcher companion widget, which is pretty much a vertical tab-bar as seen in the GTK+ demo and GNOME Tweak Tool.
Easiest way is to use a Notebook widget. You can hide the tabs since you will be controlling which page is showing, using method set_show_tabs(false). Put the top level widget for each of your frames in a pane using method append_page(), and switch between them using set_current_page(). You might want to hide the notebook's bevel if it's distracting, using method set_show_bevel(false).
Use signals to make a widget (e.g. "I'm a student" button) on one page do something (e.g. go to the second page). If you don't know what this means or how to do it, go through the gtkmm tutorial, it will explain this and more.
A bit too late ! But here is my try :
Gtk::Notebook is great but it is not ideal in switching between app frames on menu item clicks. Gtk::Stack, since gtkmm 3.10, exists to mitigate this. Assuming you're using glade and Gtk::Builder :
class
class AppName : public Gtk::ApplicationWindow
{
public:
//...Your app methods and callbacks
void on_mb_itemname_selected(); // The call back for our menu item click/select
private:
//Builder which will help build the app from a .glade file
Glib::RefPtr<Gtk::Builder> _builder;
//...
//Your menu item to activate a particular frame
Gtk::MenuItem * _mb_itemname;
//Your handle to Gtk::Stack which is usually the stack for the whole app
Gtk::Stack * _app_stack;
//...
}
constructor
AppName::AppName(BaseObjectType *cobj,
Glib::RefPtr<Gtk::Builder>& ref_builder)
:Gtk::ApplicationWindow(cobj),_builder(ref_builder)
{
//.. Other setup
_builder->get_widget("your_glade_id_to_stack",_app_stack);
_builder->get_widget("your_glade_id_to_menu_item",_mb_itemname);
// Connect signal_select of our menu item to appropriate signal handler.
mb_itemname->signal_select().connect(
sigc::mem_fun(*this,&AppName::on_mb_itemname_selected));
}
our callback
void AppName::on_mb_itemname_selected()
{
// Change the visible child of the stack concerned.
Gtk::StackTransitionType ttype = STACK_TRANSITION_TYPE_NONE;
_app_stack->set_visible_child("your_widget_name",ttype);
// Note that widget name is not widget glade id.
// You can set your widget under name Packing -> Name
return;
}
There are a lot of articles related to customizing main menu of the dialog window on, including "custom-drawn" menus. But none of them seem to answer my question.
I have a (borderless) window that has a custom-drawn by hand title bar:
I need to display somehow a main menu under this "fat" title bar. How could I do this, using MFC? By default "native" menus seem to be able to be located only in the top of the client area of the dialog window (or am I wrong here?). Is there any solution for my problem?
If someone could give some links related to my issue, I'd greatly appreciate this! I've seen a lot of products that implement this, for example Ontrack comes on mind, but never met any explanation on how this was achieved.
Thank you!
I need to display somehow a main menu under this "fat" title bar.
That's precisely where it is being drawn, according to the image you posted.
By default "native" menus seem to be able to be located only in the top of the client area of the dialog window (or am I wrong here?).
No, that's correct. The menu will be automatically drawn where menu bars belong: at the top of the window, just below the title bar.
You've decided to mess up the defaults and throw usability of your application to hell by reimplementing the non-client area. That means you can't rely on Windows to draw these elements for you. Instead, you'll need to take responsibility for drawing all of these things yourself, which requires you to write code to do so. I don't know what "Ontrack" is, but any application that does this is owner-drawing its menus.
Another popular option (used by Internet Explorer for a while) is to create your own menu-like object using a rebar control. This has the advantage of integrating into an existing toolbar control and allowing the user to rearrange items as desired. It, like writing your own menu control, has the disadvantage of not conforming to standard platform conventions and user expectations (although it's probably a lot better than whatever you can come up with yourself). There's a how-to article here on MSDN.
I suspect that in undertaking this project you've probably bitten off more than you can chew. Keep in mind that there's hardly ever (if even that) a reason to draw your own title bar. As you're seeing, conforming to your platform's standard expectations is often easier on the programmer and far better received by your users.
I am trying to create a tab-control that have the tab-buttons aligned from right-to-left, in Win32/c++. The WS_EX_LAYOUTRTL flag doesn't help me, as it mirrors the drawing completely both for the tab items and the tab page contents. The application itself handles the mirroring automatically (it's a cross platform UI solution), which is also a reason for us not to use WS_EX_LAYOUTRTL flag (we have mirroring implemented in a generic way for all UI frameworks/platforms).
One solution would be to override TCM_GETITEMRECT and TCM_HITTEST in the subclassed TabCtrls window procedure. This enables me to move the buttons allright, but the mouse events still acts on the positions that the control "knows" the buttons really are at (ie. mouseover on the first button invalidates the leftmost button - the coordinates are not mirrored).
So that seems to be a dead end for me.
Another possibility would be to insert padding before the first tab button, to push them all to the right edge. I haven't been able to figure out how to do that, though. Visual Studio sports this little dialog:
How did they put the buttons in front of the first tab page? Knowing this would enable me to solve this problem.
Update, solution:
The solution to my problem is to use the built-in RTL support. For this to work, the tab control must have both the WS_EX_LAYOUTRTL and WS_EX_NOINHERITLAYOUT flags. That will preserve the function of all existing drawing code while only the TabCtrl buttons are mirrored. I didn't realize that the ES_EX_NOINHERITLAYOUT flag goes on the parent (the TabCtrl), which is why I was looking for the workaround originally described.
For reference, I am still curious to have an answer to the original question, though.
If you take a look with a spy application you will see that it is not actually a normal windows tab-control but custom thing and the drawing is done by the parent window AFAIK:
Both Visual Studio and Office use a lot of custom controls, some of the features make their way into the common controls after a few years, some features stay private...
I am currently writing a wizard-style application using Qt4. I am not using the wizard class however, since going next/back does not make sense from every step in the process.
The user starts off at a "hub"-window with five buttons, each of which take him to another window at a different stage of the process. At the beginning all but the first button of the hub are disabled. After clearing each stage, the user will be directed back to the hub and one new button/stage will get enabled.
Since every stage has significantly differing objectives, I coded every single stage as a single QWidget that gets instantiated in the main() function. To switch between the widgets, I simply hide() the one I am leaving and show() the one I am going to.
However, this leads to problems if the user resized or moved one widget, since the next widget will always show up at its default position instead of the new one.
Is there a way to synchronize the widgets' sizes and positions?
Or, better yet, is there a more elegant way to deal with those different windows than switching between several hidden widgets?
Thank you in advance!
Create one top-level widget that holds the others.
I suggest that you either use QStackedWidget, or, if you want more control, create your own widget and use QStackedLayout directly.
Why not just have one main QWidget as a container for your pages? That way if the user moves the main QWidget and then goes to the next page, it will still open in the new position inside the main widget.
Generally, I've never had occasion to create multiple widgets inside my main method. Don't quite see the point.
I'm beginning on something similar - with different views (perspectives) for different tasks along the way. Using toolbar icons and file menu, not buttons, to move between views. Similar to how MS Outlook allows you to have the window display email, or a calendar, or contacts, etc.
My intent (haven't started yet) is to have one QMainWindow as the application window, containing my various QWidgets that offer the various views. Depending on what task the user is doing, one composite widget will be visible, and the others hidden.