Panel (always) moves after a restart on UbuntuBudgie

[Jacob-Vlijm]

Using latest master (after commit 54473a ) On Ubuntu Budgie 18.10, got an issue on panel placement. The panel consequently moves on a restart, bot horizontally and vertically: before:

and after a restart:

[spheras]

@Jacob-Vlijm, I can't reproduce. I've tried on UB making some panels, moving them, ... but nothing special happens, everything is in its place after stopping/restarting the application, even restarting the OS. Could you provide detailed steps to reproduce?

[Jacob-Vlijm]

Yeah, we are also trying to find out. Steps to reproduce here are straightforward, on every restart, panels and notes are moved. The numbers in the .desktopfolders -file are also changed. My resolution ia 1920x1080. Look what happens with the corresponding figures:

jacob@jacob-Aspire-Z3-705:~$ diff '/home/jacob/Desktop/VEG/.desktopfolder' '/home/jacob/ff/veg' 
1c1
> < {"resolutions":[{"resx":1920,"resy":1028,"x":728,"y":213,"w":300,"h":300},{"resx":1920,"resy":1080,"x":693,"y":194,"w":370,"h":370}],"resx":1920,"resy":1028,"x":728,"y":213,"w":300,"h":300,"name":"VEG","bgcolor":"df_black","fgcolor":"df_light","textbold":true,"textshadow":true,"arrangement-type":2,"arrangement-padding":10,"arrangement-orientation":2,"items":["KR allerlei;10;0;","rebuild-veg;110;0;"],"version":4,"edit-label-on-creation":true}
> \ Geen regeleindeteken (LF) aan einde van bestand
> ---
> > {"resolutions":[{"resx":1920,"resy":1028,"x":569,"y":124,"w":300,"h":300},{"resx":1920,"resy":1080,"x":728,"y":213,"w":300,"h":300}],"resx":1920,"resy":1028,"x":569,"y":124,"w":300,"h":300,"name":"VEG","bgcolor":"df_black","fgcolor":"df_light","textbold":true,"textshadow":true,"arrangement-type":2,"arrangement-padding":10,"arrangement-orientation":2,"items":["KR allerlei;10;0;","rebuild-veg;110;0;"],"version":4,"edit-label-on-creation":true}
> \ Geen regeleindeteken (LF) aan einde van bestand

[spheras]

What strategy you have on the "When changing resolution" general setting? (default is Store per resolution)

[Jacob-Vlijm]

@spheras that's the one. I'll check what happens if I set "Do nothing"...

[Jacob-Vlijm]

@spheras That was an excellent hunch. Now we've at least located where things go wrong. When set to "Do nothing", all works fine, did two restarts.

[spheras]

It is strange, I can't reproduce. I tried changing resolutions (store per resolution save at the json different positions for each resolution, restoring the position if a previously saved position was found). Can you reproduce the problem just restarting the application?? or you need to restart the OS? It would be great if you uncomment all the //debug("..") lines in the file PositionSettings.vala, and try to see what's happening there.

[Jacob-Vlijm]

@spheras I will. It'll probably be tonight (about to start teaching). I suspect it is a timing issue. When the resolution is requested too early (for this box), either none or an incorrect resolution is passed I guess, moving the panels and notes to the wrong location. Didn't look into the code on this yet though. ...to be continued :)

[Jacob-Vlijm]

@spheras No output whatsoever. Just did a restart on desktopfolder, one of the panels was moved, but no output. On a "total" restart, can't get the terminal output :). Tomorrow I can add a function to write some output to file during startup if you want. What would be useful? Curious e.g. what resolution desktopfolder reads for panel placement.

[spheras]

I'm not sure whats happening there, but if you say everything is ok with the NONE resolution strategy, then something is bad when the STORE strategy is being calculated. All this is done in the PositionSettings.vala. For example, these are the connected events to recalculate the position based on the strategy:

        Gdk.Screen.get_default ().size_changed.connect (this.on_screen_size_changed);
        Gdk.Screen.get_default ().composited_changed.connect (this.on_screen_size_changed);
        Gdk.Screen.get_default ().monitors_changed.connect (this.on_screen_size_changed);

    /**
     * @name on_screen_size_changed
     * @description detecting screen size changes
     */
    public virtual void on_screen_size_changed (Gdk.Screen screen) {
        debug ("size changed for %s", this.folder_name);
        this.settings.calculate_current_position ();
        debug ("reloading settings");
        this.view.reload_settings ();
    }

but also when the settings file is loaded first time this.settings.calculate_current_position ();:

/**
   * @name load_folder_settings
   * @description load the settings file inside the folder (if exist), if not, it will create a new one.
   * The settings file contains the basic info saved to create window and items componentes.. position, size, etc..
   */
  private void load_folder_settings () {
      // let's search the folder settings file
      var abs_path      = this.get_absolute_path ();
      // debug ("loading folder settings...%s", abs_path);
      var settings_file = abs_path + "/.desktopfolder";
      var file          = File.new_for_path (settings_file);
      if (!file.query_exists ()) {
          // we don't have yet a folder settings file, let's create one
          FolderSettings newone = new FolderSettings (this.folder_name);
          newone.save_to_file (file);
          this.settings = newone;
      } else {
          FolderSettings existent = FolderSettings.read_settings (file, this.get_folder_name (), this);
          this.settings = existent;
      }

      this.settings.calculate_current_position ();

      // creating the Manager
      this.arrangement = FolderArrangement.factory (this.settings.arrangement_type);
  }

The event is notified to all elements, and each one recalculate the position. In the case of STORE strategy, it search in the configuration (.desktopfolder) if there is a position saved for that new screen size. If so, then restore that position. As I said, this is done in the PositionSettings. If you find a way to uncoment the debug lines, compile, and redirect the output to a file or something to see the results during the restart, then we could get info about what is happening.

In theory, the STORE strategy just position the widgets in a previously saved position, but I don't know why it is moving the widgets to a different position.

[Jacob-Vlijm]

@spheras Interesting results from the output of the function private ResolutionSettings calculate_screen_resolutions (). I uncommented the deprecated method, with an interesting difference in output (restarting desktopfolder on a running box, Plank at the bottom). When I put Plank on the left, the outputs are equal to each other.

deprecated: 1920 1080 / current method: 1920 1028

The deprecated one is correct btw.

[Jacob-Vlijm]

And here we see what happens during system startup: in the beginning, result match, half way, they start to differ...

deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1080 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028 deprecated: 1920 1080 current: 1920 1028

[Jacob-Vlijm]

@spheras The new method to get the resolution seems to switch from screen resolution to working area, that seems to cause the change in output during startup. Was that on purpose? Compare e.g. the three methods below, which give quite different outputs:

public static void main (string[] args) {
    Gdk.init(ref args);
    get_desktop_bounding_box();

}

private void check_res() {
    /* see what is the resolution on the primary monitor */
    var prim = Gdk.Display.get_default().get_primary_monitor();
    var geo = prim.get_geometry();
    int width = geo.width;
    int height = geo.height;
    print(@"method from hotcorners: $width $height\n");
    int screen_xpos = geo.x;
    int screen_ypos = geo.y;
    // return {width, height, screen_xpos, screen_ypos};
}

private void get_desktop_bounding_box () {
    // get res on the primary mon
    check_res();
    // new method
    Gdk.Rectangle result   = Gdk.Rectangle ();
    Gdk.Screen    screen   = Gdk.Screen.get_default ();
    Gdk.Display   display  = screen.get_display ();
    int           monitors = display.get_n_monitors ();
    for (int i = 0; i < monitors; i++) {
        Gdk.Monitor   monitor = display.get_monitor (i);
        Gdk.Rectangle warea   = monitor.get_workarea ();
        int w = warea.width;
        int h = warea.height;
        print(@"new method, used in desktopfolder : $w $h\n");
        // deprecated one
        calculate_screen_resolutions();
    }
}

private void calculate_screen_resolutions () {
    // this was the old -deprecated- way gtk (since Gtk+2.2) to obtain that.
    Gdk.Screen screen  = Gdk.Screen.get_default ();
    int        swidth  = screen.get_width ();
    int        sheight = screen.get_height ();
    print(@"deprecated version: $swidth $sheight\n");
}

output:

method from hotcorners: 1920 1080
new method, used in desktopfolder : 1920 994
deprecated version: 1920 1080

[fossfreedom]

I can confirm that if you move plank to the bottom in UB the panel position changes after a logout/login

If plank is on the left, panel position does not change

This is plank permanently displayed - it is not set to use one of the hide modes in plank preferences.

Tested on a virtualbox session set to be full screen.

[spheras]

Thanks for the info @Jacob-Vlijm. Yes, that was a change to update the gdk dependencies. I could have taken just the geometry, but I thought the workarea could be the best to fit the desktop panel to the desktop area... for example, to avoid problems with plank, applications bar, and others panels on the desktop (take into account that this function is also used to size the desktop panel correctly). Anyway, I don't see why this could create the problem you reported.

Previously, you did a test where after the restart, the settings was changed (moving a panel). The first was the configuration before the restart (Correct me if I'm wrong)

{
    "resolutions":[
              {"resx":1920,"resy":1028,"x":728,"y":213,"w":300,"h":300}, 
              {"resx":1920,"resy":1080,"x":693,"y":194,"w":370,"h":370}
     ],
     "resx":1920,"resy":1028,"x":728,"y":213,"w":300,"h":300,

    "omiting":"not interesting parts"
}

and the other after the restart:

{
    "resolutions":[
              {"resx":1920,"resy":1028,"x":569,"y":124,"w":300,"h":300}, 
              {"resx":1920,"resy":1080,"x":728,"y":213,"w":300,"h":300}
     ],
      "resx":1920,"resy":1028,"x":569,"y":124,"w":300,"h":300,

    "omiting":"not interesting parts"
}

the resolutions array are the registered resolutions (positions and dimensions of the panel for those resolutions). After that, the current/last resolution used. In both cases, resolutions are OK (taking into account the effect you mentioned, first the working area is 192x1080 and after is changed to 192x1028, probably due to the top application bar on the desktop). The key part is:

    /**
     * @name strategy_store
     * @description the positions are all stored for the concrete resolution, if it is stored, it is restaured
     */
    private void strategy_store () {
        ResolutionSettings rs = find_current_resolution ();
        if (rs != null) {
            // debug("setting a store resolution");
            this.x    = rs.x;
            this.y    = rs.y;
            this.w    = rs.w;
            this.h    = rs.h;
            this.resx = rs.resx;
            this.resy = rs.resy;
            // debug ("strategy_store:(%d,%d,%d,%d)", this.x, this.y, this.w, this.h);
        } else {
            // debug ("strategy store: no resolution, lets scale");
            // should we resize?? not sure, normally I just add a monitor, don't need to resize, just to position it correctly
            // this.strategy_scale (oldresx, oldresy);
            this.create_current_resolution ();
        }
    }

If everything is OK (obviously no :laughing:), the store strategy is very very simple. It search the current resolution (with workarea or not) in the registered resolutions in the settings, recovering the position and size for that resolution. The store strategy never calculate a different positions, just recover the last registered position for that resolution (saved in the settings!), the only way to reposition the widget is inside the check_off_screen function, I would like to inspect what is doing there in your case.
For example, the scale strategy is different, it moves the widget and resize to the new resolution, but, is the scale strategy being executed??

Could you send to me the output after enabling all the debugs lines and restarting? Maybe I could see what is happening there. Please, answer these questions:

• Does this happens too just killing the process and launching, without restarting the OS? (time ago, similar thing happened, but I fixed it)
• Are you testing in a virtual machine or a physical one?
• If you replace the current version with the deprectaed version, everything works correctly? (I mean, I don't think the problem is the working area itself, but the changes to different resolutions)

[Jacob-Vlijm]

@spheras I need some time to read through precisely what you write, and will post back (almost teaching time again, will probably be end of the weekend, a few busy days). In the meantime: If I set "store per resolution", the panel layout actually does not (re) store previous layout. Not with plank on the left, nor on the right, nor without plank:

Set 1920 x 1080

Set to 1680 x 1050

Back to 1920 x 1080

Which makes me wonder: Does the resolution/position storage take into account if the panel is moved by desktopfolder internally or by the user? It shouldn't matter but I wouldn't be surprised if there is a "circular" issue in that.

[spheras]

Ok, I've seen something strange... I will check this evening and let you know.

[Jacob-Vlijm]

@spheras Even if it would work as intended: another thing that popped into my mind: did you take into account that on a VM, VBox window can be resized manually by dragging. That means the n- resolutions will possibly be huge, as many as the loop can handle. That will possibly/probably create a huge .desktopfolder file. I believe anyway, setting the default to "Do nothing" would be preferable, with the possibility to disable the option from the menu (in gsettings) (so distros can set an override).

[spheras]

I did a commit to solve the problem (not sure in your case, because I'm not sure if the reproduced problem is exactly the same as yours). Could you check the solution?

@Jacob-Vlijm, regarding your last comment, I did a modification to only persist resolution changes after 1 second without changes (and also because one of the problems was that, at least in a VM, the event was notified but the monitors still were giving the old resolution).

[Jacob-Vlijm]

@spheras Thanks! The good news is that switching resolutions on a running and logged in machine, the layout is remembered and restored correctly. On a log out / log in, all is still mixed up however.

[spheras]

mmm ok. I need to reproduce the problem. What I'm doing:

• rm -rf ~/Desktop
• running desktopfolder &
• creating a panel in a concrete position
• logout
• login

the panel is created exactly in the same position. What I'm doing wrong? (btw, I put plank on bottom, but still the same effect). UB is in a Oracle Virtual Box, maximized (1080).

[subbame]

I have the same issue in ElementryOS 5. I have created a panel in the right top of the desktop with a link to a few folders and locked both icons and panel but whenever I restart the system the panel is moved to the extreme top left of the screen.