Le jeudi 22 novembre 2012 13:29:06 Aaron J. Seigo a écrit :
Homerun AbstractSource class is not a model. It inherits from QObject and
provide virtual methods to create models. A source must implement at
least:
QAbstractItemModel *createModelFromConfigGroup(const KConfigGroup
group)
Le mercredi 21 novembre 2012 20:52:30 Marco Martin a écrit :
On Wednesday 21 November 2012, Aurélien Gâteau wrote:
Trying to map the way sources work to runners, instead of having a runner
calling RunnerContext::addMatches(), a runner would have a createModel()
method which would be called
On Wednesday, November 21, 2012 13:57:10 Aurélien Gâteau wrote:
Le mardi 20 novembre 2012 20:16:17 Aaron J. Seigo a écrit :
the question is which of the following makes sense:
* AbstractRunner should be a model (BIC)
* AbstractRunner should export a model (SC BC)
* RunnertContext
Le mardi 20 novembre 2012 20:16:17 Aaron J. Seigo a écrit :
On Tuesday, November 20, 2012 18:12:47 Aurélien Gâteau wrote:
First, I am convinced using Qt models is the right API design for Homerun.
I
nobody is saying don't use Qt models in homerun.
My mistake. Should have written Qt models
On Wednesday 21 November 2012, Aurélien Gâteau wrote:
Trying to map the way sources work to runners, instead of having a runner
calling RunnerContext::addMatches(), a runner would have a createModel()
method which would be called by RunnerContext or RunnerManager to reach the
runner data.
Spent yesterday evening trying to think about this topic from all edges.
First, I am convinced using Qt models is the right API design for Homerun. I
have a very hard time giving up on them for the sake of not breaking source
compatibility, to the point where I think it is better to do a clean
On Tuesday, November 20, 2012 18:12:47 Aurélien Gâteau wrote:
First, I am convinced using Qt models is the right API design for Homerun. I
nobody is saying don't use Qt models in homerun.
the question is which of the following makes sense:
* AbstractRunner should be a model (BIC)
*
Le vendredi 16 novembre 2012 18:16:12 Marco Martin a écrit :
Sources features missing in Runners:
- model-based = more QML friendly
I still think that wrapped in a model or not is a detail.
still don't see what advantages would bring the api being a model, rather a
model being a client?
On Monday, November 19, 2012 14:58:40 Aurélien Gâteau wrote:
Thinking a bit more about it, what Homerun needs is to know if a result can
be dived into instead of opened with an application. I think this does not
necessarily means KRunner behavior must change: as long as the information
is
Le lundi 19 novembre 2012 14:58:40 Aurélien Gâteau a écrit :
Le vendredi 16 novembre 2012 18:16:12 Marco Martin a écrit :
Sources features missing in Runners:
- model-based = more QML friendly
I still think that wrapped in a model or not is a detail.
still don't see what advantages
Le samedi 17 novembre 2012 12:56:13 Aaron J. Seigo a écrit :
On Friday, November 16, 2012 17:04:04 Aurélien Gâteau wrote:
A preliminary subject is API compatibility: I don't think it is possible
to extend the current AbstractRunner interface in a BC way to meet our
needs. Would you be ready
On Monday, November 19, 2012 15:31:46 Aurélien Gâteau wrote:
Le samedi 17 novembre 2012 12:56:13 Aaron J. Seigo a écrit :
On Friday, November 16, 2012 17:04:04 Aurélien Gâteau wrote:
Sources features missing in Runners:
- model-based = more QML friendly
as with Marco, i don't see any
On Friday, November 16, 2012 17:04:04 Aurélien Gâteau wrote:
A preliminary subject is API compatibility: I don't think it is possible
to extend the current AbstractRunner interface in a BC way to meet our
needs. Would you be ready to create a new runner interface?
This would require:
-
On Friday, November 16, 2012 13:36:59 Luiz Romário Santana Rios wrote:
Beyond that, I think it would be nice if runners were turned into a
library (something like librunner) so that other applications can
benefit from it.
rekonq (example you used) can't use libplasma? if not, please describe
Just my 2 cents on the matter. Feel free to ignore me.
2012/11/16 Aurélien Gâteau agat...@kde.org:
A preliminary subject is API compatibility: I don't think it is possible
to extend the current AbstractRunner interface in a BC way to meet our
needs. Would you be ready to create a new runner
On Friday 16 November 2012, Luiz Romário Santana Rios wrote:
- Implementing an adapter to load old AbstractRunner-based runners
- Porting KRunner to use AbstractRunner2 and the adapter
- Progressively porting runners shipped in KDE SC to AbstractRunner2
brainstorm from=someone who dug
On Friday 16 November 2012, Aurélien Gâteau wrote:
This would require:
- Defining and implementing this new interface (let's call it
AbstractRunner2 for now)
- Implementing an adapter to load old AbstractRunner-based runners
- Porting KRunner to use AbstractRunner2 and the adapter
-
2012/11/16 Marco Martin notm...@gmail.com:
On Friday 16 November 2012, Luiz Romário Santana Rios wrote:
- Implementing an adapter to load old AbstractRunner-based runners
- Porting KRunner to use AbstractRunner2 and the adapter
- Progressively porting runners shipped in KDE SC to
ehm.. it is
So, it's in libplasma, I assume.
Yes, though IMO it is generic enough to warrant breaking out of plasma into a
separate library. (though, again, I'm a bit overzealous when library
modularization is concerned :) )
Cheerio,
Ivan
--
So much complexity in software comes from
- can update matches
- standardized favoriteIds
what would have more than mimedata?
(would still not require all runners to be bookmarkable, don't really want
to have a bookmark of the result of the query 1+1=)
Ths idea of mimedata support was made exactly for this, and for the ability
20 matches
Mail list logo
