Review Request: Adding Accessibility Interfaces for Dolphin Views & Widgets

[Frank Reininghaus]

Hi everyone,

2012/9/22 Frederik Gladhorn:
>
> This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105972/
>
> Ship it!

in my opinion, the "Ship It!" button should be pressed only by the
maintainer or another core developer of the application. I have
clearly stated in my review that some parts of the request are not
acceptable in the current form, in particular adding the public
function KItemListView::layouter(). I have offered to test the new
feature and then change the public API of the affected classes in a
better way, but nobody bothered to comment on my statement that the
build system of KMag, which is required to test the feature, is broken
and that I can't build it. Maybe you expected me to fix KMag myself. I
could have done this, of course, but I really don't have much time for
working on Dolphin, and I prefer to spend it working on the items on
my own (very long) TODO-list.

What I find even more unfortunate than the unacceptable unautorised
push is the way the changes show up in the history now. I actually
like tools like "git log", "git blame", and qgit a lot, I like it when
the history looks clean, and I always thought that the main point of
review requests is to bring the proposed change in a form that can be
included in one, or maybe a few, logically structured commits. But the
history is now a big ugly mess. Having commits like, e.g.,

https://projects.kde.org/projects/kde/kde-baseapps/repository/revisions/e6d4a935c8d03dcfda65e0b2f92d243b18a411e3/diff

in the repository is really pointless. I know that this commit has
been done after comments from me, but the version of the files that
did not respect the coding style should not have been pushed to the
public repository in the first place. The space that these dozens of
pointless commits take up in the repository is maybe not a big concern
nowadays, but they make examining the history (which I sometimes do to
find the cause of a regression) very, very painful.

Well, the damage has been done, and there is no way to fix it now. But
I kindly ask you not to do any major changes in Dolphin code, in
particular changes in header files, ever again without discussing this
with the Dolphin core maintainers and getting approval. Thanks for
your understanding.

Another point that we have not discussed yet is who will maintain the
accessibility classes in the future. If this code is included in
Dolphin, I want to know who will take care of any bugs that users will
find.

Frank