On 6/29/07, Dr. Diesel <dr.diesel(a)gmail.com> wrote:
> Any plans to incorporate into rawhide?
was about to ask the same? what are the compiz plans for f8? will
compiz-fusion replace compiz and berly?
I've been playing with Bigboard for a while now and for this stage in
development it's both fairly solid and useful, however one thing makes
it work rather badly - the way it selects applications.
My background is on the QA team which means I tend to favor crashing
applications, reproducing crashes over and over. This leads to bug-buddy
being launched quite a bit, in fact so much that's now the 6th most used
application on my desktop, which means it's now listed in my application
list. The thing is Bug-buddy is no use for me as a separately started
application so it shouldn't be listed there in the first place.
I do realise this is one of those corner cases which on a real desktop
will (hopefully) never happen.
- David Nielsen
After just installing Fedora 7 on a new drive I was setting the screen
resolution to 1600 x 1200. The screen went black with a gray box voting
around that reads:
Not Optimum Mode
Recommended Mode: 1600 x 1200
I'm sure this is because I didn't install the driver for this monitor but I
don't know how to get to a lower resolution. I tried searching the Fedora 7
installation forum archives but I don't have permission.
We've long had a way to restart system services on an RPM upgrade via
condrestart in the initscript. However, there is another kind of service
which runs, services bound to desktop sessions. Rather that global,
these are per user session.
Is there a mechanism by which an RPM which installs a desktop service
can perform the equivalent of a condrestart on the session service?
I imagine such a mechanism would work by iterating over every DBus
session bus, query for the existence of the service, if it exists send
it a stop signal and then after the service leaves the bus perform a
StartServiceByName within the session.
Do we have anything like that? I suspect not. If not then how can a root
process iterate over existing sessions?
John Dennis <jdennis(a)redhat.com>
On Fri, 2007-06-15 at 11:58 -0400, Alan Cox wrote:
> On Fri, Jun 15, 2007 at 11:44:55AM -0400, Havoc Pennington wrote:
> > The Mugshot client daemon does this itself by installing a file called
> > "version" with the package version, and if said file changes it restarts
> > itself.
> init stats its own binary and librarie (or used to)
But that exposes you to a race condition as you don't know when all the
files have been upgraded and it requires inefficient periodic polling.
John Dennis <jdennis(a)redhat.com>
In previous release of FC, in any GTK2 apps I could choose Input
Method via right click menu. But in current Gnome desktop of F7 I can
see this such menu.
Anyone know howto eable this menu ? environment variable ? .gtkrc-2.0 ? How ?
Hi I posted this bug to bugzilla:
you can see the video and the bug here:
The issue is really easy to reproduce;
mv .mozilla .mozilla.bkp
mv .macromedia .macromedia.bkp
<repeat 5 times>
and then launch firefox and go to http://www.youtube.com - and try to
install flash plugin.
</repeat 5 times>
and then restore your firefox settings from backup:
mv .mozilla.bkp .mozilla
mv .macromedia.bkp .macromedia
then report back to bugzilla (or here on the mailing list) how many
installs of flash succeeded and how much of them failed.
this is an easy task, and then we will see if this is a issue happened by some
off chance only to me or this is a bug.
I don't see how you don't see the problem here. I posted a bug also
for fedora 7 test 4, it happened there also... and how it happened
again... so you draw your own conclusions...
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
[ Cc: and Reply-To: fedora-desktop-list ]
On Thu, 2007-05-31 at 19:57 +0000, Kevin Kofler wrote:
> Matthias Clasen <mclasen <at> redhat.com> writes:
> > So the two of you simply decided that it would be better for everybody
> > if the menu item changed from the (somewhat cryptic, but informative)
> > "IRC" to the totally meaningless "X-Chat" ?
> X-Chat has a meaning, it's the particular IRC client called X-Chat. There's
> several IRC clients in Fedora, including one called xchat-gnome which several
> people think should be the default (in fact, I'd LOVE for it to become the
> default, not because I actually use it, in fact I hate it, but because that
> could lead you to leave the regular X-Chat alone!), so "IRC" is very vague as a
> menu entry.
> And KDE actually displays "X-Chat (IRC client)" if the user preferences are set
> that way. Why does GNOME _still_ not support GenericName years after this
> specification has been supposedly agreed on? IMHO, the real technical problem
> lies there, mangling .desktop files like this is just papering over the
I'm not sure how you think that the Fedora GNOME desktop should be using GenericName.
The usage of a generic instead of a specific name in the Fedora menus is done for
a small subset of applications: those considered to be "best of breed".
Using a generic for everything would produce menus that looked like:
Now, using a generic for *anything* is really a hold-over from a past era when
our vision of the Fedora menus was that we'd select a small set of best-of-breed apps
for our users, instead of making them deal with the chaos of the entire set of
This no longer fits with the Fedora philosophy, especially considering the merge
of core and extras. The question is more "how to manage the chaos".
Ideas that some of us have been working on for managing the chaos:
- Collect statistics for the top applications in real use
- Concentrate on making it easy for the user to launch the applications
they use most
- Bring together the installed applications and the available applications
Those mockups are a bit stale ... the real thing is better. (bigboard package in
extras, but you might want to wait until tomorrow ... Colin has some neat stuff
in the pipeline for setting everything up for online-desktop mode.) But you
can see, sort of in the mockups, and more in the real thing, what we are using for
With a tooltip of "Chat with your friends".
(We get this from a merge of desktop files with the online Mugshot application
database; neither GNOME nor KDE desktop files have all three of the above.
GNOME desktop files miss the GenericName, KDE desktop files miss the tooltip.)
OK, back to the present: My advise for the X-Chat is to make it match how we
do a lot of other .desktop files now: do "X-Chat IRC Client" like "Firefox Web Browser"
and so forth.
Yes, that will screw over the KDE user who has chosen the Name (Generic Name)
preference, but they already have Firefox Web Browser (Web Browser), so they
can deal. Maybe we need X-Fedora-Name:, on the other hand, if we manage
to make bigboard work, we don't need Fedora-customized menus at all,
so we can (eventually, not right now, please), just use Name: X-Chat and
get rid of having to munge desktop files as compared to upstream.
I have been running Big Board ever since it was brought up on this list.
Some questions and observations:
Is this meant to replace both the top and bottom GNOME panels? I don't
see a equivalent of a task bar if it's meant to replace them both. Why
hasn't the package been submitted for review? The color on the panel is
a plain white and doesn't match the rest of GNOME system colors. I see
no way to move the panel around either. I can understand the lack of a
quit option if it is meant to replace the panel.
Is big board tied to mugshot? What if I don't have a mugshot account?
Trying to change the pic shown on the identity, application
descriptions, more button in calendar etc launches mugshot pages.
The icons including facebook, flickr etc doesn't have any tooltips. The
functionality of deskbar is not obvious.
The more link on applications launches a side panel. The descriptions
near the search button sometimes overflows the boundary. Example:
Epiphany. Installing a new application via the menu launches a command
line yum command. Though it works this is crude. You should be using the
Yum API and integrating with Pirut instead. Clicking on another area of
the desktop doesn't close this menu or even move it away which is annoying.
There are three sections - applications, photos and calendar. If i don't
intend to use any or all of these sections in the panel there is no way
to remove them although clicking on it minimizing the section within the