2017-03-25 5:14 GMT+09:00 Charles E Campbell <[email protected]>:
> Hello: > > On at least two machines, which both run Scientific Linux, I'm getting > odd behavior with a -geometry command: > > gvim -geometry "316x40+0-0" somefile > > The file is opened on the bottom of the screen (316x40, open 0 pixels > from left and 0 pixels from the bottom). > Or, at least, that's what its supposed to do. Sometimes it opens 0 > pixels from the top of the screen instead. > > I haven't found a way to get the problematic opening to occur with > regularity -- I just did it ten times and it opened correctly, for example. > > Regards, > Chip Campbell > Hi Dr. Chip, First of all, I think we need to make sure how the geometry of an X11 app is determined when it appears on the screen for the first time. That's a result of a negotiation between the window manager in use and an X11 app which is going to be substantiated on the screen. As the argument to -geometry is seemingly always honored by the window manager, it's natural that one might have an impression as if -geometry were a command. The reality is, however, that window managers are usually implemented to take the argument as a hint to compute another geometry which it thinks is suitable for the app's sharing the whole screen with other apps already appearing on the screen, based on the geometry management policy of each window manager. The result of the computation is sent out to the X11 app under negotiation as an X11 event, and, by convention, the app is expected to follow the result as it it, not asking another negotiation. Accordingly, the geometry which is actually used is not the one given by the argument to -geometry, but the one the window manager computed, taking it as a hint and into account as such. Hence, it's not a surprise that X11 apps sometimes appear on the screen in a way failing one's expectation, depending on the geometry management policy of each window manager which is often subtle or obscure. In addition to that, I think we need to consider another factor specific to gvim. Usually, geometry negotiations are done with respect to the geometry of the top-level window of an app; it re-computes children's geometry based on the geometry allocated to the top-level window by the window manager. It's really straightforward. As to gvim, when it computes its geometry, it puts more emphasis on the geometry of the text area than that of the top-level window. Naturally, the numbers of columns and lines do matter much more for Vim than the values of x, y, width and height of the top-level window because it's THE text editor :) Plus, as can be seen in the richness of 'guioptions', the text area is surrounded with GUI elements which can be added or removed arbitrarily even at runtime, which gets the computation far more involved than usual GUI apps. While following the geometry management convention, gvim is struggling to keep its values as a text editor. The negotiation is always tough and sometime fails, unfortunately, though I know that's a thing to be improved. Best, Kazunobu > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
