A small update.
In order to make the api avaliable to crappy compilers, I've made some small
changes to the code in the last mail:
// For crappy compilers
// Fancy query definition
auto fancyQuery = AllResources
| Type("text")
Hi all,
I was MiA for some time now, sorry for that.
I've settled on a query-like API. There are too many different use-cases to
be covered by something overly specific.
Now, the API looks like this at the moment (just for the Query class, the
model-based part of the api will use the Query class
On Tuesday 21 October 2014 22:48:55 Vishesh Handa wrote:
>
> The reason I'm prodding so much is I'm scared of activities becoming this
> big central thing. I have a little bit of experience on working on a
well, they always were, at least in the workspace.
the thing is it's a feature done exactly
> Kicker currently uses Muon, which is part of the workspace.
> We can [...]
Yes, I would go for that, unless we really see that it is needed to be
accessible by kactivities data models.
Ch
On 22 October 2014 15:07, Vishesh Handa wrote:
>
> On Tue, Oct 21, 2014 at 11:35 PM, Eike Hein wrote:
> The not indexing the text of genome-data-for-blah.data because it
Ok, I was afraid it completely ignored those files - misunderstood a
sentence of yours then. Cool :)
On 22 October 2014 15:01, Vishesh Handa wrote:
>
>
> On Wed, Oct 22, 2014 at 11:47 AM, Ivan Čukić wrote:
>
>>
>>
>> Does this
On Tue, Oct 21, 2014 at 11:35 PM, Eike Hein wrote:
> As I recall, this was implemented inside Kickoff itself.
> I *think* it maintained a timestamped lists of new apps
> when discovering them as it build up the menu structure
> on startup or so ...
>
> I'm guessing something similar would be an a
On Wed, Oct 22, 2014 at 11:47 AM, Ivan Čukić wrote:
>
>
> Does this mean that baloo does not search file names at all?
>>
>>
>> I'm confused about your question. You'd initially asked "if baloo skips
>> indexing a file that is in an indexable folder - does it store any
>>
>
> So, I have a genome
> needs to be the store for / provider of that shared state,
> but it's one of the options on the table ..
One of the possibilities (if we choose to do it via kamd) is to have the
kamd plugin loaded on request - when there is a client that desires it.
The mechanism for that is already in place -
On 10/22/2014 11:43 AM, Ivan Čukić wrote:
If there is no other place where the new-app thingie is used, I'd leave
it inside the launcher. But, I am open to be convinced otherwise.
Hmm well, the thing is that it's a bit similar to all the
arguments for making favorites shared state (which seem
> The reason I'm prodding so much is I'm scared of activities
> becoming [...]
As before, everything that I'm working on related to activities supports
the one-activity-only workflow. I do not have the habit of forcing things
onto the user. (even the statistics thing can be disabled - globally, or
Does this mean that baloo does not search file names at all?
>
>
> I'm confused about your question. You'd initially asked "if baloo skips
> indexing a file that is in an indexable folder - does it store any
>
So, I have a genome data called 'genome-data-for-blah-o-blah.data'. It is a
textual file
> I'm guessing something similar would be an avenue to
> getting it back - KAMD could diff ksycoca scans, or
> react to ksycoca change signals, and slam newly-dis-
> covered apps as CREATED into its db ...?
While I do still think that a 'created' event type would be useful for some
things, I'm not
On 21.10.2014 22:48, Vishesh Handa wrote:
The purpose, I assumed, from Ivan's initial email was to "see how we can
use the usage statistics gathered by kactivitymanagerd". Not to - in
general collect ideas about usage tracking. The notes page also clearly
mentions activities.
Right - I should
On 21.10.2014 22:55, Vishesh Handa wrote:
I'm not sure how this would work -
How would kamd know about when an application has been created? Would it
be getting notified by the package manager or monitoring all of /usr/
itself? Maybe Ivan can chime in since he probably had an implementation
in
On Tue, Oct 21, 2014 at 6:42 PM, Ivan Čukić wrote:
> > No. It does store any info.
>
> Does this mean that baloo does not search file names at all?
I'm confused about your question. You'd initially asked "if baloo skips
indexing a file that is in an indexable folder - does it store any info
abo
On Tue, Oct 21, 2014 at 10:48 PM, Vishesh Handa wrote:
>
> So basically a filter on top of the global list of recently used
>> documents?
>>
>
> Yes - it was suggested a few times to subdivide Recent
> Documents into content type groups like text documents
> and videos to get to the goal more qu
On Tue, Oct 21, 2014 at 9:39 PM, Eike Hein wrote:
> Recently installed applications is also for Kicker,
> to mark new apps in the submenus. There are other
> ways to implement this, however Ivan suggested it
> could be done via KAMD by adding a new 'created' event
> and it seems to make sense.
>
On Tue, Oct 21, 2014 at 9:58 PM, Eike Hein wrote:
>
>
> On 10/21/2014 07:27 PM, Vishesh Handa wrote:
>
>> Who else?
>>
>
> Kicker. Ivan also has his Lancelot launcher in develop-
> ment as I understand it.
>
>
> Could you perhaps talk about possible workflows and how this would be
>> displayed t
On 10/21/2014 07:27 PM, Vishesh Handa wrote:
Who else?
Kicker. Ivan also has his Lancelot launcher in develop-
ment as I understand it.
Could you perhaps talk about possible workflows and how this would be
displayed to the user? I'm still quite skeptical about how useful a
global recently
All of the use cases I added to the note will be used
by either Kicker or the Task Manager (some by both),
using either an application or a file type (e.g.
recently used videos) as an entry point.
Kicker currently uses KRecentDocuments already. It's
OK, but of limited usefulness because it only
On Tuesday 21 October 2014 19:27:10 Vishesh Handa wrote:
> > The point is to have a generic thing that supports different variations on
> > the same tune. That is, a few different things need to know what was
> > opened
> > and when, and then you get a lot of side things that could benefit from it
On Tuesday 21 October 2014 18:17:09 Vishesh Handa wrote:
> > Most used (high usage score) documents by $application.
>
> I'm not too sure if anyone but the $application would use this list.
taskbar
--
Marco Martin
___
Plasma-devel mailing list
Plasma-
On Tuesday 21 October 2014 19:00:02 Ivan Čukić wrote:
> In this case, yes, every application does implement its recent documents
> mechanism and could implement the high scored ones etc. But, in that
> case,the workspace would have no idea about any of those - the tasks applet
> (or the launchers)
On Tue, Oct 21, 2014 at 7:00 PM, Ivan Čukić wrote:
> > Recently used applications across the entire system.
>>
>> Potential Use case: I can only see this being used in KRunner when
>> searching for applications.
>>
>
> And Kickoff etc. (not only when searching apps)
>
So Kickoff would be showing
On Tue, Oct 21, 2014 at 6:27 PM, Marco Martin wrote:
> that would definitely be less draining..
> there the problem would be that it would lose it as soon it gets moved
> across
> partitions right?
>
Yup. And reverse lookups are very very hard. You you can only do (url ->
id) not the other way a
>
> > Recently used applications across the entire system.
>
> Potential Use case: I can only see this being used in KRunner when
> searching for applications.
>
And Kickoff etc. (not only when searching apps)
> > Recently installed applications.
>
> Potential Use Case: Displaying it in Muon?
>
> No. It does store any info.
Does this mean that baloo does not search file names at all?
> The NTFS file system has something similar. It's called a USN Journal.
It's
> their solution to applications being able to see what changed when they
> weren't running or if they missed some events.
>
> I
> across partitions right?
And that we would not know the file's name anymore.
Anyhow, I think that this is more a question for kde-devel, not
plasma-devel. Maybe a wider audience for brainstorming on files could be
useful.
--
KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/
gpg key id: 85
On Tuesday 21 October 2014, Vishesh Handa wrote:
> > an id etc even if is not in an indexed folder? (i can imagine it not
> > scaling
> > well tough)
>
> I'm not too keen on doing this as we then need to track everything, and we
> all know how much inotify sucks.
>
> If we really want this, we c
On Tue, Oct 21, 2014 at 6:13 PM, Marco Martin wrote:
> > * The Baloo identifiers will only work for indexed files. Given that
> we're
> > not enforcing users to index everything (nor should we). We need a
> > different approach.
>
> could baloo implement some function to track a specific single f
Hey guys
On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić wrote:
> Hi all,
>
> As promised, starting a discussion on how we can use the usage statistics
> gathered by kactivitymanagerd (kamd in the rest of the text). And the
> design
> of the API to cover the use-cases.
>
> The point is to discuss al
On Monday 20 October 2014, Vishesh Handa wrote:
> On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić wrote:
> > 3. What will be needed
> >
> >
> > Integration with baloo. It will require patches on both sides if we are
> > to support all the use-cases without cross-queries. We will need
On Tue, Oct 21, 2014 at 11:22 AM, Ivan Čukić wrote:
> One thing to ask here is if baloo skips indexing a file that is in an
> indexable folder - does it store any info about the file (name, date etc.)
> or
> not?
>
No. It does store any info.
Still, baloo is not off the hook - if we want to det
On Monday 20 October 2014 17:24:02 Vishesh Handa wrote:
> On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić wrote:
> > 3. What will be needed
> >
> >
> > Integration with baloo. It will require patches on both sides if we are
to
> > support all the use-cases without cross-queries. We wi
On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić wrote:
>
> 3. What will be needed
>
>
> Integration with baloo. It will require patches on both sides if we are to
> support all the use-cases without cross-queries. We will need accessible
> file
> types via sqlite (on baloo side) and b
On Mon, Oct 20, 2014 at 4:53 PM, Ivan Čukić wrote:
> > One use case that we might want to consider is including email frequency
>
> > when sorting contacts.
>
>
> Well, I'd say sent e-mail frequency. I don't care that some person is
> spamming
>
> me often - I do care if I'm spamming them. :)
>
> One use case that we might want to consider is including email frequency
> when sorting contacts.
Well, I'd say sent e-mail frequency. I don't care that some person is
spamming
me often - I do care if I'm spamming them. :)
> What makes this very different from the rest is that the length of
On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić wrote:
> Hi all,
>
> As promised, starting a discussion on how we can use the usage statistics
> gathered by kactivitymanagerd (kamd in the rest of the text). And the
> design
> of the API to cover the use-cases.
>
> The point is to discuss all of this
> also, once what it can do and can't is explained well, the VDG can go crazy
> with ideas for taskbar/launchers
+1
> could the generic kpart patch that was at some point in kdelibs4 then
> removed be in kf5 kparts? would it work with current architecture?
I'm guessing it would work. Don't know
On Monday 13 October 2014, Ivan Čukić wrote:
> - Replacing the 'recent documents' with something more meaningful (kinda a
> subset of the previous item)
> - Tasks applet and launchers could show the list of important (or recent)
> documents opened in a specific application.
> - ** more advanced
Thanks for starting this :)
Just to recap, here's the stuff I can see myself needing from
the Task Manager and Kicker side:
* Recently used applications across the entire system.
* Most frequently used applications across the entire system.
* Recently installed applications.
* Recently used doc
Hi all,
As promised, starting a discussion on how we can use the usage statistics
gathered by kactivitymanagerd (kamd in the rest of the text). And the design
of the API to cover the use-cases.
The point is to discuss all of this and put the summaries on the etherpad page
at https://notes.kde.
42 matches
Mail list logo
