Re: whitespace / patch to access resource->units from GUI

Regarding whitespace, here is a list of files I currently have local 
changes in:

M      libplanner/mrp-task.c
M      libplanner/mrp-project.c
M      libplanner/mrp-task.h
M      libplanner/mrp-project.h
M      libplanner/mrp-assignment.c
M      libplanner/mrp-assignment.h
M      libplanner/mrp-resource.c
M      libplanner/mrp-resource.h
M      libplanner/mrp-error.h
M      src/planner-task-dialog.h
M      src/planner-cmd-manager.c
M      src/planner-cmd-manager.h
M      src/planner-gantt-row.c
M      src/planner-usage-row.c
M      src/planner-resource-dialog.c
M      src/planner-task-tree.c
M      src/Makefile.am
M      src/Makefile.win32
M      src/planner-project-properties.c
M      src/planner-task-dialog.c

I know I went a bit quiet -- I have spent some time on Antarctica, and 
communication from there is difficult. However, as shown above, I have 
come back to a series of patches here which give a simple working 
resource levelling algorithm, and an infrastructure which will allow 
more to be added. Hopefully now I'll be able to continue releasing these 
to the list in sensible chunks for review and any corrections.

I'll start where Maurice left off in his mail of 13/12/8:

Maurice van der Pot wrote:
> Apart from the change to a percentage that you already said you were
> going to do, I have a few more comments:
>   
Despite saying I would do this, I've been thinking about it with 
reference to my resource units patches and I think we need to revisit 
this decision.

To quickly recap, this bug relates to whether there should be a 
percentage sign on the dialog when ASSIGNING a resource to a task, 
against the 'units' entry.

Before I submitted these patches to allow users to set the maximum 
number of units available to a resource, adding a percentage sign  
seemed like a sensible solution -- 100 was hard coded into planner as 
the maximum number of units which could be assigned per resource, so 
obviously when choosing how much of a resource to assign it was a 
percentage.

However, now users can change whether 100 is the maximum number of 
allocatable units. This brings us to a question: what does the Units 
entry on the dialog when ASSIGNING a resource to a task now mean?

There are two answers I can think of to this question - I'll illustrate 
them with a resource which has a maximum number of allocatable units of 134:

1) Units is a user definable feature, so when the assignment dialog asks 
about the number of units to assign, you pick a number between 0 and the 
maximum number of units defined on the resource (134). in this case, you 
are choosing the number of units to assign, which does not necessarily 
have to be a percentage of anything! In order to completely assign the 
resource to the task, you would enter 134 in this field.

2) Units is a percentage of the maximum allocatable units, so if you 
want to completely assign the resource's 134 units to the task, you 
would enter 100 in this field.

In trying to decide which one of these situations makes most sense, I am 
biased slightly by what is going on in the code, and of course the code 
doesn't deal with percentages at all - it deals with allocated and 
maximum units, and works out whether things are overallocated by adding 
up units. If we made this field a percentage, it would actually add 
another step to the code, because the code will have to work out the 
number of units which have been allocated based on the percentage and 
the maximum units.

However, I also think it is better from a user perspective to think 
about units - If, as a user, you have decided the maximum number of 
units is not going to be 100 for whatever reason (e.g. 134), I think you 
are more likely to want to specify the number of these units (e.g. 34) 
when performing allocations to tasks, instead of guessing at a 
percentage of your new maximum (34 units out of a maximum of 134 would 
be 25.373%).

In light of this, perhaps the better solution to bug #387985 is to 
explain the flexibility of these fields in more depth, either in the 
manual or with a tooltip, instead of just tagging '%' in the GUI.

Any thoughts?
> - I get a couple of these:
>   (planner:9050): Gtk-WARNING **: GtkSpinButton: setting an adjustment
>   with non-zero page size is deprecated
>   
I couldn't reproduce this error (presumably it occurs at run time?) but 
quick google showed the likely cause, which I have fixed in the attached 
revised patch.
> - The value of available units defaults to 0. Should that be 100?
>   
I did consider making it 100, but in the end my feeling was that the 
principle of least surprise probably meant it was better left at zero 
for now -- the reason being that the units field has *existed* on 
resources for some time in xml (it has just not been possible to set), 
and that it has been set to zero by default in existing xml files.

If we change the default to 100, opening a legacy planner file will lead 
to this value being zero for all existing resources. If a user then 
creates a new resource in the legacy file, it would be set to 100. There 
will then be resources with different maximum units, which is probably 
not what the user expects and may cause confusion (especially once I 
submit patches which start making use of this variable).

One alternative is that we attempt to automatically update the available 
units values saved in legacy planner xml files, but I don't think we 
have the right to do this -- I feel it should be left to the user to 
alter their work.

Any thoughts? In any case, it is still an easy fix if we decide that 
having 100 by default is a better route to take.
> - Available units should also be added as a column to the resource view
>   
Similar to the point above, the trouble with this item is that people 
using planner already have a config file saved in their .planner 
directory which does not include the available units column in the 
resource view's 'visible columns'. So, whilst my patch actually *does*  
expose the column in resource view, people who have ran planner before 
on their machine still have to manually update their .planner files by 
clicking on view, 'edit visible columns'.

New users of the planner application, however, will automatically see 
the available units field, as demonstrated by deleting your .planner 
directory and restarting planner.

I don't really have any ideas about how we might fix this without 
automatically updating people's .planner directory entries, and again, I 
don't think it is right for us to mess with the contents of that 
directory -- perhaps the best we can do is mention in the changelog the 
need for users to manually edit their visible columns?
> - Eventually the number of available units should also be exported to
>   HTML, but that can stay on the TODO list for now. Speaking of which,
>   it may be useful to add such a file to the repository. It could
>   contain things like this that we postpone for now but need to solve
>   for the next release and that do not have a bugzilla entry.
>   
OK, I can do this - do you just want a plain text file or should we do 
something following GNOME todo list XML standards like the output of gtodo?
> Thanks,
> Maurice.
>   
Thanks, and more to come!

>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Planner-dev-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/planner-dev-list
>

_______________________________________________
Planner-dev-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/planner-dev-list

Index: data/glade/resource-dialog.glade
===================================================================
--- data/glade/resource-dialog.glade	(revision 940)
+++ data/glade/resource-dialog.glade	(working copy)
@@ -60,7 +60,7 @@
 	    <widget class="GtkTable" id="table1">
 	      <property name="border_width">12</property>
 	      <property name="visible">True</property>
-	      <property name="n_rows">6</property>
+	      <property name="n_rows">7</property>
 	      <property name="n_columns">2</property>
 	      <property name="homogeneous">False</property>
 	      <property name="row_spacing">6</property>
@@ -334,6 +334,56 @@
 		  <property name="y_options"></property>
 		</packing>
 	      </child>
+	      <child>
+		<widget class="GtkLabel" id="label_units">
+		  <property name="visible">True</property>
+		  <property name="label" translatable="yes">Available _Units:</property>
+		  <property name="use_underline">True</property>
+		  <property name="use_markup">False</property>
+		  <property name="justify">GTK_JUSTIFY_LEFT</property>
+		  <property name="wrap">False</property>
+		  <property name="selectable">False</property>
+		  <property name="xalign">0</property>
+		  <property name="yalign">0.5</property>
+		  <property name="xpad">0</property>
+		  <property name="ypad">0</property>
+		  <property name="mnemonic_widget">units_spinbutton</property>
+		  <property name="ellipsize">PANGO_ELLIPSIZE_NONE</property>
+		  <property name="width_chars">-1</property>
+		  <property name="single_line_mode">False</property>
+		  <property name="angle">0</property>
+		</widget>
+		<packing>
+		  <property name="left_attach">0</property>
+		  <property name="right_attach">1</property>
+		  <property name="top_attach">6</property>
+		  <property name="bottom_attach">7</property>
+		  <property name="x_options">fill</property>
+		  <property name="y_options"></property>
+		</packing>
+	      </child>
+	      <child>
+		<widget class="GtkSpinButton" id="units_spinbutton">
+		  <property name="visible">True</property>
+		  <property name="tooltip" translatable="yes">The maximum units available for a resource without overloading it.</property>
+		  <property name="can_focus">True</property>
+		  <property name="climb_rate">1</property>
+		  <property name="digits">0</property>
+		  <property name="numeric">False</property>
+		  <property name="update_policy">GTK_UPDATE_ALWAYS</property>
+		  <property name="snap_to_ticks">False</property>
+		  <property name="wrap">False</property>
+		  <property name="adjustment">100 0 9999 1 10 0</property>
+		</widget>
+		<packing>
+		  <property name="left_attach">1</property>
+		  <property name="right_attach">2</property>
+		  <property name="top_attach">6</property>
+		  <property name="bottom_attach">7</property>
+		  <property name="y_options"></property>
+		</packing>
+	      </child>
+	      
 	    </widget>
 	    <packing>
 	      <property name="tab_expand">False</property>