[DEVELOPERS] Renaming all the GUI files

[Sarah Mount]

I've been thinking about how best we might go about managing all the
GUI files for open-ihm. At the moment it isn't always clear which .ui
files in designs/ go with which .py files in interfaces/. Also, the
naming scheme isn't always consistent, some things are frm_thingy and
some frmthingy and so on. I think this would be confusing for a new
developer.

I've had a go at trying to refactor all these names, the result is in
a cloned repository here: http://code.google.com/r/mountsarah-openihm/

The naming scheme I've adopted looks like this:

1) All .ui files and .py files are in one directory

2) Every .ui file should have a corresponding .py file with the same
name (up to the file extension)

3) The names are made of up the name of that part of the model that
the dialog box is concerned with and a verb which describes what the
dialog is for. For example, household_add should add a household to
the current project, etc.

If you want to use this, just pull my changes from my repo into your
current working directory, merge them with your current code and push
to the usual IHM repository. However, I've held off doing this myself
for several reasons...

1) The changes I've made need testing

2) I'm not sure if I've correctly named each dialog, as I've only
looked briefly in the code in each file. For example, it looks from
the code like there are two files which could be called household_edit
(and there are a few other cases like this). So, the files need
checking by someone who understands the code a bit better than me.

3) You may prefer a different naming scheme, in which case go for that!

4) There are two files called ui_SOMETHING that seem to be left over.
Are we using them?

Also, I've renamed all the files, it would also be worth renaming the
classes inside this files...

Cheers,

Sarah

--
Sarah Mount, Senior Lecturer, University of Wolverhampton
website:  http://www.snim2.org/
twitter: @snim2

[Sarah Mount]

What happened to all this refactoring work?

[celia petty]

Thanks Sarah. One question: could these changes have any impact on the working of open-ihm? ie is there potential to destabilise the software if (for example) someone in SHA updates their software when this work is going on?
I will be working with Hosea in Kenya next week, where we may be installing open-ihm on new computers, and we must have a stable version while we're in the field. I know this also relates to the need for a 'developers' branch-as far as I know we don't yet have this?
Celia
ps could you add Wolf to googlegroups-thanks.

[Sarah Mount]

I was just trying to find out what happened to this code and whether
or not it has already been merged in somewhere.

I've added Wolf to both mailing lists, but he will need to send me an
email address for a Google Account to go on the wiki / issues list /
etc for both projects.

Sarah

> --

[snim2]

Now that the QiP programme is under way, it really is essential to find out what happened to this refactoring and whether anyone used it / merged it into default or any other branch. 

On Saturday, 11 August 2012 14:20:21 UTC+1, snim2 wrote:

I was just trying to find out what happened to this code and whether
or not it has already been merged in somewhere.

I've added Wolf to both mailing lists, but he will need to send me an
email address for a Google Account to go on the wiki / issues list /
etc for both projects.

Sarah

[Sarah Mount]

Again, I would really appreciate it if someone could tell me whether this refactoring work ever got looked at or merged in to any branches?