Review Request 109188: Moved actions and groups creation into separate functions in main widget

Roman Nazarenko me at jtalk.me
Wed Feb 27 17:57:28 UTC 2013



> On Feb. 27, 2013, 5:34 p.m., David Edmundson wrote:
> > main-widget.h, line 101
> > <http://git.reviewboard.kde.org/r/109188/diff/1/?file=116082#file116082line101>
> >
> >     confugures -> configures
> >     
> >     
> >     if we convert this into 
> >     
> >     KAction * createAction(const QString& text, QObject *signalReceiver, const char *slot, bool isChecked);
> >     
> >     which is the same as it is now, but calls "new KAction(this)" at the start
> >     
> >     
> >     It's basically the same as the ctor of ActionOptions but keeping logic grouped together

That was the first version I've written, exactly.
I rejected it. I think, it's really a bad practice to allocate objects implicitly. We cannot say, where exactly the actions is taken from, untill we look into realization. This one is clear: it takes an action, applies options to it and returns configured action back. You don't need to read through sources to find it out. 
The second goal: we need to set some actions chechable before setupAction is called. According to Qt documentation, setCheckable(true) must be called before setChecked(). 


> On Feb. 27, 2013, 5:34 p.m., David Edmundson wrote:
> > main-widget.h, line 102
> > <http://git.reviewboard.kde.org/r/109188/diff/1/?file=116082#file116082line102>
> >
> >     this then becomes QList<KAction*> and gets simplified.

Then we need to create actions outside. We also need to make it checkable outside. And the purpose of this function - avoiding 6 copy-paste code pieces in one method - will be completely ruined.


> On Feb. 27, 2013, 5:34 p.m., David Edmundson wrote:
> > main-widget.h, line 90
> > <http://git.reviewboard.kde.org/r/109188/diff/1/?file=116082#file116082line90>
> >
> >     Making a struct that mimics all the properties of a KAction doesn't make a lot of sense to me. We're duplicating data, data duplication leads to problems.
> >

I really tried to avoid that. I know it looks like a crooked nail, but I haven't invented something more reliable. Any ideas? 


- Roman


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109188/#review28206
-----------------------------------------------------------


On Feb. 27, 2013, 10:29 a.m., Roman Nazarenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109188/
> -----------------------------------------------------------
> 
> (Updated Feb. 27, 2013, 10:29 a.m.)
> 
> 
> Review request for Telepathy.
> 
> 
> Description
> -------
> 
> There was 6 identical routines creating actions for "Contact List Type" and "Shown contacts" menus. 
> I made one universal routine to do that, one routine to build those two groups and one struct as an options tuple.
> 
> 
> Diffs
> -----
> 
>   main-widget.h be7004d 
>   main-widget.cpp 39442de 
> 
> Diff: http://git.reviewboard.kde.org/r/109188/diff/
> 
> 
> Testing
> -------
> 
> Tried to toggle all those actions in both standard and global menus.
> Have not tested "Shown contacts" since I have no blocked ones.
> 
> 
> Thanks,
> 
> Roman Nazarenko
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20130227/d7a05645/attachment-0001.html>


More information about the KDE-Telepathy mailing list