Re: Application window geometry specifier
On 2021-01-13 at 21:41:26 -0600, Python wrote: > On Thu, Jan 14, 2021 at 12:27:19PM +1100, Chris Angelico wrote: > > On Thu, Jan 14, 2021 at 12:11 PM Python wrote: > > > > > > On Tue, Jan 12, 2021 at 06:43:39PM -, Grant Edwards wrote: > > > > And those X11 users will swear at you if you override their window > > > > managers configured window placement. Application code should not care > > > > about or try to control window geometry. Period. > > > > > > I think this is just plain wrong. > > As a side note, from a purely technical standpoint, Grant's point is > demonstrably factually false. A GUI application necessarily must > "care about or try to control window geometry" so that if the user > moves or resizes the application, enables or disables additional > widgets, etc., the widgets it contains are redrawn such that they > remain usable, possibly expanding the canvas they're drawn on or > adding new GUI elements like scrollbars to ensure that (at least it > does if it wants to be useful) ... A GUI application must care about the geometry (to react to changes made by the user or the window manager). OTOH, if I (the user) request a 80x24 character terminal window with a certain size glyph, and I get a terminal that isn't 80x24 and that glyph size, then at least one of the application, the window manager, or some other library is broken. Period. Go ahead, tell me, the *user*, that I shouldn't do that, or that I should reconsider my use case, or that such a request is too demanding for a modern computer system to honor. See also Extended Window Manager Hints,¹ with the emphasis on *hints*. > ... GUI frameworks may provide a core that automatically handles this > for you, but that is not always the case (as an extreme example, if > you're writing the whole app from scratch in assembly language) ... Define "from scratch." Why does the language in which I'm writing my application matter? ¹ https://en.wikipedia.org/wiki/Extended_Window_Manager_Hints -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 03:02:05PM +1100, Chris Angelico wrote: > On Thu, Jan 14, 2021 at 2:43 PM Python wrote: > > > it is far FAR better to put control in the user's hands > > > > I love how you dismissed that the semantics I described gives MORE > > control to the user, not less, without actually sacrificing anything. > > Actually, you give control to the application, and then the > application has to choose to give it to the user. Right, because unless the user can somehow execute instructions directly on the CPU via some sort of direct cerebral link, all control the user has over the behavior of the applications comes... from the applications. > But apparently, this thread has devolved to this kind of total > dismissal For which you are entirely the cause. I simply responded in kind. Apparently you don't like it any more than the rest of us do. -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 2:43 PM Python wrote: > > it is far FAR better to put control in the user's hands > > I love how you dismissed that the semantics I described gives MORE > control to the user, not less, without actually sacrificing anything. Actually, you give control to the application, and then the application has to choose to give it to the user. But apparently, this thread has devolved to this kind of total dismissal, so I'm not going to respond further. Have fun building your app, do what you like with it, and I'll continue to use standards-compliant applications that actually behave correctly in all situations. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi, David, On Wed, Jan 13, 2021 at 9:24 PM David L Neil via Python-list wrote: > > On 14/01/2021 15.25, boB Stepp wrote: > > On Wed, Jan 13, 2021 at 7:28 PM Chris Angelico wrote: > > > >> I love how "I think" is allowed to trump decades of usability research. > > I'm just pleased that @Chris has found love! > (not detracting from the point though) > > > > Can you recommend a good reference for someone relatively new to GUI > > programming that is based on such research? Book or web reference > > would be fine. > > Most of my training-materials (certainly in this topic) are web-based - > but the ideas are also common to Python. > > > Nielsen-Norman Group do a lot of work in UX and offer a regular > newsletter which is usually a good way to make the brain-cells work for > their living: https://www.nngroup.com/ > > eg https://www.nngroup.com/articles/usability-101-introduction-to-usability/ > > > A more applied view, courtesy of the New Zealand Government: > https://www.digital.govt.nz/standards-and-guidance/nz-government-web-standards/web-usability-standard-1-3/ > > > Some become confused between the two terms: Accessibility and Usability. > > Here's what the boss says: > https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/ > > This article clearly explains each and then offers a comparison. > https://www.telerik.com/blogs/web-accessibility-vs-usability > > > If you really want to dig-down, I know for-sure that IBM, Microsoft, > Apple (and presumably others) have compiled style-guides about how > various GUIs should work, starting from really basic matters such as > when to use radio-buttons and when check-boxes. I can't tell you if the > gtk, qt, or wx people offer something similar... Certainly not wx - because wx using native set of widgets and therefore relies on the OS UI guidelines. Thank you. > -- > Regards =dn > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 12:27:19PM +1100, Chris Angelico wrote: > On Thu, Jan 14, 2021 at 12:11 PM Python wrote: > > > > On Tue, Jan 12, 2021 at 06:43:39PM -, Grant Edwards wrote: > > > And those X11 users will swear at you if you override their window > > > managers configured window placement. Application code should not care > > > about or try to control window geometry. Period. > > > > I think this is just plain wrong. As a side note, from a purely technical standpoint, Grant's point is demonstrably factually false. A GUI application necessarily must "care about or try to control window geometry" so that if the user moves or resizes the application, enables or disables additional widgets, etc., the widgets it contains are redrawn such that they remain usable, possibly expanding the canvas they're drawn on or adding new GUI elements like scrollbars to ensure that (at least it does if it wants to be useful). GUI frameworks may provide a core that automatically handles this for you, but that is not always the case (as an extreme example, if you're writing the whole app from scratch in assembly language), and in any event the framework is part of the application... not the window manager. Just because you didn't write that code doesn't mean your app doesn't need those facilities. > I love how "I think" is allowed to trump decades of usability research. I love how your complete dismissal of everything I said is allowed to replace logical counterargument, particuarly when you ignored the fact that absolutely nothing I said actually contradicts any such years of usability research IN ANY WAY--I merely pointed out that if the application were to have ADDITIONAL flexibility for expert users in regard to placing and sizing windows, the application must necessarily care about and be able to control its window geometry. All the other behaviors remain consistent with usability standards--assuming the vendor implemented them properly, which is a big assumption. In fact, providing such extra semantics may allow the user to overcome bad UI when the vendor failed. > it is far FAR better to put control in the user's hands I love how you dismissed that the semantics I described gives MORE control to the user, not less, without actually sacrificing anything. I love how you dismissed that not all computer users and not all humans are the same, that there are variances and outliers within all usability studies, and indeed all studies of human behavior, and that flexibility and configurability have value for that reason. I love how you dismissed the perpectives and motivations of posters in this thread without understanding or even hearing them. For all you know Rich may just be doing it as an academic exercise, in which case whether or not it conforms to usability best practices is utterly irrelevant, even if it weren't already the case that giving more control to the user--something you just claimed to value--requires giving control to the app. -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Chris, On Wed, Jan 13, 2021 at 8:12 PM Chris Angelico wrote: > > On Thu, Jan 14, 2021 at 1:05 PM Igor Korot wrote: > > > > Chris, > > > > On Wed, Jan 13, 2021 at 7:45 PM Chris Angelico wrote: > > > > > > On Thu, Jan 14, 2021 at 12:39 PM Igor Korot wrote: > > > > > > > > Chris, > > > > > > > > On Wed, Jan 13, 2021 at 7:33 PM Chris Angelico wrote: > > > > > > > > > > On Thu, Jan 14, 2021 at 12:18 PM Python > > > > > wrote: > > > > > > > The results will differ based on whether the user in question has > > > > > > > basically just one primary application (an IDE, or some gigantic > > > > > > > app > > > > > > > like Adobe PhotoShop) that they spend all their time in > > > > > > > > > > > > OK, so you admit that such apps do exist. But I guess you knew that > > > > > > the OP is not writing that sort of application, and know who its > > > > > > intended audience is, and their work habits and preferences... > > > > > > > > > > > > > > > > The difference isn't in what's best, but in what people are willing to > > > > > accept. Just because people roll over and accept the latest Windows, > > > > > the latest Mac OS, the latest PhotoShop, the latest Gmail, the latest > > > > > whatever else, doesn't mean that (a) they actually like it, nor (b) > > > > > it's actually better. (Which are independent.) > > > > > > > > > > When someone spends all their life in a single app, they're more > > > > > likely to learn its particular way of doing things and assume that > > > > > that's "correct". But that doesn't make it so. > > > > > > > > Correct. > > > > But when that same person goes to a different company where a > > > > different application > > > > is used, he expects it to behave the same. Because the functionality of > > > > such > > > > application is the same. > > > > > > > > Wouldn't you? > > > > > > > > It is called association. > > > > > > > > "I was working with Application A. Now I'm working with application > > > > AA. And application > > > > AA behaves very weirdly." > > > > > > > > > > Yes, association is correct. > > > > > > "I was working with Application A. Now I'm working with Application B. > > > And it behaves very weirdly." > > > > > > It's entirely possible that App A was the bad one, and unfortunately, > > > that does happen. But this is exactly why it's better to follow the > > > standards. Unless you are so egotistical that you think your users > > > won't need *any* other applications in their lives, follow the > > > standards. > > > > And you still don't say anything about my DB example. > > > > Normal DB application has to place credentials dialog center > > screen or center frame, depending when it shows. > > > > Otherwise they will popup all over the place wrecking havoc > > with the users. > > > > And so its better to show it centered, just like in my example > > above. And as I said - I hope you are inside this 99.99% of users/ > > developers. > > > > And isn't that exactly where the WM would put it by default too? The > difference is, if the user wishes it to be somewhere else *for all > applications*, s/he can reconfigure the WM, but it's an absolute pain > if all these kinds of apps have to be independently reconfigured. The > obvious defaults are obvious to the creators of WMs even more than app > developers, AND you're not forcing people into your personal > preferences. I don't know. Do you? Are you absolutely sure 100% it will put it there? Especially by default? Now here is the more interesting question: if I create such a dialog (meaning it will not be pulled from external library) what will happen? Can you guarantee that my dialog will be placed accordingly and if I call "dlg.Center()" it won't be ignored? Thank you. > > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On 14/01/2021 15.25, boB Stepp wrote: > On Wed, Jan 13, 2021 at 7:28 PM Chris Angelico wrote: > >> I love how "I think" is allowed to trump decades of usability research. I'm just pleased that @Chris has found love! (not detracting from the point though) > Can you recommend a good reference for someone relatively new to GUI > programming that is based on such research? Book or web reference > would be fine. Most of my training-materials (certainly in this topic) are web-based - but the ideas are also common to Python. Nielsen-Norman Group do a lot of work in UX and offer a regular newsletter which is usually a good way to make the brain-cells work for their living: https://www.nngroup.com/ eg https://www.nngroup.com/articles/usability-101-introduction-to-usability/ A more applied view, courtesy of the New Zealand Government: https://www.digital.govt.nz/standards-and-guidance/nz-government-web-standards/web-usability-standard-1-3/ Some become confused between the two terms: Accessibility and Usability. Here's what the boss says: https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/ This article clearly explains each and then offers a comparison. https://www.telerik.com/blogs/web-accessibility-vs-usability If you really want to dig-down, I know for-sure that IBM, Microsoft, Apple (and presumably others) have compiled style-guides about how various GUIs should work, starting from really basic matters such as when to use radio-buttons and when check-boxes. I can't tell you if the gtk, qt, or wx people offer something similar... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On 14/01/2021 15.25, boB Stepp wrote: > On Wed, Jan 13, 2021 at 7:28 PM Chris Angelico wrote: > >> I love how "I think" is allowed to trump decades of usability research. I'm just pleased that @Chris has found love! (not detracting from the point though) > Can you recommend a good reference for someone relatively new to GUI > programming that is based on such research? Book or web reference > would be fine. Most of my training-materials (certainly in this topic) are web-based - but the ideas are also common to Python. Nielsen-Norman Group do a lot of work in UX and offer a regular newsletter which is usually a good way to make the brain-cells work for their living: https://www.nngroup.com/ eg https://www.nngroup.com/articles/usability-101-introduction-to-usability/ A more applied view, courtesy of the New Zealand Government: https://www.digital.govt.nz/standards-and-guidance/nz-government-web-standards/web-usability-standard-1-3/ Some become confused between the two terms: Accessibility and Usability. Here's what the boss says: https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/ This article clearly explains each and then offers a comparison. https://www.telerik.com/blogs/web-accessibility-vs-usability If you really want to dig-down, I know for-sure that IBM, Microsoft, Apple (and presumably others) have compiled style-guides about how various GUIs should work, starting from really basic matters such as when to use radio-buttons and when check-boxes. I can't tell you if the gtk, qt, or wx people offer something similar... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Wed, Jan 13, 2021 at 7:28 PM Chris Angelico wrote: > I love how "I think" is allowed to trump decades of usability research. Can you recommend a good reference for someone relatively new to GUI programming that is based on such research? Book or web reference would be fine. Cheers! boB -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 1:05 PM Igor Korot wrote: > > Chris, > > On Wed, Jan 13, 2021 at 7:45 PM Chris Angelico wrote: > > > > On Thu, Jan 14, 2021 at 12:39 PM Igor Korot wrote: > > > > > > Chris, > > > > > > On Wed, Jan 13, 2021 at 7:33 PM Chris Angelico wrote: > > > > > > > > On Thu, Jan 14, 2021 at 12:18 PM Python wrote: > > > > > > The results will differ based on whether the user in question has > > > > > > basically just one primary application (an IDE, or some gigantic app > > > > > > like Adobe PhotoShop) that they spend all their time in > > > > > > > > > > OK, so you admit that such apps do exist. But I guess you knew that > > > > > the OP is not writing that sort of application, and know who its > > > > > intended audience is, and their work habits and preferences... > > > > > > > > > > > > > The difference isn't in what's best, but in what people are willing to > > > > accept. Just because people roll over and accept the latest Windows, > > > > the latest Mac OS, the latest PhotoShop, the latest Gmail, the latest > > > > whatever else, doesn't mean that (a) they actually like it, nor (b) > > > > it's actually better. (Which are independent.) > > > > > > > > When someone spends all their life in a single app, they're more > > > > likely to learn its particular way of doing things and assume that > > > > that's "correct". But that doesn't make it so. > > > > > > Correct. > > > But when that same person goes to a different company where a > > > different application > > > is used, he expects it to behave the same. Because the functionality of > > > such > > > application is the same. > > > > > > Wouldn't you? > > > > > > It is called association. > > > > > > "I was working with Application A. Now I'm working with application > > > AA. And application > > > AA behaves very weirdly." > > > > > > > Yes, association is correct. > > > > "I was working with Application A. Now I'm working with Application B. > > And it behaves very weirdly." > > > > It's entirely possible that App A was the bad one, and unfortunately, > > that does happen. But this is exactly why it's better to follow the > > standards. Unless you are so egotistical that you think your users > > won't need *any* other applications in their lives, follow the > > standards. > > And you still don't say anything about my DB example. > > Normal DB application has to place credentials dialog center > screen or center frame, depending when it shows. > > Otherwise they will popup all over the place wrecking havoc > with the users. > > And so its better to show it centered, just like in my example > above. And as I said - I hope you are inside this 99.99% of users/ > developers. > And isn't that exactly where the WM would put it by default too? The difference is, if the user wishes it to be somewhere else *for all applications*, s/he can reconfigure the WM, but it's an absolute pain if all these kinds of apps have to be independently reconfigured. The obvious defaults are obvious to the creators of WMs even more than app developers, AND you're not forcing people into your personal preferences. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Chris, On Wed, Jan 13, 2021 at 7:45 PM Chris Angelico wrote: > > On Thu, Jan 14, 2021 at 12:39 PM Igor Korot wrote: > > > > Chris, > > > > On Wed, Jan 13, 2021 at 7:33 PM Chris Angelico wrote: > > > > > > On Thu, Jan 14, 2021 at 12:18 PM Python wrote: > > > > > The results will differ based on whether the user in question has > > > > > basically just one primary application (an IDE, or some gigantic app > > > > > like Adobe PhotoShop) that they spend all their time in > > > > > > > > OK, so you admit that such apps do exist. But I guess you knew that > > > > the OP is not writing that sort of application, and know who its > > > > intended audience is, and their work habits and preferences... > > > > > > > > > > The difference isn't in what's best, but in what people are willing to > > > accept. Just because people roll over and accept the latest Windows, > > > the latest Mac OS, the latest PhotoShop, the latest Gmail, the latest > > > whatever else, doesn't mean that (a) they actually like it, nor (b) > > > it's actually better. (Which are independent.) > > > > > > When someone spends all their life in a single app, they're more > > > likely to learn its particular way of doing things and assume that > > > that's "correct". But that doesn't make it so. > > > > Correct. > > But when that same person goes to a different company where a > > different application > > is used, he expects it to behave the same. Because the functionality of such > > application is the same. > > > > Wouldn't you? > > > > It is called association. > > > > "I was working with Application A. Now I'm working with application > > AA. And application > > AA behaves very weirdly." > > > > Yes, association is correct. > > "I was working with Application A. Now I'm working with Application B. > And it behaves very weirdly." > > It's entirely possible that App A was the bad one, and unfortunately, > that does happen. But this is exactly why it's better to follow the > standards. Unless you are so egotistical that you think your users > won't need *any* other applications in their lives, follow the > standards. And you still don't say anything about my DB example. Normal DB application has to place credentials dialog center screen or center frame, depending when it shows. Otherwise they will popup all over the place wrecking havoc with the users. And so its better to show it centered, just like in my example above. And as I said - I hope you are inside this 99.99% of users/ developers. Thank you. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On 14/01/21 1:58 pm, Chris Angelico wrote: On Thu, Jan 14, 2021 at 11:53 AM Python wrote: I believe it is or was quite common for large, integrated applications like DAWs, graphical design software, etc. to remember where you placed your various floating toolbars and add-ons Not just large, integrated applications. If I open Intaglio (a modestly sized drawing app) on my Mac right now, the palettes are all where I left them last time. The results will differ based on whether the user in question has basically just one primary application (an IDE, or some gigantic app like Adobe PhotoShop) that they spend all their time in, or if they're using myriad different applications. Especially in the latter case, it is far FAR better to put control in the user's hands I don't follow. If the app is just remembering where the user put things, then it *is* putting control in the user's hands. And I don't see what difference it makes how many different apps they use. Leaving things where the user put them seems like a good idea regardless. Ideally, the OS or window manager would do the remembering, but if it doesn't provide such a facility, I don't see any harm in allowing the app to *request* (not force) a certain position for a window. The app can of course abuse that privilege, but that's the fault of the app, not the feature. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 12:39 PM Igor Korot wrote: > > Chris, > > On Wed, Jan 13, 2021 at 7:33 PM Chris Angelico wrote: > > > > On Thu, Jan 14, 2021 at 12:18 PM Python wrote: > > > > The results will differ based on whether the user in question has > > > > basically just one primary application (an IDE, or some gigantic app > > > > like Adobe PhotoShop) that they spend all their time in > > > > > > OK, so you admit that such apps do exist. But I guess you knew that > > > the OP is not writing that sort of application, and know who its > > > intended audience is, and their work habits and preferences... > > > > > > > The difference isn't in what's best, but in what people are willing to > > accept. Just because people roll over and accept the latest Windows, > > the latest Mac OS, the latest PhotoShop, the latest Gmail, the latest > > whatever else, doesn't mean that (a) they actually like it, nor (b) > > it's actually better. (Which are independent.) > > > > When someone spends all their life in a single app, they're more > > likely to learn its particular way of doing things and assume that > > that's "correct". But that doesn't make it so. > > Correct. > But when that same person goes to a different company where a > different application > is used, he expects it to behave the same. Because the functionality of such > application is the same. > > Wouldn't you? > > It is called association. > > "I was working with Application A. Now I'm working with application > AA. And application > AA behaves very weirdly." > Yes, association is correct. "I was working with Application A. Now I'm working with Application B. And it behaves very weirdly." It's entirely possible that App A was the bad one, and unfortunately, that does happen. But this is exactly why it's better to follow the standards. Unless you are so egotistical that you think your users won't need *any* other applications in their lives, follow the standards. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Chris, On Wed, Jan 13, 2021 at 7:33 PM Chris Angelico wrote: > > On Thu, Jan 14, 2021 at 12:18 PM Python wrote: > > > The results will differ based on whether the user in question has > > > basically just one primary application (an IDE, or some gigantic app > > > like Adobe PhotoShop) that they spend all their time in > > > > OK, so you admit that such apps do exist. But I guess you knew that > > the OP is not writing that sort of application, and know who its > > intended audience is, and their work habits and preferences... > > > > The difference isn't in what's best, but in what people are willing to > accept. Just because people roll over and accept the latest Windows, > the latest Mac OS, the latest PhotoShop, the latest Gmail, the latest > whatever else, doesn't mean that (a) they actually like it, nor (b) > it's actually better. (Which are independent.) > > When someone spends all their life in a single app, they're more > likely to learn its particular way of doing things and assume that > that's "correct". But that doesn't make it so. Correct. But when that same person goes to a different company where a different application is used, he expects it to behave the same. Because the functionality of such application is the same. Wouldn't you? It is called association. "I was working with Application A. Now I'm working with application AA. And application AA behaves very weirdly." Thank you. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 12:18 PM Python wrote: > > The results will differ based on whether the user in question has > > basically just one primary application (an IDE, or some gigantic app > > like Adobe PhotoShop) that they spend all their time in > > OK, so you admit that such apps do exist. But I guess you knew that > the OP is not writing that sort of application, and know who its > intended audience is, and their work habits and preferences... > The difference isn't in what's best, but in what people are willing to accept. Just because people roll over and accept the latest Windows, the latest Mac OS, the latest PhotoShop, the latest Gmail, the latest whatever else, doesn't mean that (a) they actually like it, nor (b) it's actually better. (Which are independent.) When someone spends all their life in a single app, they're more likely to learn its particular way of doing things and assume that that's "correct". But that doesn't make it so. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi, On Wed, Jan 13, 2021 at 7:20 PM Python wrote: > > On Thu, Jan 14, 2021 at 11:58:34AM +1100, Chris Angelico wrote: > > On Thu, Jan 14, 2021 at 11:53 AM Python wrote: > > Have you actually done any research by (a) asking people what they > > actually prefer, and better still (b) silently watching over someone's > > shoulder and seeing which one makes people more productive? > > As I said, though it's been a long while, I was actually a user of > such applications myself. So I can tell you quite authoritatively > that in those kinds of apps, *I* absolutely prefer that the app > remember where my windows are and what's in them, no contest. And I > would always use them alongside a slew of other apps--web browsers, > text editors, mail clients, etc... most likely on a separate desktop, > if I wasn't mobile, but necessarily on the same one if I was. > > > The results will differ based on whether the user in question has > > basically just one primary application (an IDE, or some gigantic app > > like Adobe PhotoShop) that they spend all their time in > > OK, so you admit that such apps do exist. But I guess you knew that > the OP is not writing that sort of application, and know who its > intended audience is, and their work habits and preferences... Unfortunately, this is how Wayland behaves right now. When I tried to complain they said that saving/restoring perspective is in the works. But I sure hope that when people will switch to Wayland that DB credentials dialog I was talking about in the previous reply will still be positioned on the center of the screen. Or even better - on the center of the main frame and not somewhere else. Thank you. > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 12:11 PM Python wrote: > > On Tue, Jan 12, 2021 at 06:43:39PM -, Grant Edwards wrote: > > And those X11 users will swear at you if you override their window > > managers configured window placement. Application code should not care > > about or try to control window geometry. Period. > > I think this is just plain wrong. I love how "I think" is allowed to trump decades of usability research. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi, On Wed, Jan 13, 2021 at 7:12 PM Python wrote: > > On Tue, Jan 12, 2021 at 06:43:39PM -, Grant Edwards wrote: > > And those X11 users will swear at you if you override their window > > managers configured window placement. Application code should not care > > about or try to control window geometry. Period. > > I think this is just plain wrong. If you, the user, want to override > what you, the user, configured your window manager to do, for WHATEVER > reason your little heart may desire, then the application needs to > give you an interface to request it, and rather importantly the WM must > necessarily honor it. > > The policy reallly ought to be: > > - If the user took the time to specify a geometry, do what it says >(i.e. honor the placement the application asks for) > - If not but the window manager has something configured for that > application/widget/whatever, do what it says > - Otherwise, resort to the window manager's default policy > > Arguably there ought to also be a way for the application to *suggest* > a default geometry that the WM can override, but obviously providing a > way to force the geometry gives rise to the opportunity for abuse by > badly behaved developers. Don't use those apps. > > Fortunately, at least historically, in practice most X11 window > managers more or less did all that anyway. I recall that when I > switched to Gnome I had some trouble with this (as in, it just didn't > work, generally, even if the relevant app allowed you to specify > --geometry or similar), but AFAICT Gnome has long held to the notion > that Gnome Gnows better than you do how you should run your apps, so > when using Gnome all bets are off. Well, I am running GNOME 3 on top of X11. I didn't preselect or configure any windows positioning in there. My application that I'm developing will be connecting to the database to pull some data. When I tried to connect to Sybase ASE with their own ODBC driver the dialog that asks for credentials shows up in the center of the screen. And this is the position where (and I hope 99.99% of people) expect it to show up. Hopefully this number (99.99%) does include Mr. Angelico,. But my application is maximized right now, so maybe it is centered on the main frame. Anyway that dialog (TLW) is centered. Thank you. > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 11:58:34AM +1100, Chris Angelico wrote: > On Thu, Jan 14, 2021 at 11:53 AM Python wrote: > Have you actually done any research by (a) asking people what they > actually prefer, and better still (b) silently watching over someone's > shoulder and seeing which one makes people more productive? As I said, though it's been a long while, I was actually a user of such applications myself. So I can tell you quite authoritatively that in those kinds of apps, *I* absolutely prefer that the app remember where my windows are and what's in them, no contest. And I would always use them alongside a slew of other apps--web browsers, text editors, mail clients, etc... most likely on a separate desktop, if I wasn't mobile, but necessarily on the same one if I was. > The results will differ based on whether the user in question has > basically just one primary application (an IDE, or some gigantic app > like Adobe PhotoShop) that they spend all their time in OK, so you admit that such apps do exist. But I guess you knew that the OP is not writing that sort of application, and know who its intended audience is, and their work habits and preferences... -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Tue, Jan 12, 2021 at 06:43:39PM -, Grant Edwards wrote: > And those X11 users will swear at you if you override their window > managers configured window placement. Application code should not care > about or try to control window geometry. Period. I think this is just plain wrong. If you, the user, want to override what you, the user, configured your window manager to do, for WHATEVER reason your little heart may desire, then the application needs to give you an interface to request it, and rather importantly the WM must necessarily honor it. The policy reallly ought to be: - If the user took the time to specify a geometry, do what it says (i.e. honor the placement the application asks for) - If not but the window manager has something configured for that application/widget/whatever, do what it says - Otherwise, resort to the window manager's default policy Arguably there ought to also be a way for the application to *suggest* a default geometry that the WM can override, but obviously providing a way to force the geometry gives rise to the opportunity for abuse by badly behaved developers. Don't use those apps. Fortunately, at least historically, in practice most X11 window managers more or less did all that anyway. I recall that when I switched to Gnome I had some trouble with this (as in, it just didn't work, generally, even if the relevant app allowed you to specify --geometry or similar), but AFAICT Gnome has long held to the notion that Gnome Gnows better than you do how you should run your apps, so when using Gnome all bets are off. -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 11:53 AM Python wrote: > > On Wed, Jan 13, 2021 at 10:07:23AM +1100, Chris Angelico wrote: > > On Wed, Jan 13, 2021 at 10:02 AM Igor Korot wrote: > > > But for my dialogs (especially for dialogs where I need to ask for > > > credentials) - I don't think I want > > > WM to do my job. > > > > > > Again - we are talking positioning here and not size/client size. > > > > > > > And I don't think I want you to do the WM's job. > > > > You're welcome to keep going to great effort to do the wrong thing, > > but be aware that nobody will appreciate the work you're doing, and in > > fact are more likely to curse you for it. Just save yourself a LOT of > > hassle and let the WM do its job. It knows the user's wishes better > > than you do. > > I think this is quite very, very far from true. It's been a while > since I've used such tools, but I believe it is or was quite common > for large, integrated applications like DAWs, graphical design > software, etc. to remember where you placed your various floating > toolbars and add-ons (and even much more detailed state about how > you'd set the various widgets in them), and that users of such > applications expect that. > Have you actually done any research by (a) asking people what they actually prefer, and better still (b) silently watching over someone's shoulder and seeing which one makes people more productive? The results will differ based on whether the user in question has basically just one primary application (an IDE, or some gigantic app like Adobe PhotoShop) that they spend all their time in, or if they're using myriad different applications. Especially in the latter case, it is far FAR better to put control in the user's hands than to try to make the monopoly position work. Of course, if you are a big enough name (like Apple, especially), you can do whatever you like, and people just have to accept it. That's a monopoly for you, and there's no evidence that it's better, just that people learn to live with it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Wed, Jan 13, 2021 at 10:07:23AM +1100, Chris Angelico wrote: > On Wed, Jan 13, 2021 at 10:02 AM Igor Korot wrote: > > But for my dialogs (especially for dialogs where I need to ask for > > credentials) - I don't think I want > > WM to do my job. > > > > Again - we are talking positioning here and not size/client size. > > > > And I don't think I want you to do the WM's job. > > You're welcome to keep going to great effort to do the wrong thing, > but be aware that nobody will appreciate the work you're doing, and in > fact are more likely to curse you for it. Just save yourself a LOT of > hassle and let the WM do its job. It knows the user's wishes better > than you do. I think this is quite very, very far from true. It's been a while since I've used such tools, but I believe it is or was quite common for large, integrated applications like DAWs, graphical design software, etc. to remember where you placed your various floating toolbars and add-ons (and even much more detailed state about how you'd set the various widgets in them), and that users of such applications expect that. Obviously the software needs to be aware of, and compensate for, cases when the available display can't draw the various widgets in visible space on the desktop/canvas/whatever, but if the application wants to do all that, it seems like a perfectly wonderful feature to me. The last thing I want to do is spend 15 minutes to relocate and reconfgure UI elements to where and how I like them before I can even start working on a media project (or whatever). -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Wed, Jan 13, 2021 at 10:02 AM Igor Korot wrote: > But for my dialogs (especially for dialogs where I need to ask for > credentials) - I don't think I want > WM to do my job. > > Again - we are talking positioning here and not size/client size. > And I don't think I want you to do the WM's job. You're welcome to keep going to great effort to do the wrong thing, but be aware that nobody will appreciate the work you're doing, and in fact are more likely to curse you for it. Just save yourself a LOT of hassle and let the WM do its job. It knows the user's wishes better than you do. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Chris, On Tue, Jan 12, 2021 at 4:38 PM Chris Angelico wrote: > > On Wed, Jan 13, 2021 at 9:30 AM Igor Korot wrote: > > > > Not sure I follow - frame is a TLW. Dialog is a TLW. > > Program flow is as follows: > > > > 1. Program starts with a frame > > 2. At some point the user asks to connect to the database. > > 3. Credentials dialog is shown. > > > > Now, while frame is TLW and may follow the renderer rules, the dialog > > that vask the user for credentials should not. > > > > Now, system dialog should probably follow the rules of the WM, but if I > > want my > > dialog to appear centered on the parent (not on the screen) - what > > right the WM have > > to override it? > > > > I also think that ALL dialogs are TLWs independently of whether they > > are created with > > the actual parent (frame) or a null-parent (desktop). > > In regards that they are not buttons/list controls/toolbars/etc. > > In one sense you're right, but in another, the creation of a window > with a parent is very different from the creation of a window without > a parent. The WM will handle them differently because the user will > expect them to behave differently. In fact, centering on the parent is > a very likely position, so don't worry about it - just declare your > parent correctly. For the dialog (as well as any other TLW), it should be no difference. Because if I pass a "parent" as NULL, it means I have a parent as a "Desktop" window. That's why frames and dialogs are called TLWs - they don't have to have an "explicit" parent. > > > Are you talking about geometry or a position? > > For me geometry is a complex thing - position, size of the window and > > the client size > > of the window (which is important especially in *nix). > > The size of the window is generally governed by its contents, so > that's under the application's control (within limits set by the WM). > The position, though, is up to the WM. And what about client size? Because if we are talking about *nix (which I think we are) you should count decorations. > > > > > > (That's actually a 100% realistic scenario, given that I'm usually on > > > > > my desktop system, but occasionally I'll be on my laptop, SSH'd in > > > > > with X11 forwarding.) > > > > > > > > Absolutely. > > > > I found myself in this situation recently - when I'm in the office I > > > > have 2 external > > > > monitors, and when I am at home - I only have a laptop. > > > > And windows are showing on the primary all the time. > > > > > > > > > > Right! That's the WM's job. Let it do its job, and everyone's lives > > > will be easier. > > > > Well, please re-read my initial statement. > > You can't decide where to put that credential dialog. It has to appear > > in the middle > > of the screen (if there is 1 - on it, if multiple - on the screen > > where the main frame is). > > > > DO you see the problem with that? > > Yes, I see a problem with the application trying to remember where the > dialog was last time. A MAJOR problem. Restoring the dialog's geometry > might have it completely off screen, or at best, in a position that is > decidedly unideal. But if you let the WM decide where the dialog > should be placed, it's guaranteed to be where the user expects it (or > more precisely, it's guaranteed to be consistent with every *other* > application that also behaves like this, and the user has the power to > configure this). In this particular case there is no need to remember - credentials dialog need to appear at the center of the monitor 0 and they should be sized accordingly. Now here are the scenarios I'm looking at: 1. Program starts - credentials dialog is shown. The parent of this dialog is "Desktop" window. It is better to be displayed in the center of the "Monitor 0". 2. Program start - frame is shown. I agree that it is best to let the WM decide its position. At some point of time I need to connect to the DB and so credential dialog is shown. In this scenario this dialog should also be shown "Monitor 0" centered. 3. Start with scenario 2. Resize the frame and exit the application. Attach the new monitor. Start the application again. Frame will probably appear on "Monitor 0" (depending on the WM rules). Start the DB connection. The credentials dialog should appear centered on the screen where the frame is. As you can see none of those scenarios include system dialogs (open/save, font selection, etc). They has to follow system/WM rules and appear as appropriate. Because they are system based and user code shouldn't say anything about their positioning. But for my dialogs (especially for dialogs where I need to ask for credentials) - I don't think I want WM to do my job. Again - we are talking positioning here and not size/client size. Thank you. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Wed, Jan 13, 2021 at 9:30 AM Igor Korot wrote: > > Not sure I follow - frame is a TLW. Dialog is a TLW. > Program flow is as follows: > > 1. Program starts with a frame > 2. At some point the user asks to connect to the database. > 3. Credentials dialog is shown. > > Now, while frame is TLW and may follow the renderer rules, the dialog > that vask the user for credentials should not. > > Now, system dialog should probably follow the rules of the WM, but if I want > my > dialog to appear centered on the parent (not on the screen) - what > right the WM have > to override it? > > I also think that ALL dialogs are TLWs independently of whether they > are created with > the actual parent (frame) or a null-parent (desktop). > In regards that they are not buttons/list controls/toolbars/etc. In one sense you're right, but in another, the creation of a window with a parent is very different from the creation of a window without a parent. The WM will handle them differently because the user will expect them to behave differently. In fact, centering on the parent is a very likely position, so don't worry about it - just declare your parent correctly. > Are you talking about geometry or a position? > For me geometry is a complex thing - position, size of the window and > the client size > of the window (which is important especially in *nix). The size of the window is generally governed by its contents, so that's under the application's control (within limits set by the WM). The position, though, is up to the WM. > > > > (That's actually a 100% realistic scenario, given that I'm usually on > > > > my desktop system, but occasionally I'll be on my laptop, SSH'd in > > > > with X11 forwarding.) > > > > > > Absolutely. > > > I found myself in this situation recently - when I'm in the office I > > > have 2 external > > > monitors, and when I am at home - I only have a laptop. > > > And windows are showing on the primary all the time. > > > > > > > Right! That's the WM's job. Let it do its job, and everyone's lives > > will be easier. > > Well, please re-read my initial statement. > You can't decide where to put that credential dialog. It has to appear > in the middle > of the screen (if there is 1 - on it, if multiple - on the screen > where the main frame is). > > DO you see the problem with that? Yes, I see a problem with the application trying to remember where the dialog was last time. A MAJOR problem. Restoring the dialog's geometry might have it completely off screen, or at best, in a position that is decidedly unideal. But if you let the WM decide where the dialog should be placed, it's guaranteed to be where the user expects it (or more precisely, it's guaranteed to be consistent with every *other* application that also behaves like this, and the user has the power to configure this). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi, Chris, On Tue, Jan 12, 2021 at 4:05 PM Chris Angelico wrote: > > On Wed, Jan 13, 2021 at 7:00 AM Igor Korot wrote: > > > > Hi, Chris, > > > > On Tue, Jan 12, 2021 at 1:33 PM Chris Angelico wrote: > > > > > > On Wed, Jan 13, 2021 at 6:18 AM Igor Korot wrote: > > > > > > > > Hi, Grant, > > > > > > > > On Tue, Jan 12, 2021 at 12:47 PM Grant Edwards > > > > wrote: > > > > > > > > > > On 2021-01-12, Rich Shepard wrote: > > > > > > On Tue, 12 Jan 2021, Igor Korot wrote: > > > > > > > > > > > >> Keep in mind that if you target Linux, the "modern" window server > > > > > >> (Wayland) will not allow user code to decide the positioning and > > > > > >> size of > > > > > >> the TLW. > > > > > > > > > > > > Igor, > > > > > > > > > > > > I suspect that Slackware will continue with X11. > > > > > > > > > > And those X11 users will swear at you if you override their window > > > > > managers configured window placement. Application code should not care > > > > > about or try to control window geometry. Period. > > > > > > > > I have a very strong argument against it!! > > > > > > > > Imagine you are developing an application that need to communicate > > > > with the database. > > > > Also imagine this application will be used by millions of users inside > > > > different companies. > > > > > > > > SInce the application will require DB access you will need a dialog to > > > > ask for credentials. > > > > > > > > I, personally, would be very surprised if such dialog would appear > > > > somewhere at the bottom of the screen, > > > > as dialogs ARE TLWs (top level windows). > > > > > > > > Wouldn't you? > > > > > > Yes, I would too - because I have my window manager configured to > > > place that dialog where *I* want it, not where the application > > > developer chose to put it. > > > > So, how do *you* distinguish between such dialog and all other dialogs > > an application might raise (open/save dialogs. font selection dialog, user > > warning thing). > > > > Because with my scenario there are 2 TLWs in the picture - main frame and > > dialog for credentials. > > > > Besides it looks like you are setting this dialog to appear at constant > > position > > anyway. Or am I missing smth? > > Hmm, maybe I'm missing something. The initial window isn't a "dialog", > it's an application window. They follow slightly different rules > (mainly, they don't have a parent window), but they still follow > *rules*. Not sure I follow - frame is a TLW. Dialog is a TLW. Program flow is as follows: 1. Program starts with a frame 2. At some point the user asks to connect to the database. 3. Credentials dialog is shown. Now, while frame is TLW and may follow the renderer rules, the dialog that vask the user for credentials should not. Now, system dialog should probably follow the rules of the WM, but if I want my dialog to appear centered on the parent (not on the screen) - what right the WM have to override it? I also think that ALL dialogs are TLWs independently of whether they are created with the actual parent (frame) or a null-parent (desktop). In regards that they are not buttons/list controls/toolbars/etc. > > > > > So why I somewhat agree with such a notion - it is not always a useful > > > > feature. > > > > Also, such an algorithm better allow me to save and restore the > > > > geometry of the TLW. > > > > > > Why save and restore the geometry when the window manager can do a > > > better job of positioning it? Give the WM the hints it needs, then let > > > it figure out the placement. > > > > Because I want this application to appear at the same place every time? > > The first time it shows I may just drag it away or minimize it at some > > point or > > make it very small to clear the space. > > > > And the next time I want it to start at the same position. > > And I find that most apps that behave this way end up being more > annoying than not. Well its just a matter of opinion than. ;-) > > > > Consider that the last time your window was opened, I might have had > > > one 1366x768 monitor, but now I have four - 1920x1080, 1920x1080, > > > 1280x1024, and 1600x900. Where should your dialog go? Not your > > > problem, because my WM knows and understands. > > > > There is a notion of the "primary display" which is here for a reason. ;-) > > So you can attach/detach as many monitors as you want - in the end if > > the monitor is not available and that window will appear on the primary > > monitor. > > In the second scenario, the primary monitor is at position (1920, 0). > So you've just described exactly what a window manager does - follow > rules to decide where the window appears - and NOT what happens if you > remember geometry, which would be to put the window somewhere in the > top left. You see the problem with remembering geometry? Are you talking about geometry or a position? For me geometry is a complex thing - position, size of the window and the client size of the window (which is important
Re: Application window geometry specifier
On Wed, Jan 13, 2021 at 7:00 AM Igor Korot wrote: > > Hi, Chris, > > On Tue, Jan 12, 2021 at 1:33 PM Chris Angelico wrote: > > > > On Wed, Jan 13, 2021 at 6:18 AM Igor Korot wrote: > > > > > > Hi, Grant, > > > > > > On Tue, Jan 12, 2021 at 12:47 PM Grant Edwards > > > wrote: > > > > > > > > On 2021-01-12, Rich Shepard wrote: > > > > > On Tue, 12 Jan 2021, Igor Korot wrote: > > > > > > > > > >> Keep in mind that if you target Linux, the "modern" window server > > > > >> (Wayland) will not allow user code to decide the positioning and > > > > >> size of > > > > >> the TLW. > > > > > > > > > > Igor, > > > > > > > > > > I suspect that Slackware will continue with X11. > > > > > > > > And those X11 users will swear at you if you override their window > > > > managers configured window placement. Application code should not care > > > > about or try to control window geometry. Period. > > > > > > I have a very strong argument against it!! > > > > > > Imagine you are developing an application that need to communicate > > > with the database. > > > Also imagine this application will be used by millions of users inside > > > different companies. > > > > > > SInce the application will require DB access you will need a dialog to > > > ask for credentials. > > > > > > I, personally, would be very surprised if such dialog would appear > > > somewhere at the bottom of the screen, > > > as dialogs ARE TLWs (top level windows). > > > > > > Wouldn't you? > > > > Yes, I would too - because I have my window manager configured to > > place that dialog where *I* want it, not where the application > > developer chose to put it. > > So, how do *you* distinguish between such dialog and all other dialogs > an application might raise (open/save dialogs. font selection dialog, user > warning thing). > > Because with my scenario there are 2 TLWs in the picture - main frame and > dialog for credentials. > > Besides it looks like you are setting this dialog to appear at constant > position > anyway. Or am I missing smth? Hmm, maybe I'm missing something. The initial window isn't a "dialog", it's an application window. They follow slightly different rules (mainly, they don't have a parent window), but they still follow *rules*. > > > So why I somewhat agree with such a notion - it is not always a useful > > > feature. > > > Also, such an algorithm better allow me to save and restore the > > > geometry of the TLW. > > > > Why save and restore the geometry when the window manager can do a > > better job of positioning it? Give the WM the hints it needs, then let > > it figure out the placement. > > Because I want this application to appear at the same place every time? > The first time it shows I may just drag it away or minimize it at some point > or > make it very small to clear the space. > > And the next time I want it to start at the same position. And I find that most apps that behave this way end up being more annoying than not. > > Consider that the last time your window was opened, I might have had > > one 1366x768 monitor, but now I have four - 1920x1080, 1920x1080, > > 1280x1024, and 1600x900. Where should your dialog go? Not your > > problem, because my WM knows and understands. > > There is a notion of the "primary display" which is here for a reason. ;-) > So you can attach/detach as many monitors as you want - in the end if > the monitor is not available and that window will appear on the primary > monitor. In the second scenario, the primary monitor is at position (1920, 0). So you've just described exactly what a window manager does - follow rules to decide where the window appears - and NOT what happens if you remember geometry, which would be to put the window somewhere in the top left. You see the problem with remembering geometry? > > (That's actually a 100% realistic scenario, given that I'm usually on > > my desktop system, but occasionally I'll be on my laptop, SSH'd in > > with X11 forwarding.) > > Absolutely. > I found myself in this situation recently - when I'm in the office I > have 2 external > monitors, and when I am at home - I only have a laptop. > And windows are showing on the primary all the time. > Right! That's the WM's job. Let it do its job, and everyone's lives will be easier. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi, Chris, On Tue, Jan 12, 2021 at 1:33 PM Chris Angelico wrote: > > On Wed, Jan 13, 2021 at 6:18 AM Igor Korot wrote: > > > > Hi, Grant, > > > > On Tue, Jan 12, 2021 at 12:47 PM Grant Edwards > > wrote: > > > > > > On 2021-01-12, Rich Shepard wrote: > > > > On Tue, 12 Jan 2021, Igor Korot wrote: > > > > > > > >> Keep in mind that if you target Linux, the "modern" window server > > > >> (Wayland) will not allow user code to decide the positioning and size > > > >> of > > > >> the TLW. > > > > > > > > Igor, > > > > > > > > I suspect that Slackware will continue with X11. > > > > > > And those X11 users will swear at you if you override their window > > > managers configured window placement. Application code should not care > > > about or try to control window geometry. Period. > > > > I have a very strong argument against it!! > > > > Imagine you are developing an application that need to communicate > > with the database. > > Also imagine this application will be used by millions of users inside > > different companies. > > > > SInce the application will require DB access you will need a dialog to > > ask for credentials. > > > > I, personally, would be very surprised if such dialog would appear > > somewhere at the bottom of the screen, > > as dialogs ARE TLWs (top level windows). > > > > Wouldn't you? > > Yes, I would too - because I have my window manager configured to > place that dialog where *I* want it, not where the application > developer chose to put it. So, how do *you* distinguish between such dialog and all other dialogs an application might raise (open/save dialogs. font selection dialog, user warning thing). Because with my scenario there are 2 TLWs in the picture - main frame and dialog for credentials. Besides it looks like you are setting this dialog to appear at constant position anyway. Or am I missing smth? > > > So why I somewhat agree with such a notion - it is not always a useful > > feature. > > Also, such an algorithm better allow me to save and restore the > > geometry of the TLW. > > Why save and restore the geometry when the window manager can do a > better job of positioning it? Give the WM the hints it needs, then let > it figure out the placement. Because I want this application to appear at the same place every time? The first time it shows I may just drag it away or minimize it at some point or make it very small to clear the space. And the next time I want it to start at the same position. > > Consider that the last time your window was opened, I might have had > one 1366x768 monitor, but now I have four - 1920x1080, 1920x1080, > 1280x1024, and 1600x900. Where should your dialog go? Not your > problem, because my WM knows and understands. There is a notion of the "primary display" which is here for a reason. ;-) So you can attach/detach as many monitors as you want - in the end if the monitor is not available and that window will appear on the primary monitor. > > (That's actually a 100% realistic scenario, given that I'm usually on > my desktop system, but occasionally I'll be on my laptop, SSH'd in > with X11 forwarding.) Absolutely. I found myself in this situation recently - when I'm in the office I have 2 external monitors, and when I am at home - I only have a laptop. And windows are showing on the primary all the time. Thank you. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Wed, Jan 13, 2021 at 6:18 AM Igor Korot wrote: > > Hi, Grant, > > On Tue, Jan 12, 2021 at 12:47 PM Grant Edwards > wrote: > > > > On 2021-01-12, Rich Shepard wrote: > > > On Tue, 12 Jan 2021, Igor Korot wrote: > > > > > >> Keep in mind that if you target Linux, the "modern" window server > > >> (Wayland) will not allow user code to decide the positioning and size of > > >> the TLW. > > > > > > Igor, > > > > > > I suspect that Slackware will continue with X11. > > > > And those X11 users will swear at you if you override their window > > managers configured window placement. Application code should not care > > about or try to control window geometry. Period. > > I have a very strong argument against it!! > > Imagine you are developing an application that need to communicate > with the database. > Also imagine this application will be used by millions of users inside > different companies. > > SInce the application will require DB access you will need a dialog to > ask for credentials. > > I, personally, would be very surprised if such dialog would appear > somewhere at the bottom of the screen, > as dialogs ARE TLWs (top level windows). > > Wouldn't you? Yes, I would too - because I have my window manager configured to place that dialog where *I* want it, not where the application developer chose to put it. > So why I somewhat agree with such a notion - it is not always a useful > feature. > Also, such an algorithm better allow me to save and restore the > geometry of the TLW. Why save and restore the geometry when the window manager can do a better job of positioning it? Give the WM the hints it needs, then let it figure out the placement. Consider that the last time your window was opened, I might have had one 1366x768 monitor, but now I have four - 1920x1080, 1920x1080, 1280x1024, and 1600x900. Where should your dialog go? Not your problem, because my WM knows and understands. (That's actually a 100% realistic scenario, given that I'm usually on my desktop system, but occasionally I'll be on my laptop, SSH'd in with X11 forwarding.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi, Rich, On Tue, Jan 12, 2021 at 12:52 PM Rich Shepard wrote: > > On Tue, 12 Jan 2021, Igor Korot wrote: > > > Maybe. :-) > > But it looks Wayland becomes more and more popular. > > Igor, > > What I've read from those struggling to use Wayland, it may turn out to be a > popular as systemd. :-) > > It's important to remember that while all progress involves change, not all > change involves progress. 200% agree. See my reply to Grant. Thank you. > > Regards, > > Rich > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi, Grant, On Tue, Jan 12, 2021 at 12:47 PM Grant Edwards wrote: > > On 2021-01-12, Rich Shepard wrote: > > On Tue, 12 Jan 2021, Igor Korot wrote: > > > >> Keep in mind that if you target Linux, the "modern" window server > >> (Wayland) will not allow user code to decide the positioning and size of > >> the TLW. > > > > Igor, > > > > I suspect that Slackware will continue with X11. > > And those X11 users will swear at you if you override their window > managers configured window placement. Application code should not care > about or try to control window geometry. Period. I have a very strong argument against it!! Imagine you are developing an application that need to communicate with the database. Also imagine this application will be used by millions of users inside different companies. SInce the application will require DB access you will need a dialog to ask for credentials. I, personally, would be very surprised if such dialog would appear somewhere at the bottom of the screen, as dialogs ARE TLWs (top level windows). Wouldn't you? So why I somewhat agree with such a notion - it is not always a useful feature. Also, such an algorithm better allow me to save and restore the geometry of the TLW. Thank you. > > -- > Grant > > > > > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Tue, 12 Jan 2021, Grant Edwards wrote: And those X11 users will swear at you if you override their window managers configured window placement. Application code should not care about or try to control window geometry. Period. Grant, Since this application is my own business use those users can swear all they want. :-) If I decide to post all the code on github other can modify it to their heart's delight. They can even make it work on their wrist computer (formerly known as a wrist watch.) Regards, Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Tue, 12 Jan 2021, Igor Korot wrote: Maybe. :-) But it looks Wayland becomes more and more popular. Igor, What I've read from those struggling to use Wayland, it may turn out to be a popular as systemd. :-) It's important to remember that while all progress involves change, not all change involves progress. Regards, Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On 2021-01-12, Rich Shepard wrote: > On Tue, 12 Jan 2021, Igor Korot wrote: > >> Keep in mind that if you target Linux, the "modern" window server >> (Wayland) will not allow user code to decide the positioning and size of >> the TLW. > > Igor, > > I suspect that Slackware will continue with X11. And those X11 users will swear at you if you override their window managers configured window placement. Application code should not care about or try to control window geometry. Period. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
In comp.lang.python, Rich Shepard wrote: >> Keep in mind that if you target Linux, the "modern" window server >> (Wayland) will not allow user code to decide the positioning and size of > I suspect that Slackware will continue with X11. Even with traditional X11, geometry is "preferred" size and position[*], not a requirement. Window managers have always been able to override that if desired, and tiling window managers make that override a feature. There might not be a tiling window manager in Slack's standard packages, but there sure are in Slackbuilds. Elijah -- [*] See GEOMETRY SPECIFICATIONS in "man X" -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi, On Tue, Jan 12, 2021, 11:44 AM Rich Shepard wrote: > On Tue, 12 Jan 2021, Igor Korot wrote: > > > Keep in mind that if you target Linux, the "modern" window server > > (Wayland) will not allow user code to decide the positioning and size of > > the TLW. > > Igor, > > I suspect that Slackware will continue with X11. > Maybe. :-) But it looks Wayland becomes more and more popular. Thank you. > Rich > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Tue, 12 Jan 2021, Igor Korot wrote: Keep in mind that if you target Linux, the "modern" window server (Wayland) will not allow user code to decide the positioning and size of the TLW. Igor, I suspect that Slackware will continue with X11. Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier [RESOLVED]
On Wed, 13 Jan 2021, Chris Angelico wrote: Do the offsets need to be integers? ChrisA, Yep. I totally missed that. Thanks for seeing it. Stay well, Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
Hi,
On Tue, Jan 12, 2021 at 10:47 AM Chris Angelico wrote:
>
> On Wed, Jan 13, 2021 at 3:38 AM Rich Shepard wrote:
> >
> > I want my application's window (main frame) to open centered on the
> > monitor's screen.
Keep in mind that if you target Linux, the "modern" window server (Wayland)
will not allow user code to decide the positioning and size of the TLW.
Instead some renderer will make the decision for you and place it appropriately.
So you may re-think that design. ;-)
Thank you.
>> This code:
> > # open application centered on screen; set window width and height
> > self.appwidth = 600
> > self.appheight = 500
> > # get screen width and height
> > self.scrwidth = self.winfo_screenwidth()
> > self.scrheight = self.winfo_screenheight()
> > # formula to find screen center
> > self.xLeft = (self.scrwidth/2) - (self.appwidth/2)
> > self.yTop = (self.scrheight/2) - (self.appheight/2)
> > # set geometry
> > self.geometry(str(self.appwidth) + "x" + str(self.appheight) +
> >"+" + str(self.xLeft) + "+" + str(self.yTop))
> >
> > generates this error when run:
> > File "/usr/lib64/python3.9/tkinter/__init__.py", line 2036, in wm_geometry
> > return self.tk.call('wm', 'geometry', self._w, newGeometry)
> > _tkinter.TclError: bad geometry specifier "600x500+340.0+262.0"
> >
> > As the geometry string represents window width times window height plus
> > x-offset
> > plus y-offset I'm not seeing my error.
> >
>
> Do the offsets need to be integers?
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Wed, Jan 13, 2021 at 3:38 AM Rich Shepard wrote:
>
> I want my application's window (main frame) to open centered on the
> monitor's screen. This code:
> # open application centered on screen; set window width and height
> self.appwidth = 600
> self.appheight = 500
> # get screen width and height
> self.scrwidth = self.winfo_screenwidth()
> self.scrheight = self.winfo_screenheight()
> # formula to find screen center
> self.xLeft = (self.scrwidth/2) - (self.appwidth/2)
> self.yTop = (self.scrheight/2) - (self.appheight/2)
> # set geometry
> self.geometry(str(self.appwidth) + "x" + str(self.appheight) +
>"+" + str(self.xLeft) + "+" + str(self.yTop))
>
> generates this error when run:
> File "/usr/lib64/python3.9/tkinter/__init__.py", line 2036, in wm_geometry
> return self.tk.call('wm', 'geometry', self._w, newGeometry)
> _tkinter.TclError: bad geometry specifier "600x500+340.0+262.0"
>
> As the geometry string represents window width times window height plus
> x-offset
> plus y-offset I'm not seeing my error.
>
Do the offsets need to be integers?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Application window geometry specifier
I want my application's window (main frame) to open centered on the
monitor's screen. This code:
# open application centered on screen; set window width and height
self.appwidth = 600
self.appheight = 500
# get screen width and height
self.scrwidth = self.winfo_screenwidth()
self.scrheight = self.winfo_screenheight()
# formula to find screen center
self.xLeft = (self.scrwidth/2) - (self.appwidth/2)
self.yTop = (self.scrheight/2) - (self.appheight/2)
# set geometry
self.geometry(str(self.appwidth) + "x" + str(self.appheight) +
"+" + str(self.xLeft) + "+" + str(self.yTop))
generates this error when run:
File "/usr/lib64/python3.9/tkinter/__init__.py", line 2036, in wm_geometry
return self.tk.call('wm', 'geometry', self._w, newGeometry)
_tkinter.TclError: bad geometry specifier "600x500+340.0+262.0"
As the geometry string represents window width times window height plus x-offset
plus y-offset I'm not seeing my error.
Please show me what's wrong with specifier.
TIA,
Rich
--
https://mail.python.org/mailman/listinfo/python-list
