As you pointed out, the child itself seldomly if at all needs to access the parent, as long as the parent does all the work and keeps track of its children. However, the classic getParent is most useful when you use the framework from outside.
Scenario
A simple operation that may cause problems is the following: given two concrete widgets that are somewhere in your overall widget tree and a use-case that requires you to swap these two, how does the swapping work?
Option 1: Tell the children
Tell your child widget to swap(withOtherChild). But swapping involves updating the parent's children datastructure in some way. As your child does not know its parent, how do you achieve this?
Option 2: Tell the parents
Tell the parent of a child to remove it and add the other one. Oh wait, same problem. You only have the children objects and there's no getParent on those.
Option 3: Grunt work
As a final option, you can traverse your whole widget tree in order to find a parent with hasChild(x) and one with hasChild(y) and then fall back to option 2.
Solution
You should keep the parent if you ever want to build large widget trees and perform operations that require moving a widget's position in the tree. If your widget trees are very small, or only have a very small depth, but fast hasChild accessors, then Option 3 may be acceptable for you and you could omit the parent reference.
References in Datastructures in general
What you are planning to do here is to build up a datastructure for a tree. Let's consider a simplification and for the sake of argument assume that every widget can only have one child. The result, of course, is a list and your question now becomes "should I have a single-linked or double-linked list?".
And just like lists, there is no definite answer, but only pros and cons. Obvious pros for the single-linked (i.e., no parent reference) are a) easier to implement and b) less memory. But the cons include a) some operations become slow as they have to traverse the structure and b) not having easy access to those operations may mean that the datastructure is cumbersome to use, and c) it uses more memory.
On the other hand, the double-linked variant, i.e. with parent reference, pretty much reverses these pros and cons.
In terms of a GUI library/framework though, the memory limits are usually not a problem that prohibits parent pointers. If you rule that out, and realize that it's a library/framework, and hence, it is preferrable for it to be hard to implement, but easy to use, then you essentially rule out the above pros of a single-linked approach.
I am not aware of the peculiarities of your project, so I want to refrain from telling you to keep the parent reference, as some of my above reasoning may well not apply in your case. In general, however, I consider parent references in a widget datastructure to be worthwhile for the above reasons.
