Add trait to get layout anchors for a view #108
Conversation
Isaac-Leonard
changed the title
|
I've put all the implementations and functions that make use of it all in one file for now, I think they'd probably be better off in each components file but this is probably easier to see what I'm intending for now. |
|
So I think this is a gray area for me... it's definitely getting outside of what AppKit/UIKit offer by default, but cacao's taken the opinionated position before so I could be convinced to support this. I would say a few changes come to mind tho:
pub struct ColumnLayout {
pub spacing: usize // psuedocode, do whatever type here
}
pub fn column<I, C>(parent: &Layout, layout: ColumnLayout, children: I)
where
I: IntoIterator<Item = &C>,
C: Layout,
{
// Manage adding views, setting spacing, etc
}This feels more declarative in nature to me, e.g I could then write: impl MyGenericView {
pub fn build(&self) {
column(&self.view_handle, ColumnLayout {
spacing: 8
}, [
&self.child_view_1,
&self.child_view_2,
// etc
]);
}
}The above is all pseudocode and not tested but hopefully showcases the idea.
|
|
I'd like to move it into the Layout trait but currently the Layout trait is not object safe and so doesn't work well as a dyn generic parameter.
HasLayout is intended to be used as a dyn parameter so you can pass a list of random components to top_to_bottom / columns and other similar functions.
I might make another PR soon to make Layout object safe but it will require some pretty large api changes with new traits but most actual functions should remain the exact same.
On 12 Sep 2023, at 03:17, Ryan McGrath ***@***.***> wrote:
So I think this is a gray area for me... it's definitely getting outside of what AppKit/UIKit offer by default, but cacao's taken the opinionated position before so I could be convinced to support this.
I would say a few changes come to mind tho:
* The layout anchor getters could probably be safely thrown onto the Layout trait without much issue, to reduce trait importing (mental) overhead.
* top_to_bottom would be improved (IMO) with the following api:
pub struct ColumnLayout {
pub spacing: usize // psuedocode, do whatever type here
}
pub fn column<I, C>(parent: &Layout, layout: ColumnLayout, children: I)
where
I: IntoIterator<Item = &C>,
C: Layout,
{
// Manage adding views, setting spacing, etc
}
This feels more declarative in nature to me, e.g I could then write:
impl MyGenericView {
pub fn build(&self) {
column(&self.view_handle, ColumnLayout {
spacing: 8
}, [
&self.child_view_1,
&self.child_view_2,
// etc
]);
}
}
The above is all pseudocode and not tested but hopefully showcases the idea.
fill_safe_area I'm less enthused about and might want that in a contrib or helpers module, but I'll muse on that one for a bit.
—
Reply to this email directly, view it on GitHub<#108 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFMGHTZEVCHGRLX4NRBY5ULXZ5BRLANCNFSM6AAAAAA4R5Q52A>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Hmm, interesting. FYI this might be a thing you'll need to rebase since we merged the |
…mponents and add some functions that make use of it to simplify creating layout constraints
Isaac-Leonard
force-pushed
the
has-layout
branch
from
91c55b6
to
876ff3f
Compare
|
Hey, not sure if its just me but I can't seem to get a bunch of warnings and errors when running cargo +nightly clippy and warnings with cargo check and build: warning: Am I doing something wrong o might there be an issue with my set up? |
…nction Acked-by: Isaac Leonard <isaac.mjs.leonard@gmail.com>
|
Offhand I dunno - but if that's deprecated the replacement does the same thing, we can certainly just swap the key out. |
|
There's 51 warnings with cargo check and over 100 with clippy though, is just an issue on my system or is it with the repo? |
Note the api has been reworked. The get_from_backing_obj() method has been changed to get_backing_obj and now returns a Ref to the Object rather then calling a callback with it. This is because there was no way to make the callback method work without generics but we can't have generics if we want to make it object safe
|
Okay, so I think I've implemented everything now that's needed to use Layout as a dye trait. |
|
Hmm… I’ll try to find time to take a look at this over the weekend. This wound up being more invasive than I thought (which isn’t your fault, I think I sent you down that path) so want to regroup and figure out the best option. It may end up being your original take, not sure yet.
And yeah ownership of the ObjC object is something I want to try and hide from this all, since it can get thorny quickly - it’s what led me to the handler approach originally.
Def appreciate the efforts tho and we’ll figure out the best way to do this!
…On Fri, Sep 15, 2023 at 20:51, Isaac-Leonard ***@***.***(mailto:On Fri, Sep 15, 2023 at 20:51, Isaac-Leonard <<a href=)> wrote:
Okay, so I think I've implemented everything now that's needed to use Layout as a dye trait.
I had to create a new trait for the set_frame method as I didn't really know how that could work without generics, I updated the frame example with the change.
I had to change how ObjcAccess works too as the get_from_backing_obj method couldn't work without the generic return type.
Instead I've made a new method that just returns the reference to the inner Id that callers can then just dereference and do what they were doing before.
I'm not sure if I've be putting Shared or Owned for the ownership generic of Id though, for now I've just got Owned.
I've also not had any experience with objective C so I'm not sure if I'm creating layout anchors correctly,.
I'm creating them the same way its done in the constructor for view but not sure if this creates non-allowed duplicates or anything.
I believe all of these changes may allow me to implement a more reactive framework on top of cacao too now.
—
Reply to this email directly, [view it on GitHub](#108 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAFROCBSOUFBNCIU7HBGCTX2UO4HANCNFSM6AAAAAA4R5Q52A).
You are receiving this because you commented.Message ID: ***@***.***>
|
|
No no, stuff I've been working on in my own project was also leading down this route, either way I was probably going to fork and do something similar. |
|
I've started working on a framework of sorts based on the changes I've made: |
Add trait to get layout anchors for a view, implement it on common components and add some functions that make use of it to simplify creating layout constraints