|
|
|
Home » Developing U++ » UppHub » Docking: BUG + FEATURE: Disable Close completely
|
|
|
|
|
|
|
|
| Re: Docking: BUG + FEATURE: Disable Close completely [message #25587 is a reply to message #25586] |
Tue, 02 March 2010 15:04   |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
another issue:
when a Docking has got no buttons visible, the Title if the selected Docking also disappears, i could not figure out why
because
DockCont.cpp:196
if (!s.title_font.IsNull()) {
Ctrl *c = GetLastChild();
while (c && !c->IsShown() && c->GetParent())
c = c->GetNext();
if (s.handle_vert)
r.top = c ? c->GetRect().bottom + m.top : m.top;
else
r.right = c ? c->GetRect().left + m.right : m.right;
w.Clip(r);
WString text = IsNull(dc->GetGroup()) ? dc->GetTitle() : (WString)Format("%s (%s)", dc->GetTitle(), dc->GetGroup());
w.DrawText(p.x, p.y, s.handle_vert ? 900 : 0, text, s.title_font, s.title_ink[focus]);
w.End();
}
seems to be reached and calls stuff to draw..
|
|
|
|
| Re: Docking: BUG + FEATURE: Disable Close completely [message #25608 is a reply to message #25587] |
Wed, 03 March 2010 18:29 |
mrjt
Messages: 705
Registered: March 2007
Location: London
|
Contributor |
|
|
Hi! I'm glad you're using the code.
The fix for the missing title text is:
if (!s.title_font.IsNull()) {
Ctrl *c = GetLastChild();
while (c && !c->IsShown() && c->GetParent())
c = c->GetPrev();
if (s.handle_vert)
r.top = c ? c->GetRect().bottom - m.top : r.top - m.top;
else
r.right = c ? c->GetRect().left - m.right : r.right - m.right;
w.Clip(r);
WString text = IsNull(dc->GetGroup()) ? dc->GetTitle() : (WString)Format("%s (%s)", dc->GetTitle(), dc->GetGroup());
w.DrawText(p.x, p.y, s.handle_vert ? 900 : 0, text, s.title_font, s.title_ink[focus]);
w.End();
}
Thanks for your other bug reports:
Animate config - This check box was added before the feature was split and I obviously forgot to change it. I'll add a second checkbox to the config form to independently control them.
Config dialog tree - I'll have to look at this, it used to work but as Koldo has said there seem to have been some changes to TreeCtrl.
Closing buttons and stuff - This is pretty complicated, the correct solution involves removng the X button from floating windows and all of the Close, Close Group and Close All options from the menus.
I haven't looked at the code for a while and as you can see it's pretty complicated  , but I'll try and get all the fixes incorporated by the end of the week.
There is also an outstanding bug with certain window manager settings on Linux, but I have yet to find a solution to that one.
[Updated on: Wed, 03 March 2010 18:29] Report message to a moderator |
|
|
|
|
|
| Re: Docking: BUG + FEATURE: Disable Close completely [message #25628 is a reply to message #25615] |
Thu, 04 March 2010 15:37 |
mrjt
Messages: 705
Registered: March 2007
Location: London
|
Contributor |
|
|
Ah, good find.
To fix the title not updating you need to change DockableCtrl.h:
DockableCtrl& Title(const char *_title) { title = _title; if (GetParent()) GetParent()->RefreshFrame(); return *this; }
DockableCtrl& Title(const WString& _title) { title = _title; if (GetParent()) GetParent()->RefreshFrame(); return *this; }
And this change in DockCont.h makes it keep the new title when it's detached/floated:
void StateFloating(DockWindow& dock) { State(dock, STATE_FLOATING); Title(GetTitle());
The issue with just blocking the Close action as you have is that surely the option is still visible in all the menus? It's just that when the user slects it nothing happens?
It should be possible to remove the close box in Upp now, the option seems to have appearred in the code as NoCloseBox. This change in DockCont.cpp makes it disappear:
void DockCont::WindowButtons(bool menu, bool hide, bool _close)
{
AddRemoveButton(windowpos, menu);
AddRemoveButton(autohide, hide);
AddRemoveButton(close, _close);
NoCloseBox(!_close);
SyncButtons();
}
No idea whether this works on Linux yet. I'll put these changes into the SVN when I've had time to integrate everything.
[Updated on: Thu, 04 March 2010 15:38] Report message to a moderator |
|
|
|
| Re: Docking: BUG + FEATURE: Disable Close completely [message #25630 is a reply to message #25628] |
Thu, 04 March 2010 20:02 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
thanks a lot, the fixes work pretty well, the only thing is, that via config disabled NoClose...doesnt get applied untill a doubleclick to the title bar..but ots ok
| Quote: |
The issue with just blocking the Close action as you have is that surely the option is still visible in all the menus? It's just that when the user slects it nothing happens?
|
no, the options do even disappear, so the user doesnt get any opportunity to close it, while the code api still can close it.
here is the current stuff, applied all your changes and mine, take a look on it, decide what you want to keep, maybe that saved you time, its a ready readonly svn folder to have a diff...
-
Attachment: Docking.rar
(Size: 127.80KB, Downloaded 232 times)
|
|
|
|
| another thing [message #25636 is a reply to message #25630] |
Fri, 05 March 2010 09:34 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hhi mrjt,
another beauty issue is the following. if one locks the Dock stuff, the DockCont's title bar of tabbed docks disappears. but i would be good to still have them there, they provide a good to read title, though the tabbars normally have the same info. but the user is used to have title on top..
is there a possib to do this selectable?
i think i found the place where to dig:
to unconditionally disable the setting of the nullframe
one needs to comment !lock &&
DockCont.cpp:833
void DockCont::SyncFrames(bool lock)
{
bool frames = /*!lock && */(IsDocked() || IsAutoHide());
handle.Show(frames);
if (frames)
SetFrame(0, Single<DockCont::DockContFrame>());
else
SetFrame(0, NullFrame());
}
i would be great to have something like an additional flag
(!lock || base->PermamentTitleBar()) && ...
[Updated on: Fri, 05 March 2010 09:49] Report message to a moderator |
|
|
|
|
|
| Re: another thing [message #26185 is a reply to message #25721] |
Fri, 09 April 2010 09:47 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hey mrjt, i didnt quite understand what the ShowLockedHandles is for and how it works. could you describe a use case?
fot the sake of locking some tabs to prevent detaching in tabify view, while others still beeing able to detach i made the following stuff (see attach)
if a DockableCtrl has no allowed dockable[] than detaching is neither permited. the case seems to be logical, but a decent lock button (pin or something) should be available to fix *one* participant only, to prevent its accidental moving or changing in position/size. what is your oppinion?
another thing is: what about having a 5th mode of docking? something like DOCK_FULL, which lets the participants be docked/tabified in fullscreen, not only left/right and top bottom. due to SizePosHint(), the appearance in current setups can look messy (i.e. docking stuff at top to a docking which is setup inside a splitter, so the splitter)
-
Attachment: Docking.rar
(Size: 146.22KB, Downloaded 200 times)
|
|
|
|
| Re: another thing [message #26189 is a reply to message #26185] |
Fri, 09 April 2010 15:00 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hi mrjt
DockWindow.cpp:331
if (DockCont *c = TabifyGroup(group)) {
if (c->IsDockAllowed(align))
DockContainer(align, *c, pos);
else
FloatContainer(*c);
}
should be
if (DockCont *c = TabifyGroup(group)) {
DockContainer(align, *c, pos);
}
because, as far as i understand, most actions through code API should be available even if user has selected stuff to bi unavailable (but if the code sais so, it has precedence
i.e. you want to dock in code a window that has been disabled by user a docking ability, but the user pressed "default arrangement" or something, where you need to make tabbing docking (which has been disabled by user)
does that make sense?
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Title() Bug [message #26626 is a reply to message #26514] |
Mon, 17 May 2010 13:35 |
mrjt
Messages: 705
Registered: March 2007
Location: London
|
Contributor |
|
|
I've fixed the title issues in SVN revision 2403. Floating windows now also update their titles, I'm not sure why I didn't do this properly last time 
WhenState is executed every time a DockableCtrl changes state (eg from docked to floating, or is close, or is opened). There was a case where it wasn't working (when dragging into tabs), but I've fixed that now. It does correctly call all child tabs when a DockCont changes state.
The idea of the Docking package was to implement docking in a completely Upp style way. So everything would be owned by something (no passing around naked heap pointers), the interface would be based around property methods and it would be relatively simple for the programmer to use. The most difficult bit was that it would sit as an external package to CtrlLib, so there are no alterations or special cases in CtrlLib to accomodate it.
The programmer uses the light-weight DockableCtrl class to wrap the essential requirements for docking around whatever GUI componenets he wants. This can be done by inheritance or by using is as a ParentCtrl with a layout and the class is really just a data container (for size & state data etc) and has almost no control over the docking process. A reference is then passed to the DockWindow and then everything more-or-less takes care of itself.
DockCont is the interesting class. This is a container for one or more DockableCtrl classes and is strictly internal to the Docking system. Unlike DockableCtrl it is non-persistent and they are created/destroyed as required by user actions. For instance: When a DockCont is dragged into another DockCont the tabs from the first are added to the second and then it is destroyed. When a DockableCtrl is dragged out of a DockCont a new one is created to hold it.
What makes this more complicated is that a DockCont can also be 'nested' as a tab in another DockCont. To facilitate this all controls that are owned by a DockCont are actually cast to Values and stored directly in the TabBar derived DockTabBar (all the DockCast and ContCast calls in DockCont.cpp are casting back from these Values). The DockTabBar class knows about these two classes and can draw them into tabs with the correct title and icon.
DockCont really is the 'nastiness' that I have tried to hide from the programmer-fronting interface. There are a lot of complications here such as the fake title bar when docked, managing all the possible user interactions and avoiding infinite recursions (you would not believe how many of these I got during development!).
DockWindow handles all of the wide scope docking control. It's responsible for creating and destroying the DockConts, storing all the global settings and coordinating drag-drops when signalled by the related DockCont. There is a lot of stuff in there to cater for as many user requirements as possible.
There are some other helpful classes: DockMenu is my attempt to make all of the Docking context menus as customizable as possible without complex inheritance, DockConfig is the config window (mainly intended as an example) and DockPane is a modified SplitterFrame that (tries) to do intelligent repositioning based the size hints from DockableCtrls.
TabBar is an external class that can be used completely independently of Docking. This grew out of TheIde QuickTabs package by unodgs as my requirements grew more complex. The TabBar ctrl is pretty awesome IMO
I hope that's explained some of it (though probably not very well). I'll happily answer any more specifi questions you have. It's a very complex package and I'm quite poroud of it for that reason.
[Updated on: Mon, 17 May 2010 13:36] Report message to a moderator |
|
|
|
| Re: Title() Bug [message #26642 is a reply to message #26626] |
Mon, 17 May 2010 21:59 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
many thanks for the details..i think with this bit of background infos it'll be easier to dig through code when necessary. ofcorse you can be proud of it. the Docking stuff is pretty helpful to a lot of people including me.
one thing remains though. the SizeHint problem. i try to explain you my usecase. maybe i use it in the wrong way.
* i use a vertical Splitter to have a resizeable frame area for overview and controling, residing on the left.
* the right part Splitter'ed again, but horizontally, giving a top view and a bottom view for some components. there can be a variety of them (device views at top and group views of devices at bottom)/
* to be able to detach some views from main window, i use 2 DockWindow's as members of my application class. they are Add()ed inside the splitter at top and bottom. (this was kind of a hassle, because DockWindow is a TopWindow derive, and placing it inside another TopWindow is maybe no good idea, DockInit() stuff was done in a separate init function, which somehow works).
* the contents of the views are added as DockableCtrl's ofcorse, with DockTop *only* and i need to give them a SizeHint.
* PROBLEM: the 2 DockWindows share the right part of application area, and are devided by splitter, but the views dont always use the full available size of their parent DockWindow up to bottom. result is kind of a messy application view altogether. because when resizeing main window, the splitters grow or shirnk and the SizeHint never matches the actual available space (from top to bottom, since there isnt anything else then top)
thats why the idea was born to have kind of a 5th mode (center, with full area usage like SizePos(), or at least to have the Docking calculate the actual possible usable Size, i.e. that a DockTop'ed control could use all the available space to the bottom or to the beginning of the DockBottom'ed controls.
any idea how to make this possible?
|
|
|
|
| Re: Title() Bug [message #26643 is a reply to message #26642] |
Mon, 17 May 2010 22:40 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
before i update and test your version i wanted to save my current state and to have you take a look on it maybe it's helpful for you..
i extanded the DockableCtrl.h:87 just a bit
to let the API inspect some varieties of docking permissions
bool IsDockAllowed(int a) const { ASSERT(a >= 0 && a < 4); return dockable[a]; }
bool IsDockAllowedLeft() const { return dockable[0]; }
bool IsDockAllowedTop() const { return dockable[1]; }
bool IsDockAllowedRight() const { return dockable[2]; }
bool IsDockAllowedBottom() const { return dockable[3]; }
bool IsDockAllowedAny() const { for(int i = 0; i<4; i++) { if(dockable[i]) return true; } return false; }
bool IsDockAllowedNone() const { for(int i = 0; i<4; i++) { if(dockable[i]) return false; } return true; }
DockConfig.cpp:221
to have animation settings extend on the other available params as well, but this is only a quickfix, maybe later it should be possible to disable each animation extra? (in current state only the first highlight animation is changeable via UI, the others remain unchanged (and maybe enabled), while the user expects all animation to be disabled, isnt it?
dock.Animate(~animate, dock.IsAnimatedFrames(), ~animate);
DockWindow.cpp:329
the API should have precedence over UI setups.
means if I (in application code) decide to group a component to some kind, it should do it in the desired way, even if DockableCtrl's respective capabilities have been disabled in GUI.
i ended up having DockableCtrl's thrown out floating, when restoring a default view (if desired setup was disabled by user in GUI), so TabDockGroup shouldnt throw out things floating, it should group
void DockWindow::TabDockGroup(int align, String group, int pos)
{
if (DockCont *c = TabifyGroup(group)) {
// if (c->IsDockAllowed(align))
DockContainer(align, *c, pos);
// else
// FloatContainer(*c);
}
}
DockCont.cpp:362
another floating issue, in void DockCont::TabDragged(int ix)
if a dockable is docked somewhere and is not able to regain its position later when dragged again (because docking capability is completely disabled, it should be able to float the dockable when dragging it out of a tab (it wont be able to go back there). while manual floating command is still possible. (but in tabbed cases its a weired behaviour)
if(c->IsDockAllowedNone()) return;
so far the little things. code lines are respect to prior to your change. maybe something of it is depricated now, maybe something is still usable..
cheers
kostah
PS attached is Docking sources including .svn to diff easy
-
Attachment: Docking.rar
(Size: 140.19KB, Downloaded 172 times)
[Updated on: Mon, 17 May 2010 23:01] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Tue Apr 16 07:37:01 CEST 2024
Total time taken to generate the page: 0.04160 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
