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: A beginning beginner's question about input, output and . . .
On 2021-01-11 20:37, DonK wrote: [snip] So, what do you folks use Python for? Since we're sharing: - Personal information manager in the form of a tree of pages. Each page can have code associated with it which defines functions to call when shortcut keys are pressed, giving page-specific shortcuts for page-specific functionality. - Simple money manager. Both use tkinter. -- 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: A beginning beginner's question about input, output and . . .
On 12/01/2021 10.40, Michael F. Stemper wrote: Modeling of electric power systems: - load behavior in response to conservation load reduction Sorry, that should have been "conservation voltage reduction". -- Michael F. Stemper Psalm 82:1-4 -- 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
argparse presence of switch
Its what I searched for on this group.
I want to have an argument's presence only - value is not required.
For example, my program main.py needs to know if "-r" is present when program
is invoked.
So the value command line would be:
(1) python3 main.py -r
or...
(1) python3 main.py
I tried following:
parser.add_argument('-r','--register', help='Register it')
Since argument started with "-" it should be optional, but absence of it causes
following error:
main.py: error: argument -r/--register: expected one argument
I added
parser.add_argument('-r','--register', default=None, help='Register it')
No avail - same error.
If I apply -r on the command line, it still expects a value!
Not sure what should I do?
Any help appreciated-
Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
[ANN] Austin -- CPython frame stack sampler v2.1.1 is now available
I am delighted to announce the release 2.1.1 of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straight away, even while it's running on a production environment, with minimal impact on performance. The simplest way of using Austin is by piping its output to FlameGraph or uploading it to speedscope.app for a quick and detailed representation of the collected samples. Austin is a pure C application that has no other dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. Austin can be installed easily on the following platforms and from the following sources: Linux: - Snap Store - Debian repositories - Conda Forge macOS: - Homebrew - Conda Forge Windows: - Chocolatey - Scoop Austin is also simple to compile from sources as it only depends on the standard C library, if you don't have access to the above-listed repositories. This new release of Austin brings enhanced support for many Python binary distributions across all the supported platforms, as well as a bugfix for the line number reporting. If you rely on Austin 2, upgrading to the latest version is strongly recommended. Let me also remind you of some of the other existing Python tools powered by Austin, which have also seen new releases in the past few days, and that are easily available from PyPI: https://github.com/P403n1x87/austin-tui https://github.com/P403n1x87/austin-web https://github.com/P403n1x87/pytest-austin These tools are built using the austin-python library, which is also available from PyPI, with source code hosted at https://github.com/P403n1x87/austin-python For anyone wishing to build their own Austin-powered tools, the austin-python documentation is hosted on RTD at https://austin-python.readthedocs.io/en/latest/ You can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler). All the best, Gabriele https://github.com/P403n1x87/austin";>Austin 2.1.1 - frame stack sampler for CPython. (12-Jan-21) -- https://mail.python.org/mailman/listinfo/python-list
Re: argparse presence of switch
On Wed, Jan 13, 2021 at 5:01 AM Dhimant Patel wrote:
>
> Its what I searched for on this group.
>
> I want to have an argument's presence only - value is not required.
> For example, my program main.py needs to know if "-r" is present when program
> is invoked.
> So the value command line would be:
> (1) python3 main.py -r
> or...
> (1) python3 main.py
>
> I tried following:
> parser.add_argument('-r','--register', help='Register it')
>
> Since argument started with "-" it should be optional, but absence of it
> causes following error:
>
> main.py: error: argument -r/--register: expected one argument
This is what different actions are for. I'd probably use
action="store_true" here; that should mean that args.register will be
set to True if "-r" was passed, or False if it wasn't.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: argparse presence of switch
> I want to have an argument's presence only - value is not required.
> For example, my program main.py needs to know if "-r" is present when program
> is invoked.
> So the value command line would be:
> (1) python3 main.py -r
> or...
> (1) python3 main.py
>
> I tried following:
> parser.add_argument('-r','--register', help='Register it')
You should use the "store_true" action, or perhaps some other action.
A complete minimal working sample is as follows.
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("-r", "--register", help="Register it",
action="store_true")
args = parser.parse_args()
if args.register:
print("Seen register")
For more, I suggest reading the quick tutorial in the documentation,
available at https://docs.python.org/3/howto/argparse.html#id1
Good luck! - DLD
--
https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 2021-01-12, Chris Angelico wrote: > On Wed, Jan 13, 2021 at 3:18 AM Grant Edwards > wrote: >> >> On 2021-01-12, songbird wrote: >> >> > it can be used for pretty much anything except perhaps >> > high pressure real time things, but i bet someone else will >> > know that is being done too, i've just not heard of it. :) >> >> AFAIK, Python can't be used to write device drivers for any popular OS >> (Linux, Unix, Windows, OSX). It also can't be used on small embedded >> systems (real-time or not). > > Depends how small. Of course. > An RPi has a full Linux system and can easily run Python scripts; > and the pyboard runs a dedicated Python interpreter called > MicroPython, broadly compatible with CPython 3.5, I think (some 3.x > version, anyhow), albeit with a cut-down standard library. The > pyboard is pretty tiny; according to the micropython.org blurb, it > has 192KB RAM. Yes, that's tiny compared to the desktop machine I'm posting from, but I work with ARM parts (that are in active production production and not EOL) with 2KB of RAM and 8KB of flash. -- 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
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: A beginning beginner's question about input, output and . . .
On Tue, Jan 12, 2021 at 7:41 AM DonK wrote: > So, what do you folks use Python for? > Since everyone else is, I'll add my list. * API lookups of various sorts (usually via HTTP requests) * Audio analysis. Calculate the maximum and average volume of each of many songs. * Code generation. The audio analysis output is in the form of a Lua script (a VLC extension); also I have Python scripts that generate SourcePawn code for CS:GO integration, and various other things. * Decoding and analyzing myriad formats of files, including Borderlands save files (now which character had that level 62 legendary weapon I wanted...) * Mathematical analysis and testing. Python has excellent arithmetical and higher mathematical tools. * Automated tidying up of files to eliminate spurious diffs (eg with OBS Studio's config files) * Web apps involving PostgreSQL databases, various API calls, etc, etc * Financial calculations - parse the downloaded transactions files from my bank, correlate with my client list, automatically mark invoices as paid * Command-line calculator - pressing Ctrl-Alt-P will open up a terminal with Python, and that's the normal way that I do quick calculations * And a ton of quick one-off scripts for a wide variety of jobs. Python's one of my favourite languages, and I use it a lot :) ChrisA -- 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
Binding menu accelerator to a callback
Menu options work from the menu, but not from the accelerator associated with that menu item. My research suggests that while 'command' works for the menu item, 'bind' is required for the associated accelerator. For example, File -> Quit is defined this way: self.file_menu.add_command( label="Quit", command=self.fileQuit, underline=0, accelerator='Ctrl+Q' ) and works when I pull down the File menu and click on 'Quit.' I want to modify the menu items so the accelerator is bound to the same self.fileQuit() (in this case). My web research hasn't found a solution since examples for using bind() aren't in menus. Do I need another method that associates accelerators with the callbacks? Rich -- 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
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
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
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, 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: A beginning beginner's question about input, output and . . .
On 12Jan2021 15:18, Grant Edwards wrote: >On 2021-01-12, songbird wrote: >> it can be used for pretty much anything except perhaps >> high pressure real time things, but i bet someone else will >> know that is being done too, i've just not heard of it. :) > >AFAIK, Python can't be used to write device drivers for any popular OS >(Linux, Unix, Windows, OSX). It also can't be used on small embedded >systems (real-time or not). Well, yes and no. Not a pure device driver. But there are systems like FUSE for hooking kernel level filesystem stuff to an external system programme. I've used the Python llfuse library to implement a filesystem in Python. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 12Jan2021 10:40, Michael F. Stemper wrote: >On 11/01/2021 14.37, DonK wrote: >>I've installed Python 3.7, the PyCharm IDE and watched some Youtube >>tutorials > >I would suggest that instead of watching tutorials, you open up your IDE >and start writing stuff. I would second that. Maybe this is a congnitive shortcoming on my part, but I find videos not useful for learning new programming. What they are great for is seeing explicit examples of something you are doing, particular if you hit some block and need to see someone _do_ what you're failing to do. They're great for physical repair though, which again is an explicit example of a particular fixed task. Repaired our stand mixer with reference to a good video. Would not want to use a video to learn the theory of stand mixer design. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
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: A beginning beginner's question about input, output and . . .
On 2021-01-12, Chris Angelico wrote: > * Command-line calculator - pressing Ctrl-Alt-P will open up a > terminal with Python, and that's the normal way that I do quick > calculations I do that a lot too. -- Grant -- 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 especial
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
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 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: argparse presence of switch
On 13/01/21 7:13 am, Chris Angelico wrote: This is what different actions are for. I'd probably use action="store_true" here; that should mean that args.register will be set to True if "-r" was passed, or False if it wasn't. Yes, otherwise it expects another argument following -r containing a value. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 13/01/21 4:18 am, Grant Edwards wrote: AFAIK, Python can't be used to write device drivers for any popular OS At least not until some crazy person embeds Python in the Linux kernel... -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
Am 13.01.21 um 06:24 schrieb Greg Ewing: On 13/01/21 4:18 am, Grant Edwards wrote: AFAIK, Python can't be used to write device drivers for any popular OS At least not until some crazy person embeds Python in the Linux kernel... What do you mean, "until" ? https://medium.com/@yon.goldschmidt/running-python-in-the-linux-kernel-7cbcbd44503c http://www.kplugs.org/ Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 2021-01-11, DonK wrote: > So, what do you folks use Python for? I mainly use it for writing command-line utilities. Many of them work on either Windows or Linux, but are mostly used on Linux: * Two-pass symbolic assembler and dissassembler for a proprietary communications controller. * Utilties to encrypt/decrypt files in proprietary formats. * Protocol dissector that prints the contents of network traffic for a couple different proprietary protocols. It will parse a file saved with Wireshark/tcpdump or it will display live traffic using libpcap. * A utility to discover and manage a couple different families of industrial products (discovery, configiration) using a proprietary UDP protocol. * Utilities to program firmware into various products and microprocessors. * Utilities to perform various operations (e.g. run-length encoding) on things like FPGA bitstream files. * Utilities that implement various serial protocols for testing devices that use those protocols. * Scraping my favorite comic strips from various web sites and compiling them into a local web page. * Utilties for working with industrial control devices using DeviceNet on CAN bus. * An email gateway daemon that accepted SMTP mail and relayed it to MS Exchange using WebDAV. * An email gateway daemon that fetched email from MS Exchnage using Outlook/DCOM and relayed to an SMTP server. * Custom SMTP servers used to test SMTP clients. I also wire the occasional GUI application: * A GTK "terminal" application that connects to a serial port. * A GTK IMAP mailbox notification app that monitors any number of IMAP mailboxes and notifies the user when there is new mail. * WxWindows and Tk applications to do various device management tasks for industrial equipment (update firmware, change configurations, etc.) via TCP and UDP network protocols. * WxWindows utilities for working with industrial control devices using DeviceNet on CAN bus. I've also written web "backend" code that gathers and archives data from my solar panels every 10 minutes and then produces graphs and charts on demand for AJAX web applications. Where I work we also use Python to run our production stations -- testing and programming circuit boards and assembled products. There are also a couple commercial applicatoins I use daily (but didn't write) that are written in Python: Hiri (email client) Plex (DVR and home theater application) -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 2021-01-12, songbird wrote: > it can be used for pretty much anything except perhaps > high pressure real time things, but i bet someone else will > know that is being done too, i've just not heard of it. :) AFAIK, Python can't be used to write device drivers for any popular OS (Linux, Unix, Windows, OSX). It also can't be used on small embedded systems (real-time or not). -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On Wed, Jan 13, 2021 at 3:18 AM Grant Edwards wrote: > > On 2021-01-12, songbird wrote: > > > it can be used for pretty much anything except perhaps > > high pressure real time things, but i bet someone else will > > know that is being done too, i've just not heard of it. :) > > AFAIK, Python can't be used to write device drivers for any popular OS > (Linux, Unix, Windows, OSX). It also can't be used on small embedded > systems (real-time or not). > Depends how small. An RPi has a full Linux system and can easily run Python scripts; and the pyboard runs a dedicated Python interpreter called MicroPython, broadly compatible with CPython 3.5, I think (some 3.x version, anyhow), albeit with a cut-down standard library. The pyboard is pretty tiny; according to the micropython.org blurb, it has 192KB RAM. 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
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
Re: A beginning beginner's question about input, output and . . .
On 11/01/2021 14.37, DonK wrote: I've installed Python 3.7, the PyCharm IDE and watched some Youtube tutorials I would suggest that instead of watching tutorials, you open up your IDE and start writing stuff. Get an introductory python book (I used the O'Reilly _Introducing Python_), start at the beginning, and type in each example. Then, tweak it to see what happens. I've seen some Python gui frameworks like Tkinter, PyQt, etc. but they look kinda like adding a family room onto a 1986 double wide mobile home, and they look even more complicated than creating a GUI from scratch in C++ with a message loop, raising events . . . I haven't really got my head around GUI programming myself. I tried to write one with tkinter based on on-line examples, but didn't have any conceptual framekwork, so it didn't work too well. I saw in a post here that there are actually books on it, so I might pick one up and try again. So, what do you folks use Python for? Since you asked: Various command-line utilities, including: - comparing the contents of two directories - ad-hoc linear regression - validation of DTDs - sanity check of nesting symbols in TeX files - ad-hoc plotting Maintaining and querying of data bases: - five-minute values of local temperatures - Action items for an organization of which I'm secretary - my own to-do list - non-isomorphic groups that have isomorphic character tables Modeling of electric power systems: - load behavior in response to conservation load reduction - generator and governor response to system load - economic dispatch of generators, including those with non-monotonic incremental cost curves (last two are very much works in progress) Mathematics: - experiments with number theory and combinatorics - composition of permutations of a set - properties of minimal paths through a C_m x C_n lattice - generating tikz commands for geometric diagrams in TeX documents - unstructured and uneducated exploration of Conway's Game of Life -- Michael F. Stemper 2 Chronicles 19:7 -- 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
