Re: Design in the open
I'm completely and utterly against this idea, you might push away the noise, but you are pushing away all new contributors as well... how are you supposed to become a design contributor if you're not a programmer and you cannot contribute designs because you cannot join the mailing list since you can't become a foundation member? Maybe we should think about moderating the design mailing list in a smarter way... or maybe we should have a more formal design proposal process (some sort of wiki section/template or something) and ask people to write down and discuss their crazy proposals there instead of the mailing list, I'm sure there are better ideas in this regard. Asking people to become contributors (and then foundation members) first so that they can contribute seems like a really bad idea to me. 2012/5/2 Sriram Ramkrishna s...@ramkrishna.me On Apr 25, 2012 8:43 AM, Allan Day allanp...@gmail.com wrote: On Wed, Apr 25, 2012 at 9:55 AM, John Stowers john.stowers.li...@gmail.com wrote: 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. Many of your suggestions seem designed to address or avoid conflict, or to convey design team decisions in a better manner. This is not the source of my confusion nor my uncertainty in how to interact with the design team. In order to piece together the rationale or even the process for design team decisions I currently browse commit logs on the gnome-design github repo, and look at comments made when changing live.gnome.org pages. Some of you tweet stuff, others scatter it on google+. You suggest even using $some_new_webapp to better collaborate on designs. While I cannot see the discussion and the evolution of design team thought (even if I have the time to piece together all these sources of information) all I see is a decision by decree when a live.gnome.org page is created which describes the final design. My suggestion is thus the same as it was the last time this thread was raised - if the design team does not want to archive discussions on a mailing list, may they please allow IRC logging on the gnome-design channel. I'm not sure how useful logging the channel will be (lots of noise, etc), but I'd be happy to give it a go. The main thing is that we shouldn't stop there. IRC logs aren't going to fix the whole gamut of challenges that we face in relation to community design. You can even be proactive and send email updates to ddl or something. What about a mailing list of which only foundation members can subscribe to? I made this suggestion earlier. Sri I've lapsed in my design update blog posts, but I've got a new one in the works. You think emails would be better than blogging? u Of course if the canonical way to interact with the design is to show up on IRC at a specific hour then, IMO, you will lose contributors. I can hack any time of night when I have the motivation and the free time. But if I want to understand why the design team did something I have to... trust them? Trust them, or ask them, or a combination of the two. (Trust comes best once you gain experience of working with people, of course.) 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About fast dial contacts in Overview mode
Hey Petris, pec...@gmail.com pec...@gmail.com wrote: Hi everyone! Since GNOME Shell 3.2 I love feature of overview accessing contacts database and looking up their status. However, while I understand reasoning to have default behaviour to just open entry in Contacts app, I would like to have fast access to some kind of mini menu with communication methods to choose from - like, open conversation with this contact right now, or make a call - without opening Contacts app. What core design people/Empathy people think about such posibility? ... That could be nice. We're already discussing the possibility on Bugzilla [1]. Feel free to subscribe to the bug or to chip in. Best, Allan [1] https://bugzilla.gnome.org/show_bug.cgi?id=657715 -- 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: Module Proposal: Zeitgeist
+1 for me. I think there is some great potential for interesting features in GNOME. I've always been a big fan of the mapping of documents on a calendar so I know what I was working on a particular day. As a marketing guy, I'd like us to beat our competition with unique features that can't be seen on other platforms. sri -- Sriram Ramkrishna (sriram.ramkrishna_@@_...@.gmail.com (remove _@@_) On Tue, Apr 17, 2012 at 1: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 - 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
Re: Module Proposal: Zeitgeist
You know, when I first stumbled on zeitgeist running on my system a year or so ago, I didn't know what in the world it was doing, although it appeared to be logging... something. And I think I probably forced it to quit out of pure habit, before going online to figure out what it was actually doing. For the next few months I was pretty ambivilant about having it logging stuff on my system, and continued to kill it occasionally without really know what it was doing :p. And then I realized something - its actually quite useful. By keeping *ALL* logging in one place, it makes it much easier to keep track of, and also much easier to make sure that only those applications, etc which you want to be logged are actually logged. Of course, this is made immeasurabley easier w/ the awesome privacy settings in Ubuntu 12.04 (I'm honestly not sure - does such a thing exist in other distros?). Anyhow, to the point at hand... With GNOME-Clocks, having zeitgeist keep track of alarms, timers, etc makes sense since it allows users to close clocks when not in direct use, thereby saving resources while also keeping their alarms/timers/etc in place. The same I imagine is true for Epiphany/Web as well as many other programs. It also of course enables users to easily erase logs if/when they so choose, which is, IMHO just as important these days as keeping logs in the first place, if not more so. Emily -- Whatever you can do, or dream you can, begin it. Boldness has genius, power and magic in it. - Goethe Be who you are and say what you feel because those who mind don't matter and those who matter don't mind. - Dr.Seuss Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein ___ 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: 3.6 Feature: Initial setup
On Mon, 2012-04-23 at 14:08 -0400, Matthias Clasen wrote: Sure, I agree that the online account and intro tour steps are useful for every new user, not just the first. Beyond that, they are also useful for an existing user who just upgraded his system from GNOME 2 and is not familiar with the new features of GNOME 3. I'm confident that we can find a way to provide the same UI in these situations. The main focus of the feature as it is written now, is certainly the single-user machine - since that is a really common case (...not going to make up numbers). Online account setup and system tour are optional steps, not necessary to get the system running. We don't have the numbers to cover this, but neither majority of GNOME installs are OEM, nor majority of users install system for first time. They usually know what GNOME is and how to use it. I'm not saying these steps are not necessary, only optional. Users could take a tour before installing system on hard drive, eg. by launching a separate application. Usually you do test drive, before buying a car ;) As of online account and network setup, wouldn't it be better if installer copied user configuration made on live CD, including online accounts, network manager connections, wallpaper and favorite color scheme in gnome terminal? Currently typical Linux installation looks like this: 1. Launch desktop session 2. Run installer and answer questions 3. Reboot 4. Do system configuration (either manually, or by some initial setup software) Wouldn't it be better if it looked like this: 1. Ask user necessary questions (language, name, time zone?) 2. Launch desktop session 3. Let user configure it 4. Install system 4th step would only require to setup partitions and copy user configuration to hard drive - as few questions, as possible. Additionally to cover OEM use case, admin could skip step 1. In such case program asking for user details would run after reboot, when user powers on the machine for the first time. I think this way both sides would be happy: Individual users, who want to get system up and running as fast as possible and OEM installs, which need to provide a way for end user to do some first-time configuration. Regards, Krzysztof ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.6 Feature: Lock Screen
Hello, A little off topic, but since the move to gnome-shell I miss an automatic slideshow when the computer is idle (a screensaver in old terminology). How could it be integrated with the proposed design? Would customization of the lock screen be possible? Maybe a rotating background with a more transparent clock? Though I understand that the default design of locking could be a simple static clock (like on phones), that's not really appealing for a desktop... Anyway I like the new design, only the change of background when unlocking seems a bit weird. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
Hi Shaun, I *love* the idea of showing notifications and allowing control of media playback. It's something I've wanted for a very, very long time. But I share Bhaavan's concern with having to physically drag the screen up. It's very cumbersome with a mouse. And aside from being inconvenient, without keyboard-only use it's not accessible. We briefly touch (pun intended) on keyboard interaction at the bottom of the page. You should be able to unroll the curtain with Esc. How is the PIN supposed to be set? Will that involve changes to the User Accounts panel? The login options in the user settings panel is the obvious place place for customizing that. We are also working on the initial setup*, which would also be the place where this is exposed (but we don't have anything to point to at this stage). And while we're dealing with User Accounts and passwords, could we manage to do something about the password hint? You can set it, but it doesn't do anything useful in any software anywhere. It's kind of embarrassing to have to write that in the help. Thanks for bringing that up. I imagine this becomes useful after several failed attempts to authorize. cheers * https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
Hey Maciej, Why use PIN at all? (Apparently that is question for Windows 8 as well). Or is it for smartcards? PIN entry is an alternative authorization method for form factors where a typically long text entry (especially with numerals thrown in) is too much of a burden, like on a tablet device. I can see some additional methods, like using swipe patterns or face detection viable, but this seemed like the easiest approach. cheers -- Jakub Steiner http://jimmac.musichall.cz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome 3 issues
Hello, On to the point. Why did you screw up gnome menus? I've been using gnome since 2000, and it has been the best desktop available until gnome 3 came. I had a terrible car accident 31. Dets 2005, which caused me to spend 6 months in coma. That messed up my hands and I can't use mouse. That is why I liked gnome 2, everything could be done without mouse. And strange is ... why does virtualbox have normal menus, but real PC has this big mouse controlled menu?? VBox gnome 3: http://www.hot.ee/surma/Vbox_gnome3.jpg But real computers have this crappy menu: http://blog.fpmurphy.com/blog-images/gnome3cust1-40.png Here's an idea: Maake it so, under gonf-editor you can choose the layout of the menu. -Surma___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 3 issues
On Fri, 2012-04-27 at 09:40 +0300, surma wrote: Hello, On to the point. Why did you screw up gnome menus? I've been using gnome since 2000, and it has been the best desktop available until gnome 3 came. I had a terrible car accident 31. Dets 2005, which caused me to spend 6 months in coma. That messed up my hands and I can't use mouse. That is why I liked gnome 2, everything could be done without mouse. And strange is ... why does virtualbox have normal menus, but real PC has this big mouse controlled menu?? VBox gnome 3: http://www.hot.ee/surma/Vbox_gnome3.jpg But real computers have this crappy menu: http://blog.fpmurphy.com/blog-images/gnome3cust1-40.png Here's an idea: Maake it so, under gonf-editor you can choose the layout of the menu. -Surma ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Hi, I don't know if it is possible for you but you can open application by pressing windows key and entering the name of application (it search the list as you type so you may need to enter just a few first letters - and you can use arrow keys then as well). I believe there was some further work on accessibility on Gnome 3.4. If you are referring to any other menu could you explain what you have on mind? Best regards PS. There are Gnome shell extensions which allow to 'revert' the Gnome 2 look. I don't know how good work they are doing PPS. A really minor point but one you might be interested in - the configuration moved to dconf so changing anything in gconf will not have any effect. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On 04/26/2012 02:27 PM, Jakub Steiner wrote: Hi Shaun, Hello all, I *love* the idea of showing notifications and allowing control of media playback. It's something I've wanted for a very, very long time. But I share Bhaavan's concern with having to physically drag the screen up. It's very cumbersome with a mouse. And aside from being inconvenient, without keyboard-only use it's not accessible. We briefly touch (pun intended) on keyboard interaction at the bottom of the page. You should be able to unroll the curtain with Esc. How is the PIN supposed to be set? Will that involve changes to the User Accounts panel? The login options in the user settings panel is the obvious place place for customizing that. We are also working on the initial setup*, which would also be the place where this is exposed (but we don't have anything to point to at this stage). While talking about Pins, I thought of what the iPad does when you get it wrong and it's quite good I think. For my 3 year old son, when he enters it in incorrectly several times (not just 3 or so), it locks anyone out for a mater of time, I think it's 1 minute perhaps a few more (I don't remember). This might not be a desired feature on a multi-user OS, but for a single user OS it serves well I think. My son gets the point anyway, he can't sit there for hours trying and has to ask :) Is this something we're interested in seeing? -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ 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 Mon, 2012-04-23 at 22:41 +0200, Krzysztof Walo wrote: Wouldn't it be better if it looked like this: 1. Ask user necessary questions (language, name, time zone?) 2. Launch desktop session 3. Let user configure it 4. Install system 4th step would only require to setup partitions and copy user configuration to hard drive - as few questions, as possible. I agree with this - it's tricky though. What we would need is a way to track the configuration made during the live phase and apply it after installation. It's like the Sabayon problem. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 3 issues
On Fri, Apr 27, 2012 at 8:40 AM, surma su...@hot.ee wrote: That messed up my hands and I can't use mouse. That is why I liked gnome 2, everything could be done without mouse. And the same is true for Gnome3 - to navigate to an application, you can use super ctrlPgDown tab (tab | shifttab | arrow keys) (or super ctrlalttab, select Applications, (tab | shifttab | arrow keys)) Though generally superappnameenter is a lot faster. Maake it so, under gonf-editor you can choose the layout of the menu. I encourage you to give the normal Gnome3 experience another shot (personally I actually consider it more keyboard-friendly than Gnome 2), but if you insist, you can force fallback mode (at least for now): System Settings - Details - Graphics - Forced Fallback Mode Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 3 issues
Le jeudi 03 mai 2012 à 16:56 +0200, Florian Müllner a écrit : That messed up my hands and I can't use mouse. That is why I liked gnome 2, everything could be done without mouse. And the same is true for Gnome3 - to navigate to an application, you can use super ctrlPgDown tab (tab | shifttab | arrow keys) Wouldn't it be better to make right arrow replace the ctrlPgDown tab sequence. When you enter the overview mode, arrow keys are not used, and it seems more obvious to use them in order to switch between Window and Application view. Emmanuel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Reviewed-By: and pastebins
Hi, One of my goals for 2012 is to increase the number of patches I'm reviewing myself, and more generally, even further increase the percentage of patches that go into GNOME that have peer review. git-bz and splinter make this flow fairly good, however for trivial patches, especially when multiple developers are online at the same time, it can be highly convenient to use a pastebin, then on IRC another developer says ok. In this scenario, I don't want to lose the critical information that the patch has been reviewed (and who reviewed it). So here's the proposal: When doing the pastebin+IRC approach, the person committing the patch, if they have given it a non-superficial review, should add the tag: Reviewed-By: Jane Doe jane...@example.com to the git commit. This should mean exactly the same as it does in the Linux kernel's use: http://kerneltrap.org/mailarchive/linux-kernel/2007/10/8/332384 If patches have gone through bugzilla (as many nontrivial patches should), then it's not necessary to add the tag in the git commit as well, as long as the link to bugzilla is maintained, the information is stored there. Opinions? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 3 issues
Why did you screw up gnome menus? I've been using gnome since 2000, and it has been the best desktop available until gnome 3 came. I had a terrible car accident 31. Dets 2005, which caused me to spend 6 months in coma. That messed up my hands and I can't use mouse. That is why I liked gnome 2, everything could be done without mouse. And strange is ... why does virtualbox have normal menus, but real PC has this big mouse controlled menu?? VBox gnome 3: http://www.hot.ee/surma/Vbox_gnome3.jpg But real computers have this crappy menu: http://blog.fpmurphy.com/blog-images/gnome3cust1-40.png Hi Surma ! GNOME shell can be navigated using only the keyboard. Please, read https://live.gnome.org/GnomeShell/CheatSheet to to know how to use it. I was using only the keyboard when I read this email, so I know it can be used. I think shortcuts so some functions could a good idea, but it is totally functional IMHO. Here's an idea: Maake it so, under gonf-editor you can choose the layout of the menu. -Surma You don't need gconf to switch to the fallback mode. Go to System Settings Graphics Forced fallback mode Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reviewed-By: and pastebins
On Thu, May 3, 2012 at 12:00 PM, Colin Walters walt...@verbum.org wrote: Opinions? It would be nice if git-bz and splinter could work together to get Reviewed-By tags added automatically. In general, more patch review is of course a good thing, and keeping a better record of it is a great idea - as long as we can keep it from devolving into a bureaucracy. But I'm not sure if we can set a gnome-wide policy on this - we're hosting a ton of projects with fairly varied maintainership styles... it is probably most productive to establish this as a best practice for the core modules, and go from there. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 3 issues
- Mensaje original - De: Juanjo Marín juanjomari...@yahoo.es Para: surma su...@hot.ee; desktop-devel-list@gnome.org desktop-devel-list@gnome.org CC: Enviado: Jueves 3 de Mayo de 2012 18:23 Asunto: Re: Gnome 3 issues it is totally functional IMHO. BTW, I recommend GNOME 3.4, previous versions had some issues in my experience. You don't need gconf to switch to the fallback mode. Go to System Settings Graphics Forced fallback mode System Settings Details Graphics Forced fallback mode ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reviewed-By: and pastebins
Hi, On Thu, May 3, 2012 at 12:00 PM, Colin Walters walt...@verbum.org wrote: In this scenario, I don't want to lose the critical information that the patch has been reviewed (and who reviewed it). So here's the proposal: I think when the person who reviewed a patch is critical information, then the details of the review is normally also important. I don't think the person who reviewed a patch is always critical information, though. Certainly, drive-by pastebin patches should be trivial and obvious. If the proposed changes aren't trivial and obvious, then they should go to bugzilla first so there is a paper trail leading back to the discussion. Basically, adding the reviewer's name doesn't hurt anything, but my opinion is it doesn't necessarily help either. What does help is knowing that the patch was sanity checked at all (like you said), and not committed blindly, and at that point adding the person who did the sanity checking doesn't seem like a bad idea. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Rotting patches [was: Re: Reviewed-By: and pastebins]
On Thu, 2012-05-03 at 12:00 -0400, Colin Walters wrote: One of my goals for 2012 is to increase the number of patches I'm reviewing myself, and more generally, even further increase the percentage of patches that go into GNOME that have peer review. Offtopic, but the obvious first step would be to improve the rate of reviewed patches in general. While peer reviews are great, **in some projects** teams miss manpower already to have reviews at all, without any peer. (And if you are a first-time contributor and you never receive feedback on your first patch you give up and won't know where to escalate. That's where GNOME's contributor base remains small.) https://bugzilla.gnome.org/browse.cgi?product=FOO provides a link at the right to the list of unreviewed patches for the project FOO. Two examples: * gtk+: 637 unreviewed patches; 480 of them older than 12 months * gnome-shell: 125 unreviewed; 61 of them older than 6 months I wonder if anybody has ideas how (and time) to clean up, e.g. by setting needs-rework or simply rejecting unwanted fixes. Or agreeing in a team to have maximum XX unreviewed patches by 3.6.0 or so. https://mail.gnome.org/archives/patchsquad-list/ was one idea but never took off and has been dead as hell for years. 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: Gnome 3 issues
On Thu, May 3, 2012 at 5:18 PM, Emmanuel Pacaud emman...@gnome.org wrote: Wouldn't it be better to make right arrow replace the ctrlPgDown tab sequence. ctrlPgUp/PgDown are the standard GNOME shortcuts for switching between tabs, so I don't think removing them is a good idea. Obviously we could add left/right as additional shortcuts here[0], but note that there is a GSOC project to change how the application view is triggered[0], which makes those shortcuts kinda obsolete. Regards, Florian [0] those might conflict with (currently unimplemented) windows keynav though [1] http://jimmac.musichall.cz/log/?p=1181 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rotting patches [was: Re: Reviewed-By: and pastebins]
On Thu, 2012-05-03 at 19:14 +0200, Andre Klapper wrote: While peer reviews are great, **in some projects** teams miss manpower already to have reviews at all, without any peer. If one doesn't have any peers for a particular project, yes, clearly there's no one to review. However we should be able to do significantly better than we are at building out the peering relationships between individual components. (And if you are a first-time contributor and you never receive feedback on your first patch you give up and won't know where to escalate. That's where GNOME's contributor base remains small.) https://bugzilla.gnome.org/browse.cgi?product=FOO provides a link at the right to the list of unreviewed patches for the project FOO. Two examples: * gtk+: 637 unreviewed patches; 480 of them older than 12 months * gnome-shell: 125 unreviewed; 61 of them older than 6 months That does seem very high, but note some of these *have* been reviewed, and both the reporter and reviewer agree there's a needs-work state. I wonder if anybody has ideas how (and time) to clean up, e.g. by setting needs-rework Right; offhand my guess is that's the effective state for at least 30-40% of these. Or agreeing in a team to have maximum XX unreviewed patches by 3.6.0 or so. It's going to be a continual process I think; setting hard targets might help. Just talking about it will help too as we are now =) FWIW, I marked some gnome-shell needs-work/rejected patches as such so something happened besides words... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rotting patches [was: Re: Reviewed-By: and pastebins]
On Thu, May 3, 2012 at 1:14 PM, Andre Klapper ak...@gmx.net wrote: On Thu, 2012-05-03 at 12:00 -0400, Colin Walters wrote: One of my goals for 2012 is to increase the number of patches I'm reviewing myself, and more generally, even further increase the percentage of patches that go into GNOME that have peer review. Offtopic, but the obvious first step would be to improve the rate of reviewed patches in general. While peer reviews are great, **in some projects** teams miss manpower already to have reviews at all, without any peer. (And if you are a first-time contributor and you never receive feedback on your first patch you give up and won't know where to escalate. That's where GNOME's contributor base remains small.) https://bugzilla.gnome.org/browse.cgi?product=FOO provides a link at the right to the list of unreviewed patches for the project FOO. Two examples: * gtk+: 637 unreviewed patches; 480 of them older than 12 months * gnome-shell: 125 unreviewed; 61 of them older than 6 months I try to comb through this list for gnome-shell often, looking for ACN/ACAF patches I can push, or and looking through the none ones to see if I can review them. Yes, a large majority of them are still unreviewed, usually because I don't know the state of the patch, nor if we want the feature in the first place. I wonder if anybody has ideas how (and time) to clean up, e.g. by setting needs-rework or simply rejecting unwanted fixes. Or agreeing in a team to have maximum XX unreviewed patches by 3.6.0 or so. https://mail.gnome.org/archives/patchsquad-list/ was one idea but never took off and has been dead as hell for years. 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 -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Wed, 2012-04-25 at 14:27 +0100, Allan Day wrote: But there are challenges and things we can do better. Among those obstacles, I see: * lack of design resources - we are always trailing behind where we want to be, and there are important tasks which we are unable to complete (a new HIG springs to mind) * improving the quality of design - we can always do better * getting the project behind a common vision - we sometimes lack focus * giving people a stake in the project - the danger of design-led development is that people feel that the project is no longer theirs. They want to feel they can have an impact and that they can express themselves through their activities in the community. * design disagreements can sour relationships and lead to discord * letting people stay in touch with and understand design activities, and therefore the activities of the project as a whole * helping community members to participate in design activities Fully agreed on all counts. As a way to solve these issues, I'd like to follow up on an idea which I sketched during last year's Desktop Summit - namely, about constructing a pattern language for Gnome's design based on the good things that what we have and what other systems have done well. If you have an hour or two, I heartily recommend that you read this paper: http://www.visi.com/~snowfall/LinguaFranca_DIS2000.html It's by Thomas Erickson, Lingua Francas for Design: Sacred Places and Pattern Languages. The tl;dr version (even shorter than the abstract) is this: * He gives an example of how people managed to construct a common vocabulary of the things that work well in their town (even with people not being fully aware of them), and use that knowledge to know *what* to replace and what to leave as-is. Then, he exposes Pattern Languages in general, as a form of vocabulary to embody knowledge gained through experience. Then he explores a possible pattern language for (social) interaction design. In particular, in section 5.2.2 he summarizes a pattern language for a design consultancy - something from which I think we could borrow ideas. His point is that having a pattern language gives you a way to communicate between people of different backgrounds and interests: designers, developers, users. They can all take part in the design and construction of their (software) environment, all in their best capacity, and be assured that the result will be good, usable, and that it will be able to evolve well as needs change. As for how Gnome's pattern language would help with the issues you mentioned: * Lack of design resources. Learning any kind of design is a big effort. By starting with a common vocabulary, which embodies a lot of concrete experience from past designs, we can get people up to speed. A pattern language takes the mystery out of design and lets you talk in concrete terms. It *will* take time for a newcomer to learn all the intricacies of the design, but at least he has a guide and a method of reasoning about it. * Improving the quality of the design. A pattern language gives you a way to measure things, at least on a qualitative basis. For example, This proposal for workspace thumbnails does well on the EASE OF NAVIGATION and EXPLORABLE INTERFACE patterns, but it is lacking in the PRINCIPLE OF LEAST SURPRISE one because... * Getting the project behind a common vision. As Erickson mentions in his paper, a pattern language often has a definite set of values put in it. Gnome strives for certain values - software freedom, ease of use, functionality, accessibility. Our patterns can embody these values and let us evaluate things more clearly rather than only through abstract wishes. * Giving people a stake in the project. Patterns are defined recursively; a pattern language has rather a fractal structure with big patterns composed of smaller patterns. The EXPLORABLE INTERFACE could embody patterns like UNDO/REDO, INSTANT FEEDBACK, etc. In turn, those smaller patterns can be implemented in a number of ways, aided by even smaller patterns. If you set the big picture, people can implement the sub-parts to their liking, but always based on the desired patterns. This gives them a stake in the project - they can agree on *what* is needed to make a good design, even if they don't know exactly what the final parts will look like, and they can own the implementation of their own little parts. * Resolving disagreements. This is about ensuring that one design can be compared against another one and be evaluated with respect to desirable patterns. Or it can be about disassembling both competing designs into their smaller patterns, and seeing if a combination of them would be even better. * Letting people understand design activities. With a pattern language, new designs become easy to explain. We moved notifications to the corner because we want the PERIPHERAL AWARENESS pattern in concord with the FOCUSED WORK pattern. * Helping
Re: Design in the open
On Thu, May 3, 2012 at 5:19 PM, Federico Mena Quintero feder...@gnome.org wrote: As a way to solve these issues, I'd like to follow up on an idea which I sketched during last year's Desktop Summit - namely, about constructing a pattern language for Gnome's design based on the good things that what we have and what other systems have done well. This. +1. From my experience on film stuff, having a way to refer to those things that look good or bad is essential to have collaboration between different specialists. Framing shots would be impossible if there wasn't an abstract way of describing them (flat/deep, warm/cold, lenses, etc). Sound designers/editors, photography directors, even actors, need to be aware of this language for efficient communication during production. I have been thinking lately that film making has many similarities with Free Software development. Being both abstract things with an audiovisual result that involves many different specialists. A common language of patterns is an awesome idea. I'd encourage Federico to expand on the subject. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
