D19095: Adding new Variable models for few backends

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> rbackend.cpp:73
> +
> +    if (RServerSettings::variableManagement())
> +        cap |= VariableManagement;

Why do you want to have this as an configurable parameter? Why not to always enable and use the variable model?

> rhighlighter.h:38
>    public Q_SLOTS:
> -    void refreshSyntaxRegExps();
> -    void updateHighlighting();
> -
> -  Q_SIGNALS:
> -    void syntaxRegExps(QVector<QRegExp>&,QVector<QRegExp>&);
> +    void addUserVariable(const QStringList& vars);
> +    void removeUserVariable(const QStringList& vars);

let's move the declaration of these functions to Cantor::DefaultHighlighter and make them abstract. All deriving classes should provide an implementation for them.

> rhighlighter.h:47
>  
> +    void addUserStuff(const QStringList& names, QVector<QRegExp>& vector);
> +    void removeUserStuff(const QStringList& names, QVector<QRegExp>& vector);

let's use "Definition" instead of "Stuff". Sounds better.

> rvariablemodel.h:39
> +  Q_SIGNALS:
> +    void functionsAdded(const QStringList& names);
> +    void functionsRemoved(const QStringList& names);

can the signals be made part of the base class?

REPOSITORY
  R55 Cantor

REVISION DETAIL
  https://phabricator.kde.org/D19095

To: sirgienko, asemke
Cc: kde-edu, asemke, narvaez, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20190222/b704f8a5/attachment.html>