Review Request: Adding Accessibility Interfaces for Dolphin Views & Widgets

Frederik Gladhorn gladhorn at kde.org
Sat Sep 22 23:34:55 BST 2012


Hello Frank,

On Sunday 23. September 2012 00.10.38 Frank Reininghaus wrote:
> 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 forgot this was an open point. We will look into this tomorrow, maybe we can 
find a solution that you will find acceptable.

> 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/e6d4
> a935c8d03dcfda65e0b2f92d243b18a411e3/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.

I completely agree. Sorry for the big mess, we'll be more careful to rebase 
and squash the next time.

> 
> 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.
Sorry again.

> 
> 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.
I assume Amandeep will keep an eye on this area. I will try to fix bugs when it 
comes to accessibility myself as much as I can, so please ask me to fix 
regressions in the code.

Greetings
Frederik


> 
> Frank




More information about the kfm-devel mailing list