> Well, first off, I apologize for the insult. I really should have chosen a
> less aggressive subject line. It is certainly not my intent to insult the
> Pivot team, which has produced a very impressive system with limited
> resources. Nor do I wish to glorify WPF, which I agree is a bloated beast.
> But it happens to be a beast with which I am somewhat familiar, and not long
> ago Chris invited me to discuss things from there or elsewhere that I thought
> might benefit Pivot, so here I am.
Fair enough. Discussion is always welcome.
> > <BoxPane orientation="vertical" styles="{fill:true}">
> > <BoxPane styles="{horizontalAlignment:'center'}">
> > <Border preferredWidth="150" preferredHeight="150"
> > styles="{color:'gray', thickness:4, cornerRadii:10}">
> > <ImageView bxml:id="imgPhoto" styles="{fill:true}" />
> > </Border>
> > </BoxPane>
> > <Label styles="{wrapText:true}" text="...Some long paragraph..." />
> > </BoxPane>
> ...
> > Am I missing something? Is there an easier way?
>
> I might put the BoxPane in the Border rather than the other way around.
>
> Well, that wouldn't be less wordy, but I also don't think it works. The
> Border would fill the horizontal space. And even if it didn't, I can't
> center it, since Border lacks a horizontalAlignment property.
True. To center the border, you would need to put it in a BoxPane.
> You might also consider using TablePane as your outer container instead of
> BoxPane.
>
> It's true that I can get practically anything I want with TablePane, but it
> can be pretty cumbersome. The equivalent of a vertical BoxPane means adding
> a columns specification, and wrapping each element in TablePane.Row. In my
> particular example, unless I'm missing some trick, it's more like
>
> <TablePane>
> <columns>
> <TablePane.Column width="1*" />
> <TablePane.Column width="-1" />
> <TablePane.Column width="1*" />
> </columns>
> <TablePane.Row>
> <TablePane.Filler/>
> <Border styles="{color:'gray', thickness:4, cornerRadii:10}">
> <ImageView bxml:id="imgPhoto" styles="{fill:true}"
> preferredWidth="150" preferredHeight="150" />
> </Border>
> <TablePane.Filler/>
> </TablePane.Row>
> <TablePane.Row>
> <Label TablePane.columnSpan="3" styles="{wrapText:true}"
> text="...Some long paragraph..." />
> </TablePane.Row>
> <TablePane.Row>
> <TablePane.Filler/>
> <PushButton buttonData="Press Me" />
> <TablePane.Filler/>
> </TablePane.Row>
> </TablePane>
>
> But that's not quite right, because it ties the width of the imageview to the
> width of the button -- if the image is wider than the button, the button is
> stretched to the width of the image, while if the button is wider, the border
> is stretched to the width of the button, leaving me no longer with a square
> border.
It is fairly common to put BoxPanes in table cells to manage alignment. Another
option we have talked about is allowing a caller to specify the alignment of a
table cell (similar to HTML), perhaps via an attached property such as
"TablePane.horizontalAlignment"/"TablePane.verticalAlignment". We decided
against it since the same results could be achieved via composition, but of
course it is still an option.
> So I really have to split it up into multiple tables:
...
Couldn't you just put the button in a BoxPane rather than in a separate
3-column table?
> * The XAML editor has Intellisense.
That's a tooling issue though, not an inherent design limitation.
> * There's a visual designer, so in most cases I don't have to run my app to
> see whether I got it right, or at least close.
This is also a tooling issue. But I agree that these features are invaluable.
> * The connection between a XAML file and its backing class is handled
> automagically internally.
That's largely because XAML is compiled into a class, whereas BXML is loaded
dynamically. However, it's not unreasonable to consider "compiling" BXML at
some point in the future.
> * Events are a bit simpler. That's mostly Java's fault, not Pivot's, but it
> still is a learning issue. In WPF, if I want to be notified when my control
> is resized, I add a single method (or even a closure) to the control; I don't
> have to write a ComponentListener with 11 (!) methods, 10 of which go unused.
Agreed on this point - though you can generally use an Adapter to avoid having
to implement every method.
> But if someone were to ask me my recommendation for a framework in which to
> build a GUI app that they only ever wanted to run on a Windows desktop, I'd
> have to point them at WPF, sorry. On the other hand, for cross-platform
> apps, I *do* recommend Pivot, but it's with a lot of caveats.
That's cool. I'd probably recommend WPF for Windows-only apps myself, if only
because the support is likely to be *way* better. :-)
> So when there are things from WPF that I think would make Pivot more usable,
> I hope I can bring them up. Earlier I've mentioned such things as a
> ScalingPane (something I could really use right now and have no idea how to
> implement myself) and simpler markup for document spans of text (which you
> fixed in 2.0.1, thank you). I often hesitate to do so, lest you feel I'm
> casting aspersions on Pivot. I'm probably coming off as way to much of a WPF
> fanboy as it is, which is unfortunate, since I and my colleagues get mad at
> Microsoft all the time...
I wouldn't hesitate to continue making suggestions. Overall, the end result is
positive.
G
