Add getScrollbarWidth() or getScrollArea() for gcn::DropDown

[GoogleCodeExporter]

I was just using a gcn::DropDown and wanted to resize it so that the
non-expanded form of the widget was the width of the largest object in its
list model.  The only problem with this is that gcn::DropDown::setWidth()
will, as expected, set the width INCLUDING the drop down button - meaning
some of at least one item in the list model could be blocked.

The obvious solution would be to set the width to the largest item plus the
width of the scrollbar, but there is no such access method in
gcn::DropDown.  Might I recommend that such a function be added that would
simply pass the call to the appropriate scroll area, or otherwise to
provide access to the drop down's scroll area?  (I realize that I could
also use my own scroll area, but I think it's a bit excessive to keep track
of an entirely separate object for the sole purpose of setting it's width)

I could write the code for this, if people are interested...

Original issue reported on code.google.com by holy.smo...@gmail.com on 21 Dec 2009 at 6:37

[GoogleCodeExporter]

Not trying to diss the idea, but when the only constructor to the DropDown 
widget
requires that you supply your own ScrollArea, and the fact that the ScrollArea 
is
protected, and not private, why would either of these be needed? Just create a
wrapper class over the guichan DropDown widget and use that in your code.

Now, while that'll probably be the sort of response that'll kill this bug 
before it
ever gets anywhere, I'll be kind for a bit and explain why both of those 
solutions
are nondesireable.

First off, I'm fairly sure that getScrollArea() is not provided in the first 
place
because the idea is to try to protect the ScrollArea from modification once it 
is
assigned to the Widget by outside widgets to the DropDown class. If a get 
method was
provided, you're then opening up free modification to the pointer itself by 
other
classes which shouldn't be able to modify it, and you can then cause all sorts 
of fun
exceptions to the DropDown class itself, which the DropDown shouldn't need to 
care
about or be trying to correct. Once the ScrollArea is set, the DropDown should 
then
be able to count on it staying constant, which, again, should help explain why 
there
are no getters and setters. Now, you could argue that returning a const pointer 
to
the ScrollArea wouldn't allow it to be modified, but that's worthless, since you
can't dereference a constant pointer without throwing up a compile error. So, 
this
first idea is definitely dead as it stands.

Now, as for a getScrollbarWidth(), that's spurious at best, IMO, since the 
scrollbar
itself is part of the ScrollArea, and not the DropDown, and should be kept as 
such.
Adding in a getScrollbarWidth() would seem rather out of place when the DropDown
itself doesn't manage the ScrollArea directly. This, in essence, would be like 
asking
for various other Widget methods in the ScrollArea class that have nothing to 
do with
the ScrollArea widget itself, but make the ScrollArea "more convenient" in your 
view.
The problem here is that we're not dealing with a method which is virtual, so 
there's
no guarantees that once you do access it, that you're going to access the 
method that
you want. That's poor OO programming, but it can still be done. That aside,
getScrollbarWidth() itself would be poor encapsulation, since the DropDown 
widget
doesn't directly own any methods that determine that, but the ScrollArea does 
instead.

So, in summary, the solution you probably should be seeking here is to create a
wrapper around the DropDown for your particular use case. That is the obvious
solution, IMO, and what you claimed isn't so much (since this is not a case 
where
GUIChan the library is failing. Just you're vested in the wrong type of 
solution to
this problem). It'll be just as much code for you to make your own 
ResizingDropDown
than it would be to muddy up the GUIChan widget with either a method that would
destroy the proper encapsulation of the ScrollArea class, or by adding a method 
to
the DropDown that belongs to another Widget, and have the DropDown class return
something it shouldn't know itself. Now, since you want to make a new method in 
the
first place to automatically resize your DropDown in the first place, it looks 
to me
like you're just looking to inherit off of the DropDown class, implement your 
method
for resizing using the mScrollArea variable directly to obtain your scrollbar 
width
in your automatic resizing function. Problem solved.

And, in conclusion, I don't speak for GUIChan itself, but am fairly sure that 
this is
the sort of response that you'll get from either Bjorn or Olof as well, but I 
just
happened to give you a more detailed reason as to why this issue will get 
closed and
how to resolve it than either of them might have given you. If you want to save 
this
issue at all, I think you'll need to provide a much better reason as to why 
what I
said won't work for you, but from what I can see, I don't see much hope in that 
at
all. Now, if you didn't know that you could already access the ScrollArea 
before you
submitted this issue because it's protected and not private, then hopefully 
this post
will have alerted you to that and will have benefitted you. If you already knew 
that,
then, well, I'm fairly sure I just killed your issue, but either of them would 
have
noticed this right off as well, so it never really had much chance to begin 
with.

Good luck with your code.

Original comment by irar...@gmail.com on 21 Dec 2009 at 9:20

[GoogleCodeExporter]

Ira, please don't speculate over what my response would have been. I don't have 
time 
to look into these questions (or well, especially not your response since you 
are 
being way too verbose...) so I can't even check whether your speculations are 
accurate.

Original comment by b.lindeijer on 21 Dec 2009 at 11:49

[GoogleCodeExporter]

Thanks for the reply!  Your thoughts were very helpful for me.  I will try to be
brief in my own, though.

Excellent point on the getScrollArea() idea.  My real thought in this was in 
regards
to the other method idea, but the thought had passed my mind - given with little
speculation - and I figured I should at least throw it out.

As for the getScrllbarWidth(), I certainly could build a wrapper class just as I
could keep a scroll area as a member of another class, but I still feel it 
makes more
sense for drop down to include such a method because I think it is something of 
which
drop down should be aware.  Think of it, have you ever seen a drop down menu 
anywhere
where the scroll bar (or the button to open the menu item) covers it's options? 
 I
feel that this object should either allow a user to know this width to properly 
size
the object, or draw the button and scroll bar outside of the displaying area 
(ie: in
draw() draw the button/scrollbar outside of the widget's clip area, much like a
widget's frame)  However, even if the scroll area draws the button/scrollbar 
outside
of it's clipping area, I could still argue that the width method would be 
needed so
that it could be properly positioned (and so the widget is not placed outside 
of its
parent container.  Thus I suggested only the getScrollbarWidth() idea.

Additionally, adding such a method wouldn't, IMO, break encapsulation because 
the
method shouldn't allow direct access to drop down's (or scroll area's) members. 
 In
fact, it would HAVE to be defined as a constant method in drop down, because it 
is
already a constant method in scroll area.

All that being said, I really appreciate your reply.  I'm kinda teaching myself 
how
to program as I go along, so this kind of dialog is very helpful for me!

Original comment by holy.smo...@gmail.com on 21 Dec 2009 at 1:56