Applets do not scale well with changing resolution

[Hidde Brugmans]

it seems that applets that are put on the panel do not retain their relative
position if the screen resolution is increased.
The notification area applet retains it absolute position, so if I raise my
resolution from 1280x1024 to 1600x1200, the notification area is suddenly in the
middle of the panel, instead of to the right.

[Sebastien Bacher (seb128)]

upstream have some bug open about this according to one of the devel, and not
trivial to do, perhaps they will work on this for 2.12

[Sebastien Bacher (seb128)]

*** Bug 21052 has been marked as a duplicate of this bug. ***

[Aaron Whitehouse (aaron-whitehouse)]

Just so that others can see if this is the same problem that they are describing, I will attach a screenshot.

[Vincenzo Ciancia (vincenzo-ml)]

Aaron: definitely yes, this is the same problem.

Sebastien Bacher wrote on 2005-02-15:
                                                 ^^^
"perhaps they will work on this for 2.12".

Is there something I could read on the current applet position model? Where does gnome-panel store information about applets and launchers? I would like at least try to understand what the problem is.

[Sebastien Bacher (seb128)]

The settings are stored in gconf and the code is in the gnome-panel sources

[Franck (alci)]

The bug is still there in Gusty with Gnome 2.20.0

It is even more serious as with xrandr, gnome-panel will adjust its size to the smallest output resolution.
When coming back to normal resolution, applets are arranged in a apparent random order...

Howto reproduce :
- on a laptop, resolution is 1200x800
- place applets and lock them on the top panel
- plug in a video-projector (say it supports 1024x800)
- type 'xrandr --output VGA --auto' in a terminal
- the video-projector will display desktop : great !!
- the integrated LCD display remain in 1200x800. Cool.
- gnome-panel will adjust its size to fit the 1024x800 VGA display. Really cool.
- sell your stuff to the audiance :)
- unplug the projector and type 'xrandr --output VGA --off'
- gnome-panel goes back to its original size... really nice
- BUT : applets are all mixed up :(

[Tuomo Sipola (tuomosipola)]

This happens especially when using full-screen applications (eg. SDL games) that have resolution lower than the resolution of the desktop. Many of the panel elements are moved. Sometimes it is the logout button, sometimes the Firefox quick start icon and sometimes the notification area.

[James Healy (jimmy-deefa)]

This is apparently on the Gnome roadmap, due to be fixed in 2.22. From http://live.gnome.org/RoadMap

"Fix positioning of applets when the panel size changes"

[Vincenzo Ciancia (vincenzo-ml)]

I am now using gnome 2.20.1 in gutsy-updates, and it seems fixed to me. I have tried various resolutions and rotations and my applets are still in correct order. Can somebody confirm?

[Vincenzo Ciancia (vincenzo-ml)]

I was just plain wrong. The panel is messed up at next login, not immediately.

[JD (jacobdorne)]

Also happens in VMWare. Using Ubuntu 8.04 Alpha6.

[Laszlo Kupcsik (koopac)]

Re: Franck wrote on 2007-10-25
I'm not even sure what the real problem is. Is it the right policy to move the panels to the new screen? I personally like to start the applications on my laptop LCD screen, and pull it to the new screen (which is next to it, not overlapping) and full screen them there. For a presentation it makes sense. The audience is not interested in my panel. So in my opinion it would be better to leave the panels on the LCD screen by default.

[sillyxone (sillyxone)]

This is really annoying, especially my little one plays Chilsplay and Gcompris regularly (switching back and forth between 1024x768 and 1440x900). Some issues to address:

- if the resolution goes from high to low, what if all the items won't fit on the lower resolution.
- if the resolution goes from low to high, in what fashion should the distance/position of items be scaled (I think this is similar to designing web page, with the width of the body or container always expand to 100%)

Perhaps, since the number of resolutions provided by video devices are relatively small (usually less than 50), before changing the screen resolution, record the absolute position of all items, then if the resolution is switched back, just pull out the recorded positions. Combine this option with a set of rules, such as, dropping off non-default items (and/or rightmost items) if there is not enough spaces when lowering resolution; for increasing resolution, perhaps keep absolute position for locked items, and scale percentage of non-locked items. To make thing more complicated (but also more flexible), we can introduce individual positioning setting for each item (just like CSS, position:relative or absolute, left/right: % or px).

Leaving the panels on LCD screen seems to require setting the screens in non-mirror mode, and choose one of the screens to be primary (just like OSX). I think this is pretty intuitive, just don't know about legal issue if someone claims the pattern. Also, I'm not sure how Compiz's cube is related to this.

[Psy[H[] (vovik-wfa)]

I have a lot of launchers on top panel, so decreasing resolution won't let them fit into panel. When using something fullscreen in Wine, all applets are shifted or messed up.

8.04 with latest updates

btw, I think, ability to group applets into blocks would be very handy

[lofgole (lofgole)]

Here's a workaround. I did not test it very well. It keeps the objects at the same position. Simple go the the directory ~/.gconf/apps/panel/applets/ and set the %gconf.xml to read-only after setting the position. The Shutdown-Dialog-gconf.xml is located in ~/.gconf/apps/panel/objects/session_dialog_screen0/. To make the applets stick to the right open gconf-editor goto apps/panel/applets/appletOfChoice and set panel_right_stick to 1. To order the applets from right to left set the position in gconf to 0 for the one at the border and 1 for the next one and so on. E.g. position=0 for session_dialog, position=1 for clock, position=2 for mixer, position=3 for notification-area.

[Franck (alci)]

It seems the workaround is working out of the box, without any user action (kind of a fix, in fact :)

When were the said gconf keys introduced ?

I went to the said keys in gconf and found they were already set (panel_right_stick, ...).

So I changed my resolution, relaunched gdm, relogged-in, changed again back to 1200x800, and the applets where in the right place/ right order, except for the one that was in the middle of my panel, at a fixed position.

So, apllets on the left where on the left, applets on the right where on the right in good order, and applets at an arbitrary fixed position were at an other arbitry fixed position.

Not so bad.
Quite good.

Fixed ?

[TomasHnyk (sup)]

Well, for this bug to be fixed, it would have to need not interaction from the user to actually be fixed, although this workaround is handy.

[Franck (alci)]

Hi Thomas,

well, that is what I was trying to say : I was on the way to try the workaround, but I did _nothing_, it was working already.
I must say I am using Intrepid (latest).

Can anyone else test this ?

[Vincenzo Ciancia (vincenzo-ml)]

Il giorno lun, 06/10/2008 alle 11.00 +0000, Franck ha scritto:
>
>
> well, that is what I was trying to say : I was on the way to try the
> workaround, but I did _nothing_, it was working already.

I don't know how but the mess happens at next login, not immediately. In
any case I saw this on intrepid too, so it's not fixed yet.

Vincenzo

[sillyxone (sillyxone)]

Workaround found on Ubuntuforum:
http://ubuntuforums.org/showthread.php?t=342775

To manually save my panel layout once:
gconftool-2 --dump /apps/panel > panel_layout_1280_800.entries

and restore the layout after switching back from a different resolution:
gconftool-2 --load panel_layout_1280_800.entries

[Namaku Jiro (namaku0)]

Just like most people here, my screen resolution is 1280x1024 and when I run
fullscreen application--which is in my case an old Windows game using Wine at
640x480--all launchers/applets are moved to the right.

The strange thing is this problem didn't happen when I was using Hardy!

[Linuturk (linuturk)]

I have a similar attachment as shown in the attached screenshot.

http://ubuntuforums.org/showthread.php?t=996553

Basically, I've increased the resolution via the Preferences menu applet, and my top and bottom panes weren't scaling across the screen. I've somehow managed to get the bottom panel working correctly, but trying to reproduce that result with the top panel isn't working.

I've also noticed that the Lock Screen password box isn't centered on the screen. It is centered on the old resolution.

Same goes for any Administrative Tasks box that comes up. The entire screen doesn't gray out, just the old resolution.

My login window is also the old resolution as well.

[Linuturk (linuturk)]

Turns out this wasn't related to this bug. Please disregard.

[Namaku Jiro (namaku0)]

Now, Intrepid with current update my problem[0] above is gone.

[0]https://bugs.launchpad.net/gnome-panel/+bug/36189/comments/21

[Carlo de Wolf (wolfc)]

Another workaround is forcing the values back to their default value. Now at least panel won't overwrite them any more.

gconftool-2 --load applets.gconf

[Sandro Mani (sandromani)]

The best solution that works for me I've come up so far is the following:
The problem seems to be that gnome has difficulties to decide whether it should store the position of an applet as aligned to the left or to the right. Consequently, what I did was in the gconf-editor manually browse to
/apps/panel/applets
and under applets and objects, manually set the panel_right_stick and position keys to the correct values, incrementing the position value by just one pixel between the different applets/objects in order to be sure that they really stick as much left resp right as they should. I.e.:
main menu: position=0
firefox launcher: position=1
[...]
user switcher applet: stick right, position=0
date applet: stick right, position=1
volume applet: stick right, position=2

and so on - so far worked well after changing resolution several times, applets always nicely ordered!

[Aidan Fitzpatrick (afit)]

Good to see the workarounds. However, this is still broken out of the box in Jaunty.

I have attached a screenshot with panel at 1920 width, then downsized to 1280 without any interference.

For some reason my two right-side controls (workspace switcher, window selector) get moved into the middle of the panel.

Proportional spacing is not preserved -- so everything's tightly packed on the right when there's plenty of space on the left.

I think the positioning should scale between resolutions. I appreciate getting this to feel just right may be tricky.

Worst-case, it would help if the panel at least remembered positioning from different widths.

[Myk Melez (myk-melez)]

Firefox's solution to this problem (for its customizable toolbars) is to have a "flexible space" item that acts like a spring, expanding and contracting as needed to push the controls to its left and right all the way to the left and right ends of the toolbar, respectively. Firefox's toolbars also enforce order, so controls can't reorder themselves when the size of the window changes. Perhaps GNOME could use a similar technique.

[John Haitas (jhaitas)]

I have been frustrated by this problem for a long time through several different Ubuntu releases... I run Ubuntu as a virtual machine and switching from fullscreen to windowed mode produces this behavior often...

The trouble is that this behavior can occur with a reboot or a simple update-manager update... I have coded up my own script to restore a default panel layout...

I do believe this needs to be addressed in Karmic ... preferably with little or no user intervention...

Feel free to contact me, I want this resolved - it can be a tremendous waste of time and is definitely detracts from Ubuntu's desktop user experience...

[David Fokkema (dfokkema)]

Just my 2 cents:

Some people here have discussed the options: relative positioning, keeping track of positions with different resolutions, flexible spaces, etc.

However, as some others have pointed out already, gnome already _has_ a great scheme, which is actually working very well: the panel_right_stick boolean. It's even possible to give the positions as an index instead of pixels (so, 0, 1, 2, 3) which allows for relative positioning.

The problem is that upon resize, the panel disregards your settings and rewrites (some of) them with the panel_right_stick set to False and calculates the exact pixel offset. Upon switching to a greater resolution your applets keep this exact offset and everything is messed up. One workaround mentions to set one particular settings file to read-only, thus preventing gnome to touch (i.e. mess up) your applet positioning.

My question (and our problem, I believe) is this: why on earth won't gnome just leave my applet settings alone? I paid particular attention to the fact that my applets don't run into each other when switching to a lower resolution so I see no reason _at all_ to change the settings.

[Sandro Mani (sandromani)]

From what I can judge the problem is not how the panel behaves when it is resized, but how it behaves when adding applets to the panel, i.e. practically always choosing to store the position as absolute from left, instead of from right. In fact, once I corrected all the settings manually in gconf, all applets retain their correct positions no matter how often I change resolution, i.e. I would suggest gnome does not really change any settings in the panel.

What would have to be done is, when adding an applet, make the panel detect if the new applet touches an existing stack of applets that is aligned to the left / right, and store the positioning of the new applet consequently: either stick right enabled or disabled, and not using full-width pixel positions, but rather storing à la index.

[Aidan Fitzpatrick (afit)]

I think the problem _is_ how the panel behaves when it is resized. Have a look at the first comments.

There's a workaround with gconf which makes the panel's handling much more graceful, but this is analogous to Windows users having to edit the registry to be able to change resolutions nicely. It doesn't make sense.

I thought David's comment #30 was pretty spot-on, and I see this as:

1. Exposing the gconf positioning controls through the user-interface, or finding a way to infer what they should be

2. Not breaking them when resizing (or adding new controls, as per Sandro's point)

[David Fokkema (dfokkema)]

@Sandro:
I agree with Aidan. It's not only when adding applets. However, I just now only managed to break things when switching to lower resolution, log off, log in, switching to higher resolution. Without the log off, log in, I tried to restart the panel between, before and after switching resolutions, but nothing broke. It did, however, after log off, log in. I don't know why. Maybe the problem is not even in the gnome-panel code directly.

It would be really, really nice to get a list of which code touches the gconf settings, and when.

@Aidan: Thanks! I agree with both your points.

[John Haitas (jhaitas)]

The fact is that this is not something an average user should worry about.
Most people don't care about the placement of these objects and applets.

The fact that these settings can be changed by anything other than direct
user intervention (ie: screen resolution) should be fixed.

After many times of unlocking, repositioning, and locking objects and
applets I became fed-up. I wrote a Python script to set the panel layout the
way I like it.

We need to consider the appeal of Ubuntu to ordinary users depends on
consistent behaviour. There is a mandate to my the interface as user
friendly as Mac OS X.

With regards to this bug, even Windows is a better experience.

I think a GUI to address this only further complicates matters.

I advocate tracking down apps that modify any gconf entries in the
'/apps/panel/' schema. A good first step would be to look at the 'Display
Preferences' code or any code that adjusts screen resolution and be sure
that it is considerate of this issue (not modifying 'right stick' or
'position' values of any objects or applets).

Does this sound reasonable?

Can someone point me to the source code responsible for changing screen
resolution?

On Fri, Apr 24, 2009 at 3:48 AM, David Fokkema <email address hidden> wrote:

> @Sandro:
> I agree with Aidan. It's not only when adding applets. However, I just now
> only managed to break things when switching to lower resolution, log off,
> log in, switching to higher resolution. Without the log off, log in, I tried
> to restart the panel between, before and after switching resolutions, but
> nothing broke. It did, however, after log off, log in. I don't know why.
> Maybe the problem is not even in the gnome-panel code directly.
>
> It would be really, really nice to get a list of which code touches the
> gconf settings, and when.
>
> @Aidan: Thanks! I agree with both your points.
>
> --
> Applets do not scale well with changing resolution
> https://bugs.launchpad.net/bugs/36189
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
John Haitas
<email address hidden>

[Sandro Mani (sandromani)]

From my own investigations so far I guess the best starting point is panel-toplevel.c in the sources of gnome-panel-2.26.0 -> gnome-panel.

[David Fokkema (dfokkema)]

On Mon, 2009-04-27 at 05:43 +0000, John Haitas wrote:
> The fact is that this is not something an average user should worry about.
> Most people don't care about the placement of these objects and applets.

In fact, I think average users do worry about buttons and icons which
end up in strange places. Average users that use external monitors from
time to time, that is.

> I advocate tracking down apps that modify any gconf entries in the
> '/apps/panel/' schema. A good first step would be to look at the 'Display
> Preferences' code or any code that adjusts screen resolution and be sure
> that it is considerate of this issue (not modifying 'right stick' or
> 'position' values of any objects or applets).

Exactly my point. Apps should not modify these values.

[Vincenzo Ciancia (vincenzo-ml)]

Il giorno lun, 27/04/2009 alle 05.43 +0000, John Haitas ha scritto:
>
> We need to consider the appeal of Ubuntu to ordinary users depends on
> consistent behaviour. There is a mandate to my the interface as user
> friendly as Mac OS X.

Yes and in fact this problem affects one of the most problematic areas
of the ubuntu user experience: using an external monitor. For example,
this will be very frequent on netbooks. Now on these machines the
resolution of the screen will typically be smaller than the external
monitor. My girlfriend for example has this problem on her eeepc. Using
an external monitor is very unconvenient for this reason.

V.

--
It is also important to note that hedgehogs do not actually hurt each
other when they get close to one another. Actually, when living in
groups, hedgehogs often sleep close to each other.
http://en.wikipedia.org/wiki/Hedgehog%27s_dilemma

[Jo-Erlend Schinstad (joerlend.schinstad-deactivatedaccount)]

I absolutely agree with Vincenzo. This bug has been bothering me for years, it seems, but how often have I changed resolution for my screen? Seldom. So I haven't really made a big deal out of it. Now, however, with the new netbook, the answer is: 4-5 times every day. That's something else entirely.

This gnome-panel bug should have the highest priority, cause this makes GNOME and Ubuntu look really ugly and unfinished. And if you're new to an operating system and have no experience with it. Would you trust an OS that couldn't even handle something as basic as a change of resolutions?

[Sebastien Bacher (seb128)]

Those comments are not really useful, you should better discuss that on bugzilla where the people writting the software will read your comments and you don't trust a system only because it can handle graphical layouts changes in a nice way or not

[Jo-Erlend Schinstad (joerlend.schinstad-deactivatedaccount)]

I'll take it to bugzilla. I still think this bug should have a high priority here though. Just to clarify; you're right, people wouldn't trust Ubuntu just because the applets stayed at the same places. However, trust and distrust are two very different things. Distrust comes much more easily than trust. If the system feels unfinished, then the new user might begin to wonder what else is unfinished. It's easy to forget how scary it can be, to alot of people, changing OS. I don't think this should be underestimated. But there are other, more potent arguments of course; it breaks muscle memory for instance.

[John Haitas (jhaitas)]

@SebastianCould you provide a relevant link to bugzilla where this
discussion can be carried on?

On Mon, Apr 27, 2009 at 10:00 AM, Jo-Erlend Schinstad <
<email address hidden>> wrote:

> I'll take it to bugzilla. I still think this bug should have a high
> priority here though. Just to clarify; you're right, people wouldn't
> trust Ubuntu just because the applets stayed at the same places.
> However, trust and distrust are two very different things. Distrust
> comes much more easily than trust. If the system feels unfinished, then
> the new user might begin to wonder what else is unfinished. It's easy to
> forget how scary it can be, to alot of people, changing OS. I don't
> think this should be underestimated. But there are other, more potent
> arguments of course; it breaks muscle memory for instance.
>
> --
> Applets do not scale well with changing resolution
> https://bugs.launchpad.net/bugs/36189
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
John Haitas
<email address hidden>

[Sandro Mani (sandromani)]

Here: http://bugzilla.gnome.org/show_bug.cgi?id=137473 (you can find it at the top of the page, under "assigned to")

[John Haitas (jhaitas)]

It seems as if the Gnome team do not take this bug very seriously. Would it
be inappropriate to develop a patch for Ubuntu that may or may not be pushed
upstream in the future?

On Mon, Apr 27, 2009 at 12:54 PM, Sandro Mani <email address hidden>wrote:

> Here: http://bugzilla.gnome.org/show_bug.cgi?id=137473 (you can find it
> at the top of the page, under "assigned to")
>
> --
> Applets do not scale well with changing resolution
> https://bugs.launchpad.net/bugs/36189
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
John Haitas
<email address hidden>

[Vincenzo Ciancia (vincenzo-ml)]

Il giorno lun, 27/04/2009 alle 18.23 +0000, John Haitas ha scritto:
>
>
>
>
> It seems as if the Gnome team do not take this bug very seriously.
> Would it
> be inappropriate to develop a patch for Ubuntu that may or may not be
> pushed
> upstream in the future?

To develop any patch you need some manpower. This seems to me a
"seriously trivial" issue however I myself did never found an empty
afternoon to take a look at this (and maybe conclude it's too
difficult).

If any of us developed a reasonable¹ patch, then I am sure upstream
would be glad to acccept it.

[1] The trick, here, is in the addition of "reasonable"

[John Haitas (jhaitas)]

Categorizing this issue as "seriously trivial" is underestimating it.

This is the sort of issue Linux users face, but Windows and Mac users are
never bothered with. I would be happy to patch this.

Where can I obtain the Ubuntu branch of the code that changes the screen
resolution.

On Mon, Apr 27, 2009 at 3:04 PM, Vincenzo Ciancia <email address hidden>wrote:

> Il giorno lun, 27/04/2009 alle 18.23 +0000, John Haitas ha scritto:
> >
> >
> >
> >
> > It seems as if the Gnome team do not take this bug very seriously.
> > Would it
> > be inappropriate to develop a patch for Ubuntu that may or may not be
> > pushed
> > upstream in the future?
>
> To develop any patch you need some manpower. This seems to me a
> "seriously trivial" issue however I myself did never found an empty
> afternoon to take a look at this (and maybe conclude it's too
> difficult).
>
> If any of us developed a reasonable¹ patch, then I am sure upstream
> would be glad to acccept it.
>
> [1] The trick, here, is in the addition of "reasonable"
>
> --
> Applets do not scale well with changing resolution
> https://bugs.launchpad.net/bugs/36189
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
John Haitas
<email address hidden>

[John Haitas (jhaitas)]

So here are the ways to get the source.

The git repository:
$ git clone git://git.gnome.org/gnome-control-center

The Jaunty source:
$ apt-get source gnome-control-center

The Ubuntu trunk:
$ bzr get
http://code.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu

Those who know better - please correct me.

On Mon, Apr 27, 2009 at 5:21 PM, John Haitas <email address hidden> wrote:

> Categorizing this issue as "seriously trivial" is underestimating it.
>
> This is the sort of issue Linux users face, but Windows and Mac users are
> never bothered with. I would be happy to patch this.
>
> Where can I obtain the Ubuntu branch of the code that changes the screen
> resolution.
>
>
> On Mon, Apr 27, 2009 at 3:04 PM, Vincenzo Ciancia <email address hidden>wrote:
>
>> Il giorno lun, 27/04/2009 alle 18.23 +0000, John Haitas ha scritto:
>> >
>> >
>> >
>> >
>> > It seems as if the Gnome team do not take this bug very seriously.
>> > Would it
>> > be inappropriate to develop a patch for Ubuntu that may or may not be
>> > pushed
>> > upstream in the future?
>>
>> To develop any patch you need some manpower. This seems to me a
>> "seriously trivial" issue however I myself did never found an empty
>> afternoon to take a look at this (and maybe conclude it's too
>> difficult).
>>
>> If any of us developed a reasonable¹ patch, then I am sure upstream
>> would be glad to acccept it.
>>
>> [1] The trick, here, is in the addition of "reasonable"
>>
>> --
>> Applets do not scale well with changing resolution
>> https://bugs.launchpad.net/bugs/36189
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>
>
> --
> John Haitas
> <email address hidden>
>

--
John Haitas
<email address hidden>

[John Haitas (jhaitas)]

Ok so I think I was wrong on the last post... the relevant package seems to
be 'screen-resolution-extra' .... Don't take my word on this, I am just
trying to get to the bottom of this problem...

The Jaunty source:
$ apt-get source screen-resolution-extra

The Ubuntu trunk:
$ bzr get
http://bazaar.launchpad.net/~albertomilone/screen-resolution-extra/main

Please correct me if I am wrong.

On Mon, Apr 27, 2009 at 9:01 PM, John Haitas <email address hidden> wrote:

> So here are the ways to get the source.
>
> The git repository:
> $ git clone git://git.gnome.org/gnome-control-center
>
> The Jaunty source:
> $ apt-get source gnome-control-center
>
> The Ubuntu trunk:
> $ bzr get
> http://code.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu<http://code.launchpad.net/%7Eubuntu-desktop/gnome-control-center/ubuntu>
>
> Those who know better - please correct me.
>
>
>
> On Mon, Apr 27, 2009 at 5:21 PM, John Haitas <email address hidden> wrote:
>
>> Categorizing this issue as "seriously trivial" is underestimating it.
>>
>> This is the sort of issue Linux users face, but Windows and Mac users are
>> never bothered with. I would be happy to patch this.
>>
>> Where can I obtain the Ubuntu branch of the code that changes the screen
>> resolution.
>>
>>
>> On Mon, Apr 27, 2009 at 3:04 PM, Vincenzo Ciancia <email address hidden>wrote:
>>
>>> Il giorno lun, 27/04/2009 alle 18.23 +0000, John Haitas ha scritto:
>>> >
>>> >
>>> >
>>> >
>>> > It seems as if the Gnome team do not take this bug very seriously.
>>> > Would it
>>> > be inappropriate to develop a patch for Ubuntu that may or may not be
>>> > pushed
>>> > upstream in the future?
>>>
>>> To develop any patch you need some manpower. This seems to me a
>>> "seriously trivial" issue however I myself did never found an empty
>>> afternoon to take a look at this (and maybe conclude it's too
>>> difficult).
>>>
>>> If any of us developed a reasonable¹ patch, then I am sure upstream
>>> would be glad to acccept it.
>>>
>>> [1] The trick, here, is in the addition of "reasonable"
>>>
>>> --
>>> Applets do not scale well with changing resolution
>>> https://bugs.launchpad.net/bugs/36189
>>> You received this bug notification because you are a direct subscriber
>>> of the bug.
>>>
>>
>>
>>
>> --
>> John Haitas
>> <email address hidden>
>>
>
>
>
> --
> John Haitas
> <email address hidden>
>

--
John Haitas
<email address hidden>

[Sandro Mani (sandromani)]

I think one should rather look at the gnome-panel source code, it is more likely that the panel listen to screen resolution changes events and resizes itself accordingly than the screen resolution program itself resizing the panel. At least this is the impression I got looking at the gnome-panel source code.

[John Haitas (jhaitas)]

Thank you Sandro, I appreciate your reply. I realized that late last night
(failed to report).

Jaunty source:
$ apt-get source gnome-panel

--
John Haitas
<email address hidden>

[Sandro Mani (sandromani)]

You're welcome. In case you make any interesting findings, please report - as stated above I have the impression that the file panel-toplevel.c is a good starting point to study the behavior of the panel, but as the code is next to undocumented, it is quite difficult to understand it at first sight, especially with next to none GTK programming experience... But I'll try to find out more as time permits.

[Vincenzo Ciancia (vincenzo-ml)]

Il giorno lun, 27/04/2009 alle 22.21 +0000, John Haitas ha scritto:
>
> Categorizing this issue as "seriously trivial" is underestimating it.
>
> This is the sort of issue Linux users face, but Windows and Mac users
> are
> never bothered with. I would be happy to patch this.

I am not an ubuntu developer, and "seriously trivial" means that it is
serious even if a patch *should* be trivial. So the idea is, if some of
us non-ubuntu-developers-non-gnome-developers could develop the patch it
would be good. BTW also KDE users are not affected by this problem
AFAIK. It is gnome specific.

[John Haitas (jhaitas)]

I've been looking through the gnome-panel source and here is what I understand at the moment:

The bug probably occurs in a file that has the following #include line:

#include "panel-gconf.h"

The file that seems most likely to have the offending bug is 'panel.c'

Correct me if I am wrong here. Further comments/suggestions appreciated.

[John Haitas (jhaitas)]

Don't hold your breath on this bug. The fix is more complicated than meets the eye. I have looked into the source code and reported upstream at http://bugzilla.gnome.org/show_bug.cgi?id=137473 .

Basically the "panel_right_stick" gconf is not treated consistently between an "object" and an "applet" on the panel.

Going through the steps that originally describe the bug:
An "applet" will always lose it's "panel_right_stick"=TRUE and receive a relatively large "position" value.
An "object" can obtain a "panel_right_stick"=TRUE (even if originally "panel_right_stick"=FALSE)

Furthermore there is no UI method for "Right Stick to Panel" in the same way there is a UI method for "Lock to Panel".

Fixing these issues could cause breakage to the gnome-panel API hooks.

comments? ideas?

[Sandro Mani (sandromani)]

I've done some more testing (switching resolutions, logging out and in at different resolutions) and I must say that my applets always retain their correct position since when I've set all positioning values manually. Though what I noticed is that while right_stick is always preserved, positions change oddly, but consistently, i.e. before I had
right-applet-1: position=0
right applet-2: position=1
etc
and now I have
right-applet-1: position=-80
right-applet-2: position=-79
etc.

So from what I can tell, what one would have to do is:
1. fix the ways positions are stored when adding the applet (as stated above somewhere, I have the impression that manually added applets (always?) use left absolute positioning even if they are aligned to a stack of applets to the right)
2. once that is done, simply prevent any changes to gconf while changing resolution.

While the second step would brutally said only require to comment out the right sections of the source, the first one would require an pretty deep knowledge of GTK, i.e. how to detect if an applet touches a stack of applets that are aligned to the right and count them, in order to use relative positioning values (i.e. incrementing position values always by one)

[Vincenzo Ciancia (vincenzo-ml)]

One thing I don't understand is if it would suffice to keep the order of applets; currently it is messed up.