To elaborate on the previous remark: why didn't we just replace:
menu_monitor_queue_event (event_info);
with:
g_timeout_add_seconds (2, menu_monitor_queue_event, event_info);
(and make sure menu_monitor_queue_event() returns FALSE)?
--
You received this bug notification because you are a
The latest patch looks good to me, but with a couple of notes (no need
to fix these):
- using the _full() version of the timeout call is not necessary here
- now that this patch is simplified it becomes easy to see how all of
this is just putting values into one structure and then later moving
The patch in comment 42 is not acceptable, for two big reasons.
First: you need to hold a ref on the GFile object when you put it into
the info struct. This means that you cannot simply use g_free for the
struct: you need to write a custom free func that handles the unref as
well. Also: you can'
Although I agree that it makes sense to allow the user to modify their
own data even if not "actively logged in", I think it would also be
interesting to track down the program that is the real source of this
problem. ie: let's figure out which part of the session is writing to
accountsservice at
A couple of notes:
- this is fixed upstream in GLib already
- watching dbus for the signal is fine, but you should not use dbus to
read the property in the first place. This will result in activation of
the datetime service, which is expensive.
--
You received this bug notification because y
Just to play devil's advocate a bit here:
The logic taken in this bug (that we should show the device that will
run out of power first) seems perfectly sound, but it makes a very large
assumption, which I suspect will often be untrue: that reporting of time
remaining on mice will always be complet
Public bug reported:
The indicator implements the spec:
https://wiki.ubuntu.com/Power#Handling_multiple_batteries
which states:
"Their percentages should be averaged."
Apparently this was taken to mean the simple arithmetic mean, and not
the weighted average (by the capacity of each batter
In fact, I think this was fixed a year ago already:
https://bugzilla.gnome.org/show_bug.cgi?id=724929
Did anyone see this in newer Ubuntu releases (ie: the released version
of trusty or later)?
--
You received this bug notification because you are a member of DX
Packages, which is subscribed
It's worth noting that this bug can no longer occur as it is described
here -- g_mutex_lock() has been rewritten and the new version doesn't
abort.
That said, the underlying issue that was causing the misuse of a mutex
could very well still exist... Unfortunately, it's very difficult to
guess wha
Yup. This is a GIO issue. We register a file monitor and don't bother
checking if desktop files changed until we see the file monitor has
fired. Due to inotify implementation issues, this usually happens about
~1s later.
We will need to add a mechanism to force a reload and/or do it
automatical
** Changed in: indicator-appmenu (Ubuntu)
Assignee: Ryan Lortie (desrt) => (unassigned)
--
You received this bug notification because you are a member of DX
Packages, which is subscribed to indicator-appmenu in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/b
11 matches
Mail list logo
