cacao

cacao copied to clipboard

I'm attempting to build a table component, similar to what's in the todo list example but can't seem to get anything to display and the most progress I've been able to make is to have the item_for method being called with an index that's double the number of rows. Would it be possible to improve the module level documentation for ListViews to explain how they are meant to be used and to add more detailed comments to the todo list example please. For context I've not done any object c stuff before so am not aware of how the original framework really works.

Here's the repo of what I've got for now too: https://github.com/Isaac-Leonard/accessible_gis

Hmm, docs are always good - it's just a matter of who has time to write them. Definitely worth doing though so this issue can stay open as a tracking issue.

Do you have a sample file that can be used with your app? I could take a quick look if you do.

If you unzip this and access the australia.shp file (The others are needed cause shape files are weird) it'll crash with an index out of bounds error If you add -25 to the attributes[row] line it'll stop crashing but it won't display anything still example-shape-file.zip

Ah, so you're not actually that far off - you just didn't set any constraints on your ShapeView so the system has no idea how to display it.

You can verify by adding the following right before you add it to your subviews stack, around line 111:

shape_view.set_background_color(cacao::color::Color::SystemRed);
LayoutConstraint::activate(&[
	shape_view.width.constraint_equal_to_constant(100.0),
	shape_view.height.constraint_equal_to_constant(100.0)
]);

Screenshot:

I've just added those changes but have no change in the output

Activate LayoutConstraints after it's added to the view. :)

Okay, I've got it working now. I wonder if it would be a good idea to have the ViewDelegate traits to have a required get_layout_restraints method that then gets called automatically after did_load is called? That way it can't be forgotten and the compiler enforces that restraints have to be provided.

I'd have to think through that idea since it's like... there are potentially good reasons to not have layout constraints applied on something at all. The interface would have to return an Option<...> as a result of that, at which point you're kind of in the same boat.

Now, it does actually give a slightly cleaner approach when widget building, so you're possibly on to something. I'll let it roll around in my head for a bit and see what I land on - I actually do like the concept, I just don't want to fire without thinking it through.

(Also, that method would be a noop if the user doesn't have autolayout as a feature and is just using old school frames, etc)

Is there any guides / docs on how the framework works and the differences between auto layout and frames

How do you set constraints on individual components like buttons and labels? And is there a way to change the text of a button without making a whole new one?

You treat those like any View, they have the same constraint types available.

And yes, Button::set_text(&self) is available for that.

Do layout constraints need to be deactivated ever or does setting new ones over ride old ones? And I can only seem to find a set_text_colour method on buttons, maybe I need to update the version I'm using

Missed this - answer(s) below if you're still looking!

You've got the right idea with LayoutConstraint's: if replaced, they do not need to be explicitly deactivated - they override old ones. If you need to disable one without necessarily removing it, you need to explicitly call disable.

Button set_text is definitely in the repo - what version you using?

https://github.com/ryanmcgrath/cacao/blob/4f40d626236c8114192cde57943ff16d6310186b/src/button/mod.rs#L180-L185

I'm on version 0.3.2 which is seems to be the most recent release on crates.io, I'll switch over to using the last commit though Thank you about the constraints.

Okay, its there now