Skip to content

Conversation

@NathanBnm
Copy link
Contributor

I made a few improvements to your app structure. These are not breaking changes. Let me know if you have any questions 😄

Changelog:

  • Renamed COPYING to LICENSE
  • Improved meson.build files
  • Added some comments to meson.build files
  • Improved and simplified post_install.py script
  • Removed empty translation files

I would be happy to update French translation once this will have been reviewed

I tried to build and run the app locally and I had no issues

@NathanBnm
Copy link
Contributor Author

NathanBnm commented Jan 24, 2022

There are a lot of changes but most of them are due to empty translation file deletion

@peteruithoven
Copy link
Owner

Thanks! I'll try to look at this soon.

I don't really have an opinion but the COPYING to LICENSE is a bit subjective right?
https://stackoverflow.com/questions/5678462/should-i-provide-a-license-txt-or-copying-txt-file-in-my-project
Ah it's also the name they are using in the docs now. Good enough for me.
https://docs.elementary.io/develop/writing-apps/our-first-app#legal-stuff

@peteruithoven
Copy link
Owner

Not sure about moving the screenshots. The AppStore relies on them. So if we change the paths to the screenshots we'll break the screenshots in AppCenter until a new release is made and approved. And worse, for elementary v5 they will always be broken because I won't do another release for v5.


install_data(
meson.project_name() + '.contract',
install_dir: join_paths(get_option('datadir'), 'contractor')
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove the contract install logic but keep the contract file?
I know the contract file will no longer work: elementary/contractor#34. Maybe we should just remove all the contract logic in a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. I'll add it back so it can be removed in another PR

project (
'com.github.peteruithoven.resizer',
['vala', 'c'],
meson_version : '>= 0.47',
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not define the min. required meson?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It definitely should be defined!

Meson can refuse to run on older versions, while printing an informative error message telling you that your version of Meson is too old. Additionally, it also prints informative warnings when you use features too new for the minimum required version to handle.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add it back but even elementary apps does not include this. I assume developers should check that their development tools are up to date before trying to build the app. But I can add it back if you prefer.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why make life harder, when you could make life easier instead? :)

meson_version : '>= 0.47',
license: 'GPL-3.0+'
'c', 'vala',
version: '1.0.1'
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to limit the amount of places where the version is defined, to ideally nowhere but the tag. Is this really useful?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really know but elementary does in their app as well as many other developers so.

print('Updating desktop database…')
subprocess.call(['update-desktop-database', '-q', desktop_database_dir])
print('Updating icon cache…')
subprocess.call(['gtk-update-icon-cache', '-qtf', path.join(datadir, 'icons', 'hicolor')])
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this logic coming from? We're asking the desktop to update it's icon cache? Is that common practice? Does this make sense with it being a flatpak?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be replaced by https://mesonbuild.com/Gnome-module.html#gnomepost_install but that requires meson 0.57.0 as a minimum.

This is very common practice when installing normally, to /usr or /usr/local -- although flatpak may internally handle running this when needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this is a common practice when building the app locally with meson. Even if your app is deployed as a Flatpak you should keep the meson install config.

@peteruithoven
Copy link
Owner

Some of these comments are just questions, I'm not exactly an expert on Linux app development. I'm very spoiled in the web dev realm :P

@NathanBnm
Copy link
Contributor Author

NathanBnm commented Jan 26, 2022

I don't really have an opinion but the COPYING to LICENSE is a bit subjective right?

You're right! It is not that important but I think the most common one is LICENSE regarding elementary OS projects so I made the change 😄

Not sure about moving the screenshots. The AppStore relies on them. So if we change the paths to the screenshots we'll break the screenshots in AppCenter until a new release is made and approved. And worse, for elementary v5 they will always be broken because I won't do another release for v5.

I didn't think about that. Good point. I'll revert this

I'll do the changes when I have some time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants