Moving this to gtk+3.0. I believe it is gtk 3 specific. It is not just
limited to gedit, it happens with any app using indicator-appmenu (I
notice it most often under okular on pdfs with lots of bookmarks). But
it is also not indicator-appmenu specific because the following code,
when run with:
UB
Thanks again for testing.
In my haste, I forgot to update the other location where
purple_conversation_get_name() was used, when deleting the conversation.
I pushed one last change out to ppa:jconti/gnome3, if you wouldn't mind
checking that closing a conversation window removes the associated men
After a few minutes thought, I realized if
purple_conversation_get_name() == sender, and I can get the buddy with
account and sender, then I should be able to do the same with the
conversation name. So I have pushed a new test package to
ppa:jconti/gnome3. Please test it out and let me know if it f
Though now I'm concerned that the patch will break jabber users where it
previously worked because they didn't have random strings at the end,
but still don't have purple_buddy_get_name() matching
purple_conversation_get_name()...
--
You received this bug notification because you are a member of
Thanks for testing. That buddy id was exactly what I was hoping to see,
so at least that part seems to be fixed.
Problem 1, as Sebastien mentioned, was unfortunately always there. I'm
not sure how to fix it. On my system at least, sometimes I will get the
first notification, sometimes not. I think
Thanks for the information, the random characters at the end of the
buddy name seem to be what's hurting us here. It seems that sender may
contain too much information, looks like where the message originated
from. Originally it was using purple_buddy_get_name() instead of sender,
but for all the p
There is an attempt in pidgin-libnotify to generate unique strings for
each buddy, where each string is the id of a menu item in the Messaging
Menu. If you are getting repeat entries, then for some reason it is
generating two different strings for the same buddy.
If someone experiencing this bug c
Ah, in that case this may just be a bug with my setup.
$HOME/.config/autostart/ is likely read before any of those directories,
and I have a copy of gnome-settings-daemon.desktop in there. Thanks for
the information. I'll delete it and continue testing, but this bug is
probably invalid.
--
You re
Public bug reported:
It appears if enabling the upstart user session (
https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes#Upstart_User_Sessions_.28technology_preview.29
) there is a race between gnome-session and upstart for who starts
gnome-settings-daemon first.
Most of the time on my system,
I think I worked out at least part of the problem, so might not be a
gnome-control-center bug after all. gnome-control-center uses the
mimetype "video/x-ogm+ogg" to determine the default Video app in Default
Applications. SMplayer does not have this mimetype in its
smplayer.desktop file, but instea
Guess I should have looked at the code immediately. There was a bit of
refactoring in libmessaging-menu/messaging-menu.c and it seems the
boolean for draws_attention was always set to TRUE mistakenly. Attached
a branch that should fix it.
** Changed in: pidgin-libnotify (Ubuntu)
Status: Con
Looking at the output of: pidgin -d; I see that when I focus the
conversation, I get "REMOVING ATTENTION FOR (...)" so the plugin thinks
it is doing the right thing anyway.
I am going to add indicator-messages to this bug, I'm not sure this is a
pidgin-libnotify issue. I can reproduce the problem
@KruyKaze: Did you run gm-notify once first? You can search for it in
the dash or run gm-notify from the command line. It needs to be run once
to register with the messaging menu. (Unlike in previous versions where
there was a file in /usr/share/indicators/messages/applications/ that
would tell the
Bah sorry everyone, I was reviewing the patch after the comment and I
forgot a g_strfreev() on an error (that shouldn't ever happen but
still).
** Patch added: "pidgin-libnotify_messaging_menu_support_v3.debdiff"
https://bugs.launchpad.net/ubuntu/quantal/+source/pidgin-libnotify/+bug/1040259/+
Seems that the further testing was needed. When adding chat support I
had to change how attention was set and didn't notice that it was being
set when the conversation was focused as well. Fixed in this patch.
Didn't update the ppa with the changes.
** Patch added: "pidgin-libnotify_messaging_menu
Turned out that chat support was pretty straightforward to add, so I
went ahead and finished the patch. Should have pretty much everything
now, besides buddy icons, but note that the chat support is not
extensively tested yet since I don't use that feature. I noticed that
the pidgin-libnotify task
Ported gm-notify at lp:~jconti/gm-notify/messaging-menu with a test
build soon to be available at ppa:jconti/gnome3. Please let me know if
anyone finds any serious regressions in functionality.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed
@Chow Loong Jin: Thanks for the patch, I'll take a look and see if I can
clean up ubuntu_notify_support.patch a bit.
The problem with pidgin quitting after closing the buddy list is that I
didn't include a call to pidgin_blist_visibility_manager_add () (there
is some leftover cruft in ubuntu_notif
If it helps, I have partial pidgin support working (I'll attach a
debdiff). It implements status changing and indicators for IM messages
with buddies.
Ran into two bugs so far which kind of blocked my progress a bit:
Can't unload/reload plugin without a crash:
https://bugs.launchpad.net/ubuntu/+
A new feature of indicator-messages is that it will hide itself when
there are no apps using the menu. Unfortunately several applications
still need to be ported to the new libmessaging-menu API, including
Pidgin (I do not know about Hotot). This is
https://bugs.launchpad.net/ubuntu/+source/evoluti
Pidgin hasn't been ported to the new indicator-messages API yet, this is
bug https://bugs.launchpad.net/ubuntu/+source/evolution-
indicator/+bug/1040259
The system tray icon should work as a workaround, however in Unity,
Pidgin must be whitelisted before it will appear. Something like:
gsettings
Seems significantly better in quantal, so I am going to mark this as
fixed.
** Changed in: unity (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dp-unit
Hi Sam,
Yes the COMPIZ_CONFIG_PROFILE environment variable is still used, but if
unset or the empty string compiz first checks GNOME_DESKTOP_SESSION_ID,
which in quantal is currently set to 'this-is-deprecated'. If it is set,
then it returns the section name as "gnome_session". Doesn't really
matt
Alright, ideally I would use gsettings, but I cannot figure out how to
set up the default plugins without running some sort of script in the
user session to set the keys if they are not already set.
So, my thought is that we can just use the ini backend but with the
attached patch to compizconfig/
Though it does work with the gsettings backend if the settings are set
at the user level with either ccsm or:
gsettings set org.compiz.core:/org/compiz/profiles/Default/plugins/core/
active-plugins
"['core','composite','opengl','decor','move','imgpng','place','resize']";
So I guess it is just fro
I noticed that when loading ccsm in the gnome classic session it
outputs:
Backend: ini
I can force it to use the gsettings backend by adding:
[gnome_session]
backend = gsettings
profile = Default
to /etc/compizconfig/config, but it will just load the unity active-
plugins from /usr/share/glib-2
Updated the debdiff, forgot to bump the gtk+3.0 build-depends to 3.5.13
for the new gtk_entry_set_attributes() function in the patch.
** Patch added: "gnome-control-center_fix-big-editable-labels-v2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1041756/+attachmen
Attaching a debdiff with the upstream commit that fixes the issue.
** Patch added: "gnome-control-center_fix-big-editable-labels.debdiff"
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1041756/+attachment/3305931/+files/gnome-control-center_fix-big-editable-labels.debdiff
Just tested again and I can reproduce the problem in XFCE 4.10 in
quantal as well. Login with unity-greeter, Settings/Mouse and
Touchpad/Theme, change it to something like redglass size 48, every
cursor changes but LEFT_PTR.
Logging in with GDM and the cursor changes correctly.
Logging in with li
@Padfoot: I'm not saying this is a lightdm-gtk-greeter bug, as I said
above, it only triggers the issue. It could well be an xorg or GTK bug.
What I was saying is that if I log into Gnome with lightdm-gtk-greeter
(or unity-greeter) and the cursor is set on the root window, cursor
changing and resi
I should also note that setting the cursor explicitly to the LEFT_PTR in
any gtk app will cause that app to show cursor updates properly when
hovered over (which is why I think Firefox still works when you hover
over it as mentioned in bug #86184 ):
#include
#include
int
main()
{
gtk_init(NUL
We have actually been looking into this issue recently in #ubuntu, so I
thought I'd add my finding here.
As mentioned in the linked debian bug, logging into the session with gdm
fixes the issue (unless you are logging into a session that uses
compiz). And at the bottom of the report, lightdm-kde-g
Thanks for the bug report. I found an upstream bug here:
https://bugzilla.gnome.org/show_bug.cgi?id=668035 and I submitted a
simple patch to fix it.
You can workaround the issue by manually adding:
PACKAGENAME
VERSION
REVISION
to the generated xml. It seems that is exactly what glib does, to
c
Thanks for the screenshots. It turns out I am able to reproduce this in
the unity-2d session. Bug #1005136 is about adding the option for that
session.
Please check:
echo $DESKTOP_SESSION;
to see if you are running the ubuntu-2d session. If so, either try the
Ubuntu session or there are workarou
One more idea, try running in a terminal:
XDG_CURRENT_DESKTOP=Unity gnome-control-center;
It will only show that option in a unity session, but maybe your
XDG_CURRENT_DESKTOP environment variable is overwritten somewhere. If
the above works, check:
echo $XDG_CURRENT_DESKTOP;
--
You received th
Thanks for the bug report. However, I cannot reproduce this bug. I am
going to move this to gnome-control-center. Can you add the output of:
apt-cache policy gnome-control-center;
Maybe you have a PPA overriding the default package. A screenshot of the
Appearance dialog may also be helpful. Thank
Thanks for the bug report. I can confirm that enabling greeter-show-
manual-login results in the behavior above. This appears to be some sort
of drawing bug in unity-greeter, so I am going to move the bug to that
package.
After adding a few more debugging lines, the only difference I noted
between
CTRL+D sends EOF to the shell, indicating the end of input, so the shell
exits, which causes gnome-terminal to exit. You can verify this by
running another bash session in the terminal:
bash
then press CTRL+D. That instance of bash will exit but gnome-terminal
will remain open. Another example, a
Have you tested this since the updates to glib 2.32 and gtk 3.4? I
marked this as confirmed last night since I could reproduce it
consistently, but since the updates today, I can no longer reproduce the
issue.
--
You received this bug notification because you are a member of Desktop
Packages, whi
This is fixed in 3.3.8-0ubuntu1.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gtk+3.0 in Ubuntu.
https://bugs.launchpad.net/bugs/917071
Title:
gedit crashed with SIGSEGV in
_gtk_tree_selection_internal_select_node()
Status in “ge
*** This bug is a duplicate of bug 917071 ***
https://bugs.launchpad.net/bugs/917071
I believe this issue is the same as bug #917071 so I am going to mark
this bug as a duplicate, since the other has a bit more information.
Thanks for the test case!
** This bug has been marked a duplicate of
It isn't limited to gedit, but seems to affect any GtkTreeView. I
believe it is fixed upstream though:
http://git.gnome.org/browse/gtk+/commit/gtk/gtktreeview.c?id=022c576bd2764dc1fc48e46ad97aa95287c175cc
Rebuilt gtk with the patch and I can't reproduce the crash.
** Also affects: gtk+3.0 (Ubuntu
Looks like this is the same bug as in
https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/908787
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/910195
Title:
nautilus cra
Found the problem, it is actually caused by ubuntuone-client
(specifically libsyncdaemon). Due to a recent change from bug #859635 ,
the library is registering a dbus message marshaller for VOID__POINTER,
however the type registered is actually VOID__BOXED, which happens to be
the same type as Devi
I can reproduce this in precise as well. Here is a slightly better
backtrace:
1) gdb nautilus
2) run Computer://
3) Double click a partition in the nautilus window
4) Following backtrace:
(gdb) run Computer://
Starting program: /usr/bin/nautilus Computer://
[Thread debugging using libthread_db en
I managed to get this to work by editing both /etc/pam.d/lightdm and
lightdm-autologin and adding:
account requisite pam_time.so
after the @include common-account line. Also edited /etc/pam.d/login and
uncommented the pam_time.so line.
After that, I added a line to /etc/security/time.conf and ad
The greeters were moved to /usr/sbin but the PATH only contains
/usr/lib/lightdm/lightdm:/usr/local/bin:/usr/bin:/bin. They used to be
in libexecdir which is manually added to the path in
session.c:session_start.
The greeter log at ~/.cache/lightdm/log/:1-greeter.log contains:
exec: 33: lightdm-g
47 matches
Mail list logo
