[openbeos] Re: Networks Preferences

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 14 Apr 2008 22:20:36 +0200

Hi Dario,

Casalinuovo Dario wrote:
> hi, i have fixed style and other issues reported by Stephan, i think that 
> the code is clean.

thanks for the revised patch!

> about the question of settings system, i am confused, because i don't 
> understand if i started off on the right foot :
> is my work a good start?

Yes, it is a good start, though I am hesitant to apply it as is, because 
these GUI changes are not backed up by any functionality yet and people 
will be left wondering when they use the Network preflet.

Do you know anything about the Model<->View design pattern? It means you 
need to design non-gui classes which 1) hold the data, ie network 
configuration data and 2) allow to modify this data according to the needs 
of the functionality you are trying to implement. The GUI is just a view 
onto that data model and adapts to changes.

Here is a simple example of how this concept can be applied:

Let's start with an example of how not to do it, ie the "wrong" case (in 
semi-pseudo code):

class NetworkView {
...
BTextControl*   fIPAddress;
BTextControl*   fNetMask;
...

        void LoadConfig()
        {
                open some file...
                read and parse contents...
                fIPAddress->SetText(ipString);
                ...
                fNetMask->SetText(netMaskString);
                ...
        }

        void SaveConfig()
        {
                open some file...
                file.Write(fIPAddress->Text(), strlen(fIPAddress->Text()));
                ...
                file.Write(fNetMask->Text(), strlen(fNetMask->Text()));
                ...
        }
};

In the above example, the data is right in the GUI. There is no separate 
model of the data. This is bad. Here is a better way, you already see this 
started in the current Network preflet code:


class EthernetSettings {
public:
        void SetIP(const char* ip)
        {
                fIP = ip;
        }
        const char* IP() const
        {
                return fIP.String();
        }
        ...
private:
        BString fIP;
        BString fNetMask;
};

class NetworkView {
...
BTextControl*   fIPAddress;
BTextControl*   fNetMask;
EthernetSettings* fCurrentSettings;
...

        void SetTo(const EthernetSettings* settings)
        {
                ...
                fIPAddress->SetText(settings->IP());
                fNetMask->SetText(settings->NetMask());
                ...
        }

        void ApplyChanges()
        {
                ...
                fCurrentSettings->SetIP(fIPAddress->Text());
                fCurrentSettings->SetNetmask(fNetMask->Text());
                ...
                SaveSettings(fCurrentSettings);
        }

        void RevertChanges()
        {
                SetTo(fCurrentSettings);
        }
};

See how easy it is now to revert any changes? This is because data and GUI 
are separated. What I tried to explain in my last message was, that your 
next step would be designing these data classes. They are going to be 
hierarchically structured. You need to make a list of requirements, like so:

* Settings are hierachical
* Subsettings can shadow certain paramters of ther parent settings
* SubSettings can be shared among multiple parent settings (?)
* ...(don't remember more right now)

You need to study Waldemar's design proposal (the non-GUI part of it) and 
make a complete list of requirements that you extract from it. And then you 
need to design your data classes accordingly. Once you have designed them 
properly, it will become trival to change the settings from the GUI. The 
hard part is the design, the implementation is not that hard once you have 
a full understanding of how all the requirements will be handled by your 
design.

Best regards,
-Stephan



Other related posts: