In qml when you use certain types like Button or Icon a lot of errors like
m310 could not resolve prototype Private.HighlightImageBase (or SilicaMouseArea) shows up. The app still runs
but I dont understand where the type information is supposed to be in the qmldir ? And is there any workaround to avoid this warnings in the IDE ?
1 Like
From Sailfish IDE qt creater docs: Various warnings are produced by the QML static code checker for Sailfish.Silica types with the build targets matching recent Sailfish OS releases, like Could not resolve the prototype “SilicaItem” of “PageHeader”. (M301)
Yep. same for most of us, but as you point out, you can still build and produce apps.
Not a workaround but a feature of the SDK, you can right click on the underlined component and select 'Refactoring and choose Add a comment to suppress this message by doing this you will see this comment // @disable-check M301` is placed above the component.
These are not really errors as such, just stuff that hasn’t been ironed out as SDK is updated, I think maybe this will be fixed in the next SDK release, but either way, keep building!
4 Likes
Thanks for the tip, this helps a good deal. Having the red lines throughout my code was a bit distracting, false alarms etc.
1 Like
Yes thanks Edz // @disable-check M301 works like a champ
1 Like
Alternatively, those who do not need to use the most recent Sailfish OS API additions can use build targets matching some older Sailfish OS release. These can be installed using the SDK Maintenance Tool (or with sfdk tools install) and then appear as additional Kits under Qt Creator. Unfortunately it is not trivial to make it support recent Sailfish Silica versions.
After updating the SDK earlier today, I’ve got every single qml file in the editor literally filled up with M301 warnings for Page, Button, PullDownMenu, PushUpMenu, MenuItem, Icon, and a lot more.
The // @disable-check M301 comment works for a single instance only, so I would need to add it to every warning, in every file.
Don’t they do even the most basic check prior to releasing an SDK update? Like just launching Qt creator and opening some project in it? If they did, they surely would have noticed it as even the Page type is affected, i.e. something really hard to go unnoticed.
The issue is going to be fixed with build targets for the upcoming Sailfish OS release (4.4.0).
Meanwhile, it can be made less annoying by removing the corrupted QML type info from the affected build targets.
This can be achieved persistently with a build hook:
Create a directory for your build hooks. In this example we will use a subdirectory of Sailfish SDK installation directory. You can use any path you like but ensure it belongs to your SDK workspace (your user home directory by default).
mkdir ~/SailfishOS/hooks
Create a script named post-pull-build-requires (exactly!) under the directory, with the following content:
#!/bin/bash
drop_broken_qmltypes() {
rpm -q --changelog sailfishsilica-qt5 |grep -F -q "JB#55309" && return
rm /usr/lib*/qt5/qml/Sailfish/Silica/plugins.qmltypes &>/dev/null || return 0
touch /var/lib/rpm/* || :
}
sfdk tools exec "$SFDK_TARGET" bash -c "$(declare -f drop_broken_qmltypes); drop_broken_qmltypes"
Ensure it is executable
chmod +x ~/SailfishOS/hooks/post-pull-build-requires
And take it into use globally
sfdk config --global --push hooks-dir ~/SailfishOS/hooks
Run qmake on your project within the IDE (Build > Run qmake) and the annoying red highlight all around should change for a single red-highlighted line, the import Sailfish.Silica 1.0 line.
Learn more about build hooks in sfdk --help-all.
3 Likes
This seems to buck when the path is not located under the workspace root?
Invalid argument '/home/mwa/SailfishOS/hooks': Path not located under Sailfish SDK workspace directory (/home/mwa/src/sailfish)
sfdk config --global --push hooks-dir ~/src/sailfish/hooks
works like a charm. Thanks!
EDIT: It does work but produces:
Error running hook "/home/mwa/src/sailfish/hooks/post-pull-build-requires"
[W] QProcess: Destroyed while process ("/home/mwa/src/sailfish/hooks/post-pull-build-requires") is still running.
Fatal: The 'post-pull-build-requires' hook failed
Hm, I wonder why I didn’t hit that error. Anyway, given that the latest build targets available in Sailfish SDK 3.9 (released today morning) do not suffer from the original issue, I would recommend you to upgrade & use these instead of fighting the original issue with this workaround, which itself seems to be somehow faulty in your case.
I’m still using some older targets, too, but I will update soon. Thanks!
Yup, I mean I would recommend you to use the latest targets during the regular edit-build-test cycle and you can still use the older targets when you do e.g. release builds and you want to support older devices.
I had, in the main, been using older targets to get around what appeared to be a bug in harbour. I think, if I’m not mistaken that it’s not necessary any more. I had been uploading 3.4 target built arm7 32 bit and x86 builds and 4.x target aarch64 builds. Not sure if that’s still a necessary ‘hack’?
I now downloaded 4.4.0.58 and instead I get “Unnecessary message suppression” at the places where I put // @disable-check M301 !!
So I can now remove them !!
Good work!
1 Like