Reply
Thread Tools
Posts: 285 | Thanked: 1,900 times | Joined on Feb 2010
#71
Disconnected the charger this morning at 9 am. Currently my battery has 57% left. I have been playing clash of clans, some surfing and tinkering around. Mostly wlan, but also an hour in 3G. One reboot. So, not that bad IMO.
 
Posts: 130 | Thanked: 120 times | Joined on Feb 2012 @ Vienna, Austria
#72
I had fixed the OH bug with some tin foil, but battery feels even better after the upgrade. haven't used mine too much (few calls, texts, the usual without extensively playing around with it) today and was on wlan mostly - still 88%

I am still very impressed by battery runtime.
 

The Following User Says Thank You to dommau For This Useful Post:
tissot's Avatar
Posts: 1,839 | Thanked: 2,432 times | Joined on May 2009
#73
Originally Posted by mariusmssj View Post
So with the nfc bug fixed anyone noticed a change in battery?
Oh absolutely.
My Jolla would never last for a day previously. Was last charged when the update came (around 24 hours ago) and I have 77% of my battery left.

Last edited by tissot; 2014-02-02 at 19:15.
 
Posts: 114 | Thanked: 397 times | Joined on Sep 2013
#74
No one seems to have noticed this change: If I am using an app and the screen goes dark, I can double tap the screen right after it and the screen hasn´t gone to the lock screen but shows the app I was using. I really, really like this. =)
 

The Following 20 Users Say Thank You to Tujutzki For This Useful Post:
Posts: 951 | Thanked: 2,344 times | Joined on Jan 2012 @ UK
#75
Originally Posted by Tujutzki View Post
No one seems to have noticed this change: If I am using an app and the screen goes dark, I can double tap the screen right after it and the screen hasn´t gone to the lock screen but shows the app I was using. I really, really like this. =)
Oh yeah I noticed that as well, really welcome change. Feels weird though need to get used to it.
 
thp's Avatar
Posts: 1,391 | Thanked: 4,272 times | Joined on Sep 2007 @ Vienna, Austria
#76
(long post ahead)

For those affected by the libsailfishapp storage location change, some explanations (this might be helpful for developers to fix their apps and/or for users to better understand why the breakage happened):

First, the commit that changed default behavior is 3febb7a22 in libsailfishapp.

What this does is set the application name and organization name (and organization domain). For developers that set the application name and organization name manually, this change didn't affect anything. Previously, in most cases, the application name was set to "$APPNAME" (harbour-...) and the organization name was empty. After the change, both organization name and application name are set to $APPNAME (harbour-...).

Now, we want to align with Desktop Linux and upstream Qt API as much as possible where it makes sense - this eases the porting effort required for cross-platform developers. For Desktop Linux alignment, the XDG Base Directory Specification is the way to go. For upstream Qt API, the relevant APIs are QStandardPaths, QSettings and Qt Quick Local Storage.

Because Qt has this notion of "organization" and "application", and because application developers that develop cross-platform application and might have a good reason to use "setApplicationName()" to set the name of their application to something not equal to $APPNAME (harbour-...), it was decided to use the organization name facility of Qt to place all files into $APPNAME (harbour-...) below the configuration directories (as is required by Harbour rules). When the developer doesn't set the application name manually, it will default to $APPNAME (harbour-...) - as has already been the case before. Also, this is important for pure QML (without C++ code, i.e. using "sailfish-qml" launcher) applications that are boosted, as otherwise files might end up in some strange mapplauncherd/booster directory, which isn't at all what you would expect (the directory name would be random at every invocation).
  • How do I fix my application to use the right path? For a quick fix if you want your users to continue using your app, you can set the organization name to the empty string, which makes the behavior just like before the update. Please note that if you are using any Qt-based third party libraries, you might have to make sure they are calculating their paths correctly. If you make this change, please note that users might have installed your application after updating to 1.0.3.8, so add some additional code to move files from the new (with organization name set) path to the old one. Alternatively, you can move files from the old path to the new path on application startup if the old path exists and the new path doesn't.
  • How do I (as a user) make sure old application data is accessible to the application after the update? The easiest way is probably to create a symlink named "$APPNAME" pointing to "." in ~/.config/$APPNAME, e.g. "ln -sf . ~/.config/$APPNAME/$APPNAME" - this will work with both the old and the new system.
  • Why can't we just hardcode /home/nemo/.config/MyCoolApp and be done with it? In the future, there might be multiple users, you might have a per-TOH profile (so you can e.g. have your RSS reader show different content depending whether you have the work TOH or the party TOH on) and there might be additional sandboxing measures (so app A can't access app B's users data without app B allowing that). Also, making sure that these paths are predictable (=the system can derive from the $APPNAME the storage location of data/config/cache files) will make sure that your application data can be backed up and restored by the backup application, and that the user will at one point be able to see per-app disk usage. These are just ideas, and obviously not implemented yet, but making developers aware that they should use XDG properly and not depend on some assumptions will make new platform features easier down the road for which the application developers will not have to add Sailfish-specific code (e.g. backup app integration, clearing data on package uninstall, etc..).

Too bad this caused breakage for some users and some apps, but hopefully the apps will be fixed. In general, I think it's better to cause minor breakage in the beta phase of the OS to make sure the architecture is better down the road (and enables nice features like some of the ideas mentioned above) than to either carry along bad design decisions and/or spend time (not only implementing, but also testing all the available Harbour apps [on both the old version and then the new version] - while still missing apps that are widely used but not available on Harbour) on adding special-casing code for applications that haven't set their data paths manually.

There shouldn't be any other breakage in this area in the upcoming updates, and such breakages should definitely not happen anymore once the beta phase is over.
 

The Following 32 Users Say Thank You to thp For This Useful Post:
Posts: 1,746 | Thanked: 1,832 times | Joined on Dec 2010
#77
so the reboot loops seem and issue with btrfs, even if you can't use a recovery option, can't it be repaired by mounting on a linux box and attempting with fix with a disk utility?
 
Posts: 337 | Thanked: 891 times | Joined on Jul 2012 @ Royaume Uni.
#78
Thank you for the explanation thp, my only quibble with the update is that Jolla should have put some sort of disclaimer on the update saying that it may possibly cause an issue.
 

The Following User Says Thank You to NokiaFanatic For This Useful Post:
Posts: 197 | Thanked: 65 times | Joined on Jul 2011
#79
Originally Posted by NokiaFanatic View Post
Thank you for the explanation thp, my only quibble with the update is that Jolla should have put some sort of disclaimer on the update saying that it may possibly cause an issue.
True, this way is not good.

some thoughts on update 1.0.3.8, Naamankajärvi
- Pinch to zoom support in Camera viewfinder
# not really usable feature
- Clearly distinguish Android apps from native apps in Store
# not this way, maybe a better fix would have been with sorting
- Fixes "account needs update" messages displayed for still-authenticated accounts
# if this relates to google accounts asking to sign in, not fixed at all, still happens.
- the change in displaying notifications
# This is so weird. From what I undersood, apps have to define whether they want to have notification on locksreen and andro-apps not having that possibility at all. Why to weaken the use of andro-side :| Realtime-notifications-easily-on-sight-and-access = one of the most important features imo.
-"Losing" the UserData
# yeah , "poweruser" restores easily...
+
- this update still didnt fix the gallery bug with images (taken before latest updates) not showing properly in gallery. Well, so minor thing, never will be fixed officially - cos easy to fix by urself.

Good things are the battery usage and increasing landscape-orientation existence.
__________________
N900->Galaxy S->N9->Jolla/Lumia625
 
thp's Avatar
Posts: 1,391 | Thanked: 4,272 times | Joined on Sep 2007 @ Vienna, Austria
#80
Originally Posted by NokiaFanatic View Post
my only quibble with the update is that Jolla should have put some sort of disclaimer on the update saying that it may possibly cause an issue.
Yes, a mention in the release notes would have been good. I'll make sure that if we have a similar libsailfishapp change in the future, it will be mentioned in the release notes (and ideally we don't cause breakage at all...). Thanks for the feedback!
 

The Following 5 Users Say Thank You to thp For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 12:45.