SC Profile Manager dev blog


Activity Log – Week #5

Posted in Profile Manager GUI,Profile Manager System by scprofile on June 25, 2008

Just two weeks before the first evaluation period. During the first part of the week, I’ve corrected my singleton problem. In fact, I’ve abandoned it for two reasons :
1. Technical problem : the OSGi framework search the class in his bundle list before in the classpath
2. Optimizing performance : reading the file two times, take a little time and there no need to keep it in memory.

Now that I can get information in the framework, the development restart.

Here is the current status of the system :

  • In the launcher of SC, the system read the profiles file and get informations.
    IF there is no file THEN a new profile is created and to make the transition invisible, the system move all the files and directories in the new profile directory.
    Currently, the frame asking the user to choose a profile isn’t ready.
  • In the program, the interface has been added in the Configuration Frame. It allow the user to manages the profiles within SC : creating a new profile, renaming or deleting a existing one BUT not the current one (since the name is used in the default profile directory name).
    All the dialogs are ready, I just need to write the remaining actions.

This is the list of the points I wish to end before the next week :

  • finish the dialogs
  • finish the texts in the dialogs
  • allow the user to change of profile in the configuration Frame

Task that need to be done before the evaluation period :

  • The frame in the launcher to choose a profile a the start of the program

Activity log – Week #X

Posted in Profile Manager GUI,Profile Manager System by scprofile on June 20, 2008

I lost the track of the week number.

During the lasts weeks, I rewrite a little part of my code. The system is integrated in the launcher. At the present time, if there isn’t any profile on the computer, the program create a default one, it also move the old configuration files in the profile. Like this the user won’t notice the integration of the system.

I began to create the interfaces. The first one, will be integrated in the configuration dialog. This interface will also used at the very start of the program of ask the user to select a profile. The interface is ready but I got some problem while importing my main package and a duplication of a singleton class, so no data are imported.

The others interfaces for deleting and renaming profiles are also ready, I just need to link with main package.

In the next weeks, I will try to solve the problem and create the last interface to add a profile.

Profile Manager Implementation details

Posted in General by scprofile on June 13, 2008

I’ve think of a system which is based between the services : Configuration and FileAccess and the utils.

What is needed :
– an access to the files specifics to a profile
– an access to the common files of all the profiles

Objectif :
– Create a system bundle which will manage profiles and their datas
– Minimize all the modifications which need to be done on the FileAccessService and ConfigurationService

Modifications of the services

FileAccessService

Methods : (FileAccessServiceImpl)
– getPrivatePersistentFile
– getPrivatePersistentDirectory
– getScHomeDirLocation

Now by default, we use the profile directory to store and read the persistents files and directories. Consequently we need to add some methods for the common files and directories.

New prototypes :
public File getPrivatePersistentFile(String fileName)                        // Not changed
public File getCommonPersistentFile(String fileName)                        // New
private File getPrivatePersistentFile(String fileName, boolean commom)

The two first methods call the third one and set the last parameter.
The same system goes from the getPrivatePersistentDirectory method.

I have some interogations from the last method, what should we return ? the common home directoy ou the profile directory ?

ConfigurationService

The big question is : do we need to save common data in the configuration file or we let the plugins handle that with persistant files ?

Methods :
– createConfigurationFile
– getScHomeDirName
– getScHomeDirLocation

Creation of a new system service (System Bundle)

From my current investigation here is the methods of the ProfileService :
– getScCommonHomePath()
– getScProfileHomePath()
– getCurrentProfileName()
– getCurrentProfileId()
– getProfilesList()
– getProfile(String profileId)

– useLastProfile() –> boolean
– setUseLastProfile(boolean b)

– generateProfileId()
– generateProfilePath(String id, String name)

– addProfile(String id, String name, String path)
– updateProfileName(String id, String newName)
– deleteProfile(String id)

First start of the program

There are two models :
– Like Eclipse : we ask the user to create a profile and by default the checkbox to use a profile by default a every start isn’t checked.
– Like Firefox : we create a profile named “default” and use this profile by default. Later, the user can create anothers profiles and set to ask for a profile a the start of the program.

I think of using the Firefox model, it’s more userfriendly.

Main questions :
– how to block the start of the program to ask which profile it must use ?
– how to reboot all the settings when the user ask from another profile ?

GUI

Main frame

A new item in a menu (probably File) to switch profile. May be, also, add the profile name in the title bar (if the profile is default, it’s not displayed).

Profile Manager GUI

A system bundle merged with the ProfileService or a plugin.

A GUI to manage the profiles (add, update name, delete), define if the programm must ask for a profile at start and select another profile.

Default profile path : ~/.sip-communicator/SC-profile.id
The profile id is generated from the current date timestamp converted in an hexaform.

The user can also set another path but he need the rights to write.