How about discussing which new features we should / could add on KISS? (It's not exactly a roadmap)
I could start the list with these:
Plugin support is a nice idea, in my opinion. I would also like for the user to be able to choose their preferred color for the notification bar, including a transparency gradient.
Another useful feature would be backup and restore of shortcuts, tags etc etc
I updated the list with your comments
Actually I have a non-feature roadmap item (highly related to the plugin thing): Simplify and isolate the provider loading code.
Instead of the current provider-specific-stuff-everywhere model we should throw each provider into it's own detached, zero-dependecies-on-the-rest-of-KISS Java namespace that implements a single (and hopefully relatively simple) Java interface that the UI then talks with. Exposing such an Interface over Binder/AIDL for other apps would then be a (comparatively) trivial task. In particular this would introduce a clean separation between front-end and back-end code, by letting the back-end (providers) return its results in simple and easy-to-serialize objects (also established as Pojos) that tell the front-end (UI code): This result shall be rendered as an app/toggle/whatever with the following properties… It would then be up to the UI code to "make it happen" and render the result however it thinks is best.
Third-party apps (communicating through Binder) would not be able to define new Pojo result types in this model, but they would at least be able expose things like "dynamic shortcuts" or "app-specific toggles" already provide huge benefits over the current implementation (i.e.: none).
Sorry if the above is a bit off-topic for this simple wishlist/roadmap, but I had to write this down somewhere because I believe it would a comparatively simple and mostly iterative way forward on the "infinite wishlist item" of external plugin support.
I ve been using kiss only for years. Mainly because i am used to app called alfred on osx which is very similar. They have keyword plugins here for inspiration http://www.packal.org/
Now what i miss all the time from alfred:
Also the must is ability to put circle for allaps/favs on the right side. I have big phone and as righthanded i cant reach it. So i never use it. I would use it sometimes if it switched positions with settings dots (you dont open settings very often).
Anyways thx for all the work. Ive been spreading KISS awesomness everywhere :)
Unit coversion and right side circle sound nice.
Money conversion is tricky, you need to pull the exchange rates from somewhere on the internet.
@licaon-kter You are right that for money conversion you need rates but there are ways to go around it (cashing it and check once a day when on wifi). I would never expect exact conversion anyway.
I know this is overkill but it would be nice to leave that to community. Some sort of plugins that would allow to run user made scripts? You could interface with any API you use. Its the case with forementioned Alfred - its like smarter terminal.
A while ago I tried this, it was a test using the wit.ai API. Maybe it's useful if someone wants to try something for the currency converter
@krisis
Actually, we were talking about a plugin system on some issue. We still have to figure out how to implement it, though.
Internet access is not something that we would like to add at the moment . If we go for the plugins idea then it would be nice if plugins could request additional permissions
I tried typing an equation and also ran a dollar to euro conversion. If Google is your search provider set, the answer comes right up when your browser opens.
@a220 I think one of the points of using open-source software is to get away from google. I dont use google - especialy on phone. I asume there will be lot of people like that. Besides why to make requests for simple math?
Other search engines have units/math/money stuff too, so yeah I could see this left out for them to handle.
WolframAlpha as provider FTW! :)
The math feature @krisak mentioned is already implemented (at least 2 times). I've been using the implementation by @pinusc (see here) for some months now. Had no issues so far. Maybe we could just include this (until we've got a plugin architecture ready)?
I think the problem of the math feature was that the used library added a lot of KBs
Show Date / Time on the Homescreen
Where would you put those?
Maybe in the search bar? Possibly as a rotating text "Search apps, contacts... | Feb 2016, 05. 09:28"?
I think a nice addition would be to have results from the calendar when inputting a date or some keywords such as today, tomorrow, week, etc
Some tasker support would be nice. Stuff this woould allow tasker to do would be toggling web search proviederwhen you have no internet connectoin. Toggling contact search when in do not disturb.
One thing I was able to do with other launchers can't "or don't know how" is use tasker to make a icon to trigger a task, for example start a laundry timer in the notifcation bar when i click an icon. I did this by making a custom shortcut to run a task in tasker
Make kiss use a specific keyboard. I like hackers keyboard for this app but like a keyboard with swype on stuff like texting. right now i use tasker to switch automaticlly in certian apps
sugestions for other apps to pair this app up with to make a nicer experiance. klwp to show useful information that some people used widgets for. Material Design Tasker Plugin + tasker could make a sidebar for kiss or use a fab button -- floating button that you can press. hackers keyboard is a nice keyboard to use with this app etc
+1 to the additional screen for widgets (my only drawback to be my default launcher)
Just want to let you know:
I currently have some code in the pipeline that should get us a long way towards a sane provider extension API that other apps could actually consume. The code isn't done yet, but can be made public if there is interest. I'll provide more details later, but the basic concept is to have providers submit all the relevant information about how items should be rendered up-front, then have the UI code just interpret that data to build an appropriate widget tree. Most importantly all submit data objects have been designed to work over AIDL from the start.
@alexander255 Is your code available somewhere? I was about to start thinking about/playing with plugins, but if you've already done some work on it then there's no point me duplicating that effort.
@czan Sorry for the belated reply I had hoped I would have something semi-stable to show by now, but that is unfortunately not the case. There is still at least 2 major refactorings before all the pieces fall into place.
Anyway, I've pushed the current working set here, but it's by no means complete yet and history is likely to change:
https://github.com/alexander255/kiss-launcher/tree/refactor
Just so you know what I've been up to 🙂
Hey folks!
There were interesting discussions in this issue, but now the conversation kinda stopped; I'm closing this issue, feel free to reopen new issues (one per feature please)
just wanted to point out that backup already have it's own issue #1031
Most helpful comment
Actually I have a non-feature roadmap item (highly related to the plugin thing): Simplify and isolate the provider loading code.
Instead of the current provider-specific-stuff-everywhere model we should throw each provider into it's own detached, zero-dependecies-on-the-rest-of-KISS Java namespace that implements a single (and hopefully relatively simple) Java interface that the UI then talks with. Exposing such an Interface over Binder/AIDL for other apps would then be a (comparatively) trivial task. In particular this would introduce a clean separation between front-end and back-end code, by letting the back-end (providers) return its results in simple and easy-to-serialize objects (also established as
Pojos) that tell the front-end (UI code): This result shall be rendered as an app/toggle/whatever with the following properties… It would then be up to the UI code to "make it happen" and render the result however it thinks is best.Third-party apps (communicating through Binder) would not be able to define new
Pojoresult types in this model, but they would at least be able expose things like "dynamic shortcuts" or "app-specific toggles" already provide huge benefits over the current implementation (i.e.: none).Sorry if the above is a bit off-topic for this simple wishlist/roadmap, but I had to write this down somewhere because I believe it would a comparatively simple and mostly iterative way forward on the "infinite wishlist item" of external plugin support.