Palemoon is ignoring the geometry switch in X windows (linux)

[zelea2]

Most graphic applications in X windows support the geometry switch. Palemoon is ignoring it and uses the geometry from a previous session instead.

Example: palemoon -geometry 1100x800

[Moonchild]

Not sure why you consider this a bug. Just because "most" applications have a certain command-line switch doesn't automatically mean that not having that exact same switch is somehow a defect.

If you want to set the width and height of the opened window from the command-line, use -width x -height y with x and y given as integers (=pixels)

[zelea2]

OK, then let's call it a missing feature. The geometry switch it there for a reason: to unify the way a window dimension and placement is specified across all graphic applications.
Anyway it is probably less than 10 lines of code (between #ifdef's) to add that switch to your current build.

[New Tobin Paradigm]

If it is so critical to have but trivial to accomplish then you can take charge and contribute a patch for linux to add this alt cli arg.

[Moonchild]

Make sure you do proper sanity checking on the parameter when proposing a patch, too.
tracking: Issue #1466 (UXP)

[zelea2]

What a pleasure browseing through those 400MB of sources ...

Now I've found where the command line options are parsed in toolkit/xre/nsAppRunner.cpp but the 'width' and 'height' are just passed along down the line somewhere.
In fact these 2 options aren't documented anywhere and 'palemoon -h' doesn't even list them.

The geometry switch may also contains a window position like this: '-geometry 1200x700+20+40' I've searched for an equivalent switch and there are some screenX and screenY
references but they don't have any effect on the command line. Palemoon happily starts whatever options you put on the command line without even a warning so there's no way
to know if these are parsed or not.

So at this point all I can do is parse the geometry argument, ignore any offsets and replace it with two 'width' and 'height' args.
Is there a better way?

[Moonchild]

I'm sorry but if you want support for geometry "equal to other applications" then you'll have to implement all of it. There's little point in doing half a job, to just alias to parameters that already exist.

If the size of the code base is daunting and you're having trouble tracing where these parameters are passed down to, then our cross-reference instance is your friend.
Point your browser to http://xref.palemoon.org/ and do a search in "moonchild-central" which is an amalgamation cross-reference of UXP and several applications building on it. see what variables store the width and height parameters and check where they are passed to. The relevant window sizing is mostly likely going to be passed to a window creation API call of the OS which will likely also allow positioning. If those aren't passed down yet then you will have to make sure they are, adding relevant variables or fields, and adding parsing logic to the front-end for the full geometry format.

[zelea2]

Here's the patch for geometry switch.

[Moonchild]

Please use pull requests on the tracking issue so they can be properly reviewed, not posting diffs as attachments on the forum.
I invite you to also read the contributing guidelines and the UXP coding style guide, found in the /docs directory of the UXP repository.

[zelea2]

I'm not familiar with pull requests.

From my understanding I have to create a separate branch on github. This is what I've tried:
$ git branch geometry-switch
$ git checkout geometry-switch
$ git push
fatal: The current branch geometry-switch has no upstream branch.
$ git push --set-upstream origin geometry-switch
Username for 'https://github.com': zelea2
Password for 'https://zelea2@github.com':
remote: Permission to MoonchildProductions/UXP.git denied to zelea2.
fatal: unable to access 'https://github.com/MoonchildProductions/UXP/': The requested URL returned error: 403

what am I doing wrong?

[Moonchild]

The problem is you're trying to push directly to our repo as a remote. For obvious reasons we don't allow push access except to trusted members.
Start here to understand how pull requests work: https://help.github.com/en/github/colla ... ll-request and https://help.github.com/en/github/colla ... rom-a-fork

Basic steps:

1. Fork the repo to your own account so you have a copy you can work in and push to (in GitHub).
2. Check out your fork
3. Make changes in the feature branch like you've already done
4. Push these changes to your own forked repo
5. Create a pull request across forks back to our repo (in GitHub)