I forgot to mention I'm using Slackware 14.1, gtk 3.8.2 is the version in Slackware, so if I don't need any other dependencies to compile the latest version of GTK3 then I'll install and try it, if someone could be so kind to create a patch for it as well...

I'd also really appreciate it if the GTK team could really consider creating a compile time option so ATK is not required.

thank you again...

first of all, GTK+ 3.8 is an old stable branch, and it currently does not see any maintainer effort; there are only three maintained branches of GTK at any given time: master, the current stable branch, and the gtk-2-24 branch for GTK+ 2. no change will be committed to GTK+ 3.8, at this point.

ATK is a dependency exposed in our public API, so it cannot be conditionally ignored; the issue you have is with the ATK bridge dependency, though.

as bug 677491 (which applied and then reverted the commit you linked) clearly explains, having untested compilation options increases the maintenance and QA burden on the GTK team, and more likely than not, having an option to disable the ATK bridge will break, since nobody will test it.

you are free to add a distro-patch for your specific use case, but GTK+ decided a long time ago to support accessibility out of the box, and that implies building a certain set of dependencies.

*** This bug has been marked as a duplicate of bug 677491 ***

First, I want to make clear which I should of in the beginning, I didn't want to make this about only me, but having the GTK team sit up and look at this situation and consider, is it really the best way to go about this now and in the future with GTK? 

I want to see GTK remain as free in the ideas of Linux, choices and freedom, but if the GTK team continues down this path, then you are not leaving the end-user any choice of freedom in using GTK3.

Is it really difficult to eventually have a compile time option to disable Gnome Accessibility? Not every end-user on every distro out there needs this, so why then make this a one size fits all solution? To me this is not the Linux way.

Now what we're faced with is finding the resources, meaning the people capable of doing this, as in my situation, I'm not skilled enough to know what I can hack out and create a patch.

When we look around at source code from many developers of Linux, we see most options available to disable or enable at compile time.

Need all the GTK developers be reminded of their words?
-----------
GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces. 
-----------

Multi Platform toolkit, so when did this toolkit start to become Gnome, or Gnome dependant, to such a point that the foucus seems to be so much about Gnome, and not the 'Multi Platforms' that stretch way beyond Gnome?

I really humbly hope that the GTK team will really consider what is going on here, and please eventually make a compile time option to disable this feature, instead of locking the end-user into this Gnome dependancy...

(In reply to comment #3)
> First, I want to make clear which I should of in the beginning, I didn't want
> to make this about only me, but having the GTK team sit up and look at this
> situation and consider, is it really the best way to go about this now and in
> the future with GTK? 

having accessibility enabled by default allows GTK applications to reach more people, with the small inconvenience of having a build time dependency, which impact absolutely nobody, given the size of at-spi2-atk.

> I want to see GTK remain as free in the ideas of Linux, choices and freedom,
> but if the GTK team continues down this path, then you are not leaving the
> end-user any choice of freedom in using GTK3.

disabling accessibility support is in no way, shape, or form "about freedom", despite what you think.

> Is it really difficult to eventually have a compile time option to disable
> Gnome Accessibility? Not every end-user on every distro out there needs this,
> so why then make this a one size fits all solution? To me this is not the Linux
> way.

you are operating under a pretty large set of misguided assumptions. accessibility support has nothing to do with GNOME. it's a GTK+ feature, and it's componentized in such a way that not only the base API, ATK, is fully abstract, but also the various backends are desktop-neutral, and can be run under any environment.
 
> When we look around at source code from many developers of Linux, we see most
> options available to disable or enable at compile time.
> 
> Need all the GTK developers be reminded of their words?
> -----------
> GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical
> user interfaces. 
> -----------

GTK+ only uses at-spi-bridge under X11 and Wayland (i.e. Linux and other Unix-like OS), so I fail to see what your point is.

also, you seem to fail to understand that the GTK+ team is in no way compelled to provide a full range of configure switches for people that want to disable specific subsets of build dependencies.

are you going to ask for a way to disable Cairo for drawing because you don't need that API? or Pango, for handling text, because you only use ASCII glyphs? what makes you think that accessibility is such a secondary characteristic that it ought to be disabled?

are you also going around asking people to remove the ramps near the steps? or braille from elevator buttons?

> Multi Platform toolkit, so when did this toolkit start to become Gnome, or
> Gnome dependant, to such a point that the foucus seems to be so much about
> Gnome, and not the 'Multi Platforms' that stretch way beyond Gnome?

again, accessibility support has nothing to do with GNOME, and everything to do with enabling GTK applications to be used by everyone, regardless of their level of ability.

I strongly suggest you read the bug I linked you.

(In reply to comment #4)
> (In reply to comment #3)
> > First, I want to make clear which I should of in the beginning, I didn't want
> > to make this about only me, but having the GTK team sit up and look at this
> > situation and consider, is it really the best way to go about this now and in
> > the future with GTK? 
> 
> having accessibility enabled by default allows GTK applications to reach more
> people, with the small inconvenience of having a build time dependency, which
> impact absolutely nobody, given the size of at-spi2-atk.


Size I don't see as the issue, I see this more about being given something that isn't needed by everyone, as well as daemon(s) running in the background was more my concern, over the small dependency. It would be nice if this can be created in such a way, it does not need a running daemon service. The idea of getting stuck with something you don't need, then a daemon(s) needing to run in the background stuck with, seems a bit much... 


> 
> > I want to see GTK remain as free in the ideas of Linux, choices and freedom,
> > but if the GTK team continues down this path, then you are not leaving the
> > end-user any choice of freedom in using GTK3.
> 
> disabling accessibility support is in no way, shape, or form "about freedom",
> despite what you think.


If you're thinking about the Freedom as in Speech vs Beer, I think all Linux geeks know it very well... What I was trying to point out is that giving the end users choices, I think is still very much alive and is Linux. But the argument always seems to be if you don't like this, then the choice is to go over there and use the other, and I don't think this is always the Linux way, but to create choices in the applications that we choose. So all I'm asking is I choose to use GTK, but can you give the end-user a better choice over this matter...


> 
> > Is it really difficult to eventually have a compile time option to disable
> > Gnome Accessibility? Not every end-user on every distro out there needs this,
> > so why then make this a one size fits all solution? To me this is not the Linux
> > way.
> 
> you are operating under a pretty large set of misguided assumptions.
> accessibility support has nothing to do with GNOME. it's a GTK+ feature, and
> it's componentized in such a way that not only the base API, ATK, is fully
> abstract, but also the various backends are desktop-neutral, and can be run
> under any environment.

I'm not operating under any misguided assumptions. I'm looking at the wording that is being used in Slackware and other distros, and I'd like to think that Pat and all those invloved in the Slackware project are not misguided. Have a look at what the description mentioned in the slack-desc file, if you know Slackware, this file is part of the pkg description shown when you install a Slackware package;

http://mirrors.slackware.com/slackware/slackware64-14.1/slackware64/l/at-spi2-core-2.8.0-x86_64-1.txt

So by the wording in the text it seems to lable Gnome in two ways; 'Part of' and 'On the Gnome platform', this looks quite like a Gnome releated project...

Also what is being misguided here is really a lack of understanding on possibly the choice of words being used, and not completely describing this in full detail. Everywhere you look online to read about this you find the same wording, and to the end-user this only looks like two things;

1. Assistive Technologies 
2. available on the GNOME platform 

This also makes end-users feel like it's only an Assistive Technologies on Gnome, so end-users of KDE as an example I've seen in the past are looking at this like, I'm not using Gnome, so why do I have this...

Now are we all being misguided as to what Assistive Technologies are? All most people understand is this is a technology for people with disabilities, and that is also a reason I ask that the end-user is given a compile time option to disalbe this, because we are not all disabled, or have a need for such technology on our computers. This should be really limited to those who do have, what is labled as; 'Special Needs'. And those with Special Needs choose it, not just creating a one size fits all solution where everyone has it whether they want it or not.


> 
> > When we look around at source code from many developers of Linux, we see most
> > options available to disable or enable at compile time.
> > 
> > Need all the GTK developers be reminded of their words?
> > -----------
> > GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical
> > user interfaces. 
> > -----------
> 
> GTK+ only uses at-spi-bridge under X11 and Wayland (i.e. Linux and other
> Unix-like OS), so I fail to see what your point is.

The point gets back to the description in the file I pointed out above, how there is relation to Gnome in this, and how GTK is suppose to be 'Multi Platform', but as it turns out this appears to be more 'Gnome Platform'. So then what is this 'Mulit Platform', that is being referred to?


> 
> also, you seem to fail to understand that the GTK+ team is in no way compelled
> to provide a full range of configure switches for people that want to disable
> specific subsets of build dependencies.

Yes of course I understand you are in no way obligated to do anything you don't want to. This is merely a request to consider doing so possibly in the future is all. So if this is 'Assistive Technologies', as well all understand it, for disabled people of/with 'Special Needs', then it would be kept as an option for those that need it.


> are you going to ask for a way to disable Cairo for drawing because you don't
> need that API? or Pango, for handling text, because you only use ASCII glyphs?
> what makes you think that accessibility is such a secondary characteristic that
> it ought to be disabled?
> 
> are you also going around asking people to remove the ramps near the steps? or
> braille from elevator buttons?
> 
> > Multi Platform toolkit, so when did this toolkit start to become Gnome, or
> > Gnome dependant, to such a point that the foucus seems to be so much about
> > Gnome, and not the 'Multi Platforms' that stretch way beyond Gnome?
> 
> again, accessibility support has nothing to do with GNOME, and everything to do
> with enabling GTK applications to be used by everyone, regardless of their
> level of ability.
> 
> I strongly suggest you read the bug I linked you.


So I'm sorry I will first say, if I've failed to completely understand this, but the way this seems to be getting labled as for; 'Assistive Technologies', is the thing that is confusing end-users.

We all believe this is a technology for supporting this special needs, and I say so because I've spoken to many Linux users who feel the same way, wondering why is it like this. Many people, believe, why can't it simply be disabled for those who have no need, and then applications that also have the ability to use 
'Assistive Technologies', when they are compiled agasint GTK and see the option is disabled, simply compile as normal and without the support and work just fine without it...

As far as Cairo and Pango, I fail to see why they can't work without the support compiled into GTK, working the same way, they compile with or without the support and work just fine either way...

Also here's a thought, and I really don't mean to belittle anyone, but seriously it is a way in which I find many Linux users fail to consider.

1. When you install Linux do you do a full install of everything?
2. A lot of distros allow for Full or Custom/Expert installs, so you can pick and choose to install only what you want.

Bloat, this is not a word I made up, and with no disrespect to anyone, I'm not trying to be rude to anyone here, I'm simply trying to point out something. Many times we look at something, and as small as this one thing is, in this case the dependancy for this and it's certainly small we don't consider this bloat, because in and of itself that is foolish to think so it's not.

But if I do a full install of everything that is not needed, then everthing, all considered, this is certainly bloat. So where do we really draw the line on bloat?

I did not make up this word 'Bloat' so please remember that whenn you read this, like it's my own concept, it's not.

So ATK on it's own is certainly not bloat, but when we start adding up all the pieces not needed, then is does start to become bloat and for that reason, it's certainly is nice to consider having options, for those that choose to eliminate where possible.

I really want to thank everyone for reading this. I'm truly grateful for you all taking the time to read and consider. I know for now your minds seems made up, but things can change, and where there is a will there is a way. So I hope at some time in the future this might get changed.

Thank you... :)

Something to my surprise, looking at the 'NEWS' file in 3.8.2 it reads as follows;

* The accessibility bridge code that exports accessible objects
  on the bus is used by default (atk-bridge has been converted into
  a library that GTK+ links against). To avoid the linking, you can
  pass --without-atk-bridge when configuring GTK+.

Was this something that was left over in error, or should this work in 3.8.2?

thank you...

Sorry I'm not trying to bump this up, but I'm trying my best working on this, and I later noticed in the README this;

Release notes for 3.6
=====================

* The accessibility bridge code that exports accessible objects
  on the bus is now used by default; atk-bridge has been converted
  into a library that GTK+ links against. To void the linking,
  pass --without-atk-bridge when configuring GTK+.

This does not work in 3.6.0, so can someone clarify if this --without flag works in any version?

I've also done my best to try and make a patch, this is the best I've come up with so far, see the attachment; atk.patch.

If someone will take the time to create a patch, I will certainly do my best to help the GTK team on this.

thanks

Created attachment 292686 [details] [review]
atk.patch

PLEASE disregard the atk.patch, I have just created a patch that allows me to compile 3.8.2 without the atk-bridge, please see this new patch;

without-atk-bridge.diff

I would greatly appreciate any input, as I try to contribute something to GTK...

thank you...

Created attachment 292687 [details]
without-atk-bridge.diff

The --without-atk-bridge option was introduced in 3.5.6 and dropped again in 3.5.8. We are not interested in making this optional again.

I tried to make a contributtion, looking over this patch and the time and effort it took to disable this, was not difficult.

I actually cleaned it up to enable the flag; --without-atk-bridge and then if it's not used, it's asked for.

Well maybe someone might want to see this so I'm attaching this latest patch.

Even if GTK is not interested in maintaining this, it would certainly be nice if someone could look the patch over to give feedback.

I'm not an complete expert it, but this patch works, and if it's 100% correct or good enough, then I'm really not understanding why this would be so difficult to maintain.

Also please be aware it has never been my intentions, if anyone felt like it, that I was hear to pick on anyone or give anyone a hard time. I'm only trying to have a nice discussion over this, nothing more, and I thank those for participating.

Cheers

Created attachment 292791 [details]
without-atk-bridge.diff