Revision history [back]
 | 1 | initial version | posted 2014-04-15 21:53:32 +0200 |
Sailfish SDK: please improve experience
This question is somewhat related to my more general post about developer experience.
I'd like to point out that the developer experience of the Sailfish SDK still leaves some things to be desired.
The general idea
Currently the Sailfish SDK follows the pit of failure pattern: it is too easy to mess up, and once you've messed up it's extremely hard to even find out what's wrong, let alone solve it. On the other hand, as a huge Jolla supporter, I'd like the Sailfish SDK to follow the pit of success way of thinking, which means that things should 'just work'.
As a motto, I'd say:
The SDK should be centered around helping the developers do things as effortlessly as possible, instead of getting in the way.
- Most of the time, not only is there a problem in some cases, but the SDK gives arcane or unhelpful error messages that leave developers confused and demotivated about the platform.
A few examples
Here're a few points of interest:
- When you have multiple Jollas configured in the SDK, Qt Creator will try to deploy your app to the wrong Jolla
- The error message doesn't tell you what the problem is
- I'd expect the SDK to figure out which Jolla is connected to the computer, and only ask if there are two or more connected at the same time
- Deployment to a device is so unberably slow that it deserves its own together post
- Building a package is also very slow
- The "deploy by copying binaries" method doesn't work. It either copies a lot of unnecessary files (why?) or when I set
INSTALLS=targetforqmaketo make it just deploy what I want,ṙpmbuildcomplains about missing files. I don't even see why it needs to runrpmbuildwhen all I want is to copy a bunch of binaries to my device - If you delete
~/.scratchbox2by accident, it doesn't regenerate the missing files or give you any helpful hint on how to solve the issue, or even an error message of what's wrong. - You can't deploy your app to a device without a
specor ayamlfile, even if you don't want to package it
Conclusion
I'd like Jolla to succeed.
And a very important aspect of success is that the developer experience of the platform should be as good as possible. The better it is, the more developers will come, and the more apps will be, thus more users will come too.
If anyone has more suggestions or weird examples or errors or things that could be improved, please don't hesitate to edit this post or add a comment.
| | 2 | retagged |
Sailfish SDK: please improve experience
This question is somewhat related to my more general post about developer experience.
I'd like to point out that the developer experience of the Sailfish SDK still leaves some things to be desired.
The general idea
Currently the Sailfish SDK follows the pit of failure pattern: it is too easy to mess up, and once you've messed up it's extremely hard to even find out what's wrong, let alone solve it. On the other hand, as a huge Jolla supporter, I'd like the Sailfish SDK to follow the pit of success way of thinking, which means that things should 'just work'.
As a motto, I'd say:
The SDK should be centered around helping the developers do things as effortlessly as possible, instead of getting in the way.
- Most of the time, not only is there a problem in some cases, but the SDK gives arcane or unhelpful error messages that leave developers confused and demotivated about the platform.
A few examples
Here're a few points of interest:
- When you have multiple Jollas configured in the SDK, Qt Creator will try to deploy your app to the wrong Jolla
- The error message doesn't tell you what the problem is
- I'd expect the SDK to figure out which Jolla is connected to the computer, and only ask if there are two or more connected at the same time
- Deployment to a device is so unberably slow that it deserves its own together post
- Building a package is also very slow
- The "deploy by copying binaries" method doesn't work. It either copies a lot of unnecessary files (why?) or when I set
INSTALLS=targetforqmaketo make it just deploy what I want,ṙpmbuildcomplains about missing files. I don't even see why it needs to runrpmbuildwhen all I want is to copy a bunch of binaries to my device - If you delete
~/.scratchbox2by accident, it doesn't regenerate the missing files or give you any helpful hint on how to solve the issue, or even an error message of what's wrong. - You can't deploy your app to a device without a
specor ayamlfile, even if you don't want to package it
Conclusion
I'd like Jolla to succeed.
And a very important aspect of success is that the developer experience of the platform should be as good as possible. The better it is, the more developers will come, and the more apps will be, thus more users will come too.
If anyone has more suggestions or weird examples or errors or things that could be improved, please don't hesitate to edit this post or add a comment.