Re: Feature Proposal: finding and rediscovering shared links
On Wed, May 9, 2012 at 11:51 AM, Allan Day wrote: > Seif Lotfy wrote: > > On Wed, May 9, 2012 at 11:25 AM, Allan Day wrote: > >> > >> Seif Lotfy wrote: > >> > I created a new wiki page for this. Hylke and Garrett have been > helping > >> > out > >> > on the idea and the design. > >> > > >> > > >> > > https://live.gnome.org/ThreePointFive/Features/FindingAndRediscoveringSharedLinks > >> > >> I'm confused. Your original proposal for this feature was to add > >> functionality to Web or Contacts. Now you are talking about a new > >> application. What exactly are you proposing? > ... > > I would like to have the feature there in any way standalone or > integrated. > > Hylke thought it would make sense to have it as a standalone > application, so > > he approached the designs as a standalone. I am ok with both. > > > > Can you elaborate why a standalone application might not be a good idea? > > (not that you claimed it, but I am just assuming here). What is required > to > > consider is whether to have this integrated or stand-alone? There might > be > > good reasons for both. > > A standalone application is totally fine, in my opinion. I don't think > a shared links application belongs in the core though (in which case > you don't need to propose it). > > > I currently don't see this feature integrated into contacts or chat > > honestly. If it is to be integrated in an application then it should be > Web. > > My reasoning behind this is that one uses "Web" to browse websites. And > the > > queue feature is already planned and approved by the design team. So > having > > something to populate the queue makes more sense since it is a central > place > > to look for links. Instead of going to contacts or to chat to look for > > links. > > As I've already said, I think this could make sense in contacts (as > part of a 'related stuff' feature) or in chat (perhaps as a > conversation filter). Remember - people look for things in the last > place they saw them. Related stuff is a good solution, but I fail to see how it would help me find links that were sent to me, without knowing exactly who sent it. Example: you remember one of the designers sent you a link but you can't remember who. Wouldn't a dedicated view with links you received that also show a nice preview would help out? Shouldn't the view be dedicated and globally encapsulate all the links your received from contacts? I think this feature in Web would allow seamless browsing without having to open "contacts" or "chat" to find the links that were sent. For me it is much easier to remove things to the queue than adding stuff. So personally having my queue populated for me, would make my life much much easier. I agree that people look for things in the last place they saw them, yet people need to option to search and explore if they can't find what they are looking for. We have Documents to aggregate all the documents on the local drives as well as the cloud. Why not have Web aggregate all the links that are being sent to me in the queue or a new queue? Cheers Seif Allan > -- > IRC: aday on irc.gnome.org > Blog: http://afaikblog.wordpress.com/ > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: finding and rediscovering shared links
On Wed, May 9, 2012 at 11:45 AM, Bastien Nocera wrote: > On Fri, 2012-05-04 at 14:13 -0500, Federico Mena Quintero wrote: > > On Thu, 2012-04-19 at 15:48 +0100, Martyn Russell wrote: > > > > > Back when I was working on Gossip, I had a "links" tab in the chat > > > log/history for exactly this reason. I frequently dig out old links. > > > > > > The most important things are: > > > > > > - The link > > > - Who sent it > > > - What medium > > > - When > > > > I would find this REALLY useful! > > For me, something mining the chat logs for links would be absolutely > useless. My shared links come from Facebook, Twitter or IRC. > While I agree with you that shared links come from twitter and facebook mostly. Doesn't IRC count as a chat log? Correct me if I am wrong, but usually when I share a link via social network it is not the same as sharing a link via IM. Sharing via IM is more personal IMHO. In my personal case I don't go through links shared with me via Facebook or Twitter since mostly it is just spam. Links that are shared with me directly are more important for me. > > Whatever system we use, we'd need to be able to remember attribution: > > http://getpocket.com/blog/2011/02/version-2-4-for-ios-login-support-tweet-attribution-and-more/ > > > I have a "To read" bookmarks folder in Firefox, which is full of crap > > which I haven't bothered to delete after viewing. > > http://getpocket.com > > Or Instapaper. > > > It's just so much > > work to maintain such a list by hand that I don't bother. And yet, > > there are interesting things there, which would be much more useful if > > they had information of how I had acquired them - who sent them to me, > > etc. > > > > +1 for this feature. > > It needs to also remember which "post" the link was sent in so I can > attribute or comment properly. > I agree here. Remembering the context of the link is important. > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: finding and rediscovering shared links
On Wed, May 9, 2012 at 11:25 AM, Allan Day wrote: > Seif Lotfy wrote: > > I created a new wiki page for this. Hylke and Garrett have been helping > out > > on the idea and the design. > > > > > https://live.gnome.org/ThreePointFive/Features/FindingAndRediscoveringSharedLinks > > I'm confused. Your original proposal for this feature was to add > functionality to Web or Contacts. Now you are talking about a new > application. What exactly are you proposing? > > Allan > -- > IRC: aday on irc.gnome.org > Blog: http://afaikblog.wordpress.com/ > I would like to have the feature there in any way standalone or integrated. Hylke thought it would make sense to have it as a standalone application, so he approached the designs as a standalone. I am ok with both. Can you elaborate why a standalone application might not be a good idea? (not that you claimed it, but I am just assuming here). What is required to consider is whether to have this integrated or stand-alone? There might be good reasons for both. I currently don't see this feature integrated into contacts or chat honestly. If it is to be integrated in an application then it should be Web. My reasoning behind this is that one uses "Web" to browse websites. And the queue feature is already planned and approved by the design team. So having something to populate the queue makes more sense since it is a central place to look for links. Instead of going to contacts or to chat to look for links. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: finding and rediscovering shared links
I created a new wiki page for this. Hylke and Garrett have been helping out on the idea and the design. https://live.gnome.org/ThreePointFive/Features/FindingAndRediscoveringSharedLinks On Fri, May 4, 2012 at 9:13 PM, Federico Mena Quintero wrote: > On Thu, 2012-04-19 at 15:48 +0100, Martyn Russell wrote: > > > Back when I was working on Gossip, I had a "links" tab in the chat > > log/history for exactly this reason. I frequently dig out old links. > > > > The most important things are: > > > > - The link > > - Who sent it > > - What medium > > - When > > I would find this REALLY useful! > > I have a "To read" bookmarks folder in Firefox, which is full of crap > which I haven't bothered to delete after viewing. It's just so much > work to maintain such a list by hand that I don't bother. And yet, > there are interesting things there, which would be much more useful if > they had information of how I had acquired them - who sent them to me, > etc. > > +1 for this feature. > > Federico > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
I am happy Allan drafted the problem thoroughly and and also provided initial steps that could solve it. Well done. On Wed, Apr 25, 2012 at 7:45 PM, Karen Sandler wrote: > On Wed, April 25, 2012 9:27 am, Allan Day wrote: > > Echoing what Brian said, I like these suggestions for improvement! Are > there any that we can turn into concrete initiatives that we can organize > soon and perhaps fundraise for? Or build some initiatives for GUADEC? I > include a few more detailed questions below along these lines. > > > It is important to recognise that improving the state of design in > > GNOME isn’t just the responsibility of designers. There are things > > that all of us can do to help - from the release team and maintainers, > > to individual developers and community advocates. Here are some of my > > ideas for things that all of us can do to make design work more > > effectively and harmoniously as a part of GNOME: > > > > * a more rigorous (and better documented) feature proposal process > > I think there's some confusion here - you're not talking about purely > technical proposals here too, are you? I assume this is more focused on > anything that interfaces with any elements of design... I think Karen raises a good point here. I think there should be 2 kind of proposals. - A feature proposal: Where a feature is discussed and the technologies needed for it are decided, if the design team thinks the feature is not good then an detailed explanation would help. Also if the feature is a not accepted then there is no need to discuss the technology. - A technical proposal: Where libraries or services that could optimize performance/maintenance or prove to be beneficial in the future for existing modules can be suggested to be used. Technical proposals should not include any features, else it is a feature proposal. > * new tools for displaying and discussing designs, such as something > > like Dribble or Design Hub > > * a process for resolving design disagreements - perhaps maintainers > > or the release team could mediate if a dispute seems intractable? > > I think we should definitely explore this more, it goes hand in hand with > the other suggestions below - helping to stop bad behavior, soothing > ruffled feathers and communicating better. > > > * better communications about where GNOME is going and what the > > project is trying to achieve > > * some kind of active community management role to help soothe ruffled > > feathers > I would like to propose that we contact the people at KDE, since they already formed a community task force that manages and handles day to day disputes and work on improving communication in the community in a professional manner. AFAIK (I might be mistaken) they were given some negotiation seminar during DS 2011. > > * advertised designer playgrounds and discussion areas (for people > > wanting to stretch their design wings) > > * tackle bad behaviour across the project in a more proactive manner > > (will ensure that disagreements don’t get out of hand) > > * micro release-cycles in which new features are advertised, completed > > and tested > > * better testing facilities so people can test and give feedback on UX > > changes before release time > > What would this entail? This sounds like it could be incredibly helpful if > we could find the resources for it. > > > * keep a running list of design tasks that are appropriate for newcomers > > * work to prevent design disputes - ensure early informal contact > > between designers and developers at the beginning of feature > > initiatives > > > > So there are lots of ways that we can do design better as a community, > > and contributors on this list can all play a part in helping to make > > us to be even more successful in this regard. It will take actions as > > well as words to move forward, of course - if you want to help, or > > have your own ideas, just get in touch. > > thanks, Allan! I'm glad we're having these discussions and hope that we > can find ways for the Foundation to help too. > > karen > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > Thanks Allan for taking the time to detail the problem as much as possible. It is nice to have this discussion going in a peaceful manner. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, Apr 24, 2012 at 8:39 PM, Andre Klapper wrote: > On Tue, 2012-04-24 at 16:11 +0100, Bastien Nocera wrote: > > --8<-- > > From: Maître D' > > Subject: Spitting in the soup > > > > The kitchen staff IS NOT welcome to: > > > > * Spit in the soup > > --8<-- > > > > "I didn't say you spat in the soup" > > Correct - nobody stated so far that anybody spat in the soup. > > As you already brought up "Assume people mean well" from GNOME's code of > conduct in your initial response, this can also be applied to your own > assumptions when you try to intrepret things between the lines. > > Plus even if the form of bringing up an important problem might > sometimes be questionable, I still prefer this to not bringing up the > problem at all. And there is a problem in the GNOME community. > Exactly. I couldn't agree more right now. Again the fact that this thread is came up means that there is a problem. And as we can see both designers and developers are not happy. Ignoring the problem, going offline to get work done or whatever, is not going to solve this problem. It will just make it worse. I think we first need to: 1) agree that there is a problem 2) figure out what he problem is 3) figure out how the problem was caused 4) agree that we want to solve this problem 5) find a way to solve the problem Cheers Seif > > andre > -- > mailto:ak...@gmx.net | failed > http://blogs.gnome.org/aklapper > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, Apr 24, 2012 at 5:41 PM, Shaun McCance wrote: > On Tue, 2012-04-24 at 16:11 +0100, Bastien Nocera wrote: > > On Tue, 2012-04-24 at 10:58 -0400, Shaun McCance wrote: > > > On Tue, 2012-04-24 at 10:54 +0100, Bastien Nocera wrote: > > > > Hello Federico, > > > > > > > > Em Mon, 2012-04-23 às 20:58 -0500, Federico Mena Quintero escreveu: > > > > > > > > > > > > From http://live.gnome.org/CodeOfConduct > > > > "Assume people mean well" > > > > > > Federico made no statements as to anybody's intentions or motivations. > > > > > > For reference, this is is what it looks like when you assume somebody > > > doesn't mean well: > > > > > > "Person X did Y wrong BECAUSE he/she is evil." > > > > > > This, however, is just a disagreement about what a person did: > > > > > > "Person X did Y wrong." > > > > > > We have to be able to disagree with people's actions and to discuss > > > those disagreements publicly. If we can't, our community dies. > > > > I'm sorry, but thinly veiled insults are still insults. > > > > --8<-- > > From: Maître D' > > Subject: Spitting in the soup > > > > The kitchen staff IS NOT welcome to: > > > > * Spit in the soup > > --8<-- > > ^^^ Still not an insult. > > > "I didn't say you spat in the soup" > > Federico didn't say this. I may have implied it in my email to > Emmanuele. I'm sorry for that. I worded my response poorly. > > I stand by my assertion that you aren't NOT assuming somebody > means well if you don't ascribe motivation. You can very well > assume somebody has the best intentions at heart and still > vehemently disagree with their actions. > > > Trying to hide the fact that Federico was venting for whatever reason > > isn't going to help keep this community any more healthy. > > It's clear there is a non-negligible group of people who feel > disenfranchised. Trying to hide that fact isn't going to help > either. Whether or not anybody has done anything wrong, we have > to figure out why people feel this way. > You hit the nail on the head. Ignoring a problem doesn't make it go away. Thank you for this > -- > Shaun > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
OK first let us all please calm down (This does not apply to Emmanuele, since he seems always calm :P) We all have the best intentions at heart. I think Federico knows exactly that the design team has best intentions. And I hope the design team knows that Federico has the same intentions. This thread sums up and shows the communication flaws between the design team and some of us in the community. There must be a reason why this E-mail was sent and it is not to flame or anger people. We are discussing a problem here. We all agree that: - *No one is in charge. GNOME designers know they don't decide on behalf of GNOME.* - *We are trying to build a product here. * Yet how can we build a product if *some* developers don't feel attached to what they are contributing to. Should those leave the community just because they don't share the vision of the design team. If a designer designs a feature for an application, but the maintainer of the app does not like it, who will implement it? And the other way round we can not develop applications without designing them else no one will use them and we will lose a developer base. There is a perception that GNOME design team are the ones decided the direction. This perception did not come out of thin air and is not a conspiracy. It is a communication problem. >From my observation I think the design team cares more about building the product and sometimes forgets about the community and the social capital of GNOME. This might be based on the fact that *most* of the designers are hired by companies. So if a maintainer doesn't want to implement their designs they can rely on the financial capital to make it happen. This leads to some *developers feeling helpless about how to influence the direction of GNOME* * * Also some designs of applications are not done, and mostly are a revamp of currently existing applications. Suggesting adding a feature to one of the applications is the considered invalid because they don't fit the future plans of the design (that might not be done). Can a developer add such a feature without the design team getting upset? As someone who held a grudge for around 2 years against the design team, I managed to somehow communicate with them in the last 6 months. And they are awesome. Once the communication bridge opened I now understand them and enjoy working with them ==> I trust their ideas. But I still see the how hard it is to get to them. It was not easy. So communication efforts have to be done from both sides. If designers expect developers to implement their ideas then they should also tolerate and work around the fact that developers want to implement their own ideas. Cheers Seif On Tue, Apr 24, 2012 at 12:08 PM, Emmanuele Bassi wrote: > hi Federico; > > I think this email is not at all warranted - and it generates more > fuel for flames. > > On 24 April 2012 02:58, Federico Mena Quintero wrote: > > The design team IS welcome to: > > > The design team IS NOT welcome to: > > these elements contradict what you write below > > > * Second-guess maintainers or well-intentioned contributors. > > > > * Block development based on existing designs. > > > > * Block development based on incomplete or planned designs. > > > > * Veto development except in modules with branches that the design > > team maintains. > > > > * Be dismissive of other people's own approaches to design. > > > > * Dismiss or handwave requests for clarification about decisions taken. > > here: > > > * Every decision is up for review. The state of the world changes, > > not everyone shares your assumptions, and matters which seem settled > > may need revision. > > so, if every decision is up for review, why shouldn't the people doing > design second-guess or block? > > finally, and particularly, this is wrong: > > > * Assume that no one but them does design that is good for Gnome. > > if you're designing for Gnome, then *by definition* you are on the > Gnome design team. > > if your designs are in conflict with what other people doing design > are trying to achieve, then you should talk to them, and revise them > and/or achieve a rough consensus on what is the direction to take. > > by the way, since we're dropping rules by fiat, and given that at > least I'm empowered by the fact of having been elected on the > Foundation's board, I think people on this list are welcome to assume > that people mean well, and are NOT welcome to assume conspiracies or > assume that people do stuff just because. > > ciao, > Emmanuele. > > -- > W: http://www.emmanuelebassi.name > B: http://blogs.gnome.org/ebassi/ > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, Apr 22, 2012 at 10:18 PM, Sriram Ramkrishna wrote: > > > On Sun, Apr 22, 2012 at 1:06 PM, Seif Lotfy wrote: >> >> On Sun, Apr 22, 2012 at 6:36 PM, Shaun McCance wrote: >> > On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: >> > >> >> Which brings us to the matter of openness: the results of everything >> >> the design team does ends up on the GNOME wiki under >> >> live.gnome.org/Design. >> > >> > I think people are more concerned about being able to have input >> > on the process, not on seeing the results published on the wiki. >> > I'm on #gnome-design all day. I often skim the backlog. I don't >> > really see the discussion that leads to the results. Sometimes >> > I see mention of meetings. I don't know where those meetings >> > happen. >> >> Exactly. Non-designers want to be part of the process. Reasons behind >> decisions need to be written somewhere, but that is not enough. >> >> If a new a developer comes and asks for reasons behind a decisions, I >> doubt that the designers, who are already as busy as it gets, can take >> time to explain each one who comes over what problem is being solved >> via the design and how. >> So having design decisions and their reasoning documented would help. >> But also as designers it is their responsibility to communicate with >> those who still doubt these decisions, starting with those willing to >> implement or help out directly. Because if they can explain to those >> nearest to them, those can then jump in to help others. >> > > No, you get volunteer community managers to communicate those design > decisions. A community manager should be able to get a general feel of what > design decisions are having issues with the community. At some point maybe > sucha person can opt for a conversation with specific individuals but > otherwise you know there are a lot of unreasonable people out here and the > internet makes them more unreasonable than they would be usually. > Good point. With community managers, designers can focus more. Still I think a minimal interaction with the community from the designers side is required. I think going with some kind of liaison is a good direction. > Luckily for us, we do have a number of people who couldu do that kind of > community management, Olav for one has already been doing some of it. I do > it more externally. > Are you talking about Olav Bacon :P (bad joke, trying to lighten the mood a bit) > > Big projects like Mozilla have a community managers. It's definitely > something this project should do more of. Dave Eaves who is a Mozilla Community manager has a very nice talk I encourage everybody to watch it. http://blip.tv/djangocon/keynote-david-eaves-5571777 > > sri Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, Apr 22, 2012 at 6:36 PM, Shaun McCance wrote: > On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: > >> Which brings us to the matter of openness: the results of everything >> the design team does ends up on the GNOME wiki under >> live.gnome.org/Design. > > I think people are more concerned about being able to have input > on the process, not on seeing the results published on the wiki. > I'm on #gnome-design all day. I often skim the backlog. I don't > really see the discussion that leads to the results. Sometimes > I see mention of meetings. I don't know where those meetings > happen. Exactly. Non-designers want to be part of the process. Reasons behind decisions need to be written somewhere, but that is not enough. If a new a developer comes and asks for reasons behind a decisions, I doubt that the designers, who are already as busy as it gets, can take time to explain each one who comes over what problem is being solved via the design and how. So having design decisions and their reasoning documented would help. But also as designers it is their responsibility to communicate with those who still doubt these decisions, starting with those willing to implement or help out directly. Because if they can explain to those nearest to them, those can then jump in to help others. So I think my point here is. Documenting is important but communication is key. I get it when designers think that they can spend your whole time trying to convince people of a vision, but at some point something needs to be done. I agree to a certain extent. But who will do it? The paid developers. Well this would make us lose the community on the long run. We need to work on communication between designers and developers. Build trust. Designers have to take time and push themselves to be patient with developers and explain to them seems to them to be trivial facts. Once developers understand how hard a designers job is they will respect it and trust in the decisions and vision, even if they don't agree in the beginning. But also designers need to work on growing they base. The entry level is not that easy I guess. We need to work on basics. If someone comes with designs that are not suitable for us, we can't just pus him away. The fact that he/she came over to discuss designs with us shows initiative to contribute. So some slight wording like "You know that is really good, I am not sure how it can fit in our designs but would you try taking this view out and show me" etc... We are not selling GNOME to consumers only. We are selling the community too. I like the subject of this thread, because openness does not only reflect on the decisions making process but also on the openness to accept new contributors. Cheers Seif >> Of course it would be really fancy if the wiki also contained the >> reasoning behind decisions, but let's face it - none of us does >> anything like that (I doubt you are adding comments like "Using a >> full-blown GObject rather than a boxed type here because ..." or "This >> variable is a double and not an integer because ..." to your code - I >> certainly don't. Still, wouldn't that be helpful for newcomers?). > > That sounds like exactly the sort of thing I write in my git > commit messages. I hope you do too. > > -- > Shaun > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 22, 2012 at 7:09 PM, Florian Max wrote: >> In the end your history is scattered all over the place :P >> >> The logs are there and there is not common way to manage them. Having >> a central log like Zeitgeist will allow you to develop policies and >> blacklist for logging. Having history at a central location and having >> a central tool to disable logging completely or partially should be >> considered as an improvement of the user security. > > > The problem I see here is that it only improves the situation if it is truly > universal - if a central privacy control offers an option to "remove my > recent activity from the last 2 hours", it'd better clear my > firefox/chromium cookies as well(*). Otherwise users will either have to > know about implementation details, or will end up with a false sense of > control. First of all thank you for bringing us on topic again. I agree with you. There is more to privacy than history. Cookies etc are involve. I am just saying history is a part of it. We can start from there. We all agree that design and implementation is iterative. Chrome is not a core app. GNOME should focus on the core apps (as stated by the designers) so a privacy manager should take only GNOME apps into consideration per default. > Also - if I want to hide my recent "activity" on > http://www.furnitureporn.com/, should that really affect funnycat1.png in > recent files or my chat history with @fiancé? I am not saying that a central > tool is bad per se, just that a feature like that should be designed > *before* pushing a technology that implies a certain design. > I totally 100% agree with you that from a UX perspective this needs much more design. And I already said I am not interested anymore in adding a new feature from a UX perspective. But just as a side note. The technology is there. Which means one you want to add a privacy thing it is there, and please believe me that managing your history via Zeitgeist is much more powerful than you give it credit. You can single out stuff and do whatever. It is missing a good UI. So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? > Regards, > Florian > > (*) Maybe Canonical's downstream panel does that, I don't know - they are in > a much stronger position here than we are upstream Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
While this thread reflects a bit about some community observations on how things are handled in GNOME, and i support such a discussion, I find it a bit off-topic. Can we start a new thread discussing these issues or so. Let us stay on topic. Can an applications use Zeitgeist for technical/optimization (NOT FEATURES OR UX) causes? And how does it proceed? 1) Implement first and require dependency later. 2) Request blessed dependency and then implement, if the blessing is given. I would like to know an answer from the release-team if possible, since this is not really design related. Cheers Seif On Sun, Apr 22, 2012 at 4:36 PM, Jeremy Bicha wrote: > On 22 April 2012 06:14, Olav Vitters wrote: >> Risk for the feature focus is that the external dependencies "rules" are >> forgotten. E.g. I noticed that gnome-boxes increased its libosinfo >> version requirement in 3.4.1. That's not so nice when distribution is in >> a version freeze. > > Off-topic, Ubuntu 12.04 won't have Boxes in the repositories, at least > partly because the libvirt dependency was increased 2 weeks after The > Freeze. But this was the first stable release of Boxes, I'm sure > things will be better for 3.6. > > Jeremy > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
I agree with Florian here. It took me a bit of time to interact with the design team but it is possible. It is a very young team and extremely busy and overloaded. They are welcoming for anyone to work with them on design and once you get their attention they will help you integrate more. The best way to be heard is to get involved. But I also understand Luis. I have been working with Allan Day and others for a while now and they are a very productive. The missing point here is that maybe and only maybe because most of the designers are hired by RH (which i consider a blessing if you get paid to work for GNOME), they forget the social capital which is the community, that will implement the work they design. Without interaction with the community no work will be done. And by saying this has to be done because it was decided without any written form or communication it makes things harder. Yes I know there is a wiki but sometimes a developer wants to discuss design decisions but due to the lack of communication efforts from both sides, it seems that the decisions are taken by the design team. My point is that designers should communicate and respect the opinions of the developers. Developers don't just wait to the last moment. Get involved and discuss. I know every side has its own priorities, but we are a community and discussions and compromises need to be made. We want to deliver a product. Some of us get paid to do this, but not all of us. Most of us do it as fun and in our free time. We are a community, this means there is a social aspect involved. And if we can not nurture this social aspect, issues like these show up. Maybe the decision process is flawed. Sometimes technical aspects can not be decided by the design team and thus I would recommend having 2 types of proposals. a feature proposal (UX) and a module proposal (technical stuff). Regards Seif On Sun, Apr 22, 2012 at 4:11 PM, Florian Müllner wrote: > > > On Sat, Apr 21, 2012 at 9:28 PM, Luis Medinas wrote: >> >> do you really want to start talking about what the community think about >> this ? Because if you want to start talking i recommend to see how many >> threads we have, specially on gnome-shell ml, about design decisions that >> makes the community powerless against the almighty Design Team. > > > ... and from before the design team even existed, there are even more > threads about "design decisions that make the community powerless against > the almighty GNOME Developers" - the (rightful) answer to that is usually > "don't just complain, get involved". The same still holds true with the > design team - really, those folks would *love* seeing more people getting > involved. > > > Regards, > Florian > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Olav, Thanks a lot for clearing it up. This makes a lot of sense. As I see it there is two ways to approach this: 1) Implement first then propose as an external dependency:The risk is that implementation is done and GNOME decides the dependency is unacceptable, thus rendering a couple of months work useless. And if the application persists then it is almost like its shoving a dependency down the communities throat. 2) It is blessed to use the technology. This way we valuable time is saved and there is consensus. I prefer option 2. What do you think? Cheers Seif On Sun, Apr 22, 2012 at 12:14 PM, Olav Vitters wrote: > On Sat, Apr 21, 2012 at 08:33:43PM -0700, Sriram Ramkrishna wrote: >> What about you want to use a new technology but you don't want any new >> features but rather using this new external dependency will simpifiy things >> and making maintainance easier? I suppose that itself is the feature? >> Easier maintenance? > > That's #3 actually; propose a new external dependency (same as you do > when you want to increase a new one). > > I know the process is still imperfect (e.g. I think we didn't do a > feature request announcement yet, we should clearly announce which ones > are 'accepted' + should've monitored the progress on accepted features). > Result is that it that the 'rules' are unclear. I think in the end > focussing on features instead of external dependencies is better. But > I think the thought is still underway. > > Risk for the feature focus is that the external dependencies "rules" are > forgotten. E.g. I noticed that gnome-boxes increased its libosinfo > version requirement in 3.4.1. That's not so nice when distribution is in > a version freeze. > > -- > Regards, > Olav > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hey Luis. Very good question. Zeitgeist and Tracker are compeletely different. Tracker is a metadata storage. It is used to store tags and information about files and other data on your computer. Zeitgeist is a log. It is a very intelligent and responsive log. We can not do what tracker providers. Tracker can not do what we provide. Zeitgeist has narrowed down its scope and domain of services to do one thing and do it good. There is no conflict of interest between Zeitgeist and Tracker. Tracker and Zeitgeist are encourages to be used together. Tracker is awesome for searching. Zeitgeist can then sort these search results according to recency, frequency or relevancy. Hope this answers your question. Cheers Seif On Sat, Apr 21, 2012 at 8:22 PM, Luis Medinas wrote: > Hi, > > thanks Shaun for your reply, unfortunatly looks like who decides everything > for GNOME Project are the Design team or the RedHat employees and not the > community. This makes me belive that the community no longer has the power > to decide anything that aren't the way that the designers planned, please > don't do the same as the projects you always criticise! > > Now talking about Zeitgeist it seems to me that it proved stability and > further adoption on other projects but not the project it was designed at > the beginning (am i right Sief ?). The maintainers are very open to > suggestions and to improve the adoption on more modules. So this is a big +1 > for the inclusion. But still care to explain what should we do with tracker > ? Should we use both ? > > Cheers > Luis > > > 2012/4/21 Shaun McCance >> >> On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: >> > On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance wrote: >> > > On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: >> > >> We have a design and a plan for finding >> > >> and reminding, and Zeitgeist doesn't seem like the right technology >> > >> to >> > >> implement that plan. >> > > >> > > Who's "we"? >> > >> > "We", the GNOME designers. >> > >> > > Where is this plan? >> > >> > It's called Documents, and Photos, and Videos, and Music... basically, >> > anything in here: >> > >> > https://live.gnome.org/Design/Apps >> > >> > > And why isn't it going through >> > > the feature proposal process? >> > >> > I believe it has. >> >> I'm not seeing it in my mail archives. >> >> Your previous email seems to indicate that the features for 3.6 are >> already a foregone conclusion, and that Zeitgeist doesn't fit into >> that. But that just can't be, because WE the GNOME community decide >> what's in the next version right here on d-d-l during the proposal >> period. >> >> -- >> Shaun >> >> >> ___ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
OK seems like i sent the mail to only Jasper (damn-reply to all) Again I repeat. I am not talking about features. Web is using an SQLite DB to store its HISTORY. This is code that they need to maintain themselves. Are the Web developers allowed and blessed to use Zeitgeist to store that history. This way we can maintain it. Provide them with a maintainer technology that allows more options and future expansion. It is a simple yes or no question? :D While I 100% agree with how creepy Zeitgeist might sound. How things are going: * Chat will store its history in its own DB * Web will store its history in its own DB * Documents has access to recently used. In the end your history is scattered all over the place :P The logs are there and there is not common way to manage them. Having a central log like Zeitgeist will allow you to develop policies and blacklist for logging. Having history at a central location and having a central tool to disable logging completely or partially should be considered as an improvement of the user security. The trick is to make the user aware of such options. Cheers Seif On Sat, Apr 21, 2012 at 6:59 PM, Jasper St. Pierre wrote: > I've talked to several of my coworkers, and they just think Zeitgeist > is the right technology for anything they're trying to do. A number of > people thought the time-based approach wasn't neat enough. They > brought up the recent flames over the "Recently Used" selection by > default in the GtkFileChooser. We have a design and a plan for finding > and reminding, and Zeitgeist doesn't seem like the right technology to > implement that plan. Some didn't like that Zeitgeist tried to record > practically everything you did, they found it creepy. > > There might be an stigma against Zeitgeist, sure. But on the whole, > I'm going to agree with them: Zeitgeist *isn't* the right technology > for our finding and reminding strategy. > > On Sat, Apr 21, 2012 at 12:42 PM, Seif Lotfy wrote: >> I would like to quote Allan Day (from another public mail thread): >> >> --- >> I realise that you're frustrated by the lack of Zeitgeist adoption in >> GNOME, Seif. As I explained privately, the best way for you to pursue >> this is to talk to maintainers who might need it for search results. >> The decision to use Zeitgeist is really up to them. >> >> Allan >> --- >> >> I won't deny my frustration but I leared to live with it :P >> So let me ask a direct question: >> >> Is there any objections for a GNOME application/library/service >> whether core or not, to have a full dependency on Zeitgeist whether >> for technical reasons (optimization or features) or a UX reasons? >> >> If yes, then the chicken and egg problem is solved (for example Web is >> blessed to use Zeitgeist as its history storage) >> If no, what are the reasons? If the answer for that is propose a >> feature, (then we are back in the chicken and egg loop) >> Sometimes technical issues should be considered valid. So application >> maintainers don't have to take care of their logs (some technical >> outsourcing :P) >> >> Cheers >> Seif >> >> On Tue, Apr 17, 2012 at 10:47 PM, Seif Lotfy wrote: >>> Purpose: >>> Zeitgeist is an event logging framework. It stores user activity in a >>> structured manner and provides a powerful DBus API to query and monitor the >>> log. Zeitgeist as such does not have a graphical component, but is intended >>> to integrate wherever it makes sense. Just like Tracker, Folks and >>> GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by >>> the user directly, but rather would allow developers to harnest the feature >>> it provides and make something useful out of it in their UX. >>> >>> Preamble: >>> It has been 3 years and 8 month since Zeitgeist started under the GNOME >>> umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected >>> due to several reasons including but not limited to: >>> >>> Not enough integration with GNOME applications >>> Project hosting difficulties >>> Immaturity of the project. >>> >>> Zeitgeist is not meant for searching through your files and folders, but >>> rather as a log for user activities. This can be used for: >>> >>> Sorting search results according to frequency/recency >>> Populating dashboards >>> Finding files/contacts/etc... that are used together >>> History browser >>> Associating locations to items (used at location X or Y) >>> scheduling activities (files/contacts/et...) can
Re: Module Proposal: Zeitgeist
I would like to quote Allan Day (from another public mail thread): --- I realise that you're frustrated by the lack of Zeitgeist adoption in GNOME, Seif. As I explained privately, the best way for you to pursue this is to talk to maintainers who might need it for search results. The decision to use Zeitgeist is really up to them. Allan --- I won't deny my frustration but I leared to live with it :P So let me ask a direct question: Is there any objections for a GNOME application/library/service whether core or not, to have a full dependency on Zeitgeist whether for technical reasons (optimization or features) or a UX reasons? If yes, then the chicken and egg problem is solved (for example Web is blessed to use Zeitgeist as its history storage) If no, what are the reasons? If the answer for that is propose a feature, (then we are back in the chicken and egg loop) Sometimes technical issues should be considered valid. So application maintainers don't have to take care of their logs (some technical outsourcing :P) Cheers Seif On Tue, Apr 17, 2012 at 10:47 PM, Seif Lotfy wrote: > Purpose: > Zeitgeist is an event logging framework. It stores user activity in a > structured manner and provides a powerful DBus API to query and monitor the > log. Zeitgeist as such does not have a graphical component, but is intended > to integrate wherever it makes sense. Just like Tracker, Folks and > GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by > the user directly, but rather would allow developers to harnest the feature > it provides and make something useful out of it in their UX. > > Preamble: > It has been 3 years and 8 month since Zeitgeist started under the GNOME > umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected > due to several reasons including but not limited to: > > Not enough integration with GNOME applications > Project hosting difficulties > Immaturity of the project. > > Zeitgeist is not meant for searching through your files and folders, but > rather as a log for user activities. This can be used for: > > Sorting search results according to frequency/recency > Populating dashboards > Finding files/contacts/etc... that are used together > History browser > Associating locations to items (used at location X or Y) > scheduling activities (files/contacts/et...) can be set (See Task pooper) > > People have expressed interest in using it within GNOME, we want to help and > make it happen. We think all these use cases could be address. > > We already have GNOME specific developments: > > We already log everything that pushes into Gtk.RecentlyUsed. > For better logging we have Totem, Rhythmbox, and gedit deploying loggers as > a soft-dependency in the form of plugins. > We worked with gedit and some GNOME designers to develop the Dashboard > plugin [1] to address the empty slate problem. > Additionally, the team wrote several plugins for GNOME Shell [2][3][4] > Integration with telepathy-folks is currently under development. > Discussion about a possible Gtk Recenet Manager revamp with an optional > Zeitgeist backend. [5] > > Another deployment in development is a feature that we think would enrich > the developer story for folks, which is giving folks the ability to actually > provide developers with some interaction details for each individual. [6] > This is under development and hopefully can be merged soon. > > We also provide a logger for Telepathy as part of the zeitgeist-datasources > package. It will soon be shipped directly with Telepathy-Logger as a > soft-dependency. > > We have moved to freedesktop.org so we can play nicely with GNOME, KDE, > Ubuntu as well as others. [7] > > Since we are not a GNOME dependency some projects hesitate to integrate with > us. > It is a chicken and egg problem. Applications don't want to depend on us > since we are not GNOME upstream (thus only soft-dependencies) and GNOME > hesitates to accept Zeitgeist since no application fully depends on it. > > For example: We want to use Zeitgeist in GNOME Clocks will to store "alarms" > as scheduled activities. However we are not sure if we can do that without > Zeitgeist being an external dependency. > > Another example, Epiphany integration: Zeitgeist could take over > storing Epiphany history. However due to the uncertain state of Zeitgeist in > GNOME we can not move on. > I would like to quote Xan Lopez: if GNOME decides to use it throughout I'd > be happy to add support for it in Epiphany. > > Some interesting facts about Zeitgeist: > > It is a dependency for Ubuntu Unity > Many application specific plugins that make use of what Zeitgeist has got to > offer. > Integration into Phonon, the KDE multimedia frame
Re: Feature Proposal: finding and rediscovering shared links
On Sat, Apr 21, 2012 at 4:10 PM, Allan Day wrote: > > On Thu, Apr 19, 2012 at 3:40 PM, Seif Lotfy wrote: > ... > > So a possible view for this feature can be done in Web: Links received can > > then be automatically put in the queue of Web. And once visited can be taken > > out of the queue. > > > > Another possible view would be a dialog for sent/received links for the > > Contacts application. > > > > To sum it up: it would be appealing to have a readitlater queue without > > explicit managing (well allowing that, and having those prioritized) as well > > as having links sent through some direct mean (IM, mail) populate it. > ... > > Something like this could be useful in Contacts, Chat or Mail (I'm not > sure about Web). However, Contacts has a long way to go in terms of > basic functionality and Chat and Mail don't exist yet. I don't think > we're at the point where we can start to think about this feature. Thanks for the input :D My concept to why it belongs in Web is the simple observation that there is a "queue" view planned (hopefully in development soon). I assume that someone sending me a link should be considered as a valid addition to the queue. IMHO splitting this feature to be implemented in several Chats and Mail and Contacts seems out of place. I use Web to browse websites, manage my bookmarks and queue. So it makes sense to lookup websites I should visit from there. The queue can easily indicate where this link came from (Mail/Chat/Social Network). > > I realise that you're frustrated by the lack of Zeitgeist adoption in > GNOME, Seif. As I explained privately, the best way for you to pursue > this is to talk to maintainers who might need it for search results. > The decision to use Zeitgeist is really up to them. I will not deny your claim. But I think this feature should also be considered without Zeitgeist in mind. IMHO its a valid feature that was suggested to me from a designer (so Zeitgeist was not on his mind). So I think we should keep this thread Zeitgeist free and if whoever wants to discuss frustration, there is a thread already up and running :P > > Allan > -- > IRC: aday on irc.gnome.org > Blog: http://afaikblog.wordpress.com/ Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Sounds like a reasonable approach. The reason we looked at zg in the first place is because we were told that eds might not be a good solution for this. I implement it how you suggested and demo it u guess :) On 4/19/12, Rodrigo Moya wrote: > On Thu, 2012-04-19 at 10:31 +0100, Bastien Nocera wrote: >> On Wed, 2012-04-18 at 23:43 +0200, Seif Lotfy wrote: >> > >> > > Clocks: The clocks app is designed by the GNOME designers. >> > It is still more >> > > or less a prototype I am working on alongside Emily Gonyer. >> > We wanted to >> > > make use of Zeitgeist in storing "Alarms" as a type of >> > "scheduled event", it >> > > sounds like shoehorning but it is not. I am just hesitant >> > because I myself >> > > as a GNOME member do not want to use a technology or force >> > integrate it >> > > without GNOME agreeing of the usage of Zeitgeist. >> > >> > >> > It might help for you to elaborate why Zeitgeist is needed >> > there. >> > Clocks is intended to be a really simple application. >> > >> > >> > >> > We need to be able to store Alarms. And those alarms should still work >> > while the clocks application is closed. For that we need a central >> > storage for the scheduled event which is the alarm, to notify all >> > subscribers including Shell that an alarm went off. Same would go for >> > timers. What do you think? >> >> I think that somebody with a hammer sees every problem as a nail. You >> don't need to store alarms in Zeitgeist, you need to store the fact that >> the alarm went off in Zeitgeist. >> > why not store them in e-d-s? you can create a separate calendar, > disabled for viewing in the Evolution UI, which contains the events with > the alarms. Thus, you don't need to have anything other than the already > running evolution-alarm-notify process. > > You can even, IIRC, set up the alarm so that it runs an application, > rather than showing the Evolution alarm dialog. > > cheers > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feature Proposal: finding and rediscovering shared links
Ben, Peter, and Bruce share links to interesting articles and videos and sometimes they can't check it, like if Bruce is in a meeting or out and about on his phone, but if his computer also kept track of the link in IM, then he could look at it then. So one thing is that Bruce is unavailable to look/read/watch something, so defering it to later is an option. Another is if Bruce is looking at something and needs to come back to it. E.g: Someone sent Bruce a link to bugzilla and Bruce remembers that he wants to check on it and do stuff w/ the bug, but 2 or 3 days later or the next week he asks himself where "where was that bug again?". Seperating those links into links one has NOT been to yet, but are in messages, are even more interesting. It would be nice to see a recently encountered link view, where the user can see can see a list of links shared with the him. E.g: Sometimes Ben asks Bruce about some link he shared with him. It would be nice if Ben could just find it based on the content of the link and links they shared (sometimes he's not sure it's Bruce, but it's most likely Bruce) Bruce could use that same tool to look at links he shared with Ben: "What was that page of that JavaScript library that does the animation thing that you sent me a few months ago?" That happens a good bit, not all the time, but often enough, since both often share things with each other but one or the other of them forgets. Some of the stuff they share is just for fun other things are useful for work. And it's all mixed in together. Often, the funny and interesting things are videos and then the work stuff has various keywords, like css or javascript or such (and are usually not videos) So a possible view for this feature can be done in Web: Links received can then be automatically put in the queue of Web. And once visited can be taken out of the queue. Another possible view would be a dialog for sent/received links for the Contacts application. To sum it up: it would be appealing to have a readitlater queue without explicit managing (well allowing that, and having those prioritized) as well as having links sent through some direct mean (IM, mail) populate it. One might argue that sharing happens via Social networks but a lot of it happens via IM and E-mails too. The concept applied for both. I have 2 mockups for this idea... The first would blend in nicely with the current designs of "Web" http://i.minus.com/ibfFpg4wMTscf0.png The second would require adding a new view but has the advantage of allowing a more interactive as well as informative (contextual) display of the links http://i.minus.com/ibq81FRZb2iII4.png Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 19, 2012 at 11:29 AM, Bastien Nocera wrote: > On Thu, 2012-04-19 at 02:20 +0200, Seif Lotfy wrote: > > So let me try to take "Web" use cases that could use Zeitgeist: > > * The user wants to type in the location bar and have > > suggestions pop out while typing. > > * The user wants to blacklist some websites or all websites > > starting with "porn" from being stored in history > > * The user wants to disable history completely temporary > > * The user want to know where he downloaded a file from > > And quoting you: > > This has nothing to do with design honestly. > > Seems that you disagree with yourself. How do you know if something is > the right tool when you don't know what you're going to build? > Please elaborate. Who doesn't know what. On our side we know what we can provide. You took two mails and crossed addrssed them. In my first mail i addressed some *technical* not *usability* improvements in Web that we could provide. I don't see how I disagreed with myself there. In my second mail I am trying to list overall technical and usability ideas. Or did I understand your mail wrong? > You should focus on that. > Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 19, 2012 at 11:31 AM, Bastien Nocera wrote: > On Wed, 2012-04-18 at 23:43 +0200, Seif Lotfy wrote: > > > > > Clocks: The clocks app is designed by the GNOME designers. > > It is still more > > > or less a prototype I am working on alongside Emily Gonyer. > > We wanted to > > > make use of Zeitgeist in storing "Alarms" as a type of > > "scheduled event", it > > > sounds like shoehorning but it is not. I am just hesitant > > because I myself > > > as a GNOME member do not want to use a technology or force > > integrate it > > > without GNOME agreeing of the usage of Zeitgeist. > > > > > > It might help for you to elaborate why Zeitgeist is needed > > there. > > Clocks is intended to be a really simple application. > > > > > > > > We need to be able to store Alarms. And those alarms should still work > > while the clocks application is closed. For that we need a central > > storage for the scheduled event which is the alarm, to notify all > > subscribers including Shell that an alarm went off. Same would go for > > timers. What do you think? > > I think that somebody with a hammer sees every problem as a nail. You > don't need to store alarms in Zeitgeist, you need to store the fact that > the alarm went off in Zeitgeist. > > Both are stored into Zeitgeist. The fact that there was a scheduled event (alarm) is there until the alarm time is reached. The entry is then changed from scheduled activity to a notification. This is technical really I think we should take this into irc. Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
So let me try to take "Web" use cases that could use Zeitgeist: - The user wants to type in the location bar and have suggestions pop out while typing. - The user wants to blacklist some websites or all websites starting with "porn" from being stored in history - The user wants to disable history completely temporary - The user want to know where he downloaded a file from While I know all these features can be done without Zeitgeist. But why hack around if there is something there already, which could allow these ideas to be implemented with a few lines of code? Also I am aware that soon the design team wants to work on a Privacy feature. While privacy is much more than logging and encapsulates domain such as "sharing". Imagine the user want to delete traces of his activities from the last 30 minutes, this includes logs from Web and maybe logs from Music. I think Zeitgeist sets up a good basis for manipulating and managing the application logs if applications choose to share with Zeitgeist its activities. What do you think? We already did initial work on this downstream for Ubuntu and Dawati and I think GNOME could leverage from that. I know these are all features that are not proposed for 3.6 but would it work if I proposed our Activity Log Manager for GNOME 3.6 as a feature... I guess not, since Zeitgeist is not the main mean for logging activities in GNOME. What do you think? Cheers Seif On Wed, Apr 18, 2012 at 11:43 PM, Seif Lotfy wrote: > On Wed, Apr 18, 2012 at 11:35 PM, Allan Day wrote: > >> Seif Lotfy wrote: >> ... >> > There are 3 issues in discussion or in development where Zeitgeist >> > integration is reaching a halt due to the uncertainty of where Zeitgeist >> > stands: >> > >> > Epiphany (Web): There has long been discussions on how to deploy >> Zeitgeist >> > as a backend for Web. Web needed to rethink its history problem. It >> ended up >> > with developing an SQLite based history backend. Right now we are >> discussing >> > replacing this backend with Zeitgeist, since Zeitgeist can do >> everything the >> > SQLite backend can. plus we can add new features to Web that make use of >> > Zeitgeist's Full-Text-Search capabilities for "searching" via the uri >> bar. >> >> We don't have a design for browser history search in Web yet [1]. >> > > This has nothing to do with design honestly. This is a way to save > history. Make it easier and more efficient for Web to store/retrieve > history. How would that effect the UX? > > >> >> > Folks: I added some new properties to the individuals class in folks >> > (currently in review). Now I could give more detail and allow the >> Contacts >> > app to sort individuals by recency/frequency of interaction. The >> telepathy >> > backend for this feature needs Zeitgeist. The Telepathy backend can >> provide >> > even more info such as "Show me all files sent to X or recevied from X" >> > (same goes for URIs). This feature was requested by Garrett LeSage from >> the >> > GNOME Design team. >> >> That was considered in the Contacts design process, but it was decided >> that it wasn't appropriate/useful. >> > > I am not challenging this decision but fwiw I sort my GTalk contacts via > most popular. Which is something I think calculated via "frequency of > use"/"recently used". Does this mean having this option in the Folks > library (which is something not UI or UX related) not allowed. > > > Clocks: The clocks app is designed by the GNOME designers. It is still >> more >> > or less a prototype I am working on alongside Emily Gonyer. We wanted to >> > make use of Zeitgeist in storing "Alarms" as a type of "scheduled >> event", it >> > sounds like shoehorning but it is not. I am just hesitant because I >> myself >> > as a GNOME member do not want to use a technology or force integrate it >> > without GNOME agreeing of the usage of Zeitgeist. >> >> It might help for you to elaborate why Zeitgeist is needed there. >> Clocks is intended to be a really simple application. >> > > We need to be able to store Alarms. And those alarms should still work > while the clocks application is closed. For that we need a central storage > for the scheduled event which is the alarm, to notify all subscribers > including Shell that an alarm went off. Same would go for timers. > What do you think? > > >> >> > As I see also there is some ideas going around for the searching via >> Shell. >> > I agree t
Re: Module Proposal: Zeitgeist
On Wed, Apr 18, 2012 at 11:35 PM, Allan Day wrote: > Seif Lotfy wrote: > ... > > There are 3 issues in discussion or in development where Zeitgeist > > integration is reaching a halt due to the uncertainty of where Zeitgeist > > stands: > > > > Epiphany (Web): There has long been discussions on how to deploy > Zeitgeist > > as a backend for Web. Web needed to rethink its history problem. It > ended up > > with developing an SQLite based history backend. Right now we are > discussing > > replacing this backend with Zeitgeist, since Zeitgeist can do everything > the > > SQLite backend can. plus we can add new features to Web that make use of > > Zeitgeist's Full-Text-Search capabilities for "searching" via the uri > bar. > > We don't have a design for browser history search in Web yet [1]. > This has nothing to do with design honestly. This is a way to save history. Make it easier and more efficient for Web to store/retrieve history. How would that effect the UX? > > > Folks: I added some new properties to the individuals class in folks > > (currently in review). Now I could give more detail and allow the > Contacts > > app to sort individuals by recency/frequency of interaction. The > telepathy > > backend for this feature needs Zeitgeist. The Telepathy backend can > provide > > even more info such as "Show me all files sent to X or recevied from X" > > (same goes for URIs). This feature was requested by Garrett LeSage from > the > > GNOME Design team. > > That was considered in the Contacts design process, but it was decided > that it wasn't appropriate/useful. > I am not challenging this decision but fwiw I sort my GTalk contacts via most popular. Which is something I think calculated via "frequency of use"/"recently used". Does this mean having this option in the Folks library (which is something not UI or UX related) not allowed. > Clocks: The clocks app is designed by the GNOME designers. It is still > more > > or less a prototype I am working on alongside Emily Gonyer. We wanted to > > make use of Zeitgeist in storing "Alarms" as a type of "scheduled > event", it > > sounds like shoehorning but it is not. I am just hesitant because I > myself > > as a GNOME member do not want to use a technology or force integrate it > > without GNOME agreeing of the usage of Zeitgeist. > > It might help for you to elaborate why Zeitgeist is needed there. > Clocks is intended to be a really simple application. > We need to be able to store Alarms. And those alarms should still work while the clocks application is closed. For that we need a central storage for the scheduled event which is the alarm, to notify all subscribers including Shell that an alarm went off. Same would go for timers. What do you think? > > > As I see also there is some ideas going around for the searching via > Shell. > > I agree that every application should be able to provide it search > results > > to shell (aggregated search). I think Zeitgeist could fit in there > nicely to > > sort the aggregated results globally according to recency or frequency. > > There are some designs in development for shell search [2], and these > have implications for how we want search results to be returned within > individual applications. I don't have the expertise to comment on > which technologies are required to implement those. > > As mentioned previously in this thread, I'd expect to see a specific > feature proposal for 3.6, rather than a module proposal. A new feature > might require new dependencies, of course (which you might have to > justify, I > guess). You could certainly propose Clocks as a feature for 3.6... > I really would rather have the technologies I am allowed to use figured out before I continue with alarms. Currently Emily is doing some more designing. > > Allan > > [1] https://live.gnome.org/Design/Apps/Web#Tentative_Design > [2] https://live.gnome.org/GnomeShell/Design/Whiteboards/Search > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feature Proposals vs new modules [was: Module Proposal: Zeitgeist]
Hi Andre, Thanks for the quick reply. I have some concern though that for framework authors, it's very hard to understand the new module proposal process. This might be slightly off the topic... so I understand if you would put this in another thread. New features get planned for GNOME 3.6. When it comes to implementing them, which is most probably after the feature proposal is over, how is it decided if a technology should be used or not if the proposal period is closed? How would it affect the developers if a library or a framework is blessed to be used in a core application? How will the user notice that? E.g: Empathy want to add sorting contract according to popularity? If the feature is not in the 3.6 feature plan [0], does this mean the feature should be postponed 6 months? If no, can the Empathy developers use a library or daemon that is not regarded as an external dependency for GNOME? What if an external dependency wants to add a dependency? I am not sure that rules that apply on UI visible proposals, should be applied on libraries and non-ui modules. Cheers Seif [0] https://live.gnome.org/ThreePointFive/Features/ On Wed, Apr 18, 2012 at 10:58 AM, Andre Klapper wrote: > Hi Seif, > > FYI we dropped the module proposals period and replaced it by a proposal > period for systemwide features. See > > https://mail.gnome.org/archives/devel-announce-list/2012-March/msg5.htmlfor > the GNOME 3.5 call. > > So the question would turn into "Which (Zeitgeist-based) features could > become part of GNOME 3.6 and what are the advantages for the GNOME > system". > As far as I see this is already answered by your section below, both by > describing systemwide functionality provided by Zeitgeist and by listing > several GNOME modules with existing or planned integration code. > > andre > > On Tue, 2012-04-17 at 22:47 +0200, Seif Lotfy wrote: > > Purpose: > > Zeitgeist is an event logging framework. It stores user activity in a > > structured manner and provides a powerful DBus API to query and > > monitor the log. Zeitgeist as such does not have a graphical > > component, but is intended to integrate wherever it makes sense. Just > > like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. > > And is not a going to be used by the user directly, but rather would > > allow developers to harnest the feature it provides and make something > > useful out of it in their UX. > > > > Zeitgeist is not meant for searching through your files and folders, > > but rather as a log for user activities. This can be used for: > > * Sorting search results according to frequency/recency > > * Populating dashboards > > * Finding files/contacts/etc... that are used together > > * History browser > > * Associating locations to items (used at location X or Y) > > * scheduling activities (files/contacts/et...) can be set (See > > Task pooper) > > People have expressed interest in using it within GNOME, we want to > > help and make it happen. We think all these use cases could be > > address. > > > > We already have GNOME specific developments: > > * We already log everything that pushes into Gtk.RecentlyUsed. > > * For better logging we have Totem, Rhythmbox, and gedit > > deploying loggers as a soft-dependency in the form of plugins. > > * We worked with gedit and some GNOME designers to develop the > > Dashboard plugin [1] to address the empty slate problem. > > * Additionally, the team wrote several plugins for GNOME Shell > > [2][3][4] > > * Integration with telepathy-folks is currently under > > development. > > * Discussion about a possible Gtk Recenet Manager revamp with an > > optional Zeitgeist backend. [5] > > Another deployment in development is a feature that we think would > > enrich the developer story for folks, which is giving folks the > > ability to actually provide developers with some interaction details > > for each individual. [6] This is under development and hopefully can > > be merged soon. > > > > We also provide a logger for Telepathy as part of the > > zeitgeist-datasources package. It will soon be > > shipped directly with Telepathy-Logger as a soft-dependency. > > -- > mailto:ak...@gmx.net | failed > http://blogs.gnome.org/aklapper > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Wed, Apr 18, 2012 at 10:24 AM, Milan Bouchet-Valat wrote: > Le mardi 17 avril 2012 à 22:47 +0200, Seif Lotfy a écrit : > > Purpose: > > Zeitgeist is an event logging framework. It stores user activity in a > > structured manner and provides a powerful DBus API to query and > > monitor the log. Zeitgeist as such does not have a graphical > > component, but is intended to integrate wherever it makes sense. Just > > like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. > > And is not a going to be used by the user directly, but rather would > > allow developers to harnest the feature it provides and make something > > useful out of it in their UX. > > > > Preamble: > > It has been 3 years and 8 month since Zeitgeist started under the > > GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got > > rejected due to several reasons including but not limited to: > > * Not enough integration with GNOME applications > > * Project hosting difficulties > You didn't say anything about the places integration to the core > desktop, i.e. the Shell and the Documents app. I think this is the key > point. What's the status of the experimental Finding and Reminding view > that was based on Zeitgeist[1] and of the Shell extension[2]? Have you > discussed with designers about that recently? > > I'm all for adding Zeitgeist as a dependency, but the essential question > is (and has been since the beginning) how to make the best use of it in > the core desktop. IMHO that's where you can break the chicken-and-egg > vicious cycle. > > > My two cents > > > 1: > > http://people.gnome.org/~federico/news-2011-02.html#zeitgeist-in-gnome-shell > 2: https://extensions.gnome.org/extension/62/journal/ > Hey Milan, As far as I know the designers could not find a place for Zeitgeist in the core apps. This is the reason why I made my work as an extension so people who feel like using it can try it out easily. There are 3 issues in discussion or in development where Zeitgeist integration is reaching a halt due to the uncertainty of where Zeitgeist stands: - Epiphany (Web): There has long been discussions on how to deploy Zeitgeist as a backend for Web. Web needed to rethink its history problem. It ended up with developing an SQLite based history backend. Right now we are discussing replacing this backend with Zeitgeist, since Zeitgeist can do everything the SQLite backend can. plus we can add new features to Web that make use of Zeitgeist's Full-Text-Search capabilities for "searching" via the uri bar. - Folks: I added some new properties to the individuals class in folks (currently in review). Now I could give more detail and allow the Contacts app to sort individuals by recency/frequency of interaction. The telepathy backend for this feature needs Zeitgeist. The Telepathy backend can provide even more info such as "Show me all files sent to X or recevied from X" (same goes for URIs). This feature was requested by Garrett LeSage from the GNOME Design team. - Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing "Alarms" as a type of "scheduled event", it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. As I see also there is some ideas going around for the searching via Shell. I agree that every application should be able to provide it search results to shell (aggregated search). I think Zeitgeist could fit in there nicely to sort the aggregated results globally according to recency or frequency. This is all I got honestly. Thanks Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Module Proposal: Zeitgeist
*Purpose: *Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. *Preamble: *It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: - Not enough integration with GNOME applications - Project hosting difficulties - Immaturity of the project. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: - Sorting search results according to frequency/recency - Populating dashboards - Finding files/contacts/etc... that are used together - History browser - Associating locations to items (used at location X or Y) - scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have *GNOME specific developments*: - We already log everything that pushes into Gtk.RecentlyUsed. - For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. - We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. - Additionally, the team wrote several plugins for GNOME Shell [2][3][4] - Integration with telepathy-folks is currently under development. - Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] Another deployment in development is a feature that we think would enrich the developer story for folks, which is giving folks the ability to actually provide developers with some interaction details for each individual. [6] This is under development and hopefully can be merged soon. We also provide a logger for Telepathy as part of the zeitgeist-datasources package. It will soon be shipped directly with Telepathy-Logger as a soft-dependency. We have moved to freedesktop.org so we can play nicely with GNOME, KDE, Ubuntu as well as others. [7] Since we are not a GNOME dependency some projects hesitate to integrate with us. It is a chicken and egg problem. Applications don't want to depend on us since we are not GNOME upstream (thus only soft-dependencies) and GNOME hesitates to accept Zeitgeist since no application fully depends on it. For example: We want to use Zeitgeist in GNOME Clocks will to store "alarms" as scheduled activities. However we are not sure if we can do that without Zeitgeist being an external dependency. Another example, Epiphany integration: Zeitgeist could take over storing Epiphany history. However due to the uncertain state of Zeitgeist in GNOME we can not move on. I would like to quote Xan Lopez: if GNOME decides to use it throughout I'd be happy to add support for it in Epiphany. *Some interesting facts about Zeitgeist: * - It is a dependency for Ubuntu Unity - Many application specific plugins that make use of what Zeitgeist has got to offer. - Integration into Phonon, the KDE multimedia framework and various deployments within KDE - Deploying in Dawati [0] - Paid dedicated developers - Previously ported from Python to Vala without breaking API *Proposal to become a blessed dependency *With this appliation I would like to address the possibility of accepting Zeitgeist as a blessed dependency. *Dependencies*: - Vala - Sqlite - Xapian (Soft) - python-rdflib (only for compiling the ontologies) *Resource usage: * - Bug tracker: http://bugs.freedesktop.org/ - VCS: http://cgit.freedesktop.org/zeitgeist/ *Other notes: *What most people think of as Zeitgeist is split in two processes zeitgeist-daemon and zeitgeist-datahub. The daemon does not do any active monitoring for events, it only manages the log database and exposes a DBus interface for inserting, deleting, querying events, and monitoring for changes. The datahub monitors the system and pushes events into the daemon. This architecture makes the datahub expendable if we one day move to an architecture where apps themselves (or something else) push events into Zeitgeist. Indeed it's already the case that we have plugins for some apps that makes them push events into the daemon. [0] http://dawati.org/ [1] http://seilo.geekyogre.com/2011/11/gedit-dash-0-1/ [2] https://extensions.gnome.org/extension/62/journal/ [3] https://extensions.gnome.org/extension/33/jump-lists/ [4] htt
Re: 3.4 Features, final round
On Mon, Nov 7, 2011 at 1:09 AM, Florian Müllner wrote: > On lun, 2011-11-07 at 00:23 +0100, Seif Lotfy wrote: > > > > On Mon, Nov 7, 2011 at 12:10 AM, Florian Müllner > > > > To me it means that the application is in control of what > > appears in the > > jumplist, not necessarily that it is responsible for > > specifying the > > exact set of items. So I can imagine some "gnome-recent-items" > > action > > which is translated appropriately by the shell if included in > > the .desktop file, but I would not expect anything in the > > jumplist if > > the application does not specify anything. > > > > > > However if the app doesn't specify a list why not have a fallback > > option. > > Mostly you will end up using it in cases like gedit, rhythmbox, totem, > > epiphany and event documents. In that case I suggest the usage of > > zeitgeist and not gtk.recentmanager. Since such lists are dynamic i > > don't find it appropriate to keep updating the .desktop file with > > recently/most used every time the app is used. If apps really would do > > that I would suggest them push directly into zeitgeist. > > > I did not suggest updating the .desktop file, I suggested "special" > actions applications could specify to request certain content, for > instance a list of recent items. (Obviously that would only be step > three, after deciding whether the feature is wanted and implementing the > basic functionality). > > Fair enough :) > > Florian > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
On Mon, Nov 7, 2011 at 12:30 AM, Jasper St. Pierre wrote: > On Sun, Nov 6, 2011 at 6:23 PM, Seif Lotfy wrote: > > > > On Mon, Nov 7, 2011 at 12:10 AM, Florian Müllner > > wrote: > >> > >> On dom, 2011-11-06 at 22:52 +0100, Seif Lotfy wrote: > >> > "What you see" for me doesnt necessarily mean that the program > >> > populates the jumplist alone. It means the items in the jumplist are > >> > prgram specific. > >> > >> To me it means that the application is in control of what appears in the > >> jumplist, not necessarily that it is responsible for specifying the > >> exact set of items. So I can imagine some "gnome-recent-items" action > >> which is translated appropriately by the shell if included in > >> the .desktop file, but I would not expect anything in the jumplist if > >> the application does not specify anything. > > > > However if the app doesn't specify a list why not have a fallback option. > > Mostly you will end up using it in cases like gedit, rhythmbox, totem, > > epiphany and event documents. In that case I suggest the usage of > zeitgeist > > and not gtk.recentmanager. Since such lists are dynamic i don't find it > > appropriate to keep updating the .desktop file with recently/most used > every > > time the app is used. If apps really would do that I would suggest them > push > > directly into zeitgeist. > > I've spoken to a few people about this before. My idea is that I'd > like to see Gtk.RecentManager either use Zeitgeist, or be deprecated > and replaced by a wrapper to Zeitgeist, or something. The less > intersecting APIs we have, the better. Federico has already written > about this a bit here: > >https://live.gnome.org/GTK%2B/GtkRecentManagerAndZeitgeist > > But I'm unsure of the status right now. > We already got the people who will work on it. I will try to have a detailed description of the Gtk RecentlyUsed problem and how Zeitgeist can solve it up this week. By the end of the month I hope we can have an API design. AFAIK Michal Hruby and Federico will be doing the implementation. > > >> > Unless we provide the recentlyused and mostused files in the .desktop > >> > file the only way for the jumplist to populate itself with such items > >> > is if the app is running and pushed them into the jumplists. > >> > >> I don't agree with the notion that "jumplist == recently/frequently used > >> files" - for instance for Evolution, I would expect actions like "New > >> mail" or "Open calendar", but not a list of recently read emails > >> cluttering the list (even when that data is available in > >> gtkrecent/zeitgeist). > > > > I comepletely agree with you that jumplists is more than most/recent > items. > > I never claimed otherwise. > >> > >> Florian > >> > >> > > > > Seif > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > > > -- > Jasper > Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
On Mon, Nov 7, 2011 at 12:10 AM, Florian Müllner wrote: > On dom, 2011-11-06 at 22:52 +0100, Seif Lotfy wrote: > > "What you see" for me doesnt necessarily mean that the program > > populates the jumplist alone. It means the items in the jumplist are > > prgram specific. > > To me it means that the application is in control of what appears in the > jumplist, not necessarily that it is responsible for specifying the > exact set of items. So I can imagine some "gnome-recent-items" action > which is translated appropriately by the shell if included in > the .desktop file, but I would not expect anything in the jumplist if > the application does not specify anything. However if the app doesn't specify a list why not have a fallback option. Mostly you will end up using it in cases like gedit, rhythmbox, totem, epiphany and event documents. In that case I suggest the usage of zeitgeist and not gtk.recentmanager. Since such lists are dynamic i don't find it appropriate to keep updating the .desktop file with recently/most used every time the app is used. If apps really would do that I would suggest them push directly into zeitgeist. > Unless we provide the recentlyused and mostused files in the .desktop > > file the only way for the jumplist to populate itself with such items > > is if the app is running and pushed them into the jumplists. > > I don't agree with the notion that "jumplist == recently/frequently used > files" - for instance for Evolution, I would expect actions like "New > mail" or "Open calendar", but not a list of recently read emails > cluttering the list (even when that data is available in > gtkrecent/zeitgeist). > I comepletely agree with you that jumplists is more than most/recent items. I never claimed otherwise. > Florian > > > Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
"What you see" for me doesnt necessarily mean that the program populates the jumplist alone. It means the items in the jumplist are prgram specific. Unless we provide the recentlyused and mostused files in the .desktop file the only way for the jumplist to populate itself with such items is if the app is running and pushed them into the jumplists. On Sun, Nov 6, 2011 at 10:46 PM, Florian Müllner wrote: > On dom, 2011-11-06 at 21:52 +0100, Seif Lotfy wrote: > > Lets avoid the fact that this is by MS, it is still useful to look at. > > http://windows.microsoft.com/en-US/windows7/products/features/jump-lists > > They distinguish between recently and frequently used too > > I am not able to see the embedded silverlight movie(?), but the quote > > "What you see in a Jump List depends entirely on the program." > > would support Matthias' comment about defining actions in .desktop > files. > > > Florian > > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
Well during this UDS they tasked the Zeitgeist team to work on putting in the frequently and recently used into their jumplists. https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-zeitgeist On Sun, Nov 6, 2011 at 10:30 PM, Sriram Ramkrishna wrote: > > > On Sun, Nov 6, 2011 at 12:00 PM, Matthias Clasen < > matthias.cla...@gmail.com> wrote: > >> On Sun, Nov 6, 2011 at 1:59 PM, Sriram Ramkrishna >> wrote: >> > >> > >> > On Sun, Nov 6, 2011 at 8:06 AM, Frederic Peters >> wrote: >> >> >> >> Hello all, >> >> >> >> + Jumplists >> >> https://live.gnome.org/ThreePointThree/Features/Jumplists >> >> → didn't heard much opinion of it from designers >> >> >> > >> > Jumplists is predicated on choosing an engine like zeitgeist. So there >> is a >> > bigger question on how to implement it and using what technology. No >> > decision has been made on zeitgeist itself, and I don't believe Seif has >> > introduced Zeitgeist as a feature. >> >> I don't think jumplists require zeitgeist. >> Static jumplists work fine by just reading desktop files. >> 'Recent files' require, well, recent files. >> > > That's right... Unity does it this way I believe. I had forgotten. > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
Lets avoid the fact that this is by MS, it is still useful to look at. http://windows.microsoft.com/en-US/windows7/products/features/jump-lists They distinguish between recently and frequently used too On Sun, Nov 6, 2011 at 9:51 PM, Seif Lotfy wrote: > Let me elaborate, > One of the main ideas of jump-lists are not only actions and recently used > stuff. But also frequently used. Recently used as it is now is not helpful. > On a busy day I open several files (around 16) using gedit. Now I go to > the gedit icon in the dash. The right-click displaying the last 7 items is > not always helpful. Some of those items are things i would *not* open again > or maybe i was just browsing through code. Such items are "noise" that > populate the list taking slots that could be filled by > more promising files". To know those I need to know which of the files I > used today, I also used Yesterday (this is a feature missing in > gtk.recentlyused since it overwrites the dates) or used more than once in > the last N days (gtk.recentlyused has no concept of frequency) > Assuming that anything i open "frequently" will appear under > gtk.recentlyused is risky since the only order we have is chronological > order. With Zeitgeist its easier to detect such noise, by knowing the > count, which allows us make more use of the slots. > 4 recently used + 4 most used (within the last week). > Cheers > Seif > > > On Sun, Nov 6, 2011 at 9:32 PM, Seif Lotfy wrote: > >> What about frequent files? >> >> >> On Sun, Nov 6, 2011 at 9:00 PM, Matthias Clasen < >> matthias.cla...@gmail.com> wrote: >> >>> On Sun, Nov 6, 2011 at 1:59 PM, Sriram Ramkrishna >>> wrote: >>> > >>> > >>> > On Sun, Nov 6, 2011 at 8:06 AM, Frederic Peters >>> wrote: >>> >> >>> >> Hello all, >>> >> >>> >> + Jumplists >>> >> https://live.gnome.org/ThreePointThree/Features/Jumplists >>> >> → didn't heard much opinion of it from designers >>> >> >>> > >>> > Jumplists is predicated on choosing an engine like zeitgeist. So >>> there is a >>> > bigger question on how to implement it and using what technology. No >>> > decision has been made on zeitgeist itself, and I don't believe Seif >>> has >>> > introduced Zeitgeist as a feature. >>> >>> I don't think jumplists require zeitgeist. >>> Static jumplists work fine by just reading desktop files. >>> 'Recent files' require, well, recent files. >>> ___ >>> desktop-devel-list mailing list >>> desktop-devel-list@gnome.org >>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >>> >> >> > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
Let me elaborate, One of the main ideas of jump-lists are not only actions and recently used stuff. But also frequently used. Recently used as it is now is not helpful. On a busy day I open several files (around 16) using gedit. Now I go to the gedit icon in the dash. The right-click displaying the last 7 items is not always helpful. Some of those items are things i would *not* open again or maybe i was just browsing through code. Such items are "noise" that populate the list taking slots that could be filled by more promising files". To know those I need to know which of the files I used today, I also used Yesterday (this is a feature missing in gtk.recentlyused since it overwrites the dates) or used more than once in the last N days (gtk.recentlyused has no concept of frequency) Assuming that anything i open "frequently" will appear under gtk.recentlyused is risky since the only order we have is chronological order. With Zeitgeist its easier to detect such noise, by knowing the count, which allows us make more use of the slots. 4 recently used + 4 most used (within the last week). Cheers Seif On Sun, Nov 6, 2011 at 9:32 PM, Seif Lotfy wrote: > What about frequent files? > > > On Sun, Nov 6, 2011 at 9:00 PM, Matthias Clasen > wrote: > >> On Sun, Nov 6, 2011 at 1:59 PM, Sriram Ramkrishna >> wrote: >> > >> > >> > On Sun, Nov 6, 2011 at 8:06 AM, Frederic Peters >> wrote: >> >> >> >> Hello all, >> >> >> >> + Jumplists >> >> https://live.gnome.org/ThreePointThree/Features/Jumplists >> >> → didn't heard much opinion of it from designers >> >> >> > >> > Jumplists is predicated on choosing an engine like zeitgeist. So there >> is a >> > bigger question on how to implement it and using what technology. No >> > decision has been made on zeitgeist itself, and I don't believe Seif has >> > introduced Zeitgeist as a feature. >> >> I don't think jumplists require zeitgeist. >> Static jumplists work fine by just reading desktop files. >> 'Recent files' require, well, recent files. >> ___ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
What about frequent files? On Sun, Nov 6, 2011 at 9:00 PM, Matthias Clasen wrote: > On Sun, Nov 6, 2011 at 1:59 PM, Sriram Ramkrishna > wrote: > > > > > > On Sun, Nov 6, 2011 at 8:06 AM, Frederic Peters > wrote: > >> > >> Hello all, > >> > >> + Jumplists > >> https://live.gnome.org/ThreePointThree/Features/Jumplists > >> → didn't heard much opinion of it from designers > >> > > > > Jumplists is predicated on choosing an engine like zeitgeist. So there > is a > > bigger question on how to implement it and using what technology. No > > decision has been made on zeitgeist itself, and I don't believe Seif has > > introduced Zeitgeist as a feature. > > I don't think jumplists require zeitgeist. > Static jumplists work fine by just reading desktop files. > 'Recent files' require, well, recent files. > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
Found the 2 links where we tried to open this subject... Me: https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00026.html Federico: https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00166.html On Sun, Nov 6, 2011 at 8:18 PM, Seif Lotfy wrote: > Hey Sriram > I don't think the new GNOME policies allow me to introduce or suggest > Zeitgeist as a policy. > But rather require a feature to require Zeitgeist... > Jump-lists in my opinion require Zeitgeist. Also Federico had sent a mail > suggesting the jumplists with Zeitgeist as a feature proposal but somehow > nobody even gave it a chance or replied to it... > Cheers > Seif > > On Sun, Nov 6, 2011 at 7:59 PM, Sriram Ramkrishna wrote: > >> >> >> On Sun, Nov 6, 2011 at 8:06 AM, Frederic Peters wrote: >> >>> Hello all, >>> >>> >>> + Jumplists >>> https://live.gnome.org/ThreePointThree/Features/Jumplists >>> → didn't heard much opinion of it from designers >>> >>> >> Jumplists is predicated on choosing an engine like zeitgeist. So there >> is a bigger question on how to implement it and using what technology. No >> decision has been made on zeitgeist itself, and I don't believe Seif has >> introduced Zeitgeist as a feature. >> >> sri >> >> >> ___ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Features, final round
Hey Sriram I don't think the new GNOME policies allow me to introduce or suggest Zeitgeist as a policy. But rather require a feature to require Zeitgeist... Jump-lists in my opinion require Zeitgeist. Also Federico had sent a mail suggesting the jumplists with Zeitgeist as a feature proposal but somehow nobody even gave it a chance or replied to it... Cheers Seif On Sun, Nov 6, 2011 at 7:59 PM, Sriram Ramkrishna wrote: > > > On Sun, Nov 6, 2011 at 8:06 AM, Frederic Peters wrote: > >> Hello all, >> >> >> + Jumplists >> https://live.gnome.org/ThreePointThree/Features/Jumplists >> → didn't heard much opinion of it from designers >> >> > Jumplists is predicated on choosing an engine like zeitgeist. So there is > a bigger question on how to implement it and using what technology. No > decision has been made on zeitgeist itself, and I don't believe Seif has > introduced Zeitgeist as a feature. > > sri > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Contacts developers wanted
I am in :) On Thu, Oct 20, 2011 at 2:01 PM, Alexander Larsson wrote: > On Thu, 2011-10-20 at 14:00 +0200, Seif Lotfy wrote: > > What is the language used to develop? > > Its written in vala, and so is libfolks which is the primary dependency. > > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Contacts developers wanted
What is the language used to develop? Cheers Seif On Thu, Oct 20, 2011 at 1:33 PM, Alexander Larsson wrote: > During the 3.2 cycle I developed the Gnome Contacts app from scratch > based on designs (and interaction with) Allan Day. There wasn't much > interaction with other developers since we had to get something done for > the release. I want to continue working on it, and we have a bunch of > stuff planned for 3.4. > > However, at this point it would be nice to have more developers, as > there is always risks with having only a single developer on any module. > I'm not always around, or might have to work on something else at times. > > So, I'd like to reach out to other developers interested in working on > Gnome Contacts. This would be a great time to start hacking on this new, > exciting and still young piece of code. > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
Are there any suggestions towards jumplists? On Thu, Oct 6, 2011 at 2:13 PM, Seif Lotfy wrote: > The Jump-list stuff has been on my list for a while: > What we are facing here is: > > Adding actions to the appmenus: new tab (browser), new note (for tomboy > or gnote) or pause (for the media players) > Adding document shortcuts in the appmenus: 4 most recent documents and > other most used (in the last x days) documents with gedit > > I already have a solution for the second and the implementation is there > but relies on zeitgeist since a lot of apps don't store their actions into > gtk.recentmanager (we also are looking into > https://live.gnome.org/GTK%2B/GtkRecentManagerAndZeitgeist) and most used > can only be calculated by something that tracks history like Zeitgeist. > > I am up for the task of implementing this feature if a designer and a > technical expert can dedicate some time to walk through concept with me. > > Cheers > Seif > > On Wed, Oct 5, 2011 at 10:17 PM, Matthias Clasen < > matthias.cla...@gmail.com> wrote: > >> Hey, >> >> so according to the draft schedule that Andre posted a while ago, we >> are in the middle of the 'feature proposal' period right now. I >> haven't seen much feature discussion here at all yet, and so far, the >> wiki only lists things that I have put there, which is a little scary >> - I can't be the only one itching to get cool things into GNOME 3.4. >> >> Where are your ideas ? It would be great to get them onto that wiki >> page, in particular since next weekend a bunch of us will get together >> in Montreal to, among other things, spend time to talk about 3.4 >> features. >> >> Anyway, to make a start, here are the things that have been proposed >> as features so far: >> >>Boxes - a new application to access vms and remote systems >> >>Application menu / Actions / Jumplists - make the appmenu useful >> >>Lock Screen - unify the lock screen and the login screen, visually >> >>IBus/XKB support - make the region panel control input methods + >> keyboard layouts together >> >>Network Zones >>Network Panel Improvements - make networking not suck >> >>GNOME Documents >>User Panel Improvements >>Wacom Panel Improvements >> - incremental improvements for various parts of the desktop >> >> More details at http://live.gnome.org/ThreePointThree/Features >> >> >> Matthias >> ___ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
The Jump-list stuff has been on my list for a while: What we are facing here is: Adding actions to the appmenus: new tab (browser), new note (for tomboy or gnote) or pause (for the media players) Adding document shortcuts in the appmenus: 4 most recent documents and other most used (in the last x days) documents with gedit I already have a solution for the second and the implementation is there but relies on zeitgeist since a lot of apps don't store their actions into gtk.recentmanager (we also are looking into https://live.gnome.org/GTK%2B/GtkRecentManagerAndZeitgeist) and most used can only be calculated by something that tracks history like Zeitgeist. I am up for the task of implementing this feature if a designer and a technical expert can dedicate some time to walk through concept with me. Cheers Seif On Wed, Oct 5, 2011 at 10:17 PM, Matthias Clasen wrote: > Hey, > > so according to the draft schedule that Andre posted a while ago, we > are in the middle of the 'feature proposal' period right now. I > haven't seen much feature discussion here at all yet, and so far, the > wiki only lists things that I have put there, which is a little scary > - I can't be the only one itching to get cool things into GNOME 3.4. > > Where are your ideas ? It would be great to get them onto that wiki > page, in particular since next weekend a bunch of us will get together > in Montreal to, among other things, spend time to talk about 3.4 > features. > > Anyway, to make a start, here are the things that have been proposed > as features so far: > >Boxes - a new application to access vms and remote systems > >Application menu / Actions / Jumplists - make the appmenu useful > >Lock Screen - unify the lock screen and the login screen, visually > >IBus/XKB support - make the region panel control input methods + > keyboard layouts together > >Network Zones >Network Panel Improvements - make networking not suck > >GNOME Documents >User Panel Improvements >Wacom Panel Improvements > - incremental improvements for various parts of the desktop > > More details at http://live.gnome.org/ThreePointThree/Features > > > Matthias > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Thu, May 19, 2011 at 10:53 AM, Olav Vitters wrote: > On Thu, May 19, 2011 at 01:10:02PM +1000, Andrew Cowie wrote: > > The number of times I have been mocked and derided and laughed at on IRC > > is staggering. "That's not a real distro". "That's not maintained by > > real GNOME people". "Don't use that" "Switch distros!" > > I see nothing wrong with the latter two: > "Don't use that" > "Switch distros!" > > That is perfectly valid advice. You need various things in your > distribution to help GNOME development. I would not advise anyone to use > Ubuntu anymore when they want to get involved with GNOME. > Can you explain to me how using Ubuntu makes getting involved with GNOME development harder or wrong (couldn't extract that out of your msg) > > GNOME should run on any distribution, but if a distribution has a big > focus and is known to be problematic to do development upon, advice on > that is a good thing. > We make it a problem where its not. We could harvest lots of talent from the Ubuntu community if we did not act like snobs and look down upon them. > > The first 2 statements are not good though: > "That's not a real distro" > "That's not maintained by real GNOME people" > > Though even the latter I could explain in a more 'assume mean well' way. > > Hope that if you get bad behaviour, you do speak with those people > privately. > -- > Regards, > Olav > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Apologies to GNOME
It has been a very bumpy road for Zeitgeist with GNOME. I really don't feel like going into details and history since this won't help us proceed. I admit my part of the problem. While I might not be the best developer around I do try to bring something new to the table and I do hope that GNOME can see it at some point. What started off as a GNOME project is now being endorsed by Unity, KDE and lots of small community projects. We worked on being a cross-desktop project with our roots in GNOME. I am not going to debate what needs to be changed in Zeitgeist to be more GNOME friendly (moving to git etc...) since its not fair for other deployments and not fair for us as developers who are used to our work environment. And while I might be the face of Zeitgeist the project has outgrown me and we have lots hackers and contributors around, so please feel free to get to know them. So to sum it up: "Sorry we've disagreed about things or I've come across badly in the past. I didn't mean to be impolite. just want to help bring some cool features to GNOME and GNOME Shell. I hope we can have a clean start and try and get along well from here" Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Shell + Tracker + Zeitgeist
Looking at the mockups by McCann I am looking for a Tracker + Zeitgeist integration in Shell. Except for Frequent, and Conversations I think everything else can be done over Tracker... I would love to know how Frequent will be categorized... I hope in frequency you could cluster into "today", "last week", etc... I would encourage using Tracker to get the data on the desktop... And then when asking for frequent and Conversations to ask Zeitgeist. But as an alternative to ease integration I think Tracker guys should look into supporting our ontology... This way Zeitgeist could use its extensions to push into Tracker. This way Tracker will know about the events we have and I think it would make it easier for the shell developers to only query Tracker for frequent stuff etc... What do you think? We already have the extensions ready for you guys thanks to Rob Taylor. Let me know what you think :) Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Activity Journal
Can you please elaborate why GAJ was not accepted... We are still clueless :) On Mon, May 3, 2010 at 12:56 AM, Thorsten Prante wrote: > Purpose: > > GNOME Activity Journal is not a File Browser but an Activity Browser. > > It uses the Zeitgeist Framework to display what you did and introduces a > better way of quickly finding the things that you were doing. > > > > Target: desktop > > > > Dependencies: > > Zeitgeist (external) > > PyGTK > > Python 2.5 > > Cairo > > DBus > > Pango > > > > Resource usage: > > Bug tracker: http://bugs.launchpad.net/gnome-activity-journal > > VCS: http://code.launchpad.net/gnome-activity-journal > > Releases: http://launchpad.net/gnome-activity-journal/+download > > > > We are waiting on GNOME git approval for a new repository at which point > all resources will be moved to the GNOME Infrastructure. > > > > Adoption: > > Packages (at least) for Debian/Ubuntu, Fedora, openSuSE > > > > GNOME-ness, community: > > GNOME Activity Journal is a pure community effort with the only commercial > backing being our last GSoC project and the Zeitgeist Hackfest in Bolzano > 2009. Right now, we are 2 core maintainers, 4 developers, and 2 designers. > We've striven to be open and visible in our development. This has also led > to a steady inflow of new contributors. > > > > Other notes: > > ... > > > > Status and future: > > The Journal is able to display all events of applications currently > supported by Zeitgeist, such as: > > - Totem > > - gedit > > - eog > > - Banshee > > - Rhythmbox > > - Tomboy > > - Firefox > > - git > > - bzr > > - Telepathy > > - vim > > - ... Anything that pushes into Recently Used > > We will provide a data-providers setup and management tool with our next > release. > > > > We are working to solve the performance issues on startup, caused by the > amount of data that is being requested over DBus from Zeitgeist. Our next > release should provide a proper solution. > > > > There is a more detailed plan attached to our 0.3.4 release announcement > [1]. > > > > -- > > On behalf of the GNOME Activity Journal team, > > Thorsten > > > > [1] https://lists.launchpad.net/gnome-zeitgeist-users/msg00048.html > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- This is me doing some advertisement for my blog http://seilo.geekyogre.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Dear GNOMErs, GNOME Activity Journal is being moved to the GNOME Development Infrastructure... However after some heavy discussion within the Zeitgeist team, we decided to keep Zeitgeist in Launchpad, and not move it to the GNOME Development Infrastructure. While Zeitgeist has been developed for GNOME it doesn't heavily depend on any GNOME modules. Thus Zeitgeist could also gain adoption outside the GNOME ecosystem if it remains slightly independent, which would only serve to strengthen its reliability and usefulness on the GNOME desktop too. Our current workflow and teamwork has adopted perfectly to Launchpad. We don't intend to move to Git now or in the foreseen future, since it will disturb our organizational and development habits. So in case Zeitgeist can not be a GNOME module because of its development infrastructure, we hereby withdraw our proposal of Zeitgeist being a GNOME module and propose it as an external dependency for GNOME Activity Journal, so it will always have a close relation to GNOME. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 22, 2010 at 11:52 AM, Luis Medinas wrote: > Qua, 2010-04-21 às 22:41 +0200, Mikkel Kamstrup Erlandsen escreveu: > > Purpose: > > Zeitgeist is an event logging framework. It stores user activity in a > > structured manner and provides a powerful DBus API to query and > > monitor the log. Zeitgeist as such does not have a graphical > > component, but is intended to integrate wherever it makes sense. > > > > Target: desktop > > > What's the plan to integrate zeitgeist with gnome-shell and other > applications ? I mean totem, nautilus, brasero, empathy etc... > > Also there's a plan to rewrite some API in C so other applications can > use zeitgeist API ? Or we are just suppose to interact with zeigeist via > dbus ? > > Cheers > Luis > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > While a C lib is *VERY CLOSE* to initial release. I think integration with Shell is not really up to us... If Shell team desires the integration we are willing to help. Other than that already wrote a set of plugins for logger-plugins for various GNOME applications such as Totem, Rhythmbox, Banshee, Eye of GNOME, Tomboy, gedit and more... Also we have some initial plugins for apps like totem and Rhythmbox to make use of "most used" media that we intend to release very soon. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 22, 2010 at 11:52 AM, Luis Medinas wrote: > Qua, 2010-04-21 às 22:41 +0200, Mikkel Kamstrup Erlandsen escreveu: > > Purpose: > > Zeitgeist is an event logging framework. It stores user activity in a > > structured manner and provides a powerful DBus API to query and > > monitor the log. Zeitgeist as such does not have a graphical > > component, but is intended to integrate wherever it makes sense. > > > > Target: desktop > > > What's the plan to integrate zeitgeist with gnome-shell and other > applications ? I mean totem, nautilus, brasero, empathy etc... > > Also there's a plan to rewrite some API in C so other applications can > use zeitgeist API ? Or we are just suppose to interact with zeigeist via > dbus ? Cheers > Luis > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > While a C lib is *VERY CLOSE* to initial release. I think integration with Shell is not really up to us... If Shell team desires the integration we are willing to help. Other than that already wrote a set of plugins for logger-plugins for various GNOME applications such as Totem, Rhythmbox, Banshee, Eye of GNOME, Tomboy, gedit and more... Also we have some initial plugins for apps like totem and Rhythmbox to make use of "most used" media that we intend to release very soon. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 22, 2010 at 7:37 PM, Sandy Armstrong wrote: > On Thu, Apr 22, 2010 at 10:34 AM, Germán Póo-Caamaño > wrote: > > On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: > >> Our current development is heavily based on launchpad. > >> We are discussing the issue and we don't see a problem to have our > >> trunk from launchpad ported to git with every release. However we do > >> want to keep our development branches in bzr+launchpad. So with every > >> branch merge with our launchpad trunk we can sync it with the gnome > >> trunk. The bigger issue will be bugzilla. We will have to tackle both > >> launchpad and bugzilla simultaneously. > >> > >> We really like the way our workflow works now, and we'd like to ensure > >> that this work can be synced with gnome thus we are trying to come > >> halfway here. Also as a crossdesktop project we intend to integrate > >> with other projects such as KDE and Meego. This makes launchpad a good > >> neutral ground. > > > > In such case, should not it be a freedesktop project and be proposed as > > an external dependency for the Activity Journal? > > The Activity Journal is in Launchpad and would have the same issues as > we've been discussing (except moreso due to translator requirements). > > Sandy > > The Activity Journal will be moved to GIT with our next release... so much I can guarantee :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. We really like the way our workflow works now, and we'd like to ensure that this work can be synced with gnome thus we are trying to come halfway here. Also as a crossdesktop project we intend to integrate with other projects such as KDE and Meego. This makes launchpad a good neutral ground. Cheers Seif On Thu, Apr 22, 2010 at 6:46 PM, Cody Russell wrote: > On Thu, 2010-04-22 at 07:15 +, j...@jsschmid.de wrote: > > > Perhaps an unholy alliance of bzr-git and Launchpad's git-import > > > feature can make all parts happy (at least vcs-wise)? I will take a > > > look at this when I have the time. > > > > I think you should rather see that the other way round - track your > > git.gnome.org stuff using bzr if you are more familiar with it but > > keep > > the "real" code in git. > > I think that's exactly what Mikkel was suggesting. Storing the code in > git.gnome.org, but then using Launchpad's git-import to import things > back to bzr branches in Launchpad so that all the developers can > continue to do their work the way they're familiar with. > > / Cody > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSOC Proposal
I think you should get in contact with the Tracker and Zeitgeist developers Tracker providers content indexing and semantic relations while Zeitgeist does contextual relevancy :) Please don't hesitate to visit us at #tracker on GIMPNET and #zeitgeist on Freenode Cheers Seif 2010/3/21 SUMIT RANJAN > Hi.. > I am Sumit, third year Computer Science student from India. I am very much > enthusiastic about contributing for gnome, in google SoC'10. I have come up > with a project idea, which I wish to work on. > > Description: I would like to develop a "User friendly Command Search Tool" > which gives users facility to search for a specific command offline. The > user can give a text input related to the command. The tool will generate a > list of commands with description, sorted based on relevance. > Currently, to search for a command we can do man -k or apropos or whatis , > which searches for keywords in a set of database files containing short > description of system commands and displays the result in standard output. > But the results obtained are plenteous or sometimes empty and are > alphabetically sorted. So it becomes very painful to find the expected > command from a huge list of results. > Take for an example, > when I search for "list content of directories" ==> empty > result > "file compression" ==> > empty result > "compression" ==> 15 > results(not sorted by relevance) > Benefits: This tool can be very useful for newbies who are not familiar > with linux commands. In such cases they have to google to get the command > they want. But in case of offline users they have no choice but to look into > linux reference manuals. > > To Do: 1) Ranking the results based on relevance (developing a ranking > algorithm) > 2) Making a GUI for the tool, which displays the results in a > user friendly manner, categorizing the results. > 3) Use data from linux forums to estimate the popularity and > usage of command. > 4) Do natural language processing of the input text, to give > good search results. > > These are initial thoughts of my idea. I would very much appreciate, if I > could receive some feedback on my idea and whether this can be feasible for > google SoC proposal. I am also looking for mentors, who might be interested > in this idea. > > With regards, > Sumit Ranjan > 3rd Year, CSE > Email Id: sumit.n...@gmail.com > Mob No.: +91-9952842678 > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module semi-proposal: gnome-shell
2009/11/3 Owen Taylor > On Mon, 2009-11-02 at 16:28 -0600, Brian Cameron wrote: > > Owen: > > > > It sounds like GNOME Shell will likely not integrate with GNOME 2.30. > > > > How are users expected to turn on/enable GNOME Shell? At the Boston > > Summit, I remember people suggesting that there should be a checkbox in > > the Preferences->Appearance capplet that the user can check it to start > > using GNOME Shell. Is this the plan? > > > > Whatever such interfaces are needed in the base desktop to provide end > > users with the ability to "switch" to GNOME Shell, I hope these > > interfaces make it into GNOME 2.30. Ideally, users should just need to > > install the new GNOME Shell, mutter, etc. modules and have their desktop > > "just work". Users should be able to enable GNOME Shell without needing > > to hack around with gconf-editor, .desktop files, etc. > > > > I think it will cause problems for adoption and testing if users need to > > reinstall patched versions of gnome-control-center (or whatever) in > > order to turn on GNOME Shell after installing the GNOME Shell packages. > > Hey Brian - > > Having a standard way to easily switch back and forth is a good idea, > thanks for bringing up the topic. For Fedora we've extended our "Desktop > Effects" capplet to allow changing to GNOME Shell as well as Compiz. > > > https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00119.html > > has a screenshot. It handles like checking for hardware 3D, letting the > user confirm that they still have a working session, and adjusting the > GConf settings for gnome-session to enable the appropriate window > manager and/or panel. > > The basic operation of this program is not at all Fedora specific but > there are a couple of things that are tied to the way we do things: > > - We use the 'compiz-gtk' script to launch Compiz > - We configure Compiz to use the GConf backend and allow setting > a couple of settings that way. > > We could try to make it more flexible to handle the way Compiz works on > other distributions, or even now if /usr/bin/compiz-gtk isn't there (and > it won't be there on any other distribution) then the Compiz option will > simply not be there, but maybe we should strip out the Compiz option > entirely and make it a "GNOME 3 Preview" tool, which would basically > have some explanatory text, a link to read more about GNOME 3, and the > ability to enable or disable. > > This could just be shipped right in the gnome-shell module, so it would > be installed if gnome-shell was and not otherwise. > > I don't think integrating this into the Appearance capplet really makes > sense - already we have very different things there: > > - Themes (advanced customization) > - The size of your font (see what you are doing) > - Change wallpaper (show off a picture of your kid) > > Adding another option in there that complete changes the entire way your > desktop works adds a whole extra and much more radical level to this. > > I'd be interested in hearing the opinions of different people who are > packaging up gnome-shell on what would be useful for them. The hard part > of the code is written, it's just a question of the details of the UI > and where we put it. > > > In terms of zeitgeist, there have not been any tarball releases as far > > as I can tell. If we are seriously considering adding zeitgeist into > > GNOME, I would think we should be starting to do more formal releases of > > the code. I would think the sooner the better. > > There were a couple of releases this summer: > > http://bloc.eurion.net/archives/2009/here-is-zeitgeist-0-2-1/ > > which Siegfried stepped up to do so there would be a stable base for > GNOME Shell integration while the code was being rewritten in the 0.3 > branch. (Apparently another rewrite is planned for the Zeitgeist > hackfest.) Correction the 0.3 is the rewrite planned to be done during the hackfest (we r not rewriting all just around 50%). We will release it as a 0.9 though since it will be our last iteration before we actually meet all the services we intended. So a 1.0 is sooner than u think > - Owen > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module semi-proposal: gnome-shell
2009/11/2 Jamie McCracken > On Mon, 2009-11-02 at 17:12 -0500, Owen Taylor wrote: > > > > > My initial understanding of the Zeitgeist engine was that it was > > a data collection engine to collect a rich view of how the user > > used their computer over time, which would then be used to build > > an OLPC style journal interface; but that understanding fuzzes > > at the edges when people are pressed about this, things like > > deducing related documents from temporal overlaps and tagging > > enter into the picture. This doesn't make me comfortable. > > > > There are also questions here of the relationship with Tracker. If > > Tracker really lives up to its promise, shouldn't timeline > > information simply be extra metadata added in the Tracker store; > > after all, a timeline really is just an indexed and extended > > view of the classic ctime/mtime/atime metadata? > > > > If querying the Tracker database for this is a) not sufficiently > > efficient b) too cumbersome to code c) requires expert training > > in RDF, then that, to me, would throw doubt on the whole Tracker > > enterprise. > > > > What would make us most comfortable would be a comprehensive > > picture of how Tracker, Zeitgeist, and Nautilus work together > > with the shell to allow finding your stuff. Now it is probably > > not completely realistic for me to hang await for this to show > > up in my inbox in finished form, so the first step (from my > > technical perspective) is to get a clear statement of what the > > Zeitgeist engine does, what new user interfaces are enabled by > > that operation, what it does *not* do, and how it relates to > > Tracker. > > > I dont want to comment too much on zeitgeist but AFAIK all querying, > tagging and event logging can be done in the tracker DB. A tracker miner > could be created to perform such logging although it seems the zeitgeist > team want to use a python daemon instead. > > Tracker has tried not to step on their toes and instead encouraged it to > use tracker as a backend which they are receptive too. (they are far > happier using tracker if it were included in Gnome). AFAIK, all their > queries can be expressed in sparql so tracker should be a good fit > > Timeline data is not persistent metadata like title/subject/mtime. Its > what I would call semi-persistent in that you would probably want to > store it for a limited time only (user preference for 3/6/12 month of > history). This could be added to tracker to stop it bloating up over > time. However the main concern I have is how much logging is done. > Zeitgeist, from what I heard, appears keen to log quite a lot of data > which would quickly bloat up any DB. I personally favour a coarse grain > approach that only logs important stuff like file, application and web > histories. > > I personally would like to merge zeitgeist functionality into tracker > but really its up to the zeitgeist team on whether they are willing to > do this (it would mean converting the python code to Vala/Genie or C as > well) > > jamie > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > Hey, Thanks alot Jamie for actually explaining most of the sutff I wanted to exlpain. During the course of Zeitgeist development we got into contact with alot of Tracker devs. To sum it down. Tracker and Zeitgeist are not the same. Tracker answers question relation the metadata as well as the content of data. "Get me songs from artist A", "Get me all docs with tag B" Zeitgeist covers how the data is used. "Get me most used applications and documents within a time period", "Which files did I have open while editing X" It is our plan to actually push our metadata about the items into Tracker keeping the info about the events for ourselves. I patched a dataprovider for Zeitgeist to send events to zeitgeist and the subject of these events to tracker. But also as discussed with some Tracker devs a total merge makes no sense. However a dependency is possible and also a current option that will be tested during the hackfest. We also log every focus switch to generate contextual relevancy. This would just bloat the the Tracker storage. We have an extra table to handle this. I will write a better explanation in a new mail on the tracker ML. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
Problem with thinking of these tecnologies as what wil lit give the user is a wrong approach IMHO. The 3 technologies provide developers of applications standards and tools to provide better user experience. Unless the technology has a client (Such as the Tracker Search uses the Tracker Storage) there is no point of discussion. Applications that use or depend on these technologies should suggest these modules to be integrated. Not the Developers themselves since all 3 projects don't provide first hand experience, but rather indirectly over other apps. If GNOME Shell (which will uses Zeitgeist thanks to GSoC) and Zeitgeist will start sotring its events into Tracker-Storage then by all means Tracker-Storage will be included. 2009/8/19 Philip Van Hoof > On Wed, 2009-08-19 at 00:27 +0200, Rodrigo Moya wrote: > > On Tue, 2009-08-18 at 16:48 -0400, Matthias Clasen wrote: > > > I think this recent discussion about tracker as a gnome module is > > > somewhat backwards. I don't think it is leading us anywhere to talk > > > about ontologies and rdf and events and timelines and metadata stores > > > and kernel apis before we answer the first question: > > > > > > What is the user problem that we are solving here ? > > > Can that be described in a paragraph ? > > > And if it can, is it something that a 'regular' user would recognize > > > as a problem he has on his computer ? > > > > > > Once we have the problem scoped out, we need to look at the user > > > experience we want to aim for in solving it. Will it be a single > > > search-for-everything dialog ? A query language ? Tagging everywhere ? > > > > > > After that, it might be possible to evaluate whether tracker, > > > zeitgeist, couchdb or something else can be part of the > > > implementation... > > > > > couchdb provides just the storage of any kind of data, no indexing, > > searching, etc, so I think they solve different problems. > > Agree > > > In fact, tracker could just use local files as storage or a couchdb > database. > > If using couchdb, it would get replication and synchronization for free, > > but it would still provide the indexing > > We were recently discussing using CouchDB as a possible backup endpoint > for Tracker, and/or as a redundant storage location for user-unique > metadata. The stores to CouchDB would in latter case be synchronous (not > as a result of a backup command, but immediate). > > With user-unique metadata I mean the non-reproducable / not-cache data: > the data that is set by the user and therefor uniquely stored. For > example the tags on resources that have no physical representation on > your filesystem. (Contacts and tags, for example, don't necessarily have > a physical representation on your FS). > > We evaluated CouchDB as a primary store over sqlite, but CouchDB lacked > *very* important features. This makes it undoable. Feel free to get in > touch with us to discuss which precise features I mean. > > > -- > Philip Van Hoof, freelance software developer > home: me at pvanhoof dot be > gnome: pvanhoof at gnome dot org > http://pvanhoof.be/blog > http://codeminded.be > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
- Tracker finds relationships between data over content. Song A and Song
B are form Artist Y who is from the same hometown of Artsit X
- Zeitgeist finds relationships between data over usage. Last week "
google.com" and "Project A" were used alot together. So google is now in
relationship with "Project A". In a month the relationship will expire
because I am done with Project A. So "google.com" is now not in
relationship with "Project A"
Zeitgeist is an event aggregation framework that just makes sense of events
happening on the computer. We have a defined format for how events should be
understood. We don't extract metadata ourselves. The metadata is extracted
by the applications that send the events since they know more about their
docs then anything form the outside.
A typical Zeitgeist usecase would be providing documents most used with
other documents or recently used with recent documents. Other usecases would
be notifying applications with events of interests. Such as notifying
parental control with any events with metadata related to porn etc...
Zeitgeist plays along well with CouchDB and Tracker:
Zeitgeist aggregats and logs events form apps! We try to make sense of
incoming events (which documents are still open thus share tags etc...)
The engine uses a felxible DB module that allows us to use any kind of DB.
This is intended to later store individual events into the Tracker storage
and team events into a CouchDB storage.
2009/8/18 Josselin Mouette
> Le mardi 18 août 2009 à 17:01 -0400, Colin Walters a écrit :
> > Tracker the arguments are more complex; I think what they're
> > effectively arguing is not that one individual use case but more the
> > network effects from having all of them in one database ("where did I
> > put that download from the email from Nancy" maybe?). I'm not sure.
> > But I won't attempt to summarize the previous thread. I would like to
> > see some sample UI though in something.
>
> Well, that sole sentence summarizes the previous thread.
>
> Tracker looks like great technology, but we need to see it in action
> before putting it blindly in the desktop. If only 3 of all possible
> Tracker uses were implemented in existing desktop applications, we would
> be able to clearly tell whether it is worth including.
>
> Cheers,
> --
> .''`. Josselin Mouette
> : :' :
> `. `' “I recommend you to learn English in hope that you in
> `- future understand things” -- Jörg Schilling
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
2009/8/19 Matthias Clasen > On Tue, Aug 18, 2009 at 6:49 PM, Seif Lotfy wrote: > > Problem with thinking of these tecnologies as what wil lit give the user > is > > a wrong approach IMHO. > > 'Designing' the next desktop by picking the cool-sounding technologies > to base it on first and leaving the user experience as something to be > worked out later is a disaster in the making. We can not do things > this way. > I never said pick the cool sounding, If the appliaiton providing good user experience uses a technology to do that then this technology should be considered! We need applications that make use of these technologies first then we can decide which tehcnology is better! Basically the better application will push the technology behind it! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
Problem with thinking of these tecnologies as what wil lit give the user is a wrong approach IMHO. The 3 technologies provide developers of applications standards and tools to provide better user experience. Unless the technology has a client (Such as the Tracker Search uses the Tracker Storage) there is no point of discussion. Applications that use or depend on these technologies should suggest these modules to be integrated. Not the Developers themselves since all 3 projects don't provide first hand experience, but rather indirectly over other apps. If GNOME Shell (which will uses Zeitgeist thanks to GSoC) and Zeitgeist will start sotring its events into Tracker-Storage then by all means Tracker-Storage will be included. 2009/8/19 Philip Van Hoof > On Wed, 2009-08-19 at 00:27 +0200, Rodrigo Moya wrote: > > On Tue, 2009-08-18 at 16:48 -0400, Matthias Clasen wrote: > > > I think this recent discussion about tracker as a gnome module is > > > somewhat backwards. I don't think it is leading us anywhere to talk > > > about ontologies and rdf and events and timelines and metadata stores > > > and kernel apis before we answer the first question: > > > > > > What is the user problem that we are solving here ? > > > Can that be described in a paragraph ? > > > And if it can, is it something that a 'regular' user would recognize > > > as a problem he has on his computer ? > > > > > > Once we have the problem scoped out, we need to look at the user > > > experience we want to aim for in solving it. Will it be a single > > > search-for-everything dialog ? A query language ? Tagging everywhere ? > > > > > > After that, it might be possible to evaluate whether tracker, > > > zeitgeist, couchdb or something else can be part of the > > > implementation... > > > > > couchdb provides just the storage of any kind of data, no indexing, > > searching, etc, so I think they solve different problems. > > Agree > > > In fact, tracker could just use local files as storage or a couchdb > database. > > If using couchdb, it would get replication and synchronization for free, > > but it would still provide the indexing > > We were recently discussing using CouchDB as a possible backup endpoint > for Tracker, and/or as a redundant storage location for user-unique > metadata. The stores to CouchDB would in latter case be synchronous (not > as a result of a backup command, but immediate). > > With user-unique metadata I mean the non-reproducable / not-cache data: > the data that is set by the user and therefor uniquely stored. For > example the tags on resources that have no physical representation on > your filesystem. (Contacts and tags, for example, don't necessarily have > a physical representation on your FS). > > We evaluated CouchDB as a primary store over sqlite, but CouchDB lacked > *very* important features. This makes it undoable. Feel free to get in > touch with us to discuss which precise features I mean. > > > -- > Philip Van Hoof, freelance software developer > home: me at pvanhoof dot be > gnome: pvanhoof at gnome dot org > http://pvanhoof.be/blog > http://codeminded.be > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
- Tracker finds relationships between data over content. Song A and Song
B are form Artist Y who is from the same hometown of Artsit X
- Zeitgeist finds relationships between data over usage. Last week "
google.com" and "Project A" were used alot together. So google is now in
relationship with "Project A". In a month the relationship will expire
because I am done with Project A. So "google.com" is now not in
relationship with "Project A"
Zeitgeist is an event aggregation framework that just makes sense of events
happening on the computer. We have a defined format for how events should be
understood. We don't extract metadata ourselves. The metadata is extracted
by the applications that send the events since they know more about their
docs then anything form the outside.
A typical Zeitgeist usecase would be providing documents most used with
other documents or recently used with recent documents. Other usecases would
be notifying applications with events of interests. Such as notifying
parental control with any events with metadata related to porn etc...
Zeitgeist plays along well with CouchDB and Tracker:
Zeitgeist aggregats and logs events form apps! We try to make sense of
incoming events (which documents are still open thus share tags etc...)
The engine uses a felxible DB module that allows us to use any kind of DB.
This is intended to later store individual events into the Tracker storage
and team events into a CouchDB storage.
2009/8/18 Josselin Mouette
> Le mardi 18 août 2009 à 17:01 -0400, Colin Walters a écrit :
> > Tracker the arguments are more complex; I think what they're
> > effectively arguing is not that one individual use case but more the
> > network effects from having all of them in one database ("where did I
> > put that download from the email from Nancy" maybe?). I'm not sure.
> > But I won't attempt to summarize the previous thread. I would like to
> > see some sample UI though in something.
>
> Well, that sole sentence summarizes the previous thread.
>
> Tracker looks like great technology, but we need to see it in action
> before putting it blindly in the desktop. If only 3 of all possible
> Tracker uses were implemented in existing desktop applications, we would
> be able to clearly tell whether it is worth including.
>
> Cheers,
> --
> .''`. Josselin Mouette
> : :' :
> `. `' “I recommend you to learn English in hope that you in
> `- future understand things” -- Jörg Schilling
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.27 Release Notes - Call for items
Hi guys, As for Zeitgeist and GNOME Zeitgeist. The engine has been released as 0.2 and we are working on the 0.3 should be done by end of august i hope! GNOME Zeitgeist should be released very soon too (2 weeks from now)! Having trouble with my notebook and so on but i think i can get things going bakc on trakc soon. GNOME Zeitgeist will just be the journal view while Zeitgeist will be an event-aggregation hub. We are trying to plan a Zeitgeist hackfest for november so GNOME devs can patch their apps to send their events to the Zeitgeist engine! That should be a big step towards 3.0 if you ask me. When talking about GNOME 3.0 can someone get in touch with the Tracker guys and see when they will release their storage? Same way KDE uses Soprano as their central meta data storage! I think GNOME should do the same with Tracker! From the Zeitgeist side its nto a big deal where we store as long as we can deliver! Cheers Seif 2009/8/4 Paul Cutler > Hello developers! It's time to start working on the release notes for the > upcoming GNOME 2.27 / 2.28 release. > > Please add your notes to this page for changes to applications in GNOME > 2.28: http://live.gnome.org/TwoPointTwentyseven/ReleaseNotes > > These just need to be bullet points, nothing fancy, and the release notes > team will follow up if additional detail is needed. > > In addition to what's new for users, I am hoping for detailed information > for developers with all the cleanup done in libraries for GNOME 3.0. > Speaking of 3.0, any advice on how we start talking about GNOME 3.0 / GNOME > Shell / Zeitgeist etc in the "Plans for next release" section. > > A big thank you to the Hamster team for already including new features. > > If you have any questions or comments, please let me know. > > Thanks! > > Paul > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
