Just wondering if anyone else has experienced in F18 (GNOME3.6) a weird
bug where the alt+tab switcher does not disappear?
When it happens, i can press press alt+tab again and other switcher is
displayed under (z-index wise) the one already on the screen. If i keep
pressing alt+tab, these layer up also.
The annoying part is that when you go to restart the shell, (with
alt+f2), that overlay does not get keyboard focus, so you can't restart
it from there. The only way to restart the shell is to switch to another
tty, and kill the gnome-shell process with kill -9
anyone else experiencing this issue?
I recently discovered that if I have a printer attached to a Windows
machine (and shared via samba), it'll unusable on default install, because
samba-client isn't installed by default.
control-center's printers panel managed to discover the printer, but after
the driver prompt dialog it gave a cryptic error message and did not
install the printer.
After installing samba-client, adding a samba network printer worked as
expected. Therefor I suggest we add samba-client to our default
installation, it's only 1.2MB.
Ideally I think it should be added as a Requires in control-center's spec
file, but we could add it to comps instead. If you think adding this to the
default install is a bad idea, control-center should install it with
packagekit whenever users tries to add a Samba printer.
On a related (printing) note, I think it would also make sense to have
hpijs as a default as well, to support more printers.
Unar got approved recently
It is a multi-format extractor but the key part is that it has support for
RARv3 format and is a replacement for the non-free unrar (in RPM Fusion).
unar and lsar are just command line tools but file-roller does support it
since 3.6. Once unar gets built, I intend to push the packages changes in
file-roller (BR on json-glib-devel and requires on unar) for Rawhide and
Fedora 19. I have already tested it with a variety of RAR files and it
If anyone has any objections, let me know. Thanks
So I reported this bug back in October 2012, but it has had zero
it seems like kind of a significant bug, and it got into the release of
F18, and it's still in F19. Is anyone ever going to get around to
dealing with it?
The problem is that the "Important updates are available" notification
launches the *online* update tool. If our story is that offline updates
are the Way To Go for 'normal' users - which is certainly what
https://fedoraproject.org/wiki/Features/OfflineSystemUpdates seems to be
saying - then that's inconsistent. It seems like once the 'Install
updates and restart' bit was done people just kinda figured the feature
was done, without considering how interaction with gnome-pk should be
handled. Note the item "Update gnome-packagekit to support offline
updates" under 'Scope' is not marked as 'done', but the feature is
listed as 100% complete.
There's an implication on the feature page that there should be a
distinction drawn between updates of 'OS components' (which should be
offline) and 'application updates and installations' (which should still
be possible online), but there's no indication this has actually been
implemented, and in my testing, the update notification pops up and
calls gnome-packagekit even when the update package set contains the
kernel, or systemd, or anything like that.
It just seems like the intersection between gnome-pk and offline updates
isn't really done yet, and needs to get finished off...
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
Hello. I'm developing an application for desktop which consist on digital
treatment of images. The idea is not to open the terminal to launch the
program, but there's a little problem: I don't know how Nautilus know that
.jpg (or .png) files can be opened with my program, and what can I do to
Thanks to all!
With F19, I have a bug where shaded windows leave their decorations
(specifically, the drop shadow) behind. I love the window-shade behavior
(makes more sense than the dreaded minimize button), and it's kind of hard
to do my daily work in F19 without it. (I know weirdness the price I pay for
running F19 pre-alpha even, but, tasty dogfood and all that.)
I filed this bug here https://bugzilla.redhat.com/show_bug.cgi?id=924406;
is it more effective to instead file this in the Gnome bugzilla?
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
control-center-3.8.0-2.fc19 added the Fedora logo (instead of the GNOME
logo) on the details panel of the GNOME desktop control center. This is a
good idea, but I see two problems:
1) Use the full logotype, not just the logomark
2) The lack of the ™ symbol next to the logomark violates our own logo
usage guidelines .
On 04/03/2013 10:25 AM, Ryan Lerch wrote:
> On 04/03/2013 03:33 AM, Elad Alfassa wrote:
>> control-center-3.8.0-2.fc19 added the Fedora logo (instead of the
>> GNOME logo) on the details panel of the GNOME desktop control center.
>> This is a good idea, but I see two problems:
>> 1) Use the full logotype, not just the logomark
>> 2) The lack of the ™ symbol next to the logomark violates our own
>> logo usage guidelines .
>>  https://fedoraproject.org/wiki/Logo/UsageGuidelines
> Elad, Thanks for bringing this up!, However, I dont have a functioning
> f19 machine at the moment, would you be able to upload a screenshot so
> we can see the logo as it is currently presented?
> WE i think we should also just file a bug against this component in
> Fedora. Is that the correct course of action?
After a quick look into the patch that changed the logo, it seems that
it is using the following file (the image itself is supplied by the
That file is just the logomark (the F bubble), without the "TM"
If we do want the full logo (fedora + bubble) here, i *think* this is
the file that should be used (once again the file itself is supplied by
the fedora-logos package):
Can anyone else throw any insight on what logo we should present here?