Revision history [back]

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast there.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent month for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this.

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast there.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent month for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this.this. HiHo @velox - your way to do it with libtag will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast there.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent month for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast there.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent month for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast there. in harbour.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent month for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

• your needs (and there are many...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast in harbour.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent month for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

• your needs (and there are many...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast in harbour.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent month months for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

• your needs (and there are many...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

@Jolla: I can see that I have 40 downloads from finland (version 1.12-ff0: 11). Hm, who is it...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast in harbour.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent months for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 posts in queue - not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

• your needs (and there are many...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

@Jolla: I can see that I have 40 downloads from finland (version 1.12-ff0: 11). Hm, who is it...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast in harbour.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent months for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 posts in queue - not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

• your needs (and there are many...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

@Jolla: I can see that I have 40 downloads from finland (version 1.12-ff0: 11). Hm, who is it...

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast in harbour.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)!IMHO)! Probably I am simply too stupid to do it right...

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent months for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 posts in queue - not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

• your needs (and there are many...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

@Jolla: I can see that I have 40 downloads from finland (version 1.12-ff0: 11). Hm, who is it...

@Jolla: from the point of restriction view the saving of opml and my backup tarball are illegal, so the actual version 1.11 should also be rejected.

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast in harbour.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)! Probably I am simply too stupid to do it right...

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent months for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 posts in queue - not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

• your needs (and there are many...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

@Jolla: I can see that I have 40 downloads from finland (version 1.12-ff0: 11). Hm, who is it...

@Jolla: from the point of restriction view the saving of opml and my backup tarball are illegal, so the actual version 1.11 should also be rejected.

This is a post for the problems I have in developing the real good application with sailfish and why there will be no post 1.11 version of podQast in harbour.

Before you further read it: podQast was my first real prog I put out to the community though I am implementing stuff for decades for my own and at work. Probably my demands for applications are wrong. Probably my thoughts are not right - it is my honorably own opinion (aka IMHO)! Probably I am simply too stupid to do it right...

You may figured out that podQast has a paragon app in the iOS world and I tried out how helpful the sailfishos infrastructure (sdk, harbour...) is to implement an equal application like in other mobile systems/infrastructures. When I look at the podQast wishlists in harbour, tmo (https://talk.maemo.org/showthread.php?p=1552198), and openrepos (https://openrepos.net/content/cy8aer/podqast), I found out that most of the wishes of the end users correspond to functionality in the paragon and by now not implemented in podQast. And now exactly these end user wishes are nearly not able to fullfill with the harbour rules.

The strain from the end users for basic features (mpris, bluetooth keys) let me convince to have a "Forbidden Fruits (!)" version on openrepos for these main functionality I would demand for my own. But now I am at the point where main functionality is not implementable with the restrictions of harbour anymore. And these special wishes are the main blocker for many multimedia applications to go to harbour.

It is funny that in the A- and G-world this functionalitiy (end-users: they may want to have money for these special features!!!) is possible although an iOS-platform device is really restricted. I tried for months to let the wonder happen but the dbus interfaces provided in QML are not able to make an mpris implementation by my own, I do not know how the bluetooth key stuff is connected to dbus anyways. But the existing - and mostly working but in parts not well-kept - libraries are not allowed in harbour.

The point why I do not provide more features in harbour yet are the restrictions to files/file handling for an application which are not corresponding to the end user's wish.

You are only (and only!) allowed to save data in directories provided by the XDG environment system (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). That makes sense for configuration data and caching stuff. But the handling of files provided to the user or fetched from the user is open with this restriction.

Wish: The user wants to have podcast posts provided to have them copied away or used by other applications (I guess it is talefish - ahem this is also not available on harbour by restrictions). You need a directory for this interchange. It is file data no config, cache... But I am not allowed to save files (here it is a symbolic link) to a normal user's directory. Yes, this may change, the user may change, ok. But there is no Environment variable to have a home-root outside the .local dot-dir for these use cases. What can I now do: Implement it in the XDG_HOME_DATA directory and make a documentation for the user how to symlink it into a useful directory? Really? I want to create cool software I do not want to help everyone with no unix capacities to create symlinks.

Wish: Sideloading of audio files into the podQast playlist. Same problem but the other way round. Plus: missing central id3/ogginfo infrastructure. I am able to do this in the next days but I spent months for having a nice library for identifying the audio file info - and may have the same problems like identifying feeds. It will double my development and bug fixing times because of this. HiHo @velox - your way to do it with libtag in talefish will never let you into harbour ;-)

Another thing: because of the dot-file thingie all data of my multimedia application are stored outside the view of the end user (she does not know anything about dotfiles and needs to opt in dotfiles in file browsers...). For my setup with 20 podcasts and about 10 posts in queue - not persistant favorites (feature of 1.12) I have: 53M configuration, 31M icons, 260M audio files.

sometimes the audio files near 1G. If you use the new favorites feature the the storage of audio files will increase intensively. But the end-user only sees an decreasing system drive capacity. And then there will be the point where 16G systems will not upgrade anymore because of too less storage. At the days of gpodder I just moved the gpodder .local stuff to my sdcard by hand (and with a terminal). I thought about such a functionality from inside podQast. But this is also not allowed. I can only restrict the end user to download not more than x GB by option and need to dynamically look how much space I have to re-download stuff. Bummer.

Ok, enough screaming: For further implementing this special application in harbour the infrastructure needs to offer:

• multimedia connectors to start screen (mpris), bluetooth
• better file handling (file picker for directories would be nice)

For other applicatoins (wishlist - this is a wiki...)

• your needs (and there are many...)

Sorry about this rant but I often see posts where developers stumble over restrictions and resignate. I would not say that I am a very good developer but at some point the frustration wins. You may be able to create concurrent products like in in the G- or A- world but you need more help on the SDK side for this, like libraries and better thinking of the definition of restrictions. Otherwise Sailfish has no chance to really grow from the application side.

Of course: See you on openrepos...

@Jolla: I can see that I have 40 downloads from finland (version 1.12-ff0: 11). Hm, who is it...

@Jolla: from the point of restriction view the saving of opml and my backup tarball are illegal, so the actual version 1.11 should also be rejected.

[Update] I was so silly to have a directly coded "/home/nemo" in my source - you need to hide it from the test engine...