Pidgin should use GTK+ tab re-ordering

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!

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.

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).

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

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.

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.

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

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.

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.

http://gaim.sourceforge.net/planet/

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

Le lundi 23 octobre 2006 à 07:17 +0000, Bruno Santos a écrit :
> http://gaim.sourceforge.net/planet/
>
> 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

That will not fix this bug.

luke

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

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.

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

This will get moved to the pidgin package.