Re: Features for 3.9/3.10
Fixing old bugs :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://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 !
2011/10/8 Zeeshan Ali (Khattak) : > Hi Mathias, > > On Wed, Oct 5, 2011 at 11: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. > > Was wondering if we could take-up this forgotten feature planned for > 3.1: https://live.gnome.org/ThreePointOne/Features/Sharing > > AFAIK, the issue was that designers were way too busy with more > important features in 3.1 so they didn't get any time for this one. > Lapo has started to investigate this it seems and last I asked > Bastien, he was also interested(?) in getting this done in 3.3 cycle. I'm interested in networking and sharing is one of the variables of the equation. I'll be happy to work on the design part as soon as the network panel design is done. Sharing means a lot of things btw, so we need a plan at least. > Regards, > > Zeeshan Ali (Khattak) > FSF member#5124 > ___ > 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 !
Hi, Zeeshan Ali (Khattak) wrote: > > On Wed, Oct 5, 2011 at 11:17 PM, Matthias Clasen > wrote: >> >> 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. > > Was wondering if we could take-up this forgotten feature planned for > 3.1: https://live.gnome.org/ThreePointOne/Features/Sharing > > AFAIK, the issue was that designers were way too busy with more > important features in 3.1 so they didn't get any time for this one. > Lapo has started to investigate this it seems and last I asked > Bastien, he was also interested(?) in getting this done in 3.3 cycle. > I would love to see Tracker getting involved with this feature as well. An application like Rygel relies on Tracker sharing/serving the media files indexed by Tracker (ignoring the MediaExport plugin for convenience). There is, however, no (GUI) way to limit what is actually shared. When you want to share files indexed by Tracker through Rygel then all indexed files are shared. This means that one gets to see loads of media on e.g. a TV, also including files one would never want to view it here. E.g. video's from work related project folders, images downloaded or created for development purposes, etc. The sharing feature would be perfect to fill this gap. What can be selected to be shared through the sharing feature should not, or does not have to be, limited to what Tracker actually indexed though. This can remain system-wide folder based as currently suggested. There is, however, the matter of sharing something which is not being indexed by Tracker in the currently planned file availability approach. Tracker does not index a complete system by default. In an ideal world this would/should be the case, but what should be done until that time if something is shared which is not indexed by Tracker? I would like to suggest the following: - An application requiring metadata from Tracker (e.g. Rygel or Banshee for that matter) should register itself as such. - The application should also make known if it accepts specified shares not indexed by Tracker. - A check should be performed by the "Privacy and Sharing" dialogue if something is shared through that dialogue for an metadata-dependant application. - All is fine if all shared files are already indexed - A dialogue will be presented to the user when something is shared which is not indexed, asking if the user wants to add the files/folders in question to Tracker's indexing scope, modifying Tracker's config. - If the user refuses than the action taken depends on the application and if it accepts unindexed shares. If yes, set the shares anyway. If no, do not set those shares and tell the user why. - A boolean property is set in Tracker for those files/folders indexed and to be shared. In case of Rygel this would be the "nmm:uPnPShared" property. - It's up to the metadata-dependant application to provide a fall-back which could automatically kick in when it comes across unindexed shared files/folders of which it needs metadata. Besides the matter above there's also the matter of excluding specific folders. In addition to being able to specify which folders should be shared recursively, it would also be great to exclude specific folders within those recursively shared ones. Yours, Age Bosma -- View this message in context: http://old.nabble.com/Features-%21-tp32599349p32621481.html Sent from the Gnome - Desktop - Dev mailing list archive at Nabble.com. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
> Features ! > > From: Matthias Clasen > To: desktop-devel-list > Subject: Features ! > Date: Wed, 5 Oct 2011 16:17:00 -0400 > 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 ? At the GNOME Summit in Montreal, I spoke to Cosimo and Ryan about features I hope can be included in GNOME 3.4: gnome-control-center - Central file-sharing management (multi-protocol, user and system shares). https://bugzilla.gnome.org/show_bug.cgi?id=658498 http://bugs.launchpad.net/bugs/841523 nautilus - Continue copying files when user interaction is needed. https://bugzilla.gnome.org/show_bug.cgi?id=661343 http://bugs.launchpad.net/bugs/871492 http://brainstorm.ubuntu.com/idea/28648/ (New brainstorm for this idea) http://brainstorm.ubuntu.com/idea/15427/ (Other implementation ideas here) Cheers, - komputes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On sáb, 2011-10-08 at 11:48 -0400, Jeremy Bicha wrote: > GNOME's implementation is very young; I have a hard time finding apps > on my computer using this feature even in GNOME 3.2; There are no jumplists in GNOME 3.2, which explains your troubles finding apps making use of this feature ;-) Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On 6 October 2011 08:13, 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 Personally, I think it would be a good idea if the GNOME jumplists and the Unity jumplists shared the same implementation so that app developers could have the extra functionality for both platforms and only have to do the work once. There may be some design issues and this is probably equally a request to the Ubuntu developers (several of whom do read this list) as it is the GNOME ones, but I think crossplatform interoperability is a good thing to aim for. GNOME's implementation is very young; I have a hard time finding apps on my computer using this feature even in GNOME 3.2; Unity has more apps using jumplists. Jeremy Bicha ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
Hi Mathias, On Wed, Oct 5, 2011 at 11: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. Was wondering if we could take-up this forgotten feature planned for 3.1: https://live.gnome.org/ThreePointOne/Features/Sharing AFAIK, the issue was that designers were way too busy with more important features in 3.1 so they didn't get any time for this one. Lapo has started to investigate this it seems and last I asked Bastien, he was also interested(?) in getting this done in 3.3 cycle. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On 6 Oct 2011, at 10:31, Martyn Russell wrote: > - Is the "universal access" configuration page meant to be in a larger font > and look completely different to the other page fonts? Yes -- you'll notice it's only the "Seeing" tab that has the bigger font, for (hopefully) somewhat obvious reasons. That said, OS X used to do this on its "Seeing" prefs pane too, but they've stopped doing it in Lion, and I'm not convinced either. Partly because I don't think we actually make the font "bigger enough" in GNOME, so it just looks like a bug, and partly because you have to be able to navigate a few "normal-sized" controls to get to this point anyway, so it seems like a bit of a moot gesture to me. Cheeri, Calum. -- CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd. mailto:calum.ben...@oracle.com Solaris Desktop Team http://blogs.oracle.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Oracle Corp. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
Le jeudi 06 octobre 2011 à 10:34 +0200, Joaquim Rocha a écrit : > Still on the bottom area, I wish that when my status is available, > notifications would stick in a visible area. It often happens that I'm > far from the keyboard for 5 minutes, meanwhile a notification came (say > someone is trying to chat with me) but timed out and is now hidden in > the tray area. I end up answering those notifications much later when I > happen to notice them. Maybe this could be configured so when the status > is "available" and a notification comes, the tray area would be visible > constantly until one focus another area. Yeah missing incoming messages is a real pain with the Shell; see https://bugzilla.gnome.org/show_bug.cgi?id=641723 -- Guillaume Desmottes Jabber GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, 2011-10-06 at 09:08 -0700, Michael Knepher wrote: > On Thu, Oct 6, 2011 at 7:14 AM, Matthias Clasen > wrote: > On Thu, Oct 6, 2011 at 9:38 AM, Joaquim Rocha > wrote: > > > Why not have a switch in the Universal Access settings that > shows/hides > > the icon/menu? > > > That's a trick question, right ? I would love to see you use > the > switch to bring the menu back... > > I'm pretty sure he meant in the System Settings panel, not in the menu > itself. Yeah, from my words "[...] a switch in the Universal Access **settings** that shows/hides the icon/menu [...]". Having it in the a11y menu would not be very smart. -- Joaquim Rocha signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, Oct 6, 2011 at 7:14 AM, Matthias Clasen wrote: > On Thu, Oct 6, 2011 at 9:38 AM, Joaquim Rocha wrote: > > > Why not have a switch in the Universal Access settings that shows/hides > > the icon/menu? > > That's a trick question, right ? I would love to see you use the > switch to bring the menu back... > > I'm pretty sure he meant in the System Settings panel, not in the menu itself. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
a11y menu access (was Re: Features !)
Changing subject. As Matthias said, this is somewhat off-topic, as the original thread was about start to propose features. On 10/06/2011 01:50 PM, Alan Cox wrote: >> Someone said, "well, if it is my house, I should be able to chose", the >> reason that rationale doesn't work is because the GNOME Shell experience >> should be designed to be inclusive, so this is really closer to an office >> building or an apartment building instead of a private house. > The flaw in your logic starts beyond the front door. Clearly the login > process should be accessible, and the install and setup so that a user > can always get their system set up. > > However at the point beyond login that ceases to be true. It's necessary > that the accessibility starts available somewhere (or can be enabled > accessibly in the login) but beyond that point the user should be able to > disable it for their account. Things are not as easy as that. In some cases accessibility is not just about disable/enable something, and some disabled users doesn't need a specific feature always. For example, although some users are used to use magnification, they don't need it to login. Related to that, Joseph Scheuhammer is working on the UI to configure the zoom, and also provide brightness/contrast effects, with a high control on his configuration, as not all the users needs the same value (he is planning to propose that as a 3.4 feature btw). Users could use a contrast configuration, but then decide to change it. Having the menu access allow users to access that part easily. > > If someone needs accessibility to use my account then probably I've been > hacked by someone disabled. Granted it could be I have become disabled > but that hopefully doesn't happen to people suddenely very often. Sure > it'll happen slowly by age to many of us. Also if you can force > accessibility on as a login choice that is still ok. As I said, IMHO, we can't force the user to configure all the aspects of accessibility at login time. If not, he will require to logout if he want to change something. And this is something that we can say about any other session configuration. As you mention "it'll happen slowly by age", I will give another example. Magnifiers are heavily used by old people. But this is not usually a "all or nothing" situation. They can interact with the computer, but if they start to feel tired, they can decide to start the magnifier. > > It seems to me you can meet both sets of requirements quite easily, and > that an always accessible login with the ability to force a session to be > accessible covers the corner cases too. I made some examples that I guess you include on "the corner cases". IMHO, is making things more complex. In my personal opinion, a11y menu access should be there by default, but I don't see any problem to provide a way to hide it. BR -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On 6 October 2011 15:55, Jasper St. Pierre wrote: > On Thu, Oct 6, 2011 at 10:54 AM, Rodrigo Moya wrote: >> yes, that makes sense indeed. But apart from that, it should really >> support all kind of tablets, not only Wacom ones :) > > Of course. That's sort of orthogonal though. As far as I know, the > realistic problem is that we currently only have a good Wacom driver > in the kernel that we can use. Rigth, see the 4 question in this interview to Peter Hutterer aboout the Wacom panel: [1] [1] http://libregraphicsworld.org/blog/entry/peter-hutterer-on-the-gnome-applet-for-wacom-tablets -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, 2011-10-06 at 16:54 +0200, Rodrigo Moya wrote: > On jue, 2011-10-06 at 10:49 -0400, Jasper St. Pierre wrote: > > On Thu, Oct 6, 2011 at 10:36 AM, Rodrigo Moya wrote: > > > On jue, 2011-10-06 at 10:31 +0100, Martyn Russell wrote: > > >> > > >> - Integration with thunderbird in the calendar (there is a red hat bug > > >> about this somewhere I saw recently) > > >> > > >> - Why show the "wacom graphics tablet" configuration page in the "System > > >> Settings" if I don't have one? (perhaps Ubuntu specific) > > >> > > > not ubuntu specific, but yes, your are right, it shouldn't show up, or > > > even better, it should be something about tablets in general, not only > > > Wacom > > > > If we show it only when you plug the device in, will you know that > > there is a magic panel for Wacom tablets in the System Settings that > > appears when I plug in my newly-bought Wacom tablet? Should we pop it > > up automatically when you plug in a tablet? Maybe a notification that > > asking to configure it that opens the panel? > > > yes, that makes sense indeed. But apart from that, it should really > support all kind of tablets, not only Wacom ones :) There's no drivers for anything else. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, Oct 6, 2011 at 10:54 AM, Rodrigo Moya wrote: > yes, that makes sense indeed. But apart from that, it should really > support all kind of tablets, not only Wacom ones :) Of course. That's sort of orthogonal though. As far as I know, the realistic problem is that we currently only have a good Wacom driver in the kernel that we can use. -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On jue, 2011-10-06 at 10:49 -0400, Jasper St. Pierre wrote: > On Thu, Oct 6, 2011 at 10:36 AM, Rodrigo Moya wrote: > > On jue, 2011-10-06 at 10:31 +0100, Martyn Russell wrote: > >> > >> - Integration with thunderbird in the calendar (there is a red hat bug > >> about this somewhere I saw recently) > >> > >> - Why show the "wacom graphics tablet" configuration page in the "System > >> Settings" if I don't have one? (perhaps Ubuntu specific) > >> > > not ubuntu specific, but yes, your are right, it shouldn't show up, or > > even better, it should be something about tablets in general, not only > > Wacom > > If we show it only when you plug the device in, will you know that > there is a magic panel for Wacom tablets in the System Settings that > appears when I plug in my newly-bought Wacom tablet? Should we pop it > up automatically when you plug in a tablet? Maybe a notification that > asking to configure it that opens the panel? > yes, that makes sense indeed. But apart from that, it should really support all kind of tablets, not only Wacom ones :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, 2011-10-06 at 10:31 +0100, Martyn Russell wrote: > - Integration with thunderbird in the calendar (there is a red hat bug > about this somewhere I saw recently) Also see https://bugzilla.gnome.org/show_bug.cgi?id=660720 > - Why show the "wacom graphics tablet" configuration page in the "System > Settings" if I don't have one? (perhaps Ubuntu specific) https://bugzilla.gnome.org/show_bug.cgi?id=657424 is probably related. > - I think the "default actions" is hidden in the "System Info" > configuration page and makes more sense to be put into a new place > *with* the actions for removable media. Both feel related to me. Also see https://bugzilla.gnome.org/show_bug.cgi?id=647442 andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper | http://www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, Oct 6, 2011 at 10:36 AM, Rodrigo Moya wrote: > On jue, 2011-10-06 at 10:31 +0100, Martyn Russell wrote: >> >> - Integration with thunderbird in the calendar (there is a red hat bug >> about this somewhere I saw recently) >> >> - Why show the "wacom graphics tablet" configuration page in the "System >> Settings" if I don't have one? (perhaps Ubuntu specific) >> > not ubuntu specific, but yes, your are right, it shouldn't show up, or > even better, it should be something about tablets in general, not only > Wacom If we show it only when you plug the device in, will you know that there is a magic panel for Wacom tablets in the System Settings that appears when I plug in my newly-bought Wacom tablet? Should we pop it up automatically when you plug in a tablet? Maybe a notification that asking to configure it that opens the panel? -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On jue, 2011-10-06 at 10:31 +0100, Martyn Russell wrote: > > - Integration with thunderbird in the calendar (there is a red hat bug > about this somewhere I saw recently) > > - Why show the "wacom graphics tablet" configuration page in the "System > Settings" if I don't have one? (perhaps Ubuntu specific) > not ubuntu specific, but yes, your are right, it shouldn't show up, or even better, it should be something about tablets in general, not only Wacom > - Why show the "Additional Drivers" configuration page in the "System > Settings" if there aren't any? (perhaps Ubuntu specific) > ubuntu specific yes, and just a temporary way of not having this disappear. We are discussing what to do with this, since having separate dialogs is very ugly > - The "Language Support" configuration page is a dialog and not > integrated like the others. > again also ubuntu specific, and hopefully will go away if we get the region panel in g-c-c to have the 2 missing features (installing langs and input method config) for 3.4 > > - I think the "default actions" is hidden in the "System Info" > configuration page and makes more sense to be put into a new place > *with* the actions for removable media. Both feel related to me. IT's > essentially what my computer does when I want to do particular work with > either media or applications. > we have removable media in the system info panel for 3.3, but yes, it really needs a rename. Maybe 'System' is enough? cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, Oct 6, 2011 at 9:38 AM, Joaquim Rocha wrote: >> >> It should be easy to do because the purpose of the desktop is to make >> things easy. I agree you don't want it off automatically because you need >> to be sure that a user can find the accessibility features if they do >> need them. > > I completely agree with Alan. > > Why not have a switch in the Universal Access settings that shows/hides > the icon/menu? That's a trick question, right ? I would love to see you use the switch to bring the menu back... Anyway, this entire discussion is predicated on the premise that it is a) good to make things configurable b) good to make these knobs easily available I don't agree with either of these. 'I want it gone' is a good argument for making the a11y menu removable. And 'desktops should be easy' is a good argument for putting the knob right into the menu itself. But... all of this is more of a side-show anyway. I was asking about features you want to see worked on (or, more interesting) work on yourself for 3.4. 'Everything I don't like in GNOME 3.2' is a discussion worth having, but not quite the same thing. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, 2011-10-06 at 13:28 +0100, Alan Cox wrote: > > You're assuming the install and the setup is done by a) the same person that > > is going to use the computer, which is not the case most of the time and b) > > that the person that uses the computer is always the same one. > > No. > > > Not true, some seats have unique users (think of a university lab, or a > > multi seat setup in an office), some of these have a unique user for anybody > > that logins automatically > > And those environments already need to lock all the configuration down > anyway or regenerate it each login otherwise someone will leave it in > 320x200 pixel mode and in Korean because it's "funny". > > > setting in the universal access pane or just in GNOME Tweak Tool is > > something I leave up to the designers), but I don't think it should easily > > switched off, and by no means automatically switched off. > > It should be easy to do because the purpose of the desktop is to make > things easy. I agree you don't want it off automatically because you need > to be sure that a user can find the accessibility features if they do > need them. I completely agree with Alan. Why not have a switch in the Universal Access settings that shows/hides the icon/menu? I agree that the icon should be there by default but I disagree that it should not be easy to make it go away. After all, once you enter your account, that's your account and it is unlikely you share it with another user. Other cases like installations where users share one account (kiosks) usually have ways of preventing them from playing with the overall look of things (replacing the settings files on log-in, etc.). -- Joaquim Rocha signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, 2011-10-06 at 08:58 -0400, Jasper St. Pierre wrote: > [...] > > > > The worst part of the shell for me is the bottom tray area (sorry if > > this is not the official name for it). > > The message tray. Thanks. > [...] > > > > I think that a good way to fix this is to remove the expanding thing and > > to show the name on top of the icons on mouse-over (as tooltips). > > Something like when rests the mouse on top of an opened app's icon in > > the opened apps list on the left. > > I had a patch a for this a while ago. I've refiled it as bug > https://bugzilla.gnome.org/show_bug.cgi?id=661077 \o/ And it also deletes a lot of code. Nice! > [...] > > > > > > I think it'd be also useful if the opened windows' previews (when > > accessing activities) showed their icons, for example on a corner of the > > previews or the the left of their name. > > The designers are working on this one. Hylke came up with: > > > https://github.com/gnome-design-team/gnome-mockups/raw/master/shell/tints.png > > A first attempt at a patch is in > https://bugzilla.gnome.org/show_bug.cgi?id=661042 That is just what I had in mind. Great! > > > Finally, I think that the inclusion of a "close all" option in the apps > > menu (when right-clicking on the left area's icons) would be useful. > > I've never heard that before, but yeah, that may be useful. File a bug please? Well, it's more of a commodity. I've mistakenly opened that menu with the hope of quitting that application and then I end up doing it from the windows or the message tray (does anybody use the menu of the current app's title on top just to close windows?). I figured that having it in the menus of the left icons' area would be useful to close all instances of apps, which I don't think is that usual but I sometimes wish I could do it. Cheers, -- Joaquim Rocha signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, Oct 6, 2011 at 4:34 AM, Joaquim Rocha wrote: > On Thu, 2011-10-06 at 08:37 +0100, Martyn Russell wrote: >> [...] >> >> I love the shell generally though, this is really just where I think we >> could improve things. >> > > Hi, > > I second Martyn's proposals and I'd like to name a few things that at > least in my case, could be improved. > > The worst part of the shell for me is the bottom tray area (sorry if > this is not the official name for it). The message tray. > Besides being visually ugly (with the gradient background) IMHO, the > windows' names expanding when the mouse is over the icons is > disconcerting for me. I have to be extra accurate with the trackball in > order not to miss the exact icon or it will expand the another one, > etc... This is especially terrible when I have 10 telepathy buddy icons > and have to go expanding them all when I try to find a specific buddy > this way. (Of course I can just open the contacts list but anyway, the > use case I'm talking about is also valid IMHO) > > I think that a good way to fix this is to remove the expanding thing and > to show the name on top of the icons on mouse-over (as tooltips). > Something like when rests the mouse on top of an opened app's icon in > the opened apps list on the left. I had a patch a for this a while ago. I've refiled it as bug https://bugzilla.gnome.org/show_bug.cgi?id=661077 > Another thing I think could be given some thought is the notifications. > I understand how convenient it is to show them on the bottom of the > screen (it's a "clean" side and helps integrating the chat). The problem > is that I am often writing on the bottom of the screen (on a terminal or > chatting with a friend) and a notification comes up, blocking my text. > This is especially annoying when that notification is a chat window and > it gets focused, receiving the text I was writing before... > I don't know a good way to fix it but perhaps it could be given some > thought by the designers. > > > Still on the bottom area, I wish that when my status is available, > notifications would stick in a visible area. It often happens that I'm > far from the keyboard for 5 minutes, meanwhile a notification came (say > someone is trying to chat with me) but timed out and is now hidden in > the tray area. I end up answering those notifications much later when I > happen to notice them. Maybe this could be configured so when the status > is "available" and a notification comes, the tray area would be visible > constantly until one focus another area. > > > I think it'd be also useful if the opened windows' previews (when > accessing activities) showed their icons, for example on a corner of the > previews or the the left of their name. The designers are working on this one. Hylke came up with: https://github.com/gnome-design-team/gnome-mockups/raw/master/shell/tints.png A first attempt at a patch is in https://bugzilla.gnome.org/show_bug.cgi?id=661042 > Finally, I think that the inclusion of a "close all" option in the apps > menu (when right-clicking on the left area's icons) would be useful. I've never heard that before, but yeah, that may be useful. File a bug please? > Thanks, > > -- > Joaquim Rocha > > ___ > 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: Features !
> You're assuming the install and the setup is done by a) the same person that > is going to use the computer, which is not the case most of the time and b) > that the person that uses the computer is always the same one. No. > Not true, some seats have unique users (think of a university lab, or a > multi seat setup in an office), some of these have a unique user for anybody > that logins automatically And those environments already need to lock all the configuration down anyway or regenerate it each login otherwise someone will leave it in 320x200 pixel mode and in Korean because it's "funny". > setting in the universal access pane or just in GNOME Tweak Tool is > something I leave up to the designers), but I don't think it should easily > switched off, and by no means automatically switched off. It should be easy to do because the purpose of the desktop is to make things easy. I agree you don't want it off automatically because you need to be sure that a user can find the accessibility features if they do need them. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
2011/10/6 Alberto Ruiz : >> The flaw in your logic starts beyond the front door. Clearly the login >> process should be accessible, and the install and setup so that a user >> can always get their system set up. > > You're assuming the install and the setup is done by a) the same person that > is going to use the computer, which is not the case most of the time and b) > that the person that uses the computer is always the same one. He isn't assuming that at all, since he isn't talking about install (other than mentioning that there it must be available) but the login screen. As for b), that one account doesn't show the icon doesn't mean another account can't show it either. > Not true, some seats have unique users (think of a university lab, or a > multi seat setup in an office), some of these have a unique user for anybody > that logins automatically (in the same way than a live CD works). So even > the person that setups the machine doesn't know what sort of user ends up > using that particular machine. That's a special case (vs. personal computers) and the person doing the installation should know how to set up the system to make it accessible. -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer ___ 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: Features !
2011/10/6 Alan Cox > > Someone said, "well, if it is my house, I should be able to chose", the > > reason that rationale doesn't work is because the GNOME Shell experience > > should be designed to be inclusive, so this is really closer to an office > > building or an apartment building instead of a private house. > > The flaw in your logic starts beyond the front door. Clearly the login > process should be accessible, and the install and setup so that a user > can always get their system set up. > You're assuming the install and the setup is done by a) the same person that is going to use the computer, which is not the case most of the time and b) that the person that uses the computer is always the same one. > However at the point beyond login that ceases to be true. It's necessary > that the accessibility starts available somewhere (or can be enabled > accessibly in the login) but beyond that point the user should be able to > disable it for their account. > Sure, hence my suggestion to have a setting in GNOME Tweak Tool for those who are really annoyed by the icon. If someone needs accessibility to use my account then probably I've been > hacked by someone disabled. Not true, some seats have unique users (think of a university lab, or a multi seat setup in an office), some of these have a unique user for anybody that logins automatically (in the same way than a live CD works). So even the person that setups the machine doesn't know what sort of user ends up using that particular machine. I'm not speculating, I've actually deployed this kind of setup in high schools and universities. Granted it could be I have become disabled > but that hopefully doesn't happen to people suddenely very often. Sure > it'll happen slowly by age to many of us. Also if you can force > accessibility on as a login choice that is still ok. > > It seems to me you can meet both sets of requirements quite easily, and > that an always accessible login with the ability to force a session to be > accessible covers the corner cases too. > I'm fine with having a setting to switch it off (whether we expose the setting in the universal access pane or just in GNOME Tweak Tool is something I leave up to the designers), but I don't think it should easily switched off, and by no means automatically switched off. > Alan > -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
> Someone said, "well, if it is my house, I should be able to chose", the > reason that rationale doesn't work is because the GNOME Shell experience > should be designed to be inclusive, so this is really closer to an office > building or an apartment building instead of a private house. The flaw in your logic starts beyond the front door. Clearly the login process should be accessible, and the install and setup so that a user can always get their system set up. However at the point beyond login that ceases to be true. It's necessary that the accessibility starts available somewhere (or can be enabled accessibly in the login) but beyond that point the user should be able to disable it for their account. If someone needs accessibility to use my account then probably I've been hacked by someone disabled. Granted it could be I have become disabled but that hopefully doesn't happen to people suddenely very often. Sure it'll happen slowly by age to many of us. Also if you can force accessibility on as a login choice that is still ok. It seems to me you can meet both sets of requirements quite easily, and that an always accessible login with the ability to force a session to be accessible covers the corner cases too. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
2011/10/6 Martyn Russell > > - The "Switch User" and "Log Out" ... menu options seem quite pointless if > I am the only user on my machine. > > - The "Suspend" menu option makes no sense here when I want to shut the > thing down (on laptops), I guess this has been discussed to death so I don't > want to start some flame war about this here. I guess it depends how you use > the menu, I usually use this menu to restart/shutdown and close my laptop > lid for suspend. To me, the option is never right. > > > - I really dislike the way that connection changes are stacked and shown as > notifications permanently at the bottom of the screen. This is especially > pointless if you are re-connected to the disconnected network you have a > notification for. > +1 for this one. In general I don't like how the notification stack/tray works, I do like the design principle behind the idea but the execution needs work. For example, everytime I try to hit an icon the icon keeps moving away from my cursor unless I'm careful. Plus the text next to it is usually not that helpful. We should find a human readable name rather than the underscore process. > - The "Applications" tab is quite bad IMO and the worse part of the shell. > It lists all applications and it's never useful to me. Ideally, the list of > applications would be obtained from Tracker :) - not sure how it's done now > but it seems slow to load (takes a second or two) and perhaps could be > cached to improve things there. I would like to see: > - Better categorisation of them too. > - I don't want to see 2 browsers, 3 email clients, avahi server >browsers, archive manager, etc. I want to see a list of >applications which are useful, like my preferred clients. > - I want to see real titles, like "Text Editor", not "gedit". > - I don't want to see applications like "xdiagnose" with no icon. > +1 -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
2011/10/6 Piñeiro > > > - Don't show the accessibility menu unless needed. I never use this > > menu and I don't doubt some people do, but it seems quite redundant > > for me and likely a lot of people. > > What means "unless needed" in this context? How would be the algorithm > to decide if that menu is needed or not? > I've made this analogy before, this is a bit like asking "do not build an access ramp in my apartments building unless needed", this will automatically prevent anyone with disabilities to move into that building, so there you go... problem solved right? Someone said, "well, if it is my house, I should be able to chose", the reason that rationale doesn't work is because the GNOME Shell experience should be designed to be inclusive, so this is really closer to an office building or an apartment building instead of a private house. We could add an option in GSettings and let it be switchable from gnome-tweak-tool, but that's about it. Removing the accessibility button from my point of view is wrong. If the accessibility button is not accessible... how are people with disabilities supposed to access it? > > BR > > -- > Alejandro Piñeiro Iglesias > > ___ > 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: Features !
On 10/06/2011 09:37 AM, Martyn Russell wrote: > I certainly have some ideas to improve things for my user experience. > Most of them are general so perhaps we should have a general page from > the link you gave previously. > > In any case, here are my thoughts: > > - Don't show the accessibility menu unless needed. I never use this > menu and I don't doubt some people do, but it seems quite redundant > for me and likely a lot of people. What means "unless needed" in this context? How would be the algorithm to decide if that menu is needed or not? BR -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On 2011-10-06 11:51, Olav Vitters wrote: > So when discussing, please note that we expect someone to work on it or > somehow ensure it gets done. I know everyone has loads of ideas, please > say what you'll (want to) work on for 3.4 / 3.6 :) > > Then the discussion can be a bit more concrete (whose help do you need, > do they agree, etc) And please don't add someone as an owner of a feature without checking with them first. This happened to me during 3.2 cycle. I got added as the owner for integrating the the keyring prompts into the shell (something I want to do, but didn't have time during the last cycle). I didn't realize until too late that this was on the official feature list :S Cheers, Stef ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On 06/10/11 11:05, Patryk Zawadzki wrote: On Thu, Oct 6, 2011 at 11:30 AM, Siegfried-Angel Gevatter Pujals wrote: 2011/10/6 Martyn Russell: Or, similarly to how mac did it? does it? using a jumping icon or changing the colour or some notification which is subtle. With an icon appearing in the top (like the battery icon) which allows you to use your contacts (favourite or recently communicated with and have access to the contacts app/dialog), that would be a nice way to avoid needing the roster entirely generally. You could see notifications grouped there. You mean something like this? https://wiki.ubuntu.com/MessagingMenu?action=AttachFile&do=get&target=messaging-menu.png Exactly like that, except it should say Instant Messaging Client or something which is not "Empathy". Please, no catch-all menus in GNOME 3. This is "systray" all over again except that it's vertical now. Personally, I think IMs should be special cased here and emails shouldn't be included in any menu. It just brings constant context switching and interruption. I also don't agree that this is the system tray again at all. We're not adding 20 different applications into one menu and I wouldn't expect to allow 3rd parties to add to this menu either. -- 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: Features !
On Thu, Oct 6, 2011 at 11:30 AM, Siegfried-Angel Gevatter Pujals wrote: > 2011/10/6 Martyn Russell : >> Or, similarly to how mac did it? does it? using a jumping icon or changing >> the colour or some notification which is subtle. With an icon appearing in >> the top (like the battery icon) which allows you to use your contacts >> (favourite or recently communicated with and have access to the contacts >> app/dialog), that would be a nice way to avoid needing the roster entirely >> generally. You could see notifications grouped there. > You mean something like this? > > https://wiki.ubuntu.com/MessagingMenu?action=AttachFile&do=get&target=messaging-menu.png Please, no catch-all menus in GNOME 3. This is "systray" all over again except that it's vertical now. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
Hi, 2011/10/6 Martyn Russell : > Or, similarly to how mac did it? does it? using a jumping icon or changing > the colour or some notification which is subtle. With an icon appearing in > the top (like the battery icon) which allows you to use your contacts > (favourite or recently communicated with and have access to the contacts > app/dialog), that would be a nice way to avoid needing the roster entirely > generally. You could see notifications grouped there. You mean something like this? https://wiki.ubuntu.com/MessagingMenu?action=AttachFile&do=get&target=messaging-menu.png -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Wed, Oct 05, 2011 at 04:17:00PM -0400, Matthias Clasen wrote: > 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. One important factor to consider as mentioned on the wiki: | Note that task owners are mandatory as this is not meant as a random | wishlist. and from the last minutes: | A feature is an idea that would be a major user visible (and | marketable) change, typically affects several modules, need some | consensus, and a person to lead the change. | | The process would be a discussion of the idea on desktop-devel-list, | to achieve a general consensus, the release team role is then to | ensure that a conclusion is reached. | | Once agreed, we shouldn't add too much overhead to the process, but it | would definitely be useful to do regular status updates on features. So when discussing, please note that we expect someone to work on it or somehow ensure it gets done. I know everyone has loads of ideas, please say what you'll (want to) work on for 3.4 / 3.6 :) Then the discussion can be a bit more concrete (whose help do you need, do they agree, etc) -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, Oct 06, 2011 at 10:27:51AM +0100, Nick Glynn wrote: > Maybe something like the Ubuntu/Dell brain/ideastorm would be a nice > addition to the Gnome website for these sorts of proposals? The idea behind feature proposal time is that each proposal has a clear owner. It is *not* request what you want, hope someone might implement it (which is what this thread seems to be heading towards). > It may help prioritise those must have features/requests and then > developers/UX guys could assign, develop or shootdown the ideas as > appropriate? That has been discussed before. In short: the ideas are pretty much known, there are *way* more ideas than what people can look at, and rather get input from developers+designers on their plans than spending effort triaging loads of random ideas. e.g. the "not interested in what you say you want, but interested in what you actually need" -- Regards, Olav PS: Please don't quote the entire messages. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On 06/10/11 08:37, Martyn Russell wrote: On 05/10/11 21:17, Matthias Clasen wrote: Hey, Hi, 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. I certainly have some ideas to improve things for my user experience. Most of them are general so perhaps we should have a general page from the link you gave previously. In any case, here are my thoughts: I forgot a few :) - Integration with thunderbird in the calendar (there is a red hat bug about this somewhere I saw recently) - Why show the "wacom graphics tablet" configuration page in the "System Settings" if I don't have one? (perhaps Ubuntu specific) - Why show the "Additional Drivers" configuration page in the "System Settings" if there aren't any? (perhaps Ubuntu specific) - The "Language Support" configuration page is a dialog and not integrated like the others. - The "Network" configuration page doesn't allow me to forget networks that are automatically chosen when in a particular wifi area so I have to keep changing the connection each time. This used to be in the configuration editor somewhere, but now seems missing. - I would love a quick way to switch between capture and speaker devices because quite often I make phone calls and want to use my head set with built in mic and then want to switch back to my main speakers for listening to music. Opening the dialog each time get monotonous. Using the applet would be a great way to do this. - Is the "universal access" configuration page meant to be in a larger font and look completely different to the other page fonts? - I think the "default actions" is hidden in the "System Info" configuration page and makes more sense to be put into a new place *with* the actions for removable media. Both feel related to me. IT's essentially what my computer does when I want to do particular work with either media or applications. -- 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: Features !
Hi, On 6 October 2011 09:48, Martyn Russell wrote: > On 06/10/11 09:34, Joaquim Rocha wrote: > >> On Thu, 2011-10-06 at 08:37 +0100, Martyn Russell wrote: >> >>> [...] >>> >>> I love the shell generally though, this is really just where I think we >>> could improve things. >>> >>> >> Hi, >> > > Hi, > > I second Martyn's proposals and I'd like to name a few things that at >> least in my case, could be improved. >> >> The worst part of the shell for me is the bottom tray area (sorry if >> this is not the official name for it). >> Besides being visually ugly (with the gradient background) IMHO, the >> windows' names expanding when the mouse is over the icons is >> disconcerting for me. I have to be extra accurate with the trackball in >> order not to miss the exact icon or it will expand the another one, >> etc... This is especially terrible when I have 10 telepathy buddy icons >> and have to go expanding them all when I try to find a specific buddy >> this way. (Of course I can just open the contacts list but anyway, the >> use case I'm talking about is also valid IMHO) >> >> I think that a good way to fix this is to remove the expanding thing and >> to show the name on top of the icons on mouse-over (as tooltips). >> Something like when rests the mouse on top of an opened app's icon in >> the opened apps list on the left. >> > > Or, similarly to how mac did it? does it? using a jumping icon or changing > the colour or some notification which is subtle. With an icon appearing in > the top (like the battery icon) which allows you to use your contacts > (favourite or recently communicated with and have access to the contacts > app/dialog), that would be a nice way to avoid needing the roster entirely > generally. You could see notifications grouped there. I was struggling with > concepts for this when I worked on Gossip back in the days before Empathy. > It's not an easy UX to come up with. > > You could apply this to the network manager applet/icon too to avoid this > constant bombardment of connection state changes on devices like laptops. > > Of course, this completely conflicts with the current approach and being > able to reply to messages without opening any window. > > For me the issue is more about *not seeing* messages waiting for me and > internally people in Lanedo who have been using gnome-shell < 3.2 only > respond to messages if spoken to directly (i.e. chatrooms messages were > missed). This is likely fixed now I suspect. Either way, I never use the > bottom notification bar and don't think to check it for new events at all. > > > Another thing I think could be given some thought is the notifications. >> I understand how convenient it is to show them on the bottom of the >> screen (it's a "clean" side and helps integrating the chat). The problem >> is that I am often writing on the bottom of the screen (on a terminal or >> chatting with a friend) and a notification comes up, blocking my text. >> This is especially annoying when that notification is a chat window and >> it gets focused, receiving the text I was writing before... >> I don't know a good way to fix it but perhaps it could be given some >> thought by the designers. >> > > I agree. > > > Still on the bottom area, I wish that when my status is available, >> notifications would stick in a visible area. It often happens that I'm >> far from the keyboard for 5 minutes, meanwhile a notification came (say >> someone is trying to chat with me) but timed out and is now hidden in >> the tray area. I end up answering those notifications much later when I >> happen to notice them. Maybe this could be configured so when the status >> is "available" and a notification comes, the tray area would be visible >> constantly until one focus another area. >> > > Yea, precisely the case I see too. > > > I think it'd be also useful if the opened windows' previews (when >> accessing activities) showed their icons, for example on a corner of the >> previews or the the left of their name. >> >> >> Finally, I think that the inclusion of a "close all" option in the apps >> menu (when right-clicking on the left area's icons) would be useful. >> > > I suspect you might want to do this per workspace than all at the same > time. I only close all when rebooting. > > But I also use the extension to place certain apps on particular workspaces > because I am used to my work flow being related to the workspace I am on. > > > -- > Regards, > Martyn > > Founder and CEO of Lanedo GmbH. > __ > Maybe something like the Ubuntu/Dell brain/ideastorm would be a nice addition to the Gnome website for these sorts of proposals? It may help prioritise those must have features/requests and then developers/UX guys could assign, develop or shootdown the ideas as appropriate? Regards, Nick ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-
Re: Features !
On 06/10/11 09:34, Joaquim Rocha wrote: On Thu, 2011-10-06 at 08:37 +0100, Martyn Russell wrote: [...] I love the shell generally though, this is really just where I think we could improve things. Hi, Hi, I second Martyn's proposals and I'd like to name a few things that at least in my case, could be improved. The worst part of the shell for me is the bottom tray area (sorry if this is not the official name for it). Besides being visually ugly (with the gradient background) IMHO, the windows' names expanding when the mouse is over the icons is disconcerting for me. I have to be extra accurate with the trackball in order not to miss the exact icon or it will expand the another one, etc... This is especially terrible when I have 10 telepathy buddy icons and have to go expanding them all when I try to find a specific buddy this way. (Of course I can just open the contacts list but anyway, the use case I'm talking about is also valid IMHO) I think that a good way to fix this is to remove the expanding thing and to show the name on top of the icons on mouse-over (as tooltips). Something like when rests the mouse on top of an opened app's icon in the opened apps list on the left. Or, similarly to how mac did it? does it? using a jumping icon or changing the colour or some notification which is subtle. With an icon appearing in the top (like the battery icon) which allows you to use your contacts (favourite or recently communicated with and have access to the contacts app/dialog), that would be a nice way to avoid needing the roster entirely generally. You could see notifications grouped there. I was struggling with concepts for this when I worked on Gossip back in the days before Empathy. It's not an easy UX to come up with. You could apply this to the network manager applet/icon too to avoid this constant bombardment of connection state changes on devices like laptops. Of course, this completely conflicts with the current approach and being able to reply to messages without opening any window. For me the issue is more about *not seeing* messages waiting for me and internally people in Lanedo who have been using gnome-shell < 3.2 only respond to messages if spoken to directly (i.e. chatrooms messages were missed). This is likely fixed now I suspect. Either way, I never use the bottom notification bar and don't think to check it for new events at all. Another thing I think could be given some thought is the notifications. I understand how convenient it is to show them on the bottom of the screen (it's a "clean" side and helps integrating the chat). The problem is that I am often writing on the bottom of the screen (on a terminal or chatting with a friend) and a notification comes up, blocking my text. This is especially annoying when that notification is a chat window and it gets focused, receiving the text I was writing before... I don't know a good way to fix it but perhaps it could be given some thought by the designers. I agree. Still on the bottom area, I wish that when my status is available, notifications would stick in a visible area. It often happens that I'm far from the keyboard for 5 minutes, meanwhile a notification came (say someone is trying to chat with me) but timed out and is now hidden in the tray area. I end up answering those notifications much later when I happen to notice them. Maybe this could be configured so when the status is "available" and a notification comes, the tray area would be visible constantly until one focus another area. Yea, precisely the case I see too. I think it'd be also useful if the opened windows' previews (when accessing activities) showed their icons, for example on a corner of the previews or the the left of their name. Finally, I think that the inclusion of a "close all" option in the apps menu (when right-clicking on the left area's icons) would be useful. I suspect you might want to do this per workspace than all at the same time. I only close all when rebooting. But I also use the extension to place certain apps on particular workspaces because I am used to my work flow being related to the workspace I am on. -- 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: Features !
On Thu, 2011-10-06 at 08:37 +0100, Martyn Russell wrote: > [...] > > I love the shell generally though, this is really just where I think we > could improve things. > Hi, I second Martyn's proposals and I'd like to name a few things that at least in my case, could be improved. The worst part of the shell for me is the bottom tray area (sorry if this is not the official name for it). Besides being visually ugly (with the gradient background) IMHO, the windows' names expanding when the mouse is over the icons is disconcerting for me. I have to be extra accurate with the trackball in order not to miss the exact icon or it will expand the another one, etc... This is especially terrible when I have 10 telepathy buddy icons and have to go expanding them all when I try to find a specific buddy this way. (Of course I can just open the contacts list but anyway, the use case I'm talking about is also valid IMHO) I think that a good way to fix this is to remove the expanding thing and to show the name on top of the icons on mouse-over (as tooltips). Something like when rests the mouse on top of an opened app's icon in the opened apps list on the left. Another thing I think could be given some thought is the notifications. I understand how convenient it is to show them on the bottom of the screen (it's a "clean" side and helps integrating the chat). The problem is that I am often writing on the bottom of the screen (on a terminal or chatting with a friend) and a notification comes up, blocking my text. This is especially annoying when that notification is a chat window and it gets focused, receiving the text I was writing before... I don't know a good way to fix it but perhaps it could be given some thought by the designers. Still on the bottom area, I wish that when my status is available, notifications would stick in a visible area. It often happens that I'm far from the keyboard for 5 minutes, meanwhile a notification came (say someone is trying to chat with me) but timed out and is now hidden in the tray area. I end up answering those notifications much later when I happen to notice them. Maybe this could be configured so when the status is "available" and a notification comes, the tray area would be visible constantly until one focus another area. I think it'd be also useful if the opened windows' previews (when accessing activities) showed their icons, for example on a corner of the previews or the the left of their name. Finally, I think that the inclusion of a "close all" option in the apps menu (when right-clicking on the left area's icons) would be useful. Thanks, -- Joaquim Rocha signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On 05/10/11 21:17, Matthias Clasen wrote: Hey, Hi, 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. I certainly have some ideas to improve things for my user experience. Most of them are general so perhaps we should have a general page from the link you gave previously. In any case, here are my thoughts: - Don't show the accessibility menu unless needed. I never use this menu and I don't doubt some people do, but it seems quite redundant for me and likely a lot of people. - Disconnection between the telepathy accounts and the "Online Accounts" is disappointing to me. Like the N9, I want all my online accounts like Twitter, Facebook, XMPP, MSN, etc. To all be configurable via the Online Accounts. I heard there was some reason for this not being the case so far, but I don't know the details. - The "Switch User" and "Log Out" ... menu options seem quite pointless if I am the only user on my machine. - The "Suspend" menu option makes no sense here when I want to shut the thing down (on laptops), I guess this has been discussed to death so I don't want to start some flame war about this here. I guess it depends how you use the menu, I usually use this menu to restart/shutdown and close my laptop lid for suspend. To me, the option is never right. - I really dislike the way that connection changes are stacked and shown as notifications permanently at the bottom of the screen. This is especially pointless if you are re-connected to the disconnected network you have a notification for. - The "Applications" tab is quite bad IMO and the worse part of the shell. It lists all applications and it's never useful to me. Ideally, the list of applications would be obtained from Tracker :) - not sure how it's done now but it seems slow to load (takes a second or two) and perhaps could be cached to improve things there. I would like to see: - Better categorisation of them too. - I don't want to see 2 browsers, 3 email clients, avahi server browsers, archive manager, etc. I want to see a list of applications which are useful, like my preferred clients. - I want to see real titles, like "Text Editor", not "gedit". - I don't want to see applications like "xdiagnose" with no icon. Admittedly, this isn't an easy problem to solve. - When I search for "foo", I want to use Tracker and for it to come up with results in a similar way to tracker-needle. That being there are categories listed which people can find their content in. I would link to a video but I don't have one right now with the current category view. I am blogging today about something related to needle though so ... - I miss the weather applet, there is an extension for this, it would be nice to see that integrated and supported. - I miss timezone changing in the menu as it was which was useful if you repeatedly went between different countries. Integration with the clock at the top could be done there I suspect. - Integration with Google calendar would be nice. Actually, I am not sure if this works by using my google account in the "Online Accounts" or not because I have my private google account (which I entered there) and we use Google calendar internally with Lanedo (which is what I want to see there primarily). - Perhaps integration of the new contacts app in the menu too (for quick calls/emails/IMs) -- I love the shell generally though, this is really just where I think we could improve things. -- 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: Features !
Hi! > I guess I'm not clear on what requires a feature proposal. For example, > what about my ideas to have dynamic help buttons and menus, which I've > brought up on gtk-devel-list? I figured I'd just keep hacking on that > and convince maintainers one by one. Should I propose that? > I, personally, would love to have this proposed. It is kind of a desktop-wide feature even if every application has to opt-in on its own but it would be nice to have it on the agenda and a bit more widely discussed. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Wed, 2011-10-05 at 16:17 -0400, 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. I guess I'm not clear on what requires a feature proposal. For example, what about my ideas to have dynamic help buttons and menus, which I've brought up on gtk-devel-list? I figured I'd just keep hacking on that and convince maintainers one by one. Should I propose that? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On mié, 2011-10-05 at 16:22 -0400, Jasper St. Pierre wrote: > For the shell: mode-switch kill? Overview window borders? Yes, Jakub and me are planning on working on mode-switch kill. Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Wed, Oct 5, 2011 at 4: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 > For the shell: mode-switch kill? Overview window borders? -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features-oriented releases
Hello Alexandre, We will soon have 3.2 released, and it's quite time to discuss things for 3.4, and as I said previously, while the features focused process is something we really want, the way it happened for 3.2 was suboptimal. Let's work on this, here are some thoughts. My goal for features is to strenghten the position of the release team, it shouldn't just be a list of things put on a wiki page at the beginning of the cycle, we should demand schedules, progress reports, status updates, during the whole cycle, and over cycles, as a feature can span several of them. This will be an important job and we should therefore concentrate on a limited set of features, and here comes an important point, there is a lot of place for features that are coordinated in an ad hoc manner, without the assistance of the release team. Still it is useful for features to be presented and discussed on the desktop-devel list, as the exchanges will be signs of the directions the GNOME project want to take; and this is on that basis that the release team will have its own discussions, and declare support for some of them. What would be in it? I wrote about new requirements the release team would have, but what are the benefits? This is unfortunately hard to tell, ultimately module maintainers are the decision makers, what are the steps the release team could take to help features happen? Fortunately this shouldn't have to be about forcing patches to get in, maintainers will express themselves in the discussion period, and will agree with the direction of the project. (I do not foresee changes, and hopefully maintainers are ok with the current direction). Comments? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features vs. Time-based [Was: Gnome 2 infinity and beyond]
Seriously. There *are* those of us out there actively working towards 3.0. We'd get there a lot quicker with more help. http://beatnik.infogami.com/Gimmie -Alex Jeff Waugh wrote: Write code. Make things happen. That's ultimately what matters. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features vs. Time-based [Was: Gnome 2 infinity and beyond]
On Thu, 20 Apr 2006, Elijah Newren wrote: > On 4/20/06, Alan Horkan <[EMAIL PROTECTED]> wrote: > > > [1] Holy shit, just stop talking about version numbers at all. It > > > totally doesn't mean anything useful. > > > > I understand you and most developers do not think it is important but > > would it kill you to recognise that some people do* and it wouldn't hurt > > to try and pin down when it might happen to something less vague than > > "maybe later"? > > Personally, I'm all in favor of "Never -- unless something big comes > up making it the only reasonable path forward." Does that help? ;-) It isn't what I most want to hear but thanks for coming straight out and saying it. > Now, if you're really interested in being able to improve marketing, I > have a suggestion for how to concretely improve things now: Why not > collect feature plans that maintainers already have and trumpet those? > Our roadmap (http://live.gnome.org/RoadMap) has 3 total things listed > for 2.16. Developers have already listed some plans on this list -- > maybe you could collect them. And ping more maintainers individually > for more? And write up some cool marketing materials based on it? > (Marketing ain't my gig so I won't be doing this -- I'd rather be > working on bugfixes, or maybe some features for bugzilla) > > No one is saying when if ever we might be ready. You are not even saying > > we wont be ready for at least another 2 or 3 releases and to stop asking > > until then. No one here seems to think it is strange to have the 2.x > > branch continue for updwards of 8 years but I cannot be the only one > > looking in thinking it is a bit weird**. > > I find it a bit odd to cite someone who admittedly doesn't use Gnome okay so not the best example but ... > probably failing (unless he changes, of course). Anyway, it would > probably make more sense to cite the many people who have added > comments to http://live.gnome.org/ThreePointZero. ;-) ... you provide a better one. > > Hell at the very worst please just say nobody has any idea when if ever > > 3.0 will happen, and what might be needed before anyone can provide a > > credible answer? > > I personally have no idea when if ever it will happen and don't have a > clue what would be needed before anyone can provide a credible answer. > You probably don't like that, but it's an honest answer from me. > Note though, that my entire email is just me speaking as an > individual. It is a start, I appreciate your answers. -- Alan H. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features vs. Time-based [Was: Gnome 2 infinity and beyond]
On 4/20/06, Alan Horkan <[EMAIL PROTECTED]> wrote: > > [1] Holy shit, just stop talking about version numbers at all. It > > totally doesn't mean anything useful. > > I understand you and most developers do not think it is important but > would it kill you to recognise that some people do* and it wouldn't hurt > to try and pin down when it might happen to something less vague than > "maybe later"? Personally, I'm all in favor of "Never -- unless something big comes up making it the only reasonable path forward." Does that help? ;-) Now, if you're really interested in being able to improve marketing, I have a suggestion for how to concretely improve things now: Why not collect feature plans that maintainers already have and trumpet those? Our roadmap (http://live.gnome.org/RoadMap) has 3 total things listed for 2.16. Developers have already listed some plans on this list -- maybe you could collect them. And ping more maintainers individually for more? And write up some cool marketing materials based on it? (Marketing ain't my gig so I won't be doing this -- I'd rather be working on bugfixes, or maybe some features for bugzilla) But, even if we did bump version numbers for the sake of marketing, we could just introduce a separate Gnome version just for marketing (and still have most all packages use 2.x.y(.z) numbering). And, if we're doing it for marketing, why increase just one major number at a time? That's slow progress. It should reflect the exponential growth of improvement in Gnome, so let's make the next version 4.0, then 8.0 after that, then 16.0... :-) > No one is saying when if ever we might be ready. You are not even saying > we wont be ready for at least another 2 or 3 releases and to stop asking > until then. No one here seems to think it is strange to have the 2.x > branch continue for updwards of 8 years but I cannot be the only one > looking in thinking it is a bit weird**. I find it a bit odd to cite someone who admittedly doesn't use Gnome much (prefers blackbox and fluxbox) and merely wants to see the entire UI redone because he is "tired of the Gnome UI (as stated in the follow up at http://www.pthree.org/2006/04/18/points-of-clarification/) I believe he's specifically one of the people we should not target -- it would mean our target audience would be no one but early adopters. I'd go so far as to say that if he becomes a Gnome user, we're probably failing (unless he changes, of course). Anyway, it would probably make more sense to cite the many people who have added comments to http://live.gnome.org/ThreePointZero. ;-) > Hell at the very worst please just say nobody has any idea when if ever > 3.0 will happen, and what might be needed before anyone can provide a > credible answer? I personally have no idea when if ever it will happen and don't have a clue what would be needed before anyone can provide a credible answer. You probably don't like that, but it's an honest answer from me. Note though, that my entire email is just me speaking as an individual. Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features vs. Time-based [Was: Gnome 2 infinity and beyond]
> > [1] Holy shit, just stop talking about version numbers at all. It > > totally doesn't mean anything useful. > > I understand you and most developers do not think it is important but > would it kill you to recognise that some people do* and it wouldn't hurt > to try and pin down when it might happen to something less vague than > "maybe later"? I've been pretty specific about it, and haven't said it's "unimportant". > > Chris got it right. To fix the lack of agenda, we need to set an agenda > > that is independent of the release cycle - particularly for bigger goals > > that we think about for Topaz. That doesn't mean dumping the time-based > > releases. > > Agreed. How can I help make there be an agenda? Write code. Make things happen. That's ultimately what matters. > > There is *NO PRESSURE* to call something 'GNOME 3.0'. We can do it when > > we're ready. > > No one is saying when if ever we might be ready. You are not even saying > we wont be ready for at least another 2 or 3 releases and to stop asking > until then. No one here seems to think it is strange to have the 2.x > branch continue for updwards of 8 years but I cannot be the only one > looking in thinking it is a bit weird**. We're not going to bless something '3.0' because some people think '2.x' is weird. - Jeff -- GUADEC 2006: Vilanova i la Geltrú, Spainhttp://2006.guadec.org/ Hunch, n.: U.S. Foreign Policy. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features vs. Time-based [Was: Gnome 2 infinity and beyond]
> [1] Holy shit, just stop talking about version numbers at all. It > totally doesn't mean anything useful. I understand you and most developers do not think it is important but would it kill you to recognise that some people do* and it wouldn't hurt to try and pin down when it might happen to something less vague than "maybe later"? > Chris got it right. To fix the lack of agenda, we need to set an agenda that > is independent of the release cycle - particularly for bigger goals that we > think about for Topaz. That doesn't mean dumping the time-based releases. Agreed. How can I help make there be an agenda? > There is *NO PRESSURE* to call something 'GNOME 3.0'. We can do it when > we're ready. No one is saying when if ever we might be ready. You are not even saying we wont be ready for at least another 2 or 3 releases and to stop asking until then. No one here seems to think it is strange to have the 2.x branch continue for updwards of 8 years but I cannot be the only one looking in thinking it is a bit weird**. > We can deprecate the crap out of our platform *RIGHT NOW* and > be happy that it's still API/ABI compatible. > We can write amazingly cool new stuff *RIGHT NOW* and drop it into the > 2.x release series when it's ready. > When we decide that GNOME is qualitatively worthy [2] of the 3.0 moniker, we What is worthy is entirely subjective and another non-answer which doesn't make things any clearer until you set some way to quantify what you think would be worthy. (I don't know if this is really just another way of asking some one to write a draft spec?) Hell at the very worst please just say nobody has any idea when if ever 3.0 will happen, and what might be needed before anyone can provide a credible answer? Can you really blame me for asking about 3.0? Somebody had to ask eventually. -- Alan > can purge the deprecated crap, make big changes to the OOTB experience, and > make a fuckload of noise. [OOTB does that stand for: out of the box??? hate acronyms, I'm not stupid but had to look it up before i could even guess what you were talking about.] * At the very least it has some marketing value to change the version number based on how much has improved since 2.0 alone. ** It may be an extremely small group but I'm not the only one http://www.pthree.org/2006/04/16/where-art-thou-gnome-30/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
