Page 7 of 12 « First 56 7 89 Last »
Reply
Thread Tools
neochapay is offline neochapay
2017-01-08 , 08:28
Posts: 60 | Thanked: 459 times | Joined on Jan 2017 @ Innopolis, Russia
#61
Project Name: Update Glacier-home
Author: Neochapay (Sergey Chupligin)
Brief description: Update code of glacier-home fix many errors and bugs:
Add internatialization
Add folders on applications grid
Fix lockcode work for new org.nemomobile.devicelock
Fix wallpaper fillmode on main and lock screens
Fix folderview

And many other little bugs

Category: Fixing/Updating

https://github.com/neochapay/glacier-home

And all commits merged in master https://github.com/nemomobile-ux/glacier-home
 

The Following 13 Users Say Thank You to neochapay For This Useful Post:
reinob is offline reinob
2017-01-08 , 10:25
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#62
Originally Posted by taixzo View Post
APK is not a second binary for SFOS. APK is a second binary for Jolla phones. Many people are running SFOS on Nexus, OnePlus, Fairphone etc - none of these phones have the Android compatibility layer, because it's not part of the OS, it's an add-on.
Exactly. Allowing APK would also imply allowing, say, MS-DOS programs because the N900 runs dosbox.

It is admittedly hard to define precisely what's inside the set and what's outside the set, but something like "native applications for maemo- or mer-based operating systems" should at least capture the intention.
 

The Following 7 Users Say Thank You to reinob For This Useful Post:
Feathers McGraw's Avatar
Feathers McGraw is offline Feathers McGraw
2017-01-08 , 12:02
Posts: 654 | Thanked: 2,368 times | Joined on Jul 2014 @ UK
#63
Originally Posted by reinob View Post
It is admittedly hard to define precisely what's inside the set and what's outside the set, but something like "native applications for maemo- or mer-based operating systems" should at least capture the intention.
I agree. However, just to muddy the waters I would argue that if projects like sfdroid could be made to work on all phones running libhybris based SFOS ports, then they should be allowed (but not apps running on sfdroid obviously).
 

The Following 7 Users Say Thank You to Feathers McGraw For This Useful Post:
klinglerware is offline klinglerware
2017-01-08 , 14:27
Posts: 459 | Thanked: 669 times | Joined on Sep 2007 @ The DMV
#64
Originally Posted by Feathers McGraw View Post
I agree. However, just to muddy the waters I would argue that if projects like sfdroid could be made to work on all phones running libhybris based SFOS ports, then they should be allowed (but not apps running on sfdroid obviously).
I agree with this. I think that work on the various SFOS adaptations, and sfdroid is of interest to many in the community. Projects that result in concrete capability advancements in this space would seem to be in the spirit of this competition.
 

The Following 7 Users Say Thank You to klinglerware For This Useful Post:
Ygriega is offline Ygriega
2017-01-11 , 21:53
Posts: 17 | Thanked: 107 times | Joined on Jan 2017 @ Berlin, Germany
#65
This is my first post to TMO and already my contribution to the Developer Regatta:

Project Name: Wunderfitz

Author: Sebastian J. Wolf

Brief description: Wunderfitz is a mobile dictionary application for offline use, including the Heinzelnisse Norwegian-German dictionary (heinzelnisse.info) and supporting dict.cc dictionary export files.

Category: Fixing/Updating

Screenshot(s):


Features/work to be judged: I started Wunderfitz mainly to learn C++ and Qt - and to have a fast and offline German-Norwegian dictionary as I'm currently learning Norwegian. After the initial publishing in the Jolla Store, I got more and more requests to add other languages as well, so I decided to support the import of dict.cc dictionary export files for the Developer Regatta. So the work to be judged is:
  • Import of dict.cc dictionaries
  • Offline usage of imported dictionaries
  • Search-as-you-type for both languages of the selected dictionary
  • UX improvements such as Copy to Clipboard, Reverse search for results - both available in context menu of a result item

Package name and where to find the app/repository:
I hope you find it useful!
Last edited by Ygriega; 2017-01-11 at 21:54. Reason: Formatting
 

The Following 18 Users Say Thank You to Ygriega For This Useful Post:
eson's Avatar
eson is offline eson
2017-01-12 , 05:32
Posts: 362 | Thanked: 1,373 times | Joined on Nov 2015 @ Sweden
#66
Originally Posted by Ygriega View Post
I hope you find it useful!
Very useful! Thanks!
No offense, but could you make it possible to remove the DE-NO dictionary? That is one, I know I'll never use.
 

The Following 3 Users Say Thank You to eson For This Useful Post:
nthn's Avatar
nthn is offline nthn
2017-01-12 , 12:13
Posts: 764 | Thanked: 2,888 times | Joined on Jun 2014
#67
The separate application for XMPP is a bad idea. What's the point in using Sailfish when all it does is copy Android where you need to have a separate application running for everything? I admire the effort, but it misses the point.
 

The Following 3 Users Say Thank You to nthn For This Useful Post:
Feathers McGraw's Avatar
Feathers McGraw is offline Feathers McGraw
2017-01-12 , 12:48
Posts: 654 | Thanked: 2,368 times | Joined on Jul 2014 @ UK
#68
Originally Posted by nthn View Post
The separate application for XMPP is a bad idea. What's the point in using Sailfish when all it does is copy Android where you need to have a separate application running for everything? I admire the effort, but it misses the point.
Having done quite a lot of research into XMPP libraries, there are some good reasons (the swiften library has better support for some XEPs that are important for mobile, and group chats with pictures etc.). Telepathy is still quite desktop-centric.

Having said that, I am working on a Telepathy based XMPP client (I started researching TelepathyQt in November, before I knew about the other apps that are in development). Aim is to implement things that are missing from jolla-messages like roster management first, then look at MUC etc.

Hopefully the two apps will compliment each other, and it won't harm to have more people with a good understanding of XEPs etc. within the community. Choice is a good thing.
 

The Following 13 Users Say Thank You to Feathers McGraw For This Useful Post:
Ygriega is offline Ygriega
2017-01-12 , 18:11
Posts: 17 | Thanked: 107 times | Joined on Jan 2017 @ Berlin, Germany
#69
Originally Posted by eson View Post
Very useful! Thanks!
No offense, but could you make it possible to remove the DE-NO dictionary? That is one, I know I'll never use.
Deletion of dictionaries is certainly something I will implement in the next release.

However, removing the Heinzelnisse DE-NO dictionary from the package would be more or less an incompatible change especially for the initial users. The alternative - to set SUID and then to allow the user to delete the DB on /usr/share... - would especially be a no-go for Jolla Harbour. There I'm not allowed (and that's good!) to tinker with areas where only root can do changes. So I would need to implement some kind of a migration path (e.g. online importer for Heinzelnisse) to mitigate this issue. Moreover, the memory footprint of the dictionary is rather low - about 6MB on the disk and close to zero in memory if you've not selected it (though I haven't measured that in detail I have to admit).

So in the end my precious free time (I have a 50+ hours/week day job and a private life) would be eaten up for something which is not a very big win. So personally, I would rather invest that time in other features/important bug fixes or even a new app. I still haven't touched most of Qt and I've begun to like it that much that I want to know more...
 

The Following 9 Users Say Thank You to Ygriega For This Useful Post:
nieldk is offline nieldk
2017-01-13 , 18:13
Posts: 1,290 | Thanked: 4,319 times | Joined on Oct 2014
#70
Originally Posted by Ygriega View Post
Deletion of dictionaries is certainly something I will implement in the next release.

However, removing the Heinzelnisse DE-NO dictionary from the package would be more or less an incompatible change especially for the initial users. The alternative - to set SUID and then to allow the user to delete the DB on /usr/share... - would especially be a no-go for Jolla Harbour. There I'm not allowed (and that's good!) to tinker with areas where only root can do changes. So I would need to implement some kind of a migration path (e.g. online importer for Heinzelnisse) to mitigate this issue. Moreover, the memory footprint of the dictionary is rather low - about 6MB on the disk and close to zero in memory if you've not selected it (though I haven't measured that in detail I have to admit).

So in the end my precious free time (I have a 50+ hours/week day job and a private life) would be eaten up for something which is not a very big win. So personally, I would rather invest that time in other features/important bug fixes or even a new app. I still haven't touched most of Qt and I've begun to like it that much that I want to know more...
you should relocate to /usr/local/.. and ensure ordinairy user have rights i guess
__________________
You can still support my work by donation - click here
 

The Following 4 Users Say Thank You to nieldk For This Useful Post:
Reply
Page 7 of 12 « First 56 7 89 Last »

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 19:36.

Contact Us - Home - Archive - Top