Pidgin should use GTK+ tab re-ordering

Bug #58998 reported by dorphichinfa on 2006-09-05
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Won't Fix
gaim (Ubuntu)
pidgin (Ubuntu)

Bug Description

Binary package hint: gaim 2.0.0beta3

Gaim's tab interface isn't the same as the rest of GNOME's native applications, such as Gedit, Epiphany and GNOME Terminal. This is very annoying in terms of consistency and theming.

In particular,
1. Gaim's tabs are not the same height. (2px off, seems to be unique to Ubuntu's theme, could be related to problem #2)
2. The close button is not the same (Gaim tries to use a normal button instead which doesn't fit)
3. Dragging tabs works like Firefox (with the little arrows showing where the tab will be moved) rather than like in GNOME apps (tab moves with the cursor.

description: updated
Mark Doliner (thekingant) wrote :

To me Gaim's tabs look exactly the same as Gedit's tabs. I'm using Gaim 2.0.0 SVN. I have a feeling that's newer than what you're using.

* Hmm, I can't imagine why they wouldn't be the same height. Unless we used to use a different close button that was causing the tabs to be taller than normal. Or maybe your tabs are shorter than they would be by default and our protocol icons are causing them to be taller in Gaim?
* The bug where the close button gets cut off should be fixed. I'm not sure when we fixed it, but it was some time between 1.5.0 and 2.0.0 SVN.
* We ARE using Gtk Notebook, but tab dragging was added only very recently (GTK+ 2.10.0, July 3 2006). Are you using GTK+ 10.0 or newer? We'll have to leave in our current tab dragging code, since we support all the way back to GTK+ 2.0, but eventually we'll add support for the new tab dragging and #ifdef it so that it's only enabled for people using GTK+ 2.10.0 or higher. But that's a pretty low priority. Patches welcome!

description: updated
description: updated
description: updated

Buttons in Ubuntu have an orange glow around them on mouse-over. Close tab buttons don't, but Gaim's close tab buttons do. This causes the tab to stretch vertically to make room for the orange glow, and cuts off the side of the close button's icon. I am in 2.0.0beta3.

I would give a screenshot however the hover glow dissapears with the use of PrintScreen.

Luke Schierer (lschiere) wrote :

Why is moving the tab instead of using arrows better? Gaim is not a GNOME project, and it seems to me that firefox's behavior is more desirable. Plus, we allow other things that gedit doesn't, notably, dragging a tab out of a window (vrs having to use the menu option to do it).

Mark Doliner (thekingant) wrote :

Personally it sounds like dragging the whole tab would be much more intuitive than silly little arrows.

Luke Schierer (lschiere) wrote :

My gut reaction is the opposite, but that's at least partly because I almost always use firefox and gaim, and almost never GNOME stuff. I'm also somewhat reacting to gedit's failure to destroy a tabless window when you drag the last tab out.

if the tabs are few and big, dragging the tab certainly works well, because you can still see your target. if the tabs get small and/or many, the arrows would seem to be better, allowing more precision.

Since we restrict how small our tabs can get (firefox doesn't do so nearly as soon), this may not be a concern.

There's a rule I use when programming: "While the user is making a change, they should see the result of that change while they are making it." This rule is used throughout GNOME and should apply to tab movement as well as document editing.

I personally don't see how the arrows allows for more precision. After all, what could be more precise than seeing the tab in its desired position as you move it? Of course dragging tabs between windows is important, so if that function is at risk by all means leave the code as is.

This is just one of the three problems. I don't see how problems 1 and 2 can be difficuilt to fix.

Luke Schierer (lschiere) wrote :

hhmm. it appears on further inspection that gedit isn't doing the floating tab thing that I recall. Their current way would work as well as arrows do.

Sebastien Bacher (seb128) wrote :

gedit and epiphany-browser used to tabs dnd themself since GTK had no such feature. GTK 2.10 allow to dnd tabs now so the new versions just use GTK now, gaim could do the same

Luke Schierer (lschiere) wrote :

if someone were to write a patch for this, it would need to use #ifdefs, because a requirement on gtk 2.10 is not acceptable.

Jeff Greene (jeffgreene) wrote :

The gaim tabs are the same height as gedit, however I did notice that 2 pixels are getting cut off of the [x] button on the gaim tabs. I am running gaim2.0beta-3.1 on Edgy Knot 3. I think I recall this problem in Dapper too, however.

Jeff Greene (jeffgreene) on 2006-09-23
Changed in gaim:
status: Unconfirmed → Confirmed
Changed in gaim:
importance: Untriaged → Wishlist
Bruno Santos (bsantos) wrote :

beta4 is out Is there still time to update to it?

Le lundi 23 octobre 2006 à 07:17 +0000, Bruno Santos a écrit :
> beta4 is out Is there still time to update to it?

no, edgy is frozen for 10 days already and CD images will be rolled
soon, gaim will be updated after edgy

Has this been fixed yet?

I'm no C++ programmer, but if not, is it any more complicated than this?

- if compiled with required gtk version
          - user same code as other gnome apps
- else
          - use old, non-gnome-like code

please lets discuss the complexities if any

Richard Laager (rlaager) wrote :

We won't fix this in Pidgin. Before anyone freaks out, I'm going to make some changes and apply the relevant parts of this against Pidgin.

Changed in gaim:
status: New → Won't Fix
Richard Laager (rlaager) wrote :

Correction: "We won't fix this *Gaim*."

Changed in pidgin:
status: Unknown → New
Richard Laager (rlaager) wrote :

This will get moved to the pidgin package.

Changed in gaim:
status: Confirmed → Invalid
Changed in pidgin:
status: New → Confirmed
Changed in pidgin:
status: New → Confirmed
Changed in pidgin (Ubuntu):
importance: Undecided → Wishlist
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.