>> Ok, then I suggest the following - creating the special branch for me kin
>> the project and lets say call it accessability. Inside this branch there
>> will be folders for each ScreenReader that I shall support and I shall
>> the scripts for several screen readers under this folder and develop them
>> increasing the accessability of TSVN for some of the screen readers. Your
>> opinion on this?
> I don't think we need a special branch for this. Just a new folder under
> our 'contrib' folder. That's where such scripts belong anyway.
> If you create (or already have one) a tigris.org account, I can set you
> up with commit access to our repository so you can add and commit these
> scripts yourself. Would that be ok?
Sure, I shall create an account and send you information on it that is
needed to - login most likely - or something else is needed? I was using
Assembla for my projects before, so I do not think this should be difficult.
As soon as the scripts will be at least somehow usable we shall discuss how
to implement conditional install of them in the appropriate folder of the
screenreader - I am now studying WIX for my own projects installations so I
believe it will not be dificult to add the installation in case of the
screenreader XXX or screenreader YYY is found in the registry.
>>>>> Of course, I'm using the latest nightly builds (or my own dev builds)
>>>>> and not the 1.6.6 release. Since there are many differences already
>>>>> between those two versions it might be that this is the reason you
>>>>> see the accelerator in your screen reader?
>>>> May be, if you have already changed the window structure?
>>> The dialogs changed often on trunk, so I'm sure that many dialogs and
>>> their structure has already changed - maybe even to the worse so you
>>> really should start using such a nightly build to make sure we don't
>>> mess up anything for your screen reader.
>> Stefam, I want to start doing this but the only reason stopping me is
>> that I
>> am not sure if these builds will be accurate in everyday work - I am
>> theb TSVN in several projects and do not want to spoil them. Is it
>> to install several versions on the computer at the same time? One for
>> testing and for everyday work?
> The nightly builds from trunk are still linked with Subversion 1.6.x, so
> there's not much of a risk using those. Of course, it's always a good
> idea to keep two or three of the latest installers from the nightly
> builds around, just in case the very latest has some bug. With one or
> two earlier installers around, you can always go back.
> I'm using the nightly builds myself, not just at home but also in the
> office. And many others are using the nightly builds too and help
> testing. There's no risk of losing data. Just sometimes a button doesn't
> work properly or a crash in some situations. But those are usually no
> deal breakers and just annoying for a day until the next nightly build
> is available.
Ok, I shall install and try the last one I shall find.
>> you do not need to intercept all 21 methods of iAccessable interface,
>> one - Get_AccValue here because all the others are already providing the
>> information necessary. Since the iAccessable is the COM inside though a
>> different from others - you have the ability to intercept only the one
>> want to in your program.
> Well, I would have to implement all of them. Because it's not possible
> to implement a COM interface just partially. Of course, I would only
> have to do something in one method, and in all other methods I could
> just call the method of the original object. But I would still have to
> implement them.
Ok, in any case if you are making changes to the class it is better to
subclass it then to superclass it to have the same window class that is
familiar to the screen reader then to change it to a new one.
> But I found another way. I've implemented a callback annotation server.
> In r17946, the log dialog now fills in the help string of subitems that
> are already merged (the ones shown in gray).
Does this mean that I shall be able to take this information from the
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-12 21:02:20 CET