Rust seems to be a poor match for the way the author wishes to solve this particular problem. That doesn't mean that their design is wrong, or that Rust is wrong, but it does mean that mixing the two would require rethinking parts of the design.

> So a trait can define abstract functions, but can't access any underlying fields.

In Rust, a trait is a purely abstract interface to a type. It explains how you can use that type, but it knows nothing about the implementation.

I'm not quite sure what the design goal was with the Widget type, but the closest solution is to replace the member variable in the abstract type with some kind of accessor (and to replace the magic negative font sizes with an Option):

    trait Widget {
        // ADDED: Access whatever underlying font
        // size you have stored in this type.
        fn desired_font_size(&self) -> Option;
        // ADDED: Access the theme of this object.
        fn theme(&self) -> &Theme;
        // High-level interface to get font size.
        // (With a default implementation in terms of
        // other functions on this trait.)
        fn font_size(&self) -> i32 {
            if let Some(sz) = self.desired_font_size() {
                sz
            } else {
                self.theme().get_standard_font_size()
            }
        }
    }

> What IS the idiomatic Rust way to do a cyclical directed graph?

Unfortunately, the correct idiomatic way is that you try very hard to avoid doing so. Rust is all about clear ownership, and it doesn't like circular references.

The usual solution is to put the cyclic graph code into a library, and to use pointers and about 20 lines of unsafe code. (EDIT: See below for a better solution.) It's not much different from the C++ solution.

The Servo team really wants GCed, safe pointer support in Rust, and design work is well underway. But it's going to take a while to stabilize.

GUI libraries are an interesting special case: They involve huge class hierarchies, lots of implementation inheritance, circular references, and tricky ownership. Most older OO languages were optimized for this case. Newer languages tend to favor flatter type hierarchies and far less implementation inheritance. Which means that traditional object-oriented GUI designs may be awkward.

> GUI libraries are an interesting special case: They involve huge class hierarchies, lots of implementation inheritance, circular references, and tricky ownership.

I doubt they have to be. There are other ways to do GUI, see for instance how Light Table uses a database-like Entity Component System. https://www.youtube.com/watch?v=V1Eu9vZaDYw

I am fairly confident "someone" could write a composition-based UI. I know of no fundamental reason why that would be impossible, or even any more difficult than doing one with inheritance.

However, that does not solve the problem that all the mature existing UI widget toolkits are based on inheritance, and that causes a serious "impedance mismatch" with languages that don't have inheritance.

As I expect more languages to start privileging composition over inheritance, I also therefore expect this problem to continue to become more acute until "someone" finally solves it. However, GUI toolkits are huge and "someone" is likely to be a substantially-sized organization. The problem is going to have to become very painful before it is solved well.

Granted, current GUI toolkits are huge. On the other hand, I have worked with Qt, and this convinced me most of the complexity there was a blend of avoidable bloat and a long tail of features few people ever use (a bit like offices suites).

I'm pretty sure properly written GUI toolkits can be much smaller. As in, satisfying 90% of our needs in a couple thousand lines of code. (The remaining 10% might require heaps and heaps of code, but I'm sure it doesn't have to affect the core.)

It's only an intuition at this point (I have yet to implement my own GUI toolkit). But I have reasons to believe this intuition is right: http://www.vpri.org/pdf/tr2012001_steps.pdf

    I'm pretty sure properly written GUI toolkits can be much smaller...

Like, I'm sure you can write a procedural generator in a handful of lines of code that spits out the full works of Shakespeare. It's probably possible, if you have the right seed and the right algorithm.

...but practically speaking, how do you actually build one?

The same goes for UI libraries; certainly it should be possible (in theory) to have a minimal beautiful GUI libraries with an excellent API; but every attempt to build one seems to have failed.

Perhaps the problem domain is actually more difficult than you're giving it credit for...

- http://www.fltk.org/index.php - https://github.com/froggey/Mezzano

Then again most gui libraries end up including networking, file handling, etc...