Re: Feature Proposal: finding and rediscovering shared links
On Thu, Apr 19, 2012 at 3:40 PM, Seif Lotfy s...@lotfy.com 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. 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 -- 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 Sat, Apr 21, 2012 at 4:10 PM, Allan Day allanp...@gmail.com wrote: On Thu, Apr 19, 2012 at 3:40 PM, Seif Lotfy s...@lotfy.com 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
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 s...@lotfy.com 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 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
Re: Module Proposal: Zeitgeist
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 s...@lotfy.com 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 s...@lotfy.com 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
Re: Module Proposal: Zeitgeist
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? Where is this plan? And why isn't it going through the feature proposal process? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org 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. -- Shaun -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org 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
Re: Module Proposal: Zeitgeist
Shaun McCance wrote: 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. Indeed, there have been a few pages added on the wiki[1], some ported from 3.4, but it would really help the discussion if proponents were to send emails to this list. Also if there are features under discussion that are not listed over there, please add them, and bring the discussion over here. Thanks, Fred [1] https://live.gnome.org/ThreePointFive/Features ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
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 sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org 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
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 6:59 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org 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. These issues have been discussed at length on ddl in the past [1] and I believe that the relevant features have been through the process. For the 3.4 release we had emails [2, 3] and information on the wiki [4], for example. 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. I think that the community has been given an opportunity to discuss these proposals. Boxes was essentially rejected last round, if memory serves me correctly. I'm not saying that the feature proposal process is perfectly clear though. ;) Allan [1] https://mail.gnome.org/archives/desktop-devel-list/2010-April/msg00085.html [2] https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg3.html [3] https://mail.gnome.org/archives/desktop-devel-list/2011-November/msg00014.html [4] https://live.gnome.org/ThreePointThree/Features ___ 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 jstpie...@mecheye.net 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 s...@lotfy.com 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 s...@lotfy.com 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
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 lmedi...@gnome.org 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 sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org 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
On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org 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. That's the problem in reception: No meeting logs, no mailing list, all non-transparent - welcome to GNOME Designers, the new cabal. It's up to GNOME designers to change this but I'm not sure if everybody recognizes the problem at all. 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
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 11:24 AM, Allan Day allanp...@gmail.com wrote: I'm not saying that the feature proposal process is perfectly clear though. ;) It's a little rough, because we are only talking about features; we don't really get to address new technologies or libraries that we might want to make an existing application use without changing any features. For instance, let's say Xan who has indicated some interest to use Zeitgist in Web wanted to use it but not add any new features but instead uses Zg to store bookmarks then really does this process help that? Does he even need to come on DDL and say anything? After all, as maintainer it's his call as far as I'm concerned if he wants Zeitgist to powr his bookmarks. sri Allan [1] https://mail.gnome.org/archives/desktop-devel-list/2010-April/msg00085.html [2] https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg3.html [3] https://mail.gnome.org/archives/desktop-devel-list/2011-November/msg00014.html [4] https://live.gnome.org/ThreePointThree/Features ___ 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 Sat, Apr 21, 2012 at 11:22 AM, Luis Medinas lmedi...@gnome.org 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. Please, can we not finger specific companies when you write this? There isn't some cabal out there. It' shard for me to start taking anything seriously after the eye rolling after seeing this statement. 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!** See Alan's mail in this thread. sri Now talking about Zeitgeist 2012/4/21 Shaun McCance sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org 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
2012/4/21 Sriram Ramkrishna s...@ramkrishna.me On Sat, Apr 21, 2012 at 11:22 AM, Luis Medinas lmedi...@gnome.org 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. Please, can we not finger specific companies when you write this? There isn't some cabal out there. It' shard for me to start taking anything seriously after the eye rolling after seeing this statement. Sriram, 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. I don't want to point fingers to companies which i have much to thank for their hard work, specially their developers, but it's too much coincidence to have all these design decisions from the same people to go against all the community and also to developers who want to share their work with the GNOME Project just because it's not planned on the Design Team. Cheers Luis 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!** See Alan's mail in this thread. sri Now talking about Zeitgeist 2012/4/21 Shaun McCance sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org 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
On Sat, Apr 21, 2012 at 12:28 PM, Luis Medinas lmedi...@gnome.org wrote: 2012/4/21 Sriram Ramkrishna s...@ramkrishna.me On Sat, Apr 21, 2012 at 11:22 AM, Luis Medinas lmedi...@gnome.orgwrote: 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. Please, can we not finger specific companies when you write this? There isn't some cabal out there. It' shard for me to start taking anything seriously after the eye rolling after seeing this statement. Sriram, 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. I don't want to point fingers to The only point to my response was that fingering Red Hat specifically as part of a cabal is not productive. If people have issues then they should bring it up on foundation-list in a clear and concise manner. Most of what I've seen on shell list has been a re-hash of issues long discussed from 3.0 days. companies which i have much to thank for their hard work, specially their developers, but it's too much coincidence to have all these design decisions from the same people to go against all the community and also to developers who want to share their work with the GNOME Project just because it's not planned on the Design Team. In general, I think we should just address the issue and not drag in Red Hat, or Canonical or whatever the company du jour is. Again, it just distracts from the argument. That's all I'm saying. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.6 Feature: Initial setup
We haven't really gotten off the ground with 3.6 feature proposals yet, so I'll make a start by announcing something that I hope to complete for 3.6: A nice initial setup experience. I have created a feature page describing this here: http://live.gnome.org/ThreePointFive/Features/InitialSetup The design can be found here: https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup The idea here is that we should help a user who boots his newly installed GNOME for the first time with the setup tasks that are necessary to make the system usable. Traditionally, this has been distribution territory, with various tools like firstboot that run at some point in the boot phase before the login screen. We can do a nicer job by replacing the login screen on the first boot, and we can make the transition from the initial-setup tool to the user session seamless. The design currently has screens for - network - user account - location/timezone - online accounts The idea is that we want to ask as few things as possible while still ending up with a system that is ready to use. We don't want to ask for settings which have good defaults or can be autodetected. The initial-setup support in gdm will be entirely optional, so distributions can continue to use their own mechanisms if they prefer. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Initial setup
On 21 April 2012 21:47, Matthias Clasen matthias.cla...@gmail.com wrote: We haven't really gotten off the ground with 3.6 feature proposals yet, so I'll make a start by announcing something that I hope to complete for 3.6: A nice initial setup experience. I have created a feature page describing this here: http://live.gnome.org/ThreePointFive/Features/InitialSetup The design can be found here: https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup The idea here is that we should help a user who boots his newly installed GNOME for the first time with the setup tasks that are necessary to make the system usable. Traditionally, this has been distribution territory, with various tools like firstboot that run at some point in the boot phase before the login screen. We can do a nicer job by replacing the login screen on the first boot, and we can make the transition from the initial-setup tool to the user session seamless. The design currently has screens for - network - user account - location/timezone - online accounts The idea is that we want to ask as few things as possible while still ending up with a system that is ready to use. We don't want to ask for settings which have good defaults or can be autodetected. The initial-setup support in gdm will be entirely optional, so distributions can continue to use their own mechanisms if they prefer. This proposal assumes that Fedora's install procedure of ask some questions, do the install, reboot, and ask more questions is better than the install method used by OpenSUSE and Ubuntu of ask some questions, do the install and reboot. While the ask questions after install method is really convenient for OEM installs, only a very small percentage of Linux installs are done by OEMs. I think Fedora's install approach is more frustrating to people that want to get using their computer as soon as possible. If we ignore the OEM install use case, I think the remaining useful pieces for a first-login experience would be allowing the user to easily setup their online accounts and get an intro tour. These pieces would be useful to any user's first login, not just the person that installed the computer. In almost all cases, everyone using the same computer would have the same location (i.e. time, language keyboard) and basic network setup. Jeremy Bicha ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 11:48:59AM -0700, Sriram Ramkrishna wrote: For instance, let's say Xan who has indicated some interest to use Zeitgist in Web wanted to use it but not add any new features but instead uses Zg to store bookmarks then really does this process help that? Does he even need to come on DDL and say anything? After all, as maintainer it's his call as far as I'm concerned if he wants Zeitgist to powr his bookmarks. Essentially: * If you propose a new feature, it is accepted and it requires some new dependency: go ahead * If you want a new external dependency in an existing module: request approval or propose it as a new feature The point is that we don't want new external dependencies. But if you have a new feature, then make a choice propose it, and once accepted, run with it. The goal is having a new feature, if you need something to make the feature happen, use it. Further, this nicely avoids the cases where external dependencies have been approved, but actually nothing used it for various releases. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 8:10 PM, Olav Vitters o...@vitters.nl wrote: On Sat, Apr 21, 2012 at 11:48:59AM -0700, Sriram Ramkrishna wrote: For instance, let's say Xan who has indicated some interest to use Zeitgist in Web wanted to use it but not add any new features but instead uses Zg to store bookmarks then really does this process help that? Does he even need to come on DDL and say anything? After all, as maintainer it's his call as far as I'm concerned if he wants Zeitgist to powr his bookmarks. Essentially: * If you propose a new feature, it is accepted and it requires some new dependency: go ahead * If you want a new external dependency in an existing module: request approval or propose it as a new feature Thanks Olav for making that clearer. Maybe something for the FAQ? This will eliminate discussions on libraries and external dependencies. This also seems to make things a lot easier. The point is that we don't want new external dependencies. But if you have a new feature, then make a choice propose it, and once accepted, run with it. The goal is having a new feature, if you need something to make the feature happen, use it. Further, this nicely avoids the cases where external dependencies have been approved, but actually nothing used it for various releases. 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? sri -- 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
