desktop June 2011

desktop@lists.fedoraproject.org

21 participants
17 discussions

Default terminal in GNOME 3
by Christoph Wickert 01 Jul '11

01 Jul '11

I wondered how to set the default terminal in GNOME 3. The internet revealed gsettings set org.gnome.desktop.default-applications.terminal exec <terminal> gsettings set org.gnome.desktop.default-applications.terminal exec-arg "'-e'" This raises 2 questions: 1. Will it be possible to set the default terminal again in GNOME 3.2? 2. Where is 'exec-arg' arg coming from? In the past we had the xml files in /usr/share/gnome-control-center/default-apps/ which contained an 'exec-flag'. How can I as a maintainer of several terminal applications let people know the proper exec-flag/exec-arg? Regards, Christoph

5 9

Re: Proposal: Too similar application names
by Vitezslav Humpa 27 Jun '11

27 Jun '11

Adamw: >>>> That leaves terminal / Terminal, and all the system-config-* vs. >>>> control-center components (things like Date & Time are identical between >>>> the two). That seems a larger problem than just the menu entries, >>>> though. There's kind of a demarcation question here; GNOME seems to have >>>> decided various settings should be controlled by the desktop, and Fedora >>>> probably needs to decide where it stands on that, whether all our other >>>> desktop environments agree, and how to deal with overlapping tools for >>>> such settings from all standpoints, not just menu entries. Where we >>>> agree that something should be handed off from s-c-* to desktop control, >>>> we should check on the current status of what the s-c-* app is capable >>>> of and whether the GNOME app can do all the same stuff, and whether the >>>> other desktops make it possible to deal with the same settings, I guess. Vhumpa: >>> I went through config utilities across different environments. In some >>> cases definitely the s-c-* are being relied to for configuration >>> completely, notably in cases of LXDE and Xfce too. Sometimes they >>> overlap with the desktop environment specific utilities, but do the >>> configuring in different scopes - e.g. s-c-keyboard will set the global >>> system layout while xfce4 keyboard settings does it session-wise. Well, >>> I'd say there is no point discussing the future of s-c-* utilities in >>> respect to these environments, they are needed. >>> Gnome(and KDE), perhaps with some exceptions, seem to cover s-c-* >>> options rather well. I think we should consider simply removing the >>> conflicting s-c-* from the menus altogether, thus getting rid of the >>> duplicity. Should the user need to access these particular s-c-* >>> utilities, they will still be present in the system. >>> These are the ones, that are duplicate to the gnome-control-panel tools: >>> system-config-date (Date & Time vs. Date and Time) >>> system-config-printer (Printing vs. Printers) >>> system-config-users (Users and Groups vs. User Accounts) Bnocera: >> I would really rather they weren't installed at all, but that would do >> fine in the meanwhile. Adamw: > Well, I don't see why we shouldn't do both. Don't install 'em by default > for GNOME and KDE spins, *and* make 'em NotShowIn desktops where they're > not really needed, so that if people install them for use in Xfce or > LXDE or whatever, they don't show up in GNOME or KDE. I've toyed with NotShowIn for the 3 utilities above and it looks like it makes them hidden just fine. In case when I put NotShowIn multiple times, e.g. once for GNOME and once for KDE, the setting gets ignored by GNOME (KDE honours it). Although that is not a problem now, as it looks like we want to hide these just in GNOME, as it was suggested that KDE settings do not provide system-wide configuration. Thus - would you guys agree to make the 3 duplicate system-config-* utilities "NotShowIn" in GNOME? And if so, what steps should we take to make this so? -- Vita Humpa Fedora QA

1 0

Re: Proposal: Too similar application names
by Vitezslav Humpa 24 Jun '11

24 Jun '11

Forwarded from test list. ----- Forwarded Message ----- From: "John Dulaney" <j_dulaney(a)live.com> To: "Fedora QA" <test(a)lists.fedoraproject.org> Sent: Sunday, June 5, 2011 8:28:45 PM Subject: RE: Proposal: Too similar application names > That all said, question remains on what to actually do on this. In a > long term I'd suggest trying advocate that there is a appropriate > solution based in the upstream, might it be pop-ups (sounds reasonable > to do for all the desktop environments) or something based on how KDE > does it. Although having upstream to do something is, like I said - > long term. Thus let's decide on what to do about this now. > > I'd say that a number of cases this relates to is limited to a fairly > small number. I am counting: > - Software Update/Software Updates > - System Monitor > - Terminal > - system-config-(e.g. date) vs. gnome control panel applets > (and likely a few more). > > As a compromise between getting rid of the problem (user annoyance...) > completely and the amount of work that would have to be done, I suggest > that we simply target these applications and modify the desktop files > so that they become distinguishable. That means in the menus and on the > first sight, whatever *.desktop field is responsible for that in particular > environments. Should we manage to push having a popup in Upstream, that > would be great later on. I agree, this is a good starting point. I don't really see the point of the popups, but if other folks think they're necessary, I won't argue. > Now, should we agree on this quickfix now, how to do that? Am I right > that this would mean asking the maintainers of these cca 10 packages to > change the *.desktop files in the packaging process? Do the *.desktop > files come from upstream or are they made or at least modified already > by Fedora? I suppose it would be better if they already get modified, > as then the single extra edit would be less painful for maintainers. > Still - sounds relatively painless. In theory, the technical side should be a thirty second fix. The issue would be deciding new names. Some things shouldn't be too difficult, such as renaming Software Updates to Software Sources. > We can also consider making a simple (e.g. targeting just default live > installs) release criterion that would "force" such, though I'd think > having it done on "voluntary" basis is more appropriate. I wonder if this should be a QA test? It would help with improving the end product for us to check things like this, but it is also fairly subjective as to what constitutes as 'too similar.' I'm for it, but the aforementioned subjective nature makes coming up with a clear release criteria difficult. John. -- test mailing list test(a)lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test

3 8

GNOME Shell fixes
by Misha Shnurapet 19 Jun '11

19 Jun '11

Hello, teams! Is there any chance for this to land in Fedora 15? https://bugzilla.redhat.com/show_bug.cgi?id=701609 It is rather an important fix because it changes the label of the search bar in Overview mode which is currently mistranslated. The fix is on its way to upstream, but they say the earlier it shows up is the next version of GNOME 3 that is to come out this Autumn. Getting it in sooner is strongly desired. Thank you. -- Best regards, Misha Shnurapet, Russian L10N Team https://fedoraproject.org/wiki/Shnurapet shnurapet AT fedoraproject.org, GPG: 00217306

2 3

Thumbnails/Previewable files
by Jóhann B. Guðmundsson 16 Jun '11

16 Jun '11

As it stands now I dont get thumbnails for my raw images ( ORF ) which is one of those annoying important little things which I think we can do better in supporting so I'm wondering in what's the ( future ) plans for thumbnails/previews files in Gnome? What's preventing nautilus to properly create thumbnails/previews of raw image format and other files and arent having size and location limit on thumbnails/previews things of the past? JBG

2 1

"GNOME Software Development" group
by Paul W. Frields 14 Jun '11

14 Jun '11

I noticed that the "GNOME Software Development" yum group in F15 features a lot of GNOME 2.x libs and tools, but GNOME 3.x isn't present there. Is there a plan to change this group content in Fedora 16? (Is that even necessary, or am I looking in the wrong place?) -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Red Hat Summit/JBossWorld -- Register now! http://.theredhatsummit.com

3 6

Re: Proposal: Too similar application names
by Vitezslav Humpa 09 Jun '11

09 Jun '11

----- Original Message ----- > On Thu, 2011-06-02 at 09:54 -0400, Vitezslav Humpa wrote: > > The way KDE application launcher handles this also provides nice > > example for a design solution to this problem. They use a > > "Generic" (e.g. Terminal) field to describe the application > > primarily > > and have the name of the actual binary (e.g. Konsole) present in > > small > > letters when the generic name is not unique. > > I happen to think this is the wrong way round. For someone who's not > sure what they want, it might be marginally better, but for anyone who > already knows, i.e. for most people most of the time after learning > it, > it just produces a momentary hesitation every time you use it. > > For example, I have *never* thought to myself "Oh, I need to fire up > the > Groupware Suite". I just look for Evolution, but it's in small letters > in a grey font. Much better would be to have Evolution as the main > menu > item, with Groupware Suite in a small grey font for those who don't > know > what it is (think of it as a poor man's ToolTip). > > There's a difference between easy to use and easy to learn. We would > do > well to favour the former over the latter whenever there's a conflict. > > poc Are you referring to a situation in KDE(can't boot it now to check)? Seems to me that most of the times we do use the application's actual name in the menus. With few exceptions that form the base of this whole problem.

1 0

Re: Space for wallpapers in Fedora 16
by Máirín Duffy 09 Jun '11

09 Jun '11

On Wed, 2011-06-08 at 11:51 +0000, Jaroslav Reznik wrote: > yep, we have a support for slideshow in Plasma. But it depends if it's just > slideshow or time based wp change as we saw before in Gnome. I was thinking > about implemnting it to Plasma but after aseigo's review of the old one Gnome > XML file I decided better not do it. Even aseigo is still waiting for > implementation :) We were thinking it would just be a simple slideshow. No time-based transition effects. > Just one thing - as Kevin pointed out - the extended slideshow wps should be in > separate subpackage and the default package should be the single one due to live > image space constraints. Especially for Plasma spin. Okay, shipping four wallpapers by default was not a problem in earlier Fedoras when we've done this before (at least on the desktop spin.) We did ship the four wallpapers, which were the same wallpaper with different colorations. Fedora 8 and Fedora 9 are some examples of this. We didn't know it would be a problem if we gave advance notice; it seems even with advance notice it's a problem, so I guess we have no choice - one wallpaper it is then. > Another important thing is - we need some simple designs. I really like Fedora > designs as these aren't usually the boring abstract something like in other > distros but today with Gnome Shell, the Plasma Netbook brother (I'm surprised > how similar these two are, very nice for touchable netbooks) - the desktop now > serves for activities (both Shell and Plasma ones). The Plasma Active is going > to be even more using the desktop... So this is something you, as Design team > should consider. But still I hope we can have amazing designs, not just colorful > spits :) This is a good point, but this is probably not the appropriate thread to bring that up. Please start a new thread on the design-team list for this or you can of course provide artists feedback directly on the artboard - thanks! :) ~m

3 2

BTRFS + Gnome
by Jóhann B. Guðmundsson 08 Jun '11

08 Jun '11

What's the current status of btrfs support in Gnome and related applications like Gnome disk utility ( palimpsest )? I'm a bit worried that relevant application do not properly support btrfs and we take a step backwards and force the novice end to the terminal to deal with various filesystem related stuff if we switch to btrfs by default ( as opposed to make the switch when the proper support is in relevant applications ). Personally I have yet to see what benefits btrfs brings the novices end user over other filesystems that warrants us to switch to it by default. JBG

2 2

GNOME Shell window manager (mis)behaviour
by Michael Schwendt 08 Jun '11

08 Jun '11

Hello everyone, on 2011-04-06 I've filed https://bugzilla.redhat.com/693990 for "mutter" [ gtk_window_deiconify() ignored : Claws Mail starts minimized ] which hasn't gotten any response yet, although there are several people on the Cc list. It's somewhat sad there is only silence in that ticket. Due to lack of responset there we've worked around the show-stopper with a hack - https://bugzilla.redhat.com/attachment.cgi?id=490216 - to fix it for F15 final, but upstream of Claws Mail has merged that patch only reluctantly because they think it's a bug in the window manager. Now there's another similar issue. In F15 GNOME Shell, several of Claws Mail's dialogs don't get focus: https://bugzilla.redhat.com/711257 They get displayed, but the title bar is greyed out, and the user needs to click the dialog to activate it. This is new behaviour since F14 and not reproducible with e.g. Openbox in F15. Are there any hints on what could be done in the app to make it work flawlessly again within Fedora 15 GNOME Shell?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop June 2011