@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.
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
@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!
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!
@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.
@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.
That will allow you to turn on backtrace decorators by adding the following line somewhere in the nib2cib tool:
objj_msgSend_decorate(objj_backtrace_decorator);
Finally you could use
objj_backtrace_print(CPLog.warn); to print out the call stack.
I’ll try this with #2917 to see if it’s fixing this problem also…
@enquora Could you please check that it also works for you ?
Looking at the fix, one wonders how this worked at all previously
@mrcarlberg Sorry for #2950 but each time I compile Cappuccino, I say to myself “I’ll fix this warning ASAP”… for about a year !.. So this is now fixed. 😉
@didierkorthoudt i just noticed https://github.com/cappuccino/cappuccino/wiki/Following-host-OS-UX-UI
excellent stuff!!
@michaelbach I’m having trouble parsing their statement on pricing. The blog post says 'The pricing change does not affect most Travis CI users who run their builds on public and private repositories using Linux and Windows OS’ but later says pricing changes will apply to those building on public repositiories only, with no qualifiers.
Further, it states pricing changes apply specifically to https://travis-ci.com. What else would they apply to - travis-ci.org ceases to exist in under 60 days?
Some of the other language used is the smarmy sort used when large organizations want to obfuscate and, combined with the buy-out by private equity firms 18 months ago raises red flags.
We can certainly run on donations, but that increases the administrative burden
If we were a new project starting out just now, would we pick Travis over Github Actions, or GitLab CI? If so, why?
This also raises the question of our execution environment for tests - I presume we’re using Rhino since WebKit isn’t available on Linux? Presumably we’ll see much reduced build times once we move to Node. Are there significant aspects to that transition beyond the ones for normal dev usage?
@didierkorthoudt @mrcarlberg Confirming that PR2949, while already merged and closed, has been more extensively tested here and does fully solve the problem of tables in boxes. I’m still left wondering how that code worked at all previously! And how many other places we have improperly or incompletely initialization. For recall when weird behaviour appears in the future.
I’m not displeased with default buttons’ increased corner radii - it is a welcome visual distinction from popup buttons.
@mrcarlberg Is it reasonable then, to write XcodeCapp tests in Xcode, include them in repo, and assume anyone reviewing prior to commit will run them manually on their own machine? There is flaky behaviour in XcodeCapp’s listener interactions with the filesystem that seems worse in Catalina and Big Sur. I have a few more general cleanup items but need to look at that problem soon.