add SetParent method for Panel

[ddkwork]

Hello again, could you please add method for panel

func (p *Panel) SetParent(parent *Panel) {
        p.parent = parent
}

[ddkwork]

When I repackaged the table widget implementation I found that I needed these two methods to repackage the table widget outside of the original repository so that I could keep your implementation and I only needed to be able to repackage it in other packages, thanks.

[richardwilkes]

Setting the parent can already be achieved with the existing code. To clear it you, call .RemoveFromParent(). To set it, you call one of .AddChild() or .AddChildAtIndex().

I'm unclear on why you posted a large block of the table code here.

[ddkwork]

i will try soon, thx

---Original--- From: "Richard @.> Date: Thu, Apr 18, 2024 08:54 AM To: @.>; Cc: @.**@.>; Subject: Re: [richardwilkes/unison] Panel method (Issue #50)

Setting the parent can already be achieved with the existing code. To clear it you, call .RemoveFromParent(). To set it, you call one of .AddChild() or .AddChildAtIndex().

I'm unclear on why you posted a large block of the table code here.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ddkwork]

Setting the parent can already be achieved with the existing code. To clear it you, call .RemoveFromParent(). To set it, you call one of .AddChild() or .AddChildAtIndex().

I'm unclear on why you posted a large block of the table code here.

After a long time of testing found that only SetParent can make the node work properly, RemoveFromParent just remove themselves from the parent node, it does not have the right to operate the parent node, for AddChild, when we are ready to child nodes, you can use the parent AddChild, but AddChild has to be implemented internally to remove firstitself and then set the parent, recently added to the child set, already marked for redrawing. This process also leads to node exceptions.

通过DeepL翻译 https://www.deepl.com/app/?utm_source=android&utm_medium=app&utm_campaign=share-translation

[richardwilkes]

Both forms of AddChild already call RemoveFromParent(). RemoveFromParent() (as well as the other various Remove methods) does exactly what it says.

I'm still not understanding what the problem is that you're trying to address.

[ddkwork]

Both forms of AddChild already call RemoveFromParent(). RemoveFromParent() (as well as the other various Remove methods) does exactly what it says.

I'm still not understanding what the problem is that you're trying to address.

See here please

https://github.com/ddkwork/unison/blob/main/treetable%2Ftreetable.go#L939-L949

[richardwilkes]

Right. That's only being done that way in my code because it is in the same package and I don't really need it to do any extra work for cell installation/removal. The extra work shouldn't be harmful, though.

It seems you're going to some trouble to extract my code into your code base for no apparent reason, which is causing you issues like this since your code is not in my package. Why are you unable to just use it as a library like everyone else does?

By doing what you're doing, you end up not getting any bug fixes or feature additions I create in the future, since your copy will quickly become out of date and unsynced with mine. What are you trying to achieve by doing this?

[ddkwork]

What I'm doing is rewrapping your table widget implementation logic as: merge rowdata interface and model into a unified node structure to simplify the use of the method, it has been tested so far, but the panel lacks this method, it only takes three lines of code to add it, can you add this method conveniently? The first time I changed your table widget implementation code directly, then I extracted it into an external package encapsulation so that I could keep your implementation so that I could update your commit to check for bugs in my encapsulation. Thank you

[ddkwork]

For toolbox.call, the instantiation code for log is too long for me to remember, so rewrapped your implementation again, thank you very much, I hope you don't mind. It would be nice if the Go language officially included toolbox.call in the STD library, and your design solves the bad design of error.

[richardwilkes]

Yes, you can limit the possible uses of the table by merging that logic. It is intentionally separate to allow many different use cases, which your way of doing eliminates, making it less useful to some people.

Anyway, I will not add just direct setting of the parent field, as there is other logic that usually needs to be triggered when that happens. Because the two methods you are referring to are internal to the package, however, I took a shortcut because I was certain the extra logic wasn't needed in this specific case. That is not generally the case, so isn't something I'm willing to expose.