<div dir="ltr">The best way to solve this problem would be to re-apply the changes on your image with your package loaded and solve the conflicts, but for that to really work we should reify renames as changes, etc. But if we do that, then we can have an automatic merger that takes care of all the possible conflicts for you, etc. That was my goal behind OOSCM a project about SCM reifying changes to allow smart merges... maybe someday I'll restart it :-)<div> </div><div>Cheers!</div><div>Hernan.</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 21, 2021 at 7:23 AM Gerald Klix via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> On 7/21/21 11:15 AM, Juan Vuletich via Cuis-dev wrote: > > See that I replaced #drawRoundGradientLookOn: with #drawRoundLookOn: , > because I removed the gradient option. I believe that if you do this > rename in any senders and/or implementors in Haver, it should work ok. > In any case, check in detail updates #4677, #4678, #4681, #4682 and #4688. IC and will check it out. Early in the morning a was bit pressed for time -- I still am -- so I not dig into it. > > In general, any Cuis code that is redefined by Haver could have issues > with future Cuis updates, right? I'm not complaining, it is just that I > think we'll need to deal with this fact. That's the risk I took when started on that "Haver"-journey. In fact I spent two days or so in mitigating the risks. That is I implemented a baseline checker that creates code that -- in turn -- checks every class and method modified in a changeset/package for being of the proper version. I used for that big Environments change set with good results; it detected a trivial change. Since there was not much change, I did not use it for all the other packages. In the button case it would have helped anyways, because id does not detect sends to `super`, it just looks at extension methods that override methods in the base image. What we need (for each class), is an interface definition for subclasses, that -- at least -- lists the methods that will stay stable. Just my 0.03€ and many thanks for your help, Gerald > > Cheers, > > On 7/21/2021 4:33 AM, Gerald Klix via Cuis-dev wrote: >> Near miss: #drawRoundGradientLookOn: is still missing. >> Please see the attached debug log. >> >> The code for the button stuff is here: >> <a href="https://hg.sr.ht/~cy-de-fect/HaverOnCuis/browse/haver/ui/Buttons.pck.st" rel="noreferrer" target="_blank">https://hg.sr.ht/~cy-de-fect/HaverOnCuis/browse/haver/ui/Buttons.pck.st</a> >> >> I am sorry there is now Haver release containing this package, >> I hope that I can prepare a new release next week. >> (Raspi builds still miss the FFI plugin, I dug into that one, >> it's a sad story) >> >> Thank you for your efforts! >> >> >> Best Regards, >> >> Gerald >> >> >> >> On 7/21/21 4:31 AM, Juan Vuletich via Cuis-dev wrote: >>> Done. Just pushed another update. Please tell how it goes. >>> >>> Cheers, >>> >>> On 7/20/2021 6:34 PM, Juan Vuletich via Cuis-dev wrote: >>>> The truth is that all I need to move to the Canvas is the specific >>>> methods to draw the icons in window controls. There are Form in >>>> BitBltCanvas, but just drawing calls in VectorGraphicsCanvas. Let my >>>> try to partially revert the changes, and see if I can get VG drawing >>>> the icons, without reducing the flexibility you need. >>>> >>>> Thanks, >>>> >>>> On 7/20/2021 6:14 PM, Gerald Klix via Cuis-dev wrote: >>>>> I just looked into it, and discovered your changes as you >>>>> discribed them. >>>>> >>>>> This move is a bit unfortunate, because >>>>> I overwrote many of the drawing methods. >>>>> Only drawRoundGradientLookOn: and draw3DLookOn: >>>>> are expected to be definded in the super class. >>>>> Sending the corespoinding messages to the canvas won't >>>>> do the job, because these methods delegate the icon >>>>> drawing not the canvas and not my subclass. >>>>> I don't want the icons to be magnified that much. >>>>> Maybe factroring out the magniofaction factors >>>>> might do the job. Also the icons are displayed left of >>>>> label. >>>>> >>>>> I'll look into it tommorrow and try to come up with >>>>> a solution, its 23:10 here. >>>>> >>>>> Just one remark (or rant): >>>>> I can't the my this solution is cleaner: >>>>> Now Canavs defines the geometry of Button >>>>> and not the button itself. >>>>> >>>>> >>>>> Thanks for your help and Best Regards, >>>>> >>>>> Gerald >>>>> >>>>> >>> > > -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div> <div> </div>-- <div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="font-size:small"><a href="https://10pines.com/" style="font-family:Roboto,Helvetica,Arial,sans-serif;font-size:medium" target="_blank"><img width="108" src="https://10pines.github.io/email-signature/10pines-firma@2x.png" style="margin-bottom: 0.5em;"></a><h1 style="margin:0px;font-size:14px">Hernán Wilkinson</h1><h2 style="margin:0px 0px 1em;font-size:14px;color:rgb(100,100,100)">Software Developer, Teacher & Coach</h2>Alem 896, Floor 6, Buenos Aires, Argentina+54 11 6091 3125@HernanWilkinson</div></div></div>