Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 23 16:39
    enquora commented #2954
  • Nov 23 11:04
    cacaodev commented #2954
  • Nov 23 11:02
    djbewick closed #2957
  • Nov 23 11:02
    djbewick commented #2957
  • Nov 23 10:27
    cappbot commented #2957
  • Nov 23 10:17
    mrcarlberg commented #2957
  • Nov 23 10:03
    cappbot labeled #2957
  • Nov 23 10:03
    cappbot milestoned #2957
  • Nov 23 10:02
    djbewick opened #2957
  • Nov 22 10:01
    mrcarlberg commented #2956
  • Nov 22 10:01

    mrcarlberg on master

    Fixed: Missing call to super in… (compare)

  • Nov 22 10:01
    mrcarlberg closed #2956
  • Nov 21 21:10
    didierkorthoudt commented #2914
  • Nov 21 11:20
    cappbot commented #2956
  • Nov 21 11:11
    cappbot labeled #2956
  • Nov 21 11:11
    cappbot milestoned #2956
  • Nov 21 11:11
    didierkorthoudt edited #2956
  • Nov 21 11:09
    didierkorthoudt edited #2956
  • Nov 21 11:09
    didierkorthoudt opened #2956
  • Nov 20 16:52
    enquora commented #2942
Didier Korthoudt
@didierkorthoudt
@mrcarlberg Cappuccino day for me… 😉
Michael Bach
@michaelbach
thank you!
Didier Korthoudt
@didierkorthoudt
@mrcarlberg I’ve adapted #2918 as asked…
Didier Korthoudt
@didierkorthoudt
@mrcarlberg @michaelbach @cacaodev @enquora @daboe01 Well… After digging for some hours, switching between master, my own master, searching, scratching my head, …, I must admit that what you’ve seen in button look is… well… the correct thing. Let me explain : in Aristo2, there is only 2 visual types of button : RoundRect and Rounded. Rounded (with high radius) is the default for regular “push” buttons. What I think is that I’ve fixed something not correct in CPButton in order to be able to implement all types of buttons and that it has a side effect : making Aristo2 using the correct look.
Here is the left part of the rounded bezel :
button-bezel-rounded-left.png
And here is the left part of the round rect bezel :
button-bezel-left.png
These images are directly taken from Aristo2.
Here is a test with both types of buttons :
Screen Shot 2020-10-25 at 4.45.12 PM.png
As you see, everything is correct. I may have passed beside something important, just let me know…
I may try to implement a workaround in order to restore previous behavior, just let me know if you need it. Regarding CPButtonBar, well, as I’ve reworked it completely, please consider the new version (yet to be finalized and merged).
Didier Korthoudt
@didierkorthoudt
@mrcarlberg Beside that, I’ll have to make a PR to remove dev comments remaining in CPButton… Sorry for this.
Didier Korthoudt
@didierkorthoudt
I must now rebase my repo in order to go further. My next target will be to finalize CPButtonBar using the new buttons (some fixes may be needed).
cacaodev
@cacaodev
You changed the default bezel style from CPRoundRectBezelStyle to CPRoundedBezelStyle https://github.com/cappuccino/cappuccino/blame/master/AppKit/CPButton.j#L207
This is something we should discuss first in a PR
Didier Korthoudt
@didierkorthoudt
@cacaodev Indeed ! Thank you for pointing this. I’ve set it to rounded (push) as this is the standard button. But if you create your buttons by code, without specifying anything, it should go back to RoundRect style. Will change this so it will go back to old way of doing. Easy thank to you !..
Didier Korthoudt
@didierkorthoudt
@cacaodev @mrcarlberg I’ve pushed #2947 to fix default bezel style problem in CPButton. I’ve also removed unwanted comments…
David Richardson
@enquora

The larger button radii didn’t present a big visual problem here for existing work but the button borders in CPButtonBar and the table problems inside boxes are more worriesome. For most, if not all, of the last half-decade (at least), the main branch could plausibly be used in production apps. There is significant value in this approach - it greatly extends our testing, particularly wrt visual changes. Even Apple has (apparently) very minimal automated testing of visual changes, and implementing such is well beyond what is feasible for us. Having the main branch used by many people in existing apps provides a very real benefit.

I’m skeptical this continues to be viable (until Aristo3 is closer to fully merged) given the last few batches of merges and the complexity of the complete visual layer overhaul which is underway.

What are the arguments against merging the Aristo3 changes into an intermediate branch? This would make broader testing easier, and switching back to something stable easier - imo. The intermediate branch could then be merged into main on a regular but less frequent schedule.

Martin Carlberg
@mrcarlberg
@enquora There are many ways we can do the merger of @didierkorthoudt excellent work. We should all expect to find bugs even as I and others are testing before merging. We are using git and it is very easy to use an older version by date for production apps if needed.
It is easier for us to just merge it into the master branch and it will be tested faster :smile:
Martin Carlberg
@mrcarlberg
So, I guess we all have to live with some more bugs in master now until we can fix them all.
Didier Korthoudt
@didierkorthoudt
@mrcarlberg I’ll (try to) propose a fix for current CPButtonBar so the new CPButtonBar could be fully tested.
Martin Carlberg
@mrcarlberg
@didierkorthoudt Great! :smiley:
Michael Bach
@michaelbach
@mrcarlberg: "It is easier for us to just merge it into the master branch and it will be tested faster…" Actually, yes! Once I know the Master is appropriately updated, I'll test with ≈100 programs :) [really! but most are rather similar to each other in their resource usage].
And now I know how to roll back: Also (something in) the narwhal folder must be rolled back, not just the Framworks folder.
Didier Korthoudt
@didierkorthoudt
@enquora @mrcarlberg @daboe01 Could you please test your button bars with current master (that is with #2947 merged) ? I’ve done a quick test and all seems in order now, as you can see here :
Screen Shot 2020-10-28 at 2.56.56 PM.png
David Richardson
@enquora
#2947 fixes buttons inside CPButtonBar
Didier Korthoudt
@didierkorthoudt
@enquora Great !
Thank you for testing on your side !
David Richardson
@enquora
I again raise concerns about merging such a large undertaking as Aristo3 directly into the main branch. With anything so complex, problems and odditites are inevitable. They really deserve their own intermediate branch, to be merged into main only after extended testing by multiple people with real projects.
Didier Korthoudt
@didierkorthoudt
@enquora Well, this is @mrcarlberg work so I let him decide (I’ll do whatever is decided, of course)
David Richardson
@enquora
That leaves the strange behaviour of CPTableView inside CPBox. I haven’t had time in the last week to look further into it, but am settling back into some Cappuccino work
Didier Korthoudt
@didierkorthoudt
@enquora This is my next target
David Richardson
@enquora
@daboe01 What became of your stack exhaustion problem? I just noticed your reduction is still in my Downloads folder - wondering if this was resolved?
1 reply
David Richardson
@enquora

@didierkorthoudt The CPTableView inside CPBox problem was introduced in #2924

nib2cib throws the error null is not an object (evaluating 'self._tableColumnRanges[index - 1]’) when it encounters that configuration. The changes to nib2cib were minimal - the CPBox implementation looks more likely.

I have created a reverting patch to allow staying current with everything else - I can jump back and forth quickly now if you see something needing a quick test
David Richardson
@enquora
The immediate error is actually in the table - obviously, boxes don’t have table columns. Is a variable in CPBox being leaked globally that is clobbering a loop initialization or iterator in CPTableView?
Michael Bach
@michaelbach
With the latest master (½hr ago) I noticed
(1) button radii are fine now, thanks!
(2) the stepper arrows are no longer visible as shown it these 2 screenshots.
Best, M
David Richardson
@enquora
We have a xib label or two needing client-specific terminology. Is it appropriate to use localization in Cocoa for such situations? Perhaps specified in a sub-region of a language? Where does Cappuccino stand wrt localization support in general?
Didier Korthoudt
@didierkorthoudt
@michaelbach Thank you for pointing out the stepper problem… I’ll have a look. Should be simply the button type… (I hope so)
Didier Korthoudt
@didierkorthoudt
@michaelbach #2948 fixes the stepper problem.
Didier Korthoudt
@didierkorthoudt
@enquora I can indeed reproduce your table in a box problem. That’s the positive side of a negative situation… 😉 Will dig on this one.
Shawn Platkus
@platkus
@enquora I’ve come across the need for having client requested string labels in our Mac app. I don’t think localization techniques is the right call here as those strings would need localizations themselves. In our Mac app, there was a specific bike for this OEM and check aged the strings just for that OEM build.
For a Cappuccino app, the approach I would take for just a couple strings would be to special case them in the code. Our Cappuccino app has a JSON file of tags and values that we read in when the application starts up. I have OEM specific values in this JSON file that can be set to tell my application what installation specific options are desired. You could do something similar with a JSON Boolean or string for this client that tells your application to use the alternate strings. You could even embed the alternate strings in this JSON config file and read them from there and set them in code dynamically.
1 reply
cacaodev
@cacaodev
There are also issues with radio buttons. In Tests/Manual/CPRadioBindings you can now select multiple radio buttons and you coud not before the recent merges. An "out of bounds" error is also thrown when you select index 0 in the first popup of second section.
Didier Korthoudt
@didierkorthoudt
@cacaodev I’ve not checked this manual test indeed. This should be a side effect of the modern Cocoa radio buttons management. I’ll have a look ASAP. Thank you for pointing this.
Michael Bach
@michaelbach
@didierkorthoudt: I fixed the steppers according to your PR and they are fine now, great!
I was just going to report the radio button issue, I have it too. There's more: the rotary slider is drawn as a tiny linear slider, not a round disk with indicator. Furthermore, on some buttons (especially when I use some unicode for label) there is an exception as shown in the attached screenshot. Finally, I get an error with array manipulation, also shown in a screenshot.
And I nearly forgot: Sometimes checkboxes stay visually checked, although they transmit their status change correctly to their action functions.
Still, thanks for your immense efforts!
Screenshot 2020-10-29 at 18.25.11.png
Screenshot 2020-10-29 at 18.38.23.png
David Richardson
@enquora
@didierkorthoudt This looks likely to be where the tableview error occurs: https://github.com/cappuccino/cappuccino/blob/e6fe9396f8956447616b0140270249a74ecd6bf2/AppKit/CPTableView.j#L1746
Why your CPBox revisions should trigger it is unclear though.
Didier Korthoudt
@didierkorthoudt
@mrcarlberg Hi Martin ! I’m trying to debug @enquora problem with table in box… It’s a nib2cib problem so difficult to debug. Is there something I could call to trace the call stack ? I’m currently inserting CPLog.info here and there but it would be easier to obtain the full call stack.