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: count consecutive elements
On 2021-01-13 18:20, Dan Stromberg wrote:
> I'm kind of partial to:
>
> import collections
> import typing
>
>
> def get_longest(string: str) -> typing.Tuple[int, str]:
> """Get the longest run of a single consecutive character."""
> dict_: typing.DefaultDict[str, int] =
> collections.defaultdict(int) for left_ch, right_ch in zip(string,
> string[1:]): if left_ch == right_ch:
> dict_[left_ch] += 1
>
> maximum = max((value, key) for key, value in dict_.items())
>
> return maximum
seems to only return one value so seems to get odd results if I
specify something like
get_longest("aaabcccbbb")
which at least here tells me that "c" is the longest run, even though
aaa, bbb, and ccc are all runs of length 3. The OP didn't specify
what should happen in that case, so it would need some clarification.
-tkc
--
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: count consecutive elements
On Wed, Jan 13, 2021 at 5:59 PM Tim Chase wrote: > On 2021-01-13 21:20, Bischoop wrote: > > I want to to display a number or an alphabet which appears mostly > > consecutive in a given string or numbers or both > > Examples > > s= ' aabskaaabad' > > output: c > > # c appears 4 consecutive times > > 8bbakebaoa > > output: b > > #b appears 2 consecutive times > I'm kind of partial to: import collections import typing def get_longest(string: str) -> typing.Tuple[int, str]: """Get the longest run of a single consecutive character.""" dict_: typing.DefaultDict[str, int] = collections.defaultdict(int) for left_ch, right_ch in zip(string, string[1:]): if left_ch == right_ch: dict_[left_ch] += 1 maximum = max((value, key) for key, value in dict_.items()) return maximum HTH -- 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: count consecutive elements
On 2021-01-13 21:20, Bischoop wrote:
> I want to to display a number or an alphabet which appears mostly
> consecutive in a given string or numbers or both
> Examples
> s= ' aabskaaabad'
> output: c
> # c appears 4 consecutive times
> 8bbakebaoa
> output: b
> #b appears 2 consecutive times
I'd break the problem into two parts:
1) iterate over your thing (in this case, a string) and emit the item
and its correpsonding count of consecutive matches.
2) feed that into something that finds the longest run(s) output by
that.
So off the cuff, something like
def consecutive_counter(seq):
# I'm not sure if there's something
# like this already in itertools
cur = nada = object()
count = 0
for x in seq:
if x == cur:
count += 1
else:
if cur is not nada:
yield cur, count
cur = x
count = 1
if cur is not nada:
yield cur, count
def longest(seq):
results = []
biggest = 0
for item, count in seq:
if count > biggest:
results = [item]
biggest = count
elif count == biggest:
results.append(item)
return results, biggest
for s in (
"",
"a",
"aaa",
"aaabbb",
"aabskaaabad",
"aabskaaakbad",
):
print("Testing %r" % s)
print(repr(longest(consecutive_counter(s
-tkc
--
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: A beginning beginner's question about input, output and . . .
On 14/01/21 11:09 am, Grant Edwards wrote: Perhaps I need to recalibrate my adjectives, but with 256KB+ of flash and 32KB+ of RAM, I wouldn't call them "small" It's small by today's standards, when you consider that multiple GB of RAM is commonplace now in most "real" computers. -- Greg -- 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: A beginning beginner's question about input, output and . . .
On 13/01/21 7:57 pm, Christian Gollwitzer wrote: What do you mean, "until" ? https://medium.com/@yon.goldschmidt/running-python-in-the-linux-kernel-7cbcbd44503c He's using Micropython. That's cheating! :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: count consecutive elements
On 2021-01-13, Bischoop wrote: > t = set(s) # set of characters in s I have this one changed to: t= list(set(s)) -- https://mail.python.org/mailman/listinfo/python-list
Re: FridayFinking - Was: A beginning beginner's question about input, output and . . .
On Thu, 14 Jan 2021, dn via Python-list wrote: Concerning the definition of "old" - when I'm having a 'good day', it's anyone several years my senior (and above) - when I'm creaking and groaning, it's anyone remotely my age, and older. About 45 years ago a 25-year-older friend of mine offered a great philosophy of life. "We can do nothing about growing older," she told me, "but we can do everything about growing old." How true. Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 2021-01-13, Peter Pearson wrote: > On Mon, 11 Jan 2021 15:37:58 -0500, DonK > wrote: > [snip] >> >> 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, > > Agreed. > > Browsergui is not widely popular (I don't think anybody but me has > mentioned it on this newsgroup), but it was written to be simple and > Pythonic, and has served me well. Browsergui just uses your browser as > its user interface. Grab it from > > https://github.com/speezepearson/browsergui I've been browsing through to documentation and examples, and I don't see any way to do any sort of modern flexible layout (e.g. nesting horizontal and vertical flexboxes) where you can control which elements grow/shrink when the window size changes. Is there a way to span columns/rows in a grid or control which columns grow/shrink? Have I missed something? -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 2021-01-13, Dennis Lee Bieber wrote: > On Tue, 12 Jan 2021 15:18:05 - (UTC), Grant Edwards > declaimed the following: >>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). > > MicroPython/Circuit Python. Native language for AdaFruit's Metro > boards. Those are very cool, and I've come this -><- close to ordering one in the past. Perhaps I need to recalibrate my adjectives, but with 256KB+ of flash and 32KB+ of RAM, I wouldn't call them "small" -- even though the Trinket M0 is physically tiny. But that may just be my age showing. I remember not _that_ long ago working on processors where the RAM was measured in hundreds of bytes. And I still maintain code for ARM parts with way less than 1/10 the memory of the Trinket M0. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
count consecutive elements
I want to to display a number or an alphabet which appears mostly consecutive in a given string or numbers or both Examples s= ' aabskaaabad' output: c # c appears 4 consecutive times 8bbakebaoa output: b #b appears 2 consecutive times I thought about set the string then and for each element loop the string to check if equal with element set element if so count =+1 and check if next to it is not equal add counter value to list with same index as in set. However I'm fighting to code it and the counting numbers are not right: s = 'aabskaaabad' c = 0 t = set(s) # set of characters in s li=[0,0,0,0,0,0] # list for counted repeats for x in t: h = t.index(x) for i in s: if i == x: m = s.index(i) c +=1 if s[m+1] != x: # if next element is not x if c > li[h]: li[h]= c c = 0 for i in t: n = t.index(i) print(i,li[n]) -- Thanks -- https://mail.python.org/mailman/listinfo/python-list
FridayFinking - Was: A beginning beginner's question about input, output and . . .
On 14/01/2021 04.54, Grimble wrote: > On 11/01/2021 20:37, DonK wrote: >> >> Hi, I'm thinking about learning Python but I'm 74 years old and will >> very likely not ever have a programming job again. > At 83, I have no intention of having a programming job again! I last > coded something professionally 45 years ago, but it hasn't lost its > attraction. Hey, some 'silver surfers' who have a few years on me! Concerning the definition of "old" - when I'm having a 'good day', it's anyone several years my senior (and above) - when I'm creaking and groaning, it's anyone remotely my age, and older. Of course, many of my colleagues have fairly similar understandings - for them anyone with the digit "3" (or greater) at the front of their age, is not so much old (saying that would be rude!), but "ancient"! That said, such young-bucks wrestling with cloud-concepts today, were totally nonplussed when I told them how (mainframe) computer bureaux used to work. The 'mechanics' may be different, but the management is little-changed! ... > I find this a fascinating news group - shame there's been no updates to > Friday Finking recently! With all due apologies! I work(ed) with a particular team in a mentoring rôle, handling reviews, walk-throughs, some design meetings, Python version-upgrades coaching, etc. One of these was a 'morning tea' meeting, when we would discuss/debate/argue 'Python best practice' topics, either raised by members or that arose from other meetings but were best not discussed there-and-then. If there was an interesting topic, or one that 'we' hadn't really settled satisfactorily within the group, I would try to re-frame the discussion, and consult 'the oracles' here. So, that's the raison d'être and motivation of the "Friday Finking" series.. Then along came COVID-19, and although this country's response was amongst the best in the world, the team (and its routines) all-but fell-apart. Firstly, we had to adjust to working remotely. The effort that went into 'Friday Finking' was quickly absorbed into figuring-out remote-techniques and maintaining the social component of the team's success. Then a bunch of us were 'released to other duties' and landed-in high-pressure projects to do with modelling pandemic response-options. Various other interventions, life moved-on, etc, etc - stories familiar to most, I'm sure. So, thank you for the gentle reminder. Even though that team is still not meeting as it once did, there's plenty of other 'inspiration', eg a parallel discussion 'here' about the virtues of a programmer positioning dialog(ue)s/windows or leaving it to the window manager... I'll give it some thought - as long as Fridays keep coming! -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: learning python building 2nd app, need advices
Loris Bennett wrote:
> As an Emacs user, personally I would use the command
>
> M-x untabify
>
> within Emacs. I assume that Vim has something similar.
It does. ':retab' is what you want. If you have tabstop set to a
specific value, it'll use that. If not, you can do ':retab ',
where is an integer defining how many spaces to replace a tab
with.
Don't add the quote symbols ('), I added it for readability!
As others have mentionned, 'expand' from the shell also works.
Phil
--
AH#61 Wolf#14 BS#89 bus#1 CCB#1 SENS KOTC#4
ph...@philb.ca http://philb.ca
--
https://mail.python.org/mailman/listinfo/python-list
Re: conceptual problem (was: A beginning beginner's question about input, output and . . .
On 13Jan2021 10:37, songbird wrote: > my momentary conceptual problem is that to me OOP means >being able to encapsulate data structures and code from >other parts of the program, but to me it doesn't look like >that is how python is designed. this is probably a complete >aside to this whole thread and perhaps even this newsgroup >so i'll subthread this. Python allows you to avoid mucking with the object internals from outside. But it doesn't prevent it. So you can (and often should) adopt an OOP approach - it reduces the dependencies between your classes, with the benefits that brings. The "pure" OOP approach, where method calls are used as messages to set or fetch aspects of the object, is usually does with getter and setter methods like: x = o.getX() o.setX(9) In Python this is less common. Simple things like that which do not intrude much on the conceptual model (i.e. if all such things will have an "X") are usually exposed as a public attribute which you can get or set directly: x = o.x o.x = 9 "Public" attributes in Python are just a convention: we name "private" attributes with a leading underscore and "public" attributes with leading letters and expect people using our classes to behave well. Sometime we _don't_ have a plain old attribute "x", but we do have a property of the object looking like it. Then you can implement something which looks like an attribute from outside: @property def x(self): # "x" if a derived value return self._a + self._b @x.setter def x(self, new_x): # setting "x" gets split between _a and _b x2 = x / 3 self._a = x2# put some in _a self._b = x - x2# put the rest in _b # you can still do this, but it calls methods now x = o.x o.x = 9 So Python supports OOP practices but doesn't enforce them. Adopt the degree of discipline you think best. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On Mon, 11 Jan 2021 15:37:58 -0500, DonK wrote: [snip] > > 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, Agreed. Browsergui is not widely popular (I don't think anybody but me has mentioned it on this newsgroup), but it was written to be simple and Pythonic, and has served me well. Browsergui just uses your browser as its user interface. Grab it from https://github.com/speezepearson/browsergui then run "python -m browsergui.examples". (Disclaimer/boast: I'm related to Browsergui's author.) -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
Christian Gollwitzer wrote: > 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/ yes! haha! :) love it! wish i had time to play now. songbird -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 11/01/2021 20:37, DonK wrote: Hi, I'm thinking about learning Python but I'm 74 years old and will very likely not ever have a programming job again. At 83, I have no intention of having a programming job again! I last coded something professionally 45 years ago, but it hasn't lost its attraction. So, what do you folks use Python for? I have several scripts to help with activities for the charity that keeps me occupied. I've written a shopping list script with auto-completion and a couple of web-scraping applications that support a weather reporting application interfacing with various 1Wire sensors transcribed from an initial Ruby application. My largest GUI application is a database of personal contacts with input and output of data via vCards and .csv files (with a lot of mentoring from an American Gtk user!) I find this a fascinating news group - shame there's been no updates to Friday Finking recently! -- Grimble Registered Linux User #450547 Machine 'Bach' running Plasma 5.15.4 on 5.7.19-desktop-3.mga7 kernel. Mageia release 7 (Official) for x86_64 -- https://mail.python.org/mailman/listinfo/python-list
conceptual problem (was: A beginning beginner's question about input, output and . . .
Chris Angelico wrote: ...projects that fade... > That's not really something Python can ever control, but I can say > with some confidence that the big libraries like Qt and GTK are going > to adapt, one way or another. And perhaps more importantly: Neither > input()/print() nor web applications is going *anywhere*. You are > ALWAYS going to have those two as options. :) i hope so. :) at the moment i've only done things with GTK and pyglet. since i am way too new at python i can't say the code is pretty, but it does work. my momentary conceptual problem is that to me OOP means being able to encapsulate data structures and code from other parts of the program, but to me it doesn't look like that is how python is designed. this is probably a complete aside to this whole thread and perhaps even this newsgroup so i'll subthread this. songbird -- https://mail.python.org/mailman/listinfo/python-list
Re: A beginning beginner's question about input, output and . . .
On 11/01/2021 20:37, DonK wrote: So, what do you folks use Python for? I've written a shopping list script with auto-completion and a couple of web-scraping applications that support a weather reporting application interfacing with various 1Wire sensors transcribed from an initial Ruby application. My largest GUI application is a database of personal contacts with input and output of data via vCards and .csv files (with a lot of mentoring from an American Gtk user!) I find this a fascinating news group - shame there's been no updates to Friday Finking recently -- Grimble Registered Linux User #450547 Machine 'Bach' running Plasma 5.15.4 on 5.7.19-desktop-3.mga7 kernel. Mageia release 7 (Official) for x86_64 -- https://mail.python.org/mailman/listinfo/python-list
