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


I tend to like the general idea of moving the publicly-available methods to 
handle equalizer to a component. On the other hand this is IMO a good 
opportunity to clean up the current design which I consider messy. I know that 
you've mainly just added an interface, so I will be mostly criticising existing 
code, but hey. :-)


src/EqualizerController.h
<http://git.reviewboard.kde.org/r/106511/#comment15245>

    code style:
    a) first own header (in case of .cpp file), then Amaork headers using the 
""-style, preferrably relative to [source-dir]/src, then KDE includes, then Qt 
includes. Include groups separated by blank lines



src/EqualizerController.h
<http://git.reviewboard.kde.org/r/106511/#comment15248>

    This lacks documentation with some high-level overview and usage.



src/EqualizerController.h
<http://git.reviewboard.kde.org/r/106511/#comment15246>

    If EquelizerController is accessible through Amarok::Components, don't 
implement the singleton pattern. The same applies to The::equalizer().
    
    You may want to wait however till we discuss how to deal with components 
and their lifetime in Randa.



src/EqualizerController.h
<http://git.reviewboard.kde.org/r/106511/#comment15250>

    All methods lack documentation, which is unacceptable for a component.
    
    From the names it seems that EqualizerController would solve 2 purposes:
    
    a) getting and setting the currently used equalizer preset
    b) store for equalizer presets
    
    Is it a good idea to combine these into one controller? Maybe yes, but I'd 
like to hear the reasoning.
    
    I also dislike the whole EqulizerPresets class. Why there's no 
EqualizerPreset class that would contain the values and name? I think that it 
would make EqualizerController interface cleaner.
    
    Comments on individual methods:
     * int presetNum() const; void setPreset(int number) const: seems redundant 
with the name-base methods.
     * QString presetName() const; should be named currentPresetName()? Ideally 
this would be EqualizerPreset currentPreset() const;
     * void setPreset(QString name) const; should be named activatePreset? I 
would love it it would accept "const EqualizerPreset &preset" instead.
    
     * const EqualizerPresets presets() const; -> QList<EqualizerPreset> 
savedPresets() const;? Also returning const by value has no sense.
     * void setPresetValues(const QString name, const QList<int>& values); -> 
void savePreset( const EqualizerPreset &preset );?
     * bool deletePreset(const QString name); Why bool? Should it take name or 
const EqualizerPreset &preset as an argument?
     * bool restorePreset(const QString name); what does this do?
    
    My suggestion for the EqualizerPreset class:
    
    .h file:
    
    class EqualizerPreset
    {
        public:
            EqualizerPreset( const QString &name, const QList<int> &values )
        
            QString name() const;
            void setName();
    
            QList<int> values() const;
            void setValues( const QList<int> &values );
            void setValue( int index, int value );  // convenience
    
            operator==( const EqualizerPreset &other ) const;
    
        private:
            class Private;
            QSharedDataPointer<Private> d;
    }
    
    .cpp file:
    
    class EqualizerPreset::Private {
        public:
            QString name;
            QList<int> values;
    }



src/EqualizerController.h
<http://git.reviewboard.kde.org/r/106511/#comment15247>

    Deprecated, see above.


- Matěj Laitl


On Sept. 20, 2012, 12:27 a.m., Ryan McCoskrie wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106511/
> -----------------------------------------------------------
> 
> (Updated Sept. 20, 2012, 12:27 a.m.)
> 
> 
> Review request for Amarok.
> 
> 
> Description
> -------
> 
> This patch moves much of the Equalizer Dialogues internal behaviour into a 
> dedicated object accessed via The::equalizer()*. Any component of Amarok 
> looking to adjust equalizer levels (i.e. The equalizer scripting support I'll 
> resubmit some day) should use this interface.
> 
> I'm considering as my next steps, merging the EqualizerPresets class with the 
> EqualizerController class and possibly removing dependence on AmarokConfig to 
> make the actual changes..
> 
> *The equalizer dialogue is accessed via The::equalizerDialog()
> 
> 
> Diffs
> -----
> 
>   src/CMakeLists.txt 8596144 
>   src/EqualizerController.h PRE-CREATION 
>   src/EqualizerController.cpp PRE-CREATION 
>   src/MainWindow.cpp 0530fd7 
>   src/core/support/Components.h c38977c 
>   src/core/support/Components.cpp 22e5de0 
>   src/dialogs/EqualizerDialog.h 9dad055 
>   src/dialogs/EqualizerDialog.cpp 3a63fe6 
> 
> Diff: http://git.reviewboard.kde.org/r/106511/diff/
> 
> 
> Testing
> -------
> 
> Checked that Amarok compiles and that the equalizer dialogue still works. 
> Found that enabling/dis-enabling the equalizer forces the track to freeze or 
> restart. Pressing stop and then play will make it continue with the correct 
> preset enabled.
> 
> 
> Thanks,
> 
> Ryan McCoskrie
> 
>

_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel

Reply via email to