|
|
Home » Community » U++ community news and announcements » 2024.1a (rc)
|
Re: 2024.1a (rc) [message #61233 is a reply to message #61226] |
Sat, 14 December 2024 14:21   |
 |
Klugier
Messages: 1099 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek,
Thanks for preparing new stable version!
However, I have a concerns about the version naming convention. What about using semantic version convention? In this case we will have 2024.1.1 (major, minor, patch) instead of 2024.1a. a in version number might be consider as alpha, which I believe we would like to avoid. Also, consider changing stable branch name from stable to stable/2024.1. Thanks to that when we will avoid problems in the future when another stable branch might be needed.
Klugier
U++ - one framework to rule them all.
[Updated on: Sat, 14 December 2024 14:21] Report message to a moderator
|
|
|
Re: 2024.1a (rc) [message #61235 is a reply to message #61233] |
Sat, 14 December 2024 14:38   |
 |
mirek
Messages: 14256 Registered: November 2005
|
Ultimate Member |
|
|
Klugier wrote on Sat, 14 December 2024 14:21Hello Mirek,
Thanks for preparing new stable version!
However, I have a concerns about the version naming convention. What about using semantic version convention? In this case we will have 2024.1.1 (major, minor, patch) instead of 2024.1a. a in version number might be consider as alpha, which I believe we would like to avoid. Also, consider changing stable branch name from stable to stable/2024.1. Thanks to that when we will avoid problems in the future when another stable branch might be needed.
Klugier
No problem. Will rename.
Can somebody test? This really is targeted fix, so should not affect much else, but I would like to be minimally sure before removing (rc) moniker.
Mirek
|
|
|
|
|
|
Re: 2024.1a (rc) [message #61267 is a reply to message #61254] |
Wed, 18 December 2024 11:26   |
 |
mirek
Messages: 14256 Registered: November 2005
|
Ultimate Member |
|
|
Novo wrote on Mon, 16 December 2024 07:21
Another problem is an application icon in a switch-application dialog (cmd-tab). I couldn't take a screenshot, but it is a 16x16 icon. It looks ugly.
I tried to set application icons for my own application by following TheIDE as an example. At least I created a bunch of png-files, but this didn't work for me.
Finally, I set LargeIcon to 512x512 and Icon to 64x64.
Setting of a LargeIcon fixed an icon with the switch-application dialog, but in other places icon is just missing. I probably should've done something in a different way, but I couldn't figure out what exactly I need to do.
Well, probably it is 32x32, but I agree it looks ugly.
In MacOS, LargeIcon is used if not Null, then Icon. Rereading Apple docs it looks like setting LargeIcon to 512x512 is the correct solution, it will get rescaled down as needed. However, before I do that, I wonder about those "other places" where it is now missing...
|
|
|
|
|
|
|
Re: 2024.1a (rc) [message #61279 is a reply to message #61265] |
Thu, 19 December 2024 05:58   |
Novo
Messages: 1430 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Wed, 18 December 2024 05:05Novo wrote on Mon, 16 December 2024 07:21It looks like there are problems with icons on Mac.
I checked this on MacOS 15.1 am64.

This icon is actually loaded from web, as part of search engine intialisation. Most likely you have initialised theide in UHD mode, then switched to HD mode. TheIDE loaded these icons for UHD.
Still something to fix (I guess we will need to store both), but I do not think it is critical for stable update.
I didn't do anything special. 
I just launched TheIDE and I didn't switch anything anywhere 
It turned out that this problem is related to the current master branch.
2024.1.1 rc is fine.
Regards,
Novo
[Updated on: Thu, 19 December 2024 05:59] Report message to a moderator
|
|
|
|
Re: 2024.1a (rc) [message #61281 is a reply to message #61226] |
Thu, 19 December 2024 06:25   |
Novo
Messages: 1430 Registered: December 2006
|
Ultimate Contributor |
|
|
So far setting LargeIcon to 512x512 works for me.
I do not understand what all these icon32x32, icon64x64, icon128x128, icon256x256, and icon512x512 files for ...
They seem to be ignored by MacOS ...
Regards,
Novo
[Updated on: Thu, 19 December 2024 06:25] Report message to a moderator
|
|
|
|
|
|
Re: 2024.1a (rc) [message #61302 is a reply to message #61300] |
Sat, 21 December 2024 21:24   |
 |
Klugier
Messages: 1099 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek,
Good news! I created release on GitHub. Also, I created release/2024.1 branch based on stable branch. stable branch can be removed. Also, It looks like it is version 17459 not 17490. So, Sourceforge file names are wrong. Can you check and fix?
Klugier
U++ - one framework to rule them all.
[Updated on: Sat, 21 December 2024 21:33] Report message to a moderator
|
|
|
|
Re: 2024.1a (rc) [message #61346 is a reply to message #61342] |
Sat, 28 December 2024 21:09   |
Novo
Messages: 1430 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Sat, 28 December 2024 03:28
This problem hopefully fixed in master (by loading and storing both 16x16 and 32x32 icons for websearch, then using one based on current mode).
The problem is fixed.
Thank you very much!
Regards,
Novo
|
|
|
Goto Forum:
Current Time: Tue Apr 29 19:41:18 CEST 2025
Total time taken to generate the page: 0.01608 seconds
|
|
|