Home » Developing U++ » UppHub » TabBar: ordering of tabs by their Value (title)
|
|
| Re: TabBar: ordering of tabs by their Value (title) [message #27088 is a reply to message #27040] |
Fri, 25 June 2010 11:50   |
mrjt
Messages: 705
Registered: March 2007
Location: London
|
Contributor |
|
|
I have incorporated you changes, though I have changed the implementation and interface. that's partly because I'd implemented the sorting so badly to begin with I thought a rewrite was needed.
These functions are now available:
TabBar& SortTabs(bool b = true);
TabBar& SortTabsOnce();
TabBar& SortTabsOnce(TabSort &sort);
TabBar& SortTabs(TabSort &sort);
TabBar& SortTabValues(ValueOrder &sort);
TabBar& SortTabValuesOnce(ValueOrder &sort);
TabBar& SortTabKeys(ValueOrder &sort);
TabBar& SortTabKeysOnce(ValueOrder &sort);
TabBar& SortGroups(bool b = true);
TabBar& SortGroups(TabSort &sort);
TabBar& SortStacks(bool b = true);
TabBar& SortStacks(TabSort &sort);
TabBar& SortStacks(ValueOrder &sort);
bool IsValueSort() const { return tabsort; }
bool IsGroupSort() const { return groupsort; }
bool IsStackSort() const { return stacksort; }
I also finally got around to adding the ability to change the goup separators, so this function is now added:
TabBar &SetGroupSeparators(Value horz, Value vert);
I have also removed TabBarCtrl (I assume it was you that committed it?). I'm open to adding something like it to the package but that version lacked polish and did not match the coding style (it used camelCase among other things).
Thanks for your additions, I'll look at the Docking submission when I get time.
[Updated on: Fri, 25 June 2010 11:51] Report message to a moderator |
|
|
|
|
|
|
|
| Re: TabBar: ordering of tabs by their Value (title) [message #27096 is a reply to message #27095] |
Fri, 25 June 2010 12:54 |
mrjt
Messages: 705
Registered: March 2007
Location: London
|
Contributor |
|
|
There is nothing to stop you using it in your own app or even adding it as a seperate package to the bazaar, it's doesn't need to be included in the TabBar package.
Part of the problem is that the TabBar isn't well suited to encapsulation like that. To make a general purpose ctrl (as it would have to be to be added to the package) you have to either duplicate a lot of the interface or expose the TabBar object, which also exposes the Callbacks that the host ctrl needs to use to function.
It's something that's very easy to do for a single solution for your own app, but difficult to create a 'proper' general purpose ctrl with correct encapsulation.
I'll think about it though, maybe some small changes to TabBar could make it work better.
[Updated on: Fri, 25 June 2010 12:55] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: TabBar: ordering of tabs by their Value (title) [message #27110 is a reply to message #27107] |
Fri, 25 June 2010 17:57 |
mrjt
Messages: 705
Registered: March 2007
Location: London
|
Contributor |
|
|
Right.
I've modified TabBar so that it can now be used like a Ctrl (outside of a frame) and restricts it's drawing to the correct size. Suprisingly few changes were necessary and a nice side effect has been a slight rendering improvement when the scrollbar is hidden 
This means that you can now inherit from it directly to make a TabBarCtrl without the use of any Callbacks and the whole interface exposed.
I have attached a package that contains my implementation of TabBarCtrl a much more comprehensive TabCtrlBarTest. I'm not going to commit it just yet as it needs more testing and I haven't tried it with Docking.
EDIT: See further down-thread for latest version
[Updated on: Mon, 28 June 2010 16:49] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: TabBar: ordering of tabs by their Value (title) [message #27148 is a reply to message #27142] |
Mon, 28 June 2010 16:49 |
mrjt
Messages: 705
Registered: March 2007
Location: London
|
Contributor |
|
|
Well, it was a little more complex than that but I've made the changes.
Fucntion is:
TabBar::SetScrollThickness()
which sets the thickness of the blue bar in the scrollbar (the total thickness includes an extra 1 pixel on either side). The default value is 2.
I've also fixed a couple of ScrollBar related bugs in TabBarCtrl and updated TabBarCtrlTest to include option for changing thickness (under tab 3: "Layout3").
[Updated on: Mon, 28 June 2010 16:50] Report message to a moderator |
|
|
|
|
|
|
|
| Re: TabBar: ordering of tabs by their Value (title) [message #27174 is a reply to message #27149] |
Tue, 29 June 2010 17:53 |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
Hi Mirek
i have spent some time using / adapting your new design, the TabBarCtrl : public TabBar is a good thing
i have modified / extended some things slightly, and tried to adopt / extend the TabBarCtrlTest and the FileTabsExample.
the svn stuff is there, but basicly the current state (since your rar archive was not up in svn so diff shows all your changes as well. but you will spot the stuff i did easily.
bugfix in TabBar.cpp
TabBar& TabBar::SortStacks(bool b)
{
stacksort = b; << was staticly true
added (to my best knowledge)
TabBar& TabBar::SortGroupsOnce()
TabBar& TabBar::SortGroupsOnce(TabSort &sort)
TabBar& TabBar::SortStacksOnce()
TabBar& TabBar::SortStacksOnce(TabSort &sort)
this one was not implemented
TabBar& TabBar::SortStacks(ValueOrder &sort)
this one needs to go public, since its API functions are public as well
and thus this one has to be public as well.
struct Tab : Moveable<Tab> {
Docking:
made available the sorting functions from outside.
and some static function stuff, Value converts need not be dependant to intance, if they dont use anything from it...
why not having DockableCtrl::GetContainer() public?
there are 2 changes (first 2) in DockCont.spp from me, which i dont think are usable, so spare them out, they have to do with handling..
i hope this feedback helps
-
Attachment: bazaar.rar
(Size: 243.72KB, Downloaded 373 times)
|
|
|
|
|
|
|
|
| Re: TabBar: ordering of tabs by their Value (title) [message #27188 is a reply to message #27184] |
Tue, 29 June 2010 23:32 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i am still asking myself why the new TabBarCtrl is keeping only the current shown control as child in its pane...
thus no tree inspection is possible. why not having them all in there using Show/Hide, like in one of the early versions or was it in QuickTab, dont remember.
and having the ctrls themselves decide how they should be added (no SizePos by default)?
some hints
TabBarCtrl& TabBarCtrl::InsertCtrl(int ix, Ctrl &ctrl, Value key, Value value, Image icon, String group, bool make_active)
{
ctrls.Add(key, &ctrl);
ctrl.Hide();
pane.Add(ctrl);
TabBar::InsertKey(ix, key, value, icon, group, make_active);
return *this;
}
void TabBarCtrl::SetCtrl(int ix)
{
ASSERT(ix < GetCount());
Value key = TabBar::GetKey(ix);
int _ix = ctrls.Find(key);
if (_ix >= 0)
for(int i = 0; i < ctrls.GetCount(); i++)
{
Ctrl * pc = ctrls[i];
pc->Show(i == _ix);
}
}
a bugfix in RemoveCtrl(Value key)
// Close(key);
CloseKey(key); //should be this one, right
|
|
|
|
| Re: TabBar: ordering of tabs by their Value (title) [message #27198 is a reply to message #27188] |
Thu, 01 July 2010 14:43 |
mrjt
Messages: 705
Registered: March 2007
Location: London
|
Contributor |
|
|
Thanks again, I wrote TabBarCtrl pretty quickly so I knew it would need some improvement.
| kohait00 wrote on Tue, 29 June 2010 22:32 |
i am still asking myself why the new TabBarCtrl is keeping only the current shown control as child in its pane...
|
Changed so that all ctrls live in the pane. You're right, it's much more sensible
| Quote: |
and having the ctrls themselves decide how they should be added (no SizePos by default)?
|
I dsagree with this for 2 reasons:
- Always apply SizePos is how it works in TabCtrl
- Not doing it means that you have to remember to do it yourself, which is more prone to errors
If you want to use a layout you just need to use an additional ParentCtrl. Realistically it's not very common that you'd want to add ctrl without SizePos and not be using a Layout template anyway. I'll keep it like it is.
Mindtraveller:
I have added your icons. The cross icons are now part of TabBar::Style, with some helpful shortcut functions to swap them:
struct Style : public TabCtrl::Style
{
Image crosses[3];
Value group_separators[2];
Style & Write() const { return *static_cast<Style *>(&TabCtrl::Style::Write()); }
Style& DefaultCrosses();
Style& Variant1Crosses();
Style& DefaultGroupSeparators();
Style& GroupSeparators(Value horz, Value vert);
Style& NoGroupSeparators() { return GroupSeparators(Value(), Value()); }
};
It's a bit unorthodox but given TabBar's requirment for different styles for LEFT, RIGHT etc. I couldn't think of a better way. The only problem is that your icons are off-center, so they won't work properly with TabBars aligned to the side or bottom, but I haven't decided how to fix that yet.
This means you can this to change the global style for a TabBar to use your crosses with no separator line between groups:
TabBar::StyleDefault().Write().Variant1Crosses().NoGroupSeparators();
I've attached my latest version. TabBarCtrlTest has been modified to include style testing. I still haven't had time to properly test Docking but I'll get everything committed either tomorrow or early next week.
|
|
|
|
|
|
| Re: TabBar: ordering of tabs by their Value (title) [message #27215 is a reply to message #27110] |
Sat, 03 July 2010 23:00 |
mdelfede
Messages: 1310
Registered: September 2007
|
Ultimate Contributor |
|
|
| mrjt wrote on Fri, 25 June 2010 17:57 |
Right.
I've modified TabBar so that it can now be used like a Ctrl (outside of a frame) and restricts it's drawing to the correct size. Suprisingly few changes were necessary and a nice side effect has been a slight rendering improvement when the scrollbar is hidden
This means that you can now inherit from it directly to make a TabBarCtrl without the use of any Callbacks and the whole interface exposed.
I have attached a package that contains my implementation of TabBarCtrl a much more comprehensive TabCtrlBarTest. I'm not going to commit it just yet as it needs more testing and I haven't tried it with Docking.
EDIT: See further down-thread for latest version
|
Uhmmmm.... changes to TabBarCtrl interface from my previous one made my app not compatible with it anymore.... so I've got 2 choices... rethink my app interface to TabBarCtrl or regrab my previous one.
Still not sure if the effort of changing my app are worth. Which are the advantages of new TabBarCtrl from previous one ?
Max
Edit :
In detail, you removed following stuffs :
TabBarCtrl::Get()
TabBarCtrl::GetItem()
TabBarCtrl::Add(Ctrl&, String&)
And maybe some others.
Thinking a bit about it, I guess I'll take back my previous version.....
Max
[Updated on: Sat, 03 July 2010 23:04] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Docking: removed special sorter [message #27515 is a reply to message #27466] |
Wed, 21 July 2010 16:43 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hi mrjt,
your last commit reomved the special sorter in DockCont, it was nessessary to have, because the DockCont uses the Values as containers for the DockCtrl, not for the titles itself. thats why the weired converter
//DockCont.h
...
//and the sorting itself uses a ValueSorter inside
struct DockValueSort
: public TabBar::TabSort
{
virtual bool operator()(const TabBar::Tab &a, const TabBar::Tab &b) const
{
DockableCtrl* dca = DockCast(a.value);
DockableCtrl* dcb = DockCast(b.value);
if(dca && dcb)
return (*vo)(dca->GetTitle(), dcb->GetTitle());
else
return false;
}
const ValueOrder *vo;
};
DockValueSort tabsorter_inst;
...
void SortTabs(bool b);
void SortTabs(TabBar::TabSort &sort); //should be protected
void SortTabs(ValueOrder &sort);
void SortTabsOnce(ValueOrder &sort);
//DockCOnt.cpp
void DockCont::SortTabs(bool b)
{
tabbar.SortTabs(b);
}
void DockCont::SortTabs(TabBar::TabSort &sort)
{
tabbar.SortTabs(sort);
}
void DockCont::SortTabs(ValueOrder &sort)
{
tabsorter_inst.vo = &sort;
tabbar.SortTabs(tabsorter_inst);
}
void DockCont::SortTabsOnce(ValueOrder &sort)
{
DockValueSort q;
q.vo = &sort;
tabbar.SortTabsOnce(tabsorter_inst);
}
//ctor
tabsorter_inst.vo = &Single<StdValueOrder>();
//ive fixed it, see attachment, if ok please commit soon. my app relys on that
-
Attachment: Docking.rar
(Size: 8.80KB, Downloaded 355 times)
[Updated on: Wed, 21 July 2010 16:49] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: Docking: removed special sorter [message #27531 is a reply to message #27530] |
Thu, 22 July 2010 10:25 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i'll try both.
isn't IsShown kind of self initiated looking through a list? i thought more of beeing notified when user clicks a docked tab, to know which tab (and thus DockableCtrl it was) because i need to trigger showing some related info on a sidebar.
it's because DockCont::TabSelected does not invoke WhenState for the DockableCtrl to notify that it has been 'set visible'. but it may be that i misunderstand WhenState, beeing STATE 'docked, tabbed' etc. that's my current hack though, so maybe there is a better option
[Updated on: Thu, 22 July 2010 10:32] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Tue Apr 28 15:14:19 GMT+2 2026
Total time taken to generate the page: 0.01503 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
I knew there was something else I was supposed to but I couldn't remember what it was.
)
