On Jan 18, 6:36 pm, rantingrick <rantingr...@gmail.com> wrote: On Jan 18, 4:57 pm, Adam Skutt <ask...@gmail.com> wrote: > On Jan 18, 4:45 pm, Arndt Roger Schneider <arndt.ro...@addcom.de> > > > E.g. a button is: > > > A function gets asychnronously performed in response to > > > a finger/mouse click and release inside a certain screen area. > > No, that is not the definition of a 'button', not even when we choose > > to ignore how it is rendered, which you cannot ignore even if you wish > > to pretend you can. Otherwise, I could always treat hyperlinks and > > buttons as equivalent and even interchangeable. Unfortunately, they > > are no such things.
> What! YES it is Adam! And you just exposed yourself as an > argumentative moron! > > A hyperlink and a button are EXACTLY the same thing "functionality" > wise. :active, :visited:, :hover, and the concept of "onhover" all would like to have a word with you. They have different presentation which yields to different functionality: if it's important to tell a user "Hey, you've been there before", then a button is entirely unsuitable, while a hyperlink is designed precisely for that situation. Hyperlinks change their presentation to indicate mouse focus (nevermind the mouse cursor itself normally), buttons don't necessarily do either[1]. Hyperlinks can certainly decay to become button-like, but buttons cannot do everything hyperlinks can do. Checkboxes and radio buttons are a much better rebuttal, as they usually present "almost" the same API and expect the same model on part of the application programmer. It's the "almost" that kills us: radio buttons only behave in the desired way when part of a button group, forcing us to be cognizant of the fact we're creating radio buttons (since we must create button groups as well). Checkboxes support tri-state functionality, and sometimes radiobuttons do as well. Pushbuttons do no such thing[2]. It'd be nice to be able to support the abstract notion of a "button" and get what I wanted, but that requires guessing at intent and computers are notoriously lousy at that. > The fact that they look different has nothing to do with the > argument. Actually it does, but they not only look different, they /behave/ differently. Both in terms of how a user interacts with them, and in terms of how we interact with them in code. > More argumentative crap. Adam you are incapable of compromise or > reason... or maybe both. Try more facts next time. I'm not the one suggesting that the only difference between a hyperlink and a button is how they are rendered, FFS man, have you ever even used a modern GUI? Are you posting from tin? Adam [1] Even when they do, it's not intended to be controlled by the application. Native button widgets have no real built-in support for user-controlled styling on mouse focus, you'd have to do the drawing yourself (at which point you might as well write a custom widget). [2] I'm ignoring the UI problems with radio buttons and checkboxes, of course. Point is, even among things where the differences are subtle, the differences have inescapable ramifications on the code I write. -- http://mail.python.org/mailman/listinfo/python-list
