Opened 12 years ago

Closed 9 years ago

Last modified 7 years ago

#2629 closed patch (fixed)

Modifications needed for building with native GTK on MacOSX + docklet using GtkStatusIcon

Reported by: nevil Owned by: QuLogic
Milestone: 2.7.0 Component: pidgin (gtk)
Version: Keywords: MacOSX gtk native
Cc: mcepl, sniperbeamer, benjavalero, ari

Description

This is a patch that modifies the Pidgin.im source to build on MacOSX with the native Gtk (non X). It modifies the configure scripts to disable parts that rely on X.

It also includes a simple version of a docklet implemented using the GtkStatusIcon? API.

New configuration options: --without-x -> Will disable compilation of things depending on X, including gestures and screen saver. --disable-gestures -> disable the gesture plugin --enable-gtkstatusicon -> Use a the GtkStatusIcon? version of the docklet instead of the old version. This requires Gtk2+ >=2.9.0

I am no autoconfig master so please give me comments on the modifications.

Attachments (14)

gtk-quartz-macosx.patch (28.9 KB) - added by nevil 12 years ago.
The patch created with mtn diff
ahasconfig.sh (562 bytes) - added by nevil 12 years ago.
small script I use for configuring and running autogen.sh
gtkstatusicon.diff (22.7 KB) - added by nevil 12 years ago.
Patch to add a docklet using GtkStatusIcon? interface
withoutX.diff (7.7 KB) - added by nevil 12 years ago.
Patch to remove dependency on X (except for docklet...)
gtkstatusicon.2.diff (23.6 KB) - added by nevil 12 years ago.
GtkStatusIcon?, now setting the Icon should work on X too.
gtkstatusicon.3.diff (19.3 KB) - added by shreevatsa 12 years ago.
slightly modified version of gtkstatusicon.2.diff
gtkstatusicon.4.diff (11.4 KB) - added by shreevatsa 11 years ago.
Current version of remaining patch: Fixed 2.9 to 2.10; removed whitespace changes
ws-changes.diff (8.0 KB) - added by shreevatsa 11 years ago.
whitespace changes from the previous diff
gtkstatusicon.5.diff (9.4 KB) - added by shreevatsa 11 years ago.
Version without the "blink" padding the ui_op, so that it can go into Pidgin with only a minor bump
pidgin-2629-gtkstatusicon.diff (11.8 KB) - added by QuLogic 10 years ago.
pidgin-gtkstatusicon-win32.png (46.2 KB) - added by charkins 10 years ago.
issue with docklet context menu w/ GtkStatusIcon? on win32
pidgin-gtkstatusicon-blink.diff (12.0 KB) - added by charkins 10 years ago.
QuLogic's latest patch with blinking implemented in gtkdocklet-gtk (this time with gtkdocklet-gtk.c)
icon-diff.png (1.8 KB) - added by sniperbeamer 10 years ago.
gtkstatusicon_pidginstock.patch (837 bytes) - added by sniperbeamer 10 years ago.
Fix PIDGIN_STOCK_TRAY_* constants

Download all attachments as: .zip

Change History (73)

Changed 12 years ago by nevil

The patch created with mtn diff

Changed 12 years ago by nevil

small script I use for configuring and running autogen.sh

comment:1 Changed 12 years ago by seanegan

  • Milestone set to 2.1.2
  • Owner set to seanegan
  • Status changed from new to assigned

Can you remove all your whitespace changes please?

comment:2 Changed 12 years ago by nevil

I thought you wanted to use tabs instead of spaces for indentation so I changed that when I stumbled upon it.

I'll undo it.

comment:3 Changed 12 years ago by seanegan

Oh, nevermind then, I didn't realize it was *fixing* indentation; I assumed it was *breaking* it. Thanks.

comment:4 Changed 12 years ago by nevil

I seem to have made a small mistake in pidgin/gtkdocklet.c when I was testing if the defines was set correctly by the configure script

/************************************************************************** 
 * docklet status and utility functions 
**************************************************************************/ 
#ifndef GTK_STATUS_ICON 
sdsd 
static gboolean
docklet_blink_icon_cb()

I accidentally left the text sdsd in the patch. It should be removed otherwise it will cause compile error when compiling with the old x11-docklet. I just arrived at work so I can't fix the patch until tonight when I get home. Sorry for that stupid mistake :-(

comment:5 Changed 12 years ago by nevil

I split the patch in two parts. One for adding the new GtkStatusIcon? docklet and one for the modifications needed to compile without X11. I should probably have done this originally, although they patches are a bit related since they are both needed for running with Gtk native on MacOSX.

Changed 12 years ago by nevil

Patch to add a docklet using GtkStatusIcon? interface

Changed 12 years ago by nevil

Patch to remove dependency on X (except for docklet...)

comment:6 follow-ups: Changed 12 years ago by seanegan

For the docklet patch, it looks like you added a blink() function to the struct because gtkdocklet did blinking manually, and you wanted to use GtkStatusIcon?'s implementation directly. Is that right?

That change will need to wait for 2.2.0, as it changes the API, but I can accept the other patch for 2.1.2.

comment:7 in reply to: ↑ 6 Changed 12 years ago by rlaager

Replying to seanegan:

For the docklet patch, it looks like you added a blink() function to the struct because gtkdocklet did blinking manually, and you wanted to use GtkStatusIcon?'s implementation directly. Is that right?

That change will need to wait for 2.2.0, as it changes the API, but I can accept the other patch for 2.1.2.

charkins committed a change that already forces us to 2.2.0 for the next release, unless that's going to be reverted.

comment:8 in reply to: ↑ 6 Changed 12 years ago by nevil

Replying to seanegan:

For the docklet patch, it looks like you added a blink() function to the struct because gtkdocklet did blinking manually, and you wanted to use GtkStatusIcon?'s implementation directly. Is that right?

Yes, that is correct. Internally GTK probably does almost the same thing as the current Pidgin docklet since they seem to be based on the same code. I should probably have moved all blinking code into the docklet plugin but I wanted to avoid a small amount of code duplication. However there is not much code so maybe I should move the manual blinking code into docklet-x11 and docklet-win32 anyway?

And one more thing, I don't have a way to test the behaviour of the docklet-gtk under anything else than native GTK on MacOSX so I would appreciate if some one could test it using Gtk-X11. Especially to see that the event mapping (left mouse click, right mouse click and double click) are ok.

comment:9 follow-up: Changed 12 years ago by seanegan

I applied the withoutX patch, but am having problems with gtkstatusicon-gtk

  • GtkStatusIcon? seems to depend on having icons in the standard GTK_ICON_SIZE sizes; anything other than the 16px icon shows the broken image icon. I'm not sure how to best remedy that. It seems like a GtkStatusIcon? bug if anything.
  • Left click doesn't work as it should (it doesn't do anything).

comment:10 in reply to: ↑ 9 ; follow-up: Changed 12 years ago by nevil

Replying to seanegan:

Regarding the icon sizes, I fixed it for Mac by changing the size in pidginstock.c from GTK_ICON_SIZE_MENU to GTK_ICON_SIZE_SMALL_TOOLBAR.

#if defined(__APPLE__) && !defined(HAVE_X11) 
    gtk_icon_source_set_size(source, GTK_ICON_SIZE_SMALL_TOOLBAR); 
#else 
    gtk_icon_source_set_size(source, GTK_ICON_SIZE_MENU); 
#endif 

It worked but is a bit hacky so I didn't do this change for other than Mac. You are correct in that GtkStatusIcon? only looks for stock icons in the exact size you tell it to. However, it will rescale the icon to the correct size anyway so it works.

Regarding the left click not working, I was kind of expecting that. I've had no way of testing which id's are returned in the callback. http://library.gnome.org/devel/gtk/unstable/GtkStatusIcon.html#GtkStatusIcon-popup-menu

The problem is that the button id's received in docklet_gtk_status_clicked_cb doesn't match what pidgin_docklet_clicked() is expecting.

I can check the source of Gtk tonight after work to create a mapping that works for X11 too. (It doesn't seem to be in the documentation...)

comment:11 in reply to: ↑ 10 Changed 12 years ago by seanegan

Replying to nevil:

Replying to seanegan: Regarding the icon sizes, I fixed it for Mac by changing the size in pidginstock.c from GTK_ICON_SIZE_MENU to GTK_ICON_SIZE_SMALL_TOOLBAR.

That's a really bad hack, that will break things in other places. It sounds like a design flaw in GtkStatusIcon?.

I'd say the two best ways to do this are to either do the scaling yourself, using gtkdocklet-x11's scaling code, and not use set_from_stock, or alternately, look at GtkStatusIconQuartz?.c and create a gtkdocklet-quartz.c based on it.

comment:12 Changed 12 years ago by nevil

I prefer scaling the icons myself then. The reason for using GtkStatusIcon? and not going "os level" is to make it possible to use the same status icon code on all platforms. This interface should be portable.

I've been busy at work the last two days but I hope I will finish this up during saturday.

comment:13 Changed 12 years ago by nevil

I'm sorry. I haven't had time to look at this yet and it will take some more days. We are close to a release at work and urgent issues was reported by a customer, which means no spare time for me for last weekend and at least 3 days during this week.

Sorry guys.

comment:14 Changed 12 years ago by seanegan

  • Milestone changed from 2.2.0 to 2.3.0

comment:15 Changed 12 years ago by lschiere

Where do we stand on this?

comment:16 Changed 12 years ago by nevil

I haven't had time to do the necessary modifications to the GtkStatusIcon? patch... I hope to have the necessary time this weekend (I know, I've said it before). It shouldn't take that much time to fix when I actually have time. When is the 2.3.0 planned to be frozen?

comment:17 Changed 12 years ago by charkins

2.3.0 is currently slated for October 25th, so there's a bit of time. There's an additional ui_op that I'm planning on adding to the docklet for 2.3.0 as well (ticket #521), but it should be trivial to implement for the GtkStatusIcon?.

Changed 12 years ago by nevil

GtkStatusIcon?, now setting the Icon should work on X too.

comment:18 Changed 12 years ago by nevil

I have now added a new version which correctly scales the icon itself.

I couldn't figure out the problem with left mouse button not working. According to the GTK source, button 1 is left mouse button, and this should match with what pidgin_docklet_clicked() expects.

I added debug print to see which event is actually delivered. Please check if it is not working. I don't have X installed so I can not test.

comment:19 Changed 12 years ago by shreevatsa

Just want to report that this works :)

I got gtkstatusicon.2.diff and applied it. A couple of hunks in the patch failed because the old code has been cleaned up using macros, but they were only whitespace changes so I ignored it... compiled Pidgin from within the jhbuild shell with

--without-x --enable-gtkstatusicon --disable-gestures

And now I have Pidgin running on my Mac, and it even has a working tray icon. Thank you!

comment:20 Changed 12 years ago by nevil

My plan was to try the menu sync code from Imendio to make Pidgin more Mac like, but I haven't had any time to even start Pidgin since beginning of october :-(

http://developer.imendio.com/projects/gtk-macosx/menubar

Changed 12 years ago by shreevatsa

slightly modified version of gtkstatusicon.2.diff

comment:21 Changed 12 years ago by shreevatsa

The old .diff file choked a bit and I had to apply a patch by hand; so I've generated the new .diff file and attached it.

It's the same as the old version, except for a few line numbers that have changed, and fewer whitespace-only diffs.

comment:22 Changed 12 years ago by shreevatsa

Shouldn't this ("Use GtkStatusIcon? instead of X11 docklet") be the default for Pidgin, BTW? Surely it's better to use GTK-only stuff than to work with X11 directly...

comment:23 Changed 12 years ago by charkins

We maintain backwards compatibility with all gtk+ 2.x versions. GtkStatusIcon? was added in 2.10, so we can't ditch the X11 implementation entirely. However, it would be reasonable to use GtkStatusIcon? on all platforms when built with gtk+ 2.10, patch for that welcome as well. :-)

comment:24 Changed 12 years ago by nevil

shreevatsa: Thanks for helping with this. I haven't had the time to push this to get it included. I really appreciate what you are doing.

I noticed an error in my configure.ac. I am checking for GTK version 2.9.0 and later. Not 2.10.0 and later. I'm sure I read some where that GtkStatusIcon? was added in 2.9.x but it seems I was wrong.

If you have time please change this. Thank you!

Changed 11 years ago by shreevatsa

Current version of remaining patch: Fixed 2.9 to 2.10; removed whitespace changes

Changed 11 years ago by shreevatsa

whitespace changes from the previous diff

Changed 11 years ago by shreevatsa

Version without the "blink" padding the ui_op, so that it can go into Pidgin with only a minor bump

comment:25 Changed 11 years ago by shreevatsa

I fixed the GTK+ 2.9 to 2.10, and I removed the blink stuff for now, because getting it into Pidgin is more important, and who knows when 3.0.0 will be? This seems eligible for inclusion right now (for 2.4.0, say :-) ), and the blink stuff can be added back in for 3.0.0 (for all one knows, Pidgin's GTK dependency might be 2.10 by then, and both gtkdocket-x11 and gtkdocklet-w32 could be done away with :-))

Could a developer review this and get it in?

comment:26 Changed 11 years ago by gagern

The icon scaling doesn't seem to work here on Gentoo Linux 2007 with KDE 3.5.9, glib 2.14.6, gtk+ 2.12.8, gtkstatusicon.5.diff applied to Pidgin 2.4.0. Where the X11 setup gave me too large an icon (48px) as described in #2025, this approach gives me too small an icon (16px), where all other applications (from KDE) use 22px, arranged in two rows of icons.

comment:27 Changed 11 years ago by rekkanoryo

Ticket #7322 has been marked as a duplicate of this ticket.

comment:28 Changed 11 years ago by rekkanoryo

  • Owner changed from seanegan to MarkDoliner

Mark, I'm assigning this to you since you're the maintainer now. If I should have assigned this otherwise, let me know and I'll be happy to send it someone else's way.

comment:29 Changed 11 years ago by rekkanoryo

  • Owner changed from MarkDoliner to rlaager

Richard said I should assign this his way for him to look at after we merge the ICQ XStatus stuff to im.pidgin.pidgin.next.minor. Sorry for the noise.

comment:30 Changed 11 years ago by shreevatsa

Note for anyone trying to use these: the patches here are somewhat outdated (ignore everything); the "latest" version of these (same) patches is maintained at MacPorts. The updates have not been posted here, to avoid cluttering up Pidgin's Trac, since it's unknown when if ever Pidgin developers are going to look at this.

The patch involves a GTKStatusIcon implementation that can be used instead of the X-specific tray icon, and some changes to the autotools setup to allow using it. [Note that although the version there includes an extra field in ui_ops to get the "blink" working, that change of API can be easily removed or modified as in gtkstatusicon.5.diff above.]

comment:31 Changed 10 years ago by rekkanoryo

  • Milestone set to Patches Needing Review

Changed 10 years ago by QuLogic

comment:32 follow-up: Changed 10 years ago by QuLogic

This updated patch does not add unnecessary autotools changes. Instead, the GTK+ version is checked when compiling.

The previous version didn't actually scale the icon with the tray for me. Instead of the messy window-rendering stuff, this patch changes the creation of the stock tray icons so that their size is wildcarded. This enabled GtkStatusIcon? to pick one and scale it. However, it doesn't look quite right, so I'm hoping someone else can figure that out.

comment:33 Changed 10 years ago by Paradox

This should target 2.7.0, when the glib and gtk requirements are boosted and libegg can be fully replaced with GtkStatusIcon.

comment:34 Changed 10 years ago by QuLogic

There are no changes here that require a new GLib or GTK+.

comment:35 Changed 10 years ago by rlaager

  • Milestone changed from Patches Needing Review to 2.7.0

Even if this patch doesn't require new versions of GLib or GTK+, I'd still like to see it target 2.7.0. I think that we'll end up changing our version policy for 2.7.0, and then we can commit this with the blink ui op (since it'll be a minor bump anyway) and we can drop all the libegg code simultaneously.

comment:36 Changed 10 years ago by QuLogic

Ticket #9719 has been marked as a duplicate of this ticket.

comment:37 Changed 10 years ago by charkins

@QuLogic: Patch tests out fine for me, going to try building for win32 to confirm it works there. Do we have any developer/CPW confirming that things build OK on MacOSX? As for the blink ui op, there is no padding left in the docklet ui_ops structure, so it can't be added in a minor version bump. We can still make blinking work without the ui_op by re-implementing the blink directly in the gtkdocklet-gtk implementation (looking at that now).

For 3.0.0, we should drop the ui_ops entirely for the docklet and just implement it directly with GtkStatusIcon?. We can then implement a function for getting access to the GtkStatusIcon? object to close ticket #521.

Changed 10 years ago by charkins

issue with docklet context menu w/ GtkStatusIcon? on win32

Changed 10 years ago by charkins

QuLogic's latest patch with blinking implemented in gtkdocklet-gtk (this time with gtkdocklet-gtk.c)

comment:38 follow-up: Changed 10 years ago by charkins

There are some issues with the docklet context menu when using GtkStatusIcon? on win32. The context menu shows scroll buttons on the top and bottom, with the content appearing off of the bottom of the context menu window. After scrolling to the bottom of the menu, the scroll buttons disappear and the menu is more or less identical to the gtkdocklet-win32 version. If I can't get it straightened out soon, I think we should just switch to gtkdocklet-gtk for non-win32 platforms (dropping gtkdocklet-x11.c and eggtrayicon.[c|h]). We can try to address the win32 issue in a subsequent release.

comment:39 Changed 10 years ago by QuLogic

Ticket #10228 has been marked as a duplicate of this ticket.

Changed 10 years ago by sniperbeamer

comment:40 Changed 10 years ago by sniperbeamer

Using pidgin-gtkstatusicon-blink.diff the tray icon looks different compared to vanilla pidgin (tested on KDE and Gnome).
The icon seems brighter/semi-transparent.
icon-diff.png: vanilla (left side) / patched (right side)

comment:41 Changed 10 years ago by Paradox

I believe the difference in perceived opacity is a result of using scalable svg icons rather than the 22px icons that eggtrayicon currently uses.

To quote QuLogic:

The previous version didn't actually scale the icon with the tray for me. Instead of the messy window-rendering stuff, this patch changes the creation of the stock tray icons so that their size is wildcarded. This enabled GtkStatusIcon to pick one and scale it. However, it doesn't look quite right, so I'm hoping someone else can figure that out.

comment:42 Changed 10 years ago by sniperbeamer

Pidgin doesn't ship tray icons as svg however it probably has something to do with scaling.

comment:43 in reply to: ↑ 38 Changed 10 years ago by QuLogic

Replying to charkins:

There are some issues with the docklet context menu when using GtkStatusIcon? on win32. The context menu shows scroll buttons on the top and bottom, with the content appearing off of the bottom of the context menu window.

I think this is caused by the push_in parameter to the GtkPositionMenuFunc. According to the GTK docs, it does the following:

This parameter controls how menus placed outside the monitor are handled. If this is set to TRUE and part of the menu is outside the monitor then GTK+ pushes the window into the visible area, effectively modifying the popup position. Note that moving and possibly resizing the menu around will alter the scroll position to keep the menu items "in place", i.e. at the same monitor position they would have been without resizing. In practice, this behavior is only useful for combobox popups or option menus and cannot be used to simply confine a menu to monitor boundaries. In that case, changing the scroll offset is not desirable.

The implementation for GtkStatusIcon always sets this parameter to TRUE. In docklet_gtk_status_position_menu, you can try setting *push_in = FALSE; after the call to gtk_status_icon_position_menu.

comment:44 in reply to: ↑ 32 ; follow-up: Changed 10 years ago by QuLogic

Replying to QuLogic:

The previous version didn't actually scale the icon with the tray for me. Instead of the messy window-rendering stuff, this patch changes the creation of the stock tray icons so that their size is wildcarded. This enabled GtkStatusIcon? to pick one and scale it. However, it doesn't look quite right, so I'm hoping someone else can figure that out.

OK, so I figured out that using gtk_status_icon_set_from_icon_name will work with proper scaling. However, I haven't quite figured out the changes necessary in the makefile to get the icons in the right location (I just put them there manually for testing).

But more importantly, do icons count as "API/ABI"? If I moved all of them to conform with the icon theme spec, would that have to wait until 3.0.0? I could just move the tray icons, but that would be inconsistent.

Also, Hylke has only made a "nice" icon at 22x22. The rest will need to be updated with the blue-tinted message box and new orb.

comment:45 in reply to: ↑ 44 ; follow-up: Changed 10 years ago by datallah

Replying to QuLogic:

But more importantly, do icons count as "API/ABI"? If I moved all of them to conform with the icon theme spec, would that have to wait until 3.0.0? I could just move the tray icons, but that would be inconsistent.

I guess I'm not too worried about a temporary inconsistency. I know that some plugins use the protocol icons (not sure what else). I don't think we can break stuff before 3.0.0.

Is it reasonable to move stuff around now and make symlinks to the old places (if not, my vote is just to move the tray icons)

Also, Hylke has only made a "nice" icon at 22x22. The rest will need to be updated with the blue-tinted message box and new orb.

What happens for the other sizes (does it just look ugly, or is it broken)? If we go ahead with this early, that should hopefully be all that is needed to motivate these additional icons to appear :P

comment:46 Changed 10 years ago by QuLogic

Ticket #10676 has been marked as a duplicate of this ticket.

comment:47 Changed 10 years ago by qulogic@…

(In d47e94f98ed0b6e0a095e1f7c55cffb5a862316b):
Use GtkStatusIcon? on GTK+ 2.10+. That's actually the required version for next minor, but I'm leaving in the rest of the code until all the kinks are worked out.

I still need to figure out how to properly move the icons so that they scale nicely. The code is done, just the files need proper placement.

References #2629.

comment:48 Changed 10 years ago by qulogic@…

(In 584de5e77d7a29a10037eba7c064d791f2814821):
Apparently, I only just imagined adding this file.

Refs #2629.

comment:49 Changed 10 years ago by QuLogic

Ticket #10778 has been marked as a duplicate of this ticket.

Changed 10 years ago by sniperbeamer

Fix PIDGIN_STOCK_TRAY_* constants

comment:50 Changed 10 years ago by sniperbeamer

The constant PIDGIN_STOCK_TRAY_AVAILABLE has already been changed to match the actual filename (mtn commit).

gtkstatusicon_pidginstock.patch changes the other PIDGIN_STOCK_TRAY_* constants that need to be adapted as well (otherwise the tray icon displays a question mark).

comment:51 Changed 9 years ago by QuLogic

Ticket #11270 has been marked as a duplicate of this ticket.

comment:52 Changed 9 years ago by QuLogic

Ticket #11276 has been marked as a duplicate of this ticket.

comment:53 Changed 9 years ago by QuLogic

  • Owner changed from rlaager to QuLogic

comment:54 in reply to: ↑ 45 Changed 9 years ago by QuLogic

Replying to datallah:

Replying to QuLogic:

But more importantly, do icons count as "API/ABI"? If I moved all of them to conform with the icon theme spec, would that have to wait until 3.0.0? I could just move the tray icons, but that would be inconsistent.

I guess I'm not too worried about a temporary inconsistency. I know that some plugins use the protocol icons (not sure what else). I don't think we can break stuff before 3.0.0.

Is it reasonable to move stuff around now and make symlinks to the old places (if not, my vote is just to move the tray icons)

The status icons probably need to stay where they are because they're themeable (using something different from XDG themes.) Technically, the rest of the stock icons are also themeable, but there is no UI for doing such a thing, so I don't feel like it's a problem to move the tray icons only. I'm going to move just the tray icons and fix the stock lookup to find them in the new place.

Also, Hylke has only made a "nice" icon at 22x22. The rest will need to be updated with the blue-tinted message box and new orb.

What happens for the other sizes (does it just look ugly, or is it broken)? If we go ahead with this early, that should hopefully be all that is needed to motivate these additional icons to appear :P

They just look ugly. They're there, but in the old style.

comment:55 Changed 9 years ago by qulogic@…

(In f3a92f1db9439e0bedbcfc479c179d0bf4047b72):
Rename tray icons so that they match the stock names and can be looked up via the icon-name system. I think this is safer than changing the stock names, API/ABI-wise.

References #2629.

comment:56 Changed 9 years ago by QuLogic

  • Resolution set to fixed
  • Status changed from new to closed

It looks like the X11 and gestures changes have already been applied. Now that GtkStatusIcon should work, I think we can close this ticket.

comment:57 Changed 9 years ago by qulogic@…

(In 84c7f6ba2f4be4be1e1698201fae77872ac21fee):
GtkStatusIcon? only exposes a single button press on a Mac for whatever reason, so we'll have to make do with only showing the menu, and not toggling the buddy list visibility.

Refs #2629.

comment:58 in reply to: ↑ description ; follow-up: Changed 7 years ago by relgames

Hi, this issue still affects me on Ubuntu 12.04 with all latest updates.

http://i.stack.imgur.com/nZqQk.png

comment:59 in reply to: ↑ 58 Changed 7 years ago by QuLogic

Replying to relgames:

Hi, this issue still affects me on Ubuntu 12.04 with all latest updates.

http://i.stack.imgur.com/nZqQk.png

The image you provided is not at all related to this ticket. In fact, since there are other applications with the same behaviour, it looks like a Ubuntu bug to me.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!