On 21/05/13 12:53, Adam Wilson wrote:
> On Mon, 20 May 2013 16:50:47 -0700, Peter Williams
> <pwil3058@bigpond.net.au> wrote:
>
>> On 21/05/13 08:49, Adam Wilson wrote:
>>>
>>> I'd be willing to lead the project, I'm just not sure I am the right
>>> person to do so. I have a vision, and the skeleton of a design, but no
>>> code. I am willing, but my ability is a question mark...
>>>
>>
>> I'd volunteer to be a foot soldier on this project as I'd like D to
>> have a useful GUI capability.  At the moment, my experience of GUI
>> programming is at the user of the API end of the spectrum (mostly
>> using PyGTK to write GUI wrappers for command line programs to make my
>> life easier) but I think I'm a quick learner.  Also as a GUI API user
>> I have some idea of the sorts of thing that make a good API.
>>
>> If D had a usable GUI API I would port at least one of my current
>> PyGTK programs to D as it would benefit from better number crunching
>> capability than Python possesses.
>>
>> So, if this gets up, give me a call.
>> Peter
>>
>
> I'd love to get this up and running but I think we've got a blocker
> right now in D and that is the lack of package import,
> the GUI system is
> going to be a monster no matter how it's sliced and I'd lack to avoid
> the std.datetime effect. Sorry Jonathan Davis!

Why do you need package import?  Can't you achieve the equivalent by having one module that imports all the others publicly leaving the application programmer only one module to import?

>
> Once we get package import into D we can start building out the basics.
> Do you have any experience with concurrent hashmaps by chance?

No. Why do you want concurrency? Aren't associative arrays hashmaps?  My only experience with hashing techniques (other than as an end user of classes/functions/features using them) was implementing git binary patches in Python for use in one of my GUIs.

> Or any
> other types of containers?
>

I implemented a "left leaning red black" tree in Go (as a basis for implementing various "set" containers) a while back before I abandoned Go due to their silly "inject ';' at the end of lines" hack in the lexical analyser.  Also, the basis of my PhD thesis was the equivalent of an optimal redundant discrimination tree which is a kind of container albeit fairly specialised.

Peter

> So the basic premise of the argument is that if we can't make everyone happy we shouldn't do anything at all?

That's the initial feeling I get, but I think it comes more from the idea that a large piece of software they didn't write might be dumped on them. It's a legitimate concern, so I think a GUI library should not be included in Phobos if a group has not agreed to maintain it.

> Also, mobile, particularly WinRT, but also Android, do not enforce a look, in fact Android enshrines the idea of many different looks for widgets, my S3 is NOT the vanilla Android look. Only iOS enforces a "look" but it's still overridable. And WinRT doesn't even have the concept of OS enforced widgets looks, all it has a default style.

Trying to cover all bases seems like a headache that doesn't make sense in a standard library. For me, a standard library would provide a simple way to get basic tasks done; anything more complicated should be built on top if possible, but the core shouldn't be too bloated.

I'm thinking something closer to Clutter, not WPF. WPF is fine, but as you mentioned earlier, it has something like 40,000 classes. I'm sure much of it is just OO baggage (stupid little 20-line classes), but that still translates to a lot of code. Browsing Ohloh.net, here's an idea of the scope of other FOSS GUI toolkits:

* Qt 5 - ~7.7 million SLOC
* wkWidgets - ~1.3 million SLOC
* Gtk+ - ~769k SLOC
* EFL - ~535k SLOC
* Clutter - ~133k SLOC

As for my opinionated ideals (doesn't affect the overall design much):

* no XML (yaml maybe, but XML just isn't user-friendly)
* very limited number of default components (external libraries can provide more)
* liberally licensed (Phobos requires Boost, so that's a minimum; I prefer BSD)

I also don't like the idea of external processes interfering with the UI. I can only see security holes that cannot be plugged because of the design decision. This can, of course, be provided by a developer, but it should not be provided by default in the library code.

>> I'd love to get this up and running but I think we've got a blocker
>> right now in D and that is the lack of package import,
>> the GUI system is
>> going to be a monster no matter how it's sliced and I'd lack to avoid
>> the std.datetime effect. Sorry Jonathan Davis!
>
> Why do you need package import?  Can't you achieve the equivalent by having one module that imports all the others publicly leaving the application programmer only one module to import?

I also agree. But a package import is in the works apparently, so by the time something is ready to show, the feature will be there. Just shim for now (with an all.d or whatever) and get stuff done. I think we're looking at a 1yr or so investment before trying to include in Phobos becomes a consideration.

>> Once we get package import into D we can start building out the basics.
>> Do you have any experience with concurrent hashmaps by chance?
>
> No. Why do you want concurrency? Aren't associative arrays hashmaps?  My only experience with hashing techniques (other than as an end user of classes/functions/features using them) was implementing git binary patches in Python for use in one of my GUIs.

I agree. UIs are asynchronous by nature, not concurrent. If we agree on this premise, basic associative arrays can be used, and all access to them can be guarded by a simple mutex.

I'm completely willing to head up the initial development. I probably won't get anything done, and any initial work will be Linux-specific (I honestly don't care about Mac OS X or Windows). If anything does get done, I'll definitely come back here to get help on the design. I'm willing to do some leg-work, but I'm not experienced in any way, shape or form with GUI development (most of my work is server-type stuff in Go or front-end stuff in JS/HTML5/CSS3).

If we're generally in agreement that a UI toolkit is a good direction, I'd love to waste the next few months of my life doing something that likely won't go anywhere. I personally think it's much more exciting to make something in native D instead of trying to work around the lack of concern other C++ toolkits like Qt have for cross-language portability.

On Mon, 20 May 2013 19:48:00 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 17:04:40 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> > On Mon, 20 May 2013 15:50:06 -0700
> > "Adam Wilson" <flyboynw@gmail.com> wrote:
> >>
> >> What if as a UI designer I know that I want to specifically disallow skinning? It's not even that hard of a decision to reach. If the skinning changes the layout metrics at all (margin, padding, size, even shape), my app can end up looking terrible and I have to take a support call for a case that I couldn't have possibly dreamed up.
> >>
> >
> > Basing software decisions upon worries of "What if some user shoots himself and calls our support?" is *always* a bad idea.
> >
> 
> Is it though? Because regardless of whether or not they should call me, they will, and I will have to spend money to deal with it. Again, I have real problems that are clashing with ideology. When that happens the engineer in me demands that I address the real problems.
> 

No, you most certainly do *not* have real problems clashing with ideology:

What you have is a contrived "what if" scenario that you think is a "real" threat to your business despite the fact that you yourself are convinced that hardly anyone is going to be messing with their settings anyway.

Then you're running around crying "It's ideology versus successful business! I'd better disregard my user's settings or else the sky will fall!" Yea, I'm exaggerating, but your whole argument here is clearly exaggerated bullshit.

And if you're really *are* that worried about enough "coffee mug in the CD tray"-mentality users changing their system settings and then calling you about that, enough that it would pull you under, then you can just *not* invent a new UI styling to force on them in the first place. Big freaking deal. Like you said, most of them don't care anyway, right?

> 
> Why? The user mostly doesn't care as long as it works and solves their problem, I personally spend less and less time customizing my environments for two-fold reasons, I have an every growing number of them, and I care less and less, just get out of my way and let me work. Don't make me decide on a hundred details before I can get started.
> 

Ok. So then why in the world are you wasting *your* time inventing new UI styles for your software if so few of your users care?


> >
> > Secondly, we're not babysitters or self-appointed police here. To engage in such a level of control is *already* a very serious breach of our moral obligations.
> >
> >
> 
> In the real world, yes, we are. You see, it's a small inconvenience known as the lawsuit. Specifically that I am legally liable for any and all security vulnerabilities within my product. There is case-history going back to support this since the dawn of legal systems. It is ironclad, ideology will not change it. I consider cross-process of a UI a MAJOR security problem because it allows malicious software to modified my software in subtle ways that compromise the security of the system. And apparently I am not the only one who thinks this way because every mobile OS available today does not allow ANY kind of cross-process UI manipulation of any kind, going so far as to sandbox each app.

I think we're getting offtopic here. If we're associating "legally-accountable security negligence" together with "using native UI toolkits", then clearly we've already taken a nose-dive off the deep end.

> Where is your outrage over
> Android or iOS or WinRT or Blackberry or Symbian?
> 

Heh. If you think I *don't* have a deep seething hatred for Android, iOS and WinRT, on both practical and ethical grounds, then you're very much mistaken ;)

I don't always agree with Stallman, but one thing I did always agree completely with him on is how Steve Job's last decade of work was "the computer as a jail made cool, designed to sever fools from their freedom". Stallman didn't change my mind with that, but he did word it far better than I ever could have.


> >
> > Just for example, Spy++ or any similar such developer tool. Or GUI macros. Those are just off the top of my head. I'm sure people can, and have, thought of any number of other different uses.
> >
> 
> GUI macros work on WPF apps.

Does the same macro utility system also work across WPF, GTK, Qt, Delphi apps, whatever the fuck Nero, Winamp or Windows iTunes use, *and* Joe Schmo's Yet Another NIH-Fueled OpenGL-based Toolkit?


> Snoop does what Spy++ does.
> 

Same question as above.

> 
> Have you ever built any software where you are legally liable for any security holes your software opens up? My guess is no. Because if you had, you'd get where I am coming from.
> 

Let's not dive into ad-hominem time-wasting here. I'm not going to get into what really amounts to an "I'm more l33t than you" contest under the false pretense that the answer has any bearing whatsoever on the topic at hand.


> Ideology is fine, right up until you have to meet the real world. Do you honestly expect your users to each become security experts? Such a thought is laughable on the face of it. They have neither the time nor the interest, and nor should they, it is not a productive use of their time. This is why the law makes it MY fault for security flaws, because there is not, and can be no, reasonable expectation that they are security experts, that's MY job.

Again, you're taking one thing here and then contorting it into a mutant, paranoid strawman with only a vague connection to the real discussion:

1. The ideology of *allowing* the users who *want* control over their own computer to *have* control over their own computer is *not* in conflict with "the real world". That's downright crazed paranoia. It's not going to drown your company in support costs. It's not going to get you thrown in jail for negligent security. It's not going to eat your children and destroy family values and make the sky fall. Take a step back and look at this with some perspective.

2. If this stuff we're talking about constitutes such major security
negligence, then so does damn near every other thing computers ever do.
Almost anything useful that programmers use is every bit as
much exploitable. "Hackers can use functions to help create their
exploits?! Holy hell! We must stop this evil 'function' thing since,
after all, legitimate software can just use GOTO!" Or: "Your address
book software lets me put in all that sensitive info?! How dare you!
That means anyone who grabs my phone while I have it unlocked has easy
access to it! I'll sue you!" For fuck's sake, everything useful is
exploitable. Let's go back to our caves. (Oh shit! Rocks!)

3. Where in the would did you pull this "expect your users to each become security experts" crap from in the first place? That came completely out of nowhere.

> 
> Ergo, allowing cross-process UI manipulation is inherently wrong, it's also legally and ethically wrong.  Putting my users at risk in the name of ideology is so wrong that I am dry heaving at the thought.

Better make sure the cops never find out if you've used Snoop or GUI macros. Or Tcl Expect. Or a debugger. Or stdin/stdout. Or...


> Incidentally, this is why no mobile OS ever allows it, it's
> WAY to legally risky. Not even Google can make that lawsuit go away.
> 

I'm seeing an unsubstantiated claim here.

> 
> Nick, I hate to break it to you, but you are so far out on the extreme end of the scale on this one that it will be impossible to advance technology and keep you happy,

As opposed to being so far out in paranoia that it'll be impossible for you to use or create technology at all and still feel safe and secure from lawsuits, support call stampedes, black hats...You really are a nut here.

> so I'll have to leave you
> behind, because the 99% want there software to just work, and could
> care less how it does it. I don't like leaving people behind and
> pissing them off, but I have to go where the majority goes,

Ok, I understood. Ideals result in lawsuit, and so does failing to chase trends. Ok, gotcha. Back to your padded room...Don't forget your tinfoil hat over there...

> otherwise
> I'm just a penniless artist with a rigid ideology and no friends.
> 

You just can't help using all these slipperly slope arguments, can you? Besides, I'm guessing that paranoia doesn't help win friends and money either.

On Mon, 20 May 2013 19:24:44 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 18:04:10 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> > On Mon, 20 May 2013 15:54:10 -0700
> > "Adam Wilson" <flyboynw@gmail.com> wrote:
> >>
> >> Very few actual users care about changing the behavior of the widgets. Most people who want to change them just want to skin them.
> >>
> >
> > One standard deviation is all that ever matters. Everyone else can and should just go fuck off. It's their own goddamn fault anyway for being such a bunch of unreasonable jackasses. Fuck 'em, nobody cares about them anyway, especially since we all know perfectly well they're just a bunch of fat unshowered virgin slobs living in their parent's basement and jerking to "7 of 9".
> >
> >
> >
> > ...Right?
> >
> >
> >
> > Or, of course, we could just go with the classic favorite: "It's just business."
> >
> 
> So the basic premise of the argument is that if we can't make everyone happy we shouldn't do anything at all?

The basic premise is that "fuck the minority" is asinine. I know you've never worded it in such a way, but that's exactly what it amounts to.


> Let me pose you this
> question. If a piece of software did something for you that you
> absolutely had to do and nothing else did, but had a non-native
> widget UI, would you use that piece of software?
> 

There's nothing hypothetical about that:

I *do* use Claws mail, Gimp, DVDFab (to remove PUOs from my - yes, legitimate - discs) and various others, I have used iTunes, Flash and others in the past, and those are all non-native abominations. And yes, I put up with them *even over some native UI alternatives*, because for one reason or another they're the best option (for me) that I can find.

That still doesn't change the fact that I hate putting up with them and I would immediately jump ship given an all-around sufficient alternative.


> Most people, even the prideful ones, would just use it, because not using the software is worse than the UI decisions by the designer.
> 

So I take it you *really* weren't expecting my answer above then. You were maybe convinced I was something I'm clearly not, hmm? Just because I don't chase trends eagerly? Or just that someone not sharing your opinion, or who doesn't engage in group-think, couldn't possibly be rational? Something else, perhaps?

On Mon, 20 May 2013 20:32:30 -0700, Tyler Jameson Little <beatgammit@gmail.com> wrote:

>> So the basic premise of the argument is that if we can't make everyone happy we shouldn't do anything at all?
>
> That's the initial feeling I get, but I think it comes more from the idea that a large piece of software they didn't write might be dumped on them. It's a legitimate concern, so I think a GUI library should not be included in Phobos if a group has not agreed to maintain it.
>
>> Also, mobile, particularly WinRT, but also Android, do not enforce a look, in fact Android enshrines the idea of many different looks for widgets, my S3 is NOT the vanilla Android look. Only iOS enforces a "look" but it's still overridable. And WinRT doesn't even have the concept of OS enforced widgets looks, all it has a default style.
>
> Trying to cover all bases seems like a headache that doesn't make sense in a standard library. For me, a standard library would provide a simple way to get basic tasks done; anything more complicated should be built on top if possible, but the core shouldn't be too bloated.
>
> I'm thinking something closer to Clutter, not WPF. WPF is fine, but as you mentioned earlier, it has something like 40,000 classes. I'm sure much of it is just OO baggage (stupid little 20-line classes), but that still translates to a lot of code. Browsing Ohloh.net, here's an idea of the scope of other FOSS GUI toolkits:
>
> * Qt 5 - ~7.7 million SLOC
> * wkWidgets - ~1.3 million SLOC
> * Gtk+ - ~769k SLOC
> * EFL - ~535k SLOC
> * Clutter - ~133k SLOC
>
> As for my opinionated ideals (doesn't affect the overall design much):
>
> * no XML (yaml maybe, but XML just isn't user-friendly)
> * very limited number of default components (external libraries can provide more)
> * liberally licensed (Phobos requires Boost, so that's a minimum; I prefer BSD)
>
> I also don't like the idea of external processes interfering with the UI. I can only see security holes that cannot be plugged because of the design decision. This can, of course, be provided by a developer, but it should not be provided by default in the library code.

I actually find WPF too be far to heavy to be realistic for our purposes too. I know why they choose XML for XAML (they had existing XML parser/serialization libraries to leverage) but it ends up being frighteningly verbose. I am think a DSL and CTFE/mixins would be a MUCH more compact system and would be much more in line with D's principles. I personally have no problem with Boost, the goal is to get people using it in all scenarios, not restricting it to one licensing ideology or another.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 22:18:31 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 19:24:44 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>
>> On Mon, 20 May 2013 18:04:10 -0700, Nick Sabalausky
>> <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>> > On Mon, 20 May 2013 15:54:10 -0700
>> > "Adam Wilson" <flyboynw@gmail.com> wrote:
>> >>
>> >> Very few actual users care about changing the behavior of the
>> >> widgets. Most people who want to change them just want to skin
>> >> them.
>> >>
>> >
>> > One standard deviation is all that ever matters. Everyone else can
>> > and should just go fuck off. It's their own goddamn fault anyway
>> > for being such a bunch of unreasonable jackasses. Fuck 'em, nobody
>> > cares about them anyway, especially since we all know perfectly
>> > well they're just a bunch of fat unshowered virgin slobs living in
>> > their parent's basement and jerking to "7 of 9".
>> >
>> >
>> >
>> > ...Right?
>> >
>> >
>> >
>> > Or, of course, we could just go with the classic favorite: "It's
>> > just business."
>> >
>>
>> So the basic premise of the argument is that if we can't make
>> everyone happy we shouldn't do anything at all?
>
> The basic premise is that "fuck the minority" is asinine. I know you've
> never worded it in such a way, but that's exactly what it amounts to.
>
>
>> Let me pose you this
>> question. If a piece of software did something for you that you
>> absolutely had to do and nothing else did, but had a non-native
>> widget UI, would you use that piece of software?
>>
>
> There's nothing hypothetical about that:
>
> I *do* use Claws mail, Gimp, DVDFab (to remove PUOs from my - yes,
> legitimate - discs) and various others, I have used iTunes, Flash and
> others in the past, and those are all non-native abominations. And yes,
> I put up with them *even over some native UI alternatives*, because for
> one reason or another they're the best option (for me) that I can find.
>
> That still doesn't change the fact that I hate putting up with them and
> I would immediately jump ship given an all-around sufficient
> alternative.
>
>
>> Most people, even the prideful ones, would just use it, because not
>> using the software is worse than the UI decisions by the designer.
>>
>
> So I take it you *really* weren't expecting my answer above then. You
> were maybe convinced I was something I'm clearly not, hmm? Just because
> I don't chase trends eagerly? Or just that someone not sharing your
> opinion, or who doesn't engage in group-think, couldn't possibly be
> rational? Something else, perhaps?
>

Pretty much the answer I expected actually.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On 21/05/13 13:46, Tyler Jameson Little wrote:
> I'm completely willing to head up the initial development. I probably
> won't get anything done, and any initial work will be Linux-specific (I
> honestly don't care about Mac OS X or Windows).

Nor me, really.

Nevertheless, I've found using PyGTK means that my GUIs run on Mac/Windows provided the users are able to install the command line packages that they're wrappers for (where that's necessary).  I will admit that I had to do a very small bit of Windows specific code to properly run CLI commands and capture their output (20 or 30 lines).

> If anything does get
> done, I'll definitely come back here to get help on the design. I'm
> willing to do some leg-work, but I'm not experienced in any way, shape
> or form with GUI development (most of my work is server-type stuff in Go
> or front-end stuff in JS/HTML5/CSS3).
>
> If we're generally in agreement that a UI toolkit is a good direction,
> I'd love to waste the next few months of my life doing something that
> likely won't go anywhere. I personally think it's much more exciting to
> make something in native D instead of trying to work around the lack of
> concern other C++ toolkits like Qt have for cross-language portability.

Yes, if D aspires to be a systems programming language it can't keep relying on wrappers around C/C++ libraries (especially C++).  In the long term, it should be D all the way down to the OS API.

Peter

On Tue, 21 May 2013 05:26:29 +0200
"Diggory" <diggsey@googlemail.com> wrote:

> On Tuesday, 21 May 2013 at 02:47:59 UTC, Adam Wilson wrote:
> > could care less
> 
> http://www.youtube.com/watch?v=om7O0MFkmpw
> 
> Sorry...

Yes! I've been pointing that out for years! First time I've ever seen anyone else address it. And it's hilarious, too.

On Mon, 20 May 2013 22:00:39 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 19:48:00 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>
>> On Mon, 20 May 2013 17:04:40 -0700, Nick Sabalausky
>> <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>> > On Mon, 20 May 2013 15:50:06 -0700
>> > "Adam Wilson" <flyboynw@gmail.com> wrote:
>> >>
>> >> What if as a UI designer I know that I want to specifically
>> >> disallow skinning? It's not even that hard of a decision to reach.
>> >> If the skinning changes the layout metrics at all (margin,
>> >> padding, size, even shape), my app can end up looking terrible and
>> >> I have to take a support call for a case that I couldn't have
>> >> possibly dreamed up.
>> >>
>> >
>> > Basing software decisions upon worries of "What if some user shoots
>> > himself and calls our support?" is *always* a bad idea.
>> >
>>
>> Is it though? Because regardless of whether or not they should call
>> me, they will, and I will have to spend money to deal with it. Again,
>> I have real problems that are clashing with ideology. When that
>> happens the engineer in me demands that I address the real problems.
>>
>
> No, you most certainly do *not* have real problems clashing with
> ideology:
>
> What you have is a contrived "what if" scenario that you think is a
> "real" threat to your business despite the fact that you yourself are
> convinced that hardly anyone is going to be messing with their settings
> anyway.
>
> Then you're running around crying "It's ideology versus successful
> business! I'd better disregard my user's settings or else the sky will
> fall!" Yea, I'm exaggerating, but your whole argument here is clearly
> exaggerated bullshit.
>
> And if you're really *are* that worried about enough "coffee mug in the
> CD tray"-mentality users changing their system settings and then calling
> you about that, enough that it would pull you under, then you can just
> *not* invent a new UI styling to force on them in the first place. Big
> freaking deal. Like you said, most of them don't care anyway, right?
>

I didn't think we were talking about styling but about cross-process UI manipulation, styling isn't a security threat as you've correctly pointed out, but allowing other processes to manipulate a UI, is, otherwise all new native UI toolkit's allow it. Last I checked none of the mobile OS's do. WinRT on Win8 does not either. I'd say the trend is away from cross-process UI manipulation, not towards

>>
>> Why? The user mostly doesn't care as long as it works and solves
>> their problem, I personally spend less and less time customizing my
>> environments for two-fold reasons, I have an every growing number of
>> them, and I care less and less, just get out of my way and let me
>> work. Don't make me decide on a hundred details before I can get
>> started.
>>
>
> Ok. So then why in the world are you wasting *your* time inventing new
> UI styles for your software if so few of your users care?
>
>
>> >
>> > Secondly, we're not babysitters or self-appointed police here. To
>> > engage in such a level of control is *already* a very serious breach
>> > of our moral obligations.
>> >
>> >
>>
>> In the real world, yes, we are. You see, it's a small inconvenience
>> known as the lawsuit. Specifically that I am legally liable for any
>> and all security vulnerabilities within my product. There is
>> case-history going back to support this since the dawn of legal
>> systems. It is ironclad, ideology will not change it. I consider
>> cross-process of a UI a MAJOR security problem because it allows
>> malicious software to modified my software in subtle ways that
>> compromise the security of the system. And apparently I am not the
>> only one who thinks this way because every mobile OS available today
>> does not allow ANY kind of cross-process UI manipulation of any kind,
>> going so far as to sandbox each app.
>
> I think we're getting offtopic here. If we're associating
> "legally-accountable security negligence" together with "using native UI
> toolkits", then clearly we've already taken a nose-dive off the deep
> end.
>
>> Where is your outrage over
>> Android or iOS or WinRT or Blackberry or Symbian?
>>
>
> Heh. If you think I *don't* have a deep seething hatred for Android, iOS
> and WinRT, on both practical and ethical grounds, then you're very much
> mistaken ;)
>
> I don't always agree with Stallman, but one thing I did always agree
> completely with him on is how Steve Job's last decade of work was
> "the computer as a jail made cool, designed to sever fools from their
> freedom". Stallman didn't change my mind with that, but he did word it
> far better than I ever could have.
>
>
>> >
>> > Just for example, Spy++ or any similar such developer tool. Or GUI
>> > macros. Those are just off the top of my head. I'm sure people can,
>> > and have, thought of any number of other different uses.
>> >
>>
>> GUI macros work on WPF apps.
>
> Does the same macro utility system also work across WPF, GTK, Qt,
> Delphi apps, whatever the fuck Nero, Winamp or Windows iTunes use,
> *and* Joe Schmo's Yet Another NIH-Fueled OpenGL-based Toolkit?
>
>
>> Snoop does what Spy++ does.
>>
>
> Same question as above.
>
>>
>> Have you ever built any software where you are legally liable for
>> any security holes your software opens up? My guess is no. Because if
>> you had, you'd get where I am coming from.
>>
>
> Let's not dive into ad-hominem time-wasting here. I'm not going to get
> into what really amounts to an "I'm more l33t than you" contest under
> the false pretense that the answer has any bearing whatsoever on the
> topic at hand.
>

I wasn't intended on starting a pissing contest, I was merely pointing out a legitimate concern. It may be ad hominem and for that I do apologize.

>
>> Ideology is fine, right up until you have to meet the real world. Do
>> you honestly expect your users to each become security experts? Such
>> a thought is laughable on the face of it. They have neither the time
>> nor the interest, and nor should they, it is not a productive use of
>> their time. This is why the law makes it MY fault for security flaws,
>> because there is not, and can be no, reasonable expectation that they
>> are security experts, that's MY job.
>
> Again, you're taking one thing here and then contorting it into a
> mutant, paranoid strawman with only a vague connection to the real
> discussion:
>
> 1. The ideology of *allowing* the users who *want* control over their
> own computer to *have* control over their own computer is *not* in
> conflict with "the real world". That's downright crazed paranoia. It's
> not going to drown your company in support costs. It's not going to get
> you thrown in jail for negligent security. It's not going to eat your
> children and destroy family values and make the sky fall. Take a step
> back and look at this with some perspective.
>
> 2. If this stuff we're talking about constitutes such major security
> negligence, then so does damn near every other thing computers ever do.
> Almost anything useful that programmers use is every bit as
> much exploitable. "Hackers can use functions to help create their
> exploits?! Holy hell! We must stop this evil 'function' thing since,
> after all, legitimate software can just use GOTO!" Or: "Your address
> book software lets me put in all that sensitive info?! How dare you!
> That means anyone who grabs my phone while I have it unlocked has easy
> access to it! I'll sue you!" For fuck's sake, everything useful is
> exploitable. Let's go back to our caves. (Oh shit! Rocks!)
>
> 3. Where in the would did you pull this "expect your users to each
> become security experts" crap from in the first place? That came
> completely out of nowhere.
>
>>
>> Ergo, allowing cross-process UI manipulation is inherently wrong,
>> it's also legally and ethically wrong.  Putting my users at risk in
>> the name of ideology is so wrong that I am dry heaving at the
>> thought.
>
> Better make sure the cops never find out if you've used Snoop or GUI
> macros. Or Tcl Expect. Or a debugger. Or stdin/stdout. Or...
>
>
>> Incidentally, this is why no mobile OS ever allows it, it's
>> WAY to legally risky. Not even Google can make that lawsuit go away.
>>
>
> I'm seeing an unsubstantiated claim here.
>
>>
>> Nick, I hate to break it to you, but you are so far out on the
>> extreme end of the scale on this one that it will be impossible to
>> advance technology and keep you happy,
>
> As opposed to being so far out in paranoia that it'll be impossible
> for you to use or create technology at all and still feel safe and
> secure from lawsuits, support call stampedes, black hats...You really
> are a nut here.
>
>> so I'll have to leave you
>> behind, because the 99% want there software to just work, and could
>> care less how it does it. I don't like leaving people behind and
>> pissing them off, but I have to go where the majority goes,
>
> Ok, I understood. Ideals result in lawsuit, and so does failing to
> chase trends. Ok, gotcha. Back to your padded room...Don't forget your
> tinfoil hat over there...
>
>> otherwise
>> I'm just a penniless artist with a rigid ideology and no friends.
>>
>
> You just can't help using all these slipperly slope arguments, can
> you? Besides, I'm guessing that paranoia doesn't help win friends and
> money either.
>


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/