search

Updownquark / Quick

Quark's User Interface Creation Kit
0 stars 0 forks source link

Implement Label Widget #8

Closed Updownquark closed 11 years ago

Updownquark commented 12 years ago

No widget currently exists to display text. The class is there but it's empty.

Updownquark commented 12 years ago

Plain text in the document needs to be rendered as a label. The actual label type will support styles and possibly other text-related attributes.

Updownquark commented 12 years ago

Text works. Labels not required or implemented. Can't really think of a use case that would make a label useful. The only disadvantage to using blocks is that you have to specify a layout.

Updownquark commented 12 years ago

Unfortunately, all these commits since the issue was closed are mislabeled. They should be on #6--Create Button Widget.

Updownquark commented 11 years ago

Want to add some functionality to label. First I want to be able to specify a model value so that the label's value changes with the model.

Something that will need to be done eventually is the ability to select text in a label. This may not be reasonable until after #10 (DnD) is done.

Updownquark commented 11 years ago

This is finished, but there's a problem. For example, when the new toggle button test starts, the value in the model is null, so the label has no text and its size is zero. When one clicks a button, the value in the model changes as does the text in the label, causing the label's preferred size to change; however, no event is fired instructing the main block to do a re-layout, so the label's actual layout size is zero. If the window is resized, the label shows up like it should.

This could of course be worked around by setting the size of the label, but that's a horrible hack. We need an way to signal parents to arbitrary depth that the size of one of their descendants has changed and a layout operation is required.

The ideal solution to this would involve some screening, i.e. no layout operation would be fired if the layout size of the widget were fixed by attributes, layouts would not be done beyond a scroll pane since the size of the widget in the scroll pane will probably have no effect on the size guide of the scroll pane, etc. However, implementing these sounds extremely difficult and like it would involve a lot of hackery. It does deserve some thinking though. The actual solution may end up being simpler. I may need to take a look at what Swing and AWT do.