java-gnome-hackers

[java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnome/gtk TODO.gtk,1.38,1.39

[Mark H. <mh...@ca...>]

On Tue, Feb 17, 2004 at 01:58:19PM -0800, Jeffrey S. Morgan wrote:
> Added another GTK review

That's an awful lot of work to do. Jeff - I'm really struggling for time
at the moment - my uni work is now quite far behind and is just getting
worse at the moment, so I've not been able to spend much time on
java-gnome.  The situation will not improve before the release
unfortunately. 

I have one question about your comments from this code review:
why do you want treemodel to be an interface that liststore and
treestore implements rather than having them simply extend treemodel.
You would have to duplicate basically everything from treemodel to the
two store classes to make this change. Is it really worth it?

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] RE: [Java-gnome-checkins] CVS: java-gnome/gtk TODO.gtk,1.38,1.39

[Jeffrey M. <Jef...@Br...>]

> On Tue, Feb 17, 2004 at 01:58:19PM -0800, Jeffrey S. Morgan wrote:
> > Added another GTK review
> 
> That's an awful lot of work to do. Jeff - I'm really 
> struggling for time
> at the moment - my uni work is now quite far behind and is 
> just getting
> worse at the moment, so I've not been able to spend much time on
> java-gnome.  The situation will not improve before the release
> unfortunately. 

This is a lot to accomplish and I am not sure all of it can be
completed prior to the beta.  I plan to focus on the following:

1) Over the weekend I hope to focus on the critical miscellaneous
items listed in the TODO.gtk file.
2) The tree control and related classes are a critical component
of the bindings.  Since Mark is busy I plan to spend next week
working on these classes.  Mark, you could really help by sending
an email that would provide an overview of these classes, how they
work together, what you were able to complete and what remains.  

During my review I added that we should change a couple of the 
classes to Interfaces since they are implemented this way in gtk. 
I did this for FileChooser and implemented a FileChooserHelper 
class to actually implement those methods so there was no 
duplication of code.  Does this make sence for the Tree widgets?

Also, I am not real happy with the class name DataBlock.  What these 
really represent are column types.  I know this would break
a lot of code but we should discuss this before our API freeze.
Could we change this to something like ColumnType?  Also, could
these be stored as members of the store so calls to setValue
would not need to pass them as a parameter.  setValue could then
just pass a 0 based column number. 

Let me know what you think.

-Jeff

 NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended
only for the use of the individuals or entity to which it is addressed. If
you are not the intended recipient, or the person responsible for delivering
the message to the intended recipient, please return or delete it
immediately. Although this e-mail and any attachments are believed to be
free of any virus or other defect, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by us for
any loss or damage arising in any way from its unauthorized modification or
use.

[java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnome/gtk TODO.gtk,1.38,1.39

['Mark H. <mh...@ca...>]

On Fri, Feb 20, 2004 at 10:23:48AM -0500, Jeffrey Morgan wrote:
> 2) The tree control and related classes are a critical component
> of the bindings.  Since Mark is busy I plan to spend next week
> working on these classes.  Mark, you could really help by sending
> an email that would provide an overview of these classes, how they
> work together, what you were able to complete and what remains.  
I'll try but I'm not sure when.

> During my review I added that we should change a couple of the 
> classes to Interfaces since they are implemented this way in gtk. 
> I did this for FileChooser and implemented a FileChooserHelper 
> class to actually implement those methods so there was no 
> duplication of code.  Does this make sence for the Tree widgets?
I guess. We should probably do the same for the sortable interface for
trees.

> Also, I am not real happy with the class name DataBlock.  What these 
> really represent are column types.  I know this would break
> a lot of code but we should discuss this before our API freeze.
> Could we change this to something like ColumnType? Also, could
> these be stored as members of the store so calls to setValue
> would not need to pass them as a parameter.  setValue could then
> just pass a 0 based column number. 
1) Having two things called columns related to the same widget is
confusing. TreeViews have columns (things you see) and treemodels have
columns (for storing a particular type of data). Perhaps DataColumn or
DataStoreColumn would be better? It is not merely a ColumnType since the
integer value refers to a particular column; however, it is not an
object which stores the data of a column, just acts like a pointer to
the data.
DataBlock might not be the best name, but I still think it's better than
ColumnType. 

2) By using these rather than integers, we can enforce that the correct
type of object is being passed to setValue/getValue and so can overload
them.  I think this is the most important point. 

3) Having named object rather than integers is far more intuitive when
programming.

What do you think?

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] RE: [Java-gnome-checkins] CVS: java-gnome/gtk TODO.gtk,1.38,1.39

[Jeffrey M. <Jef...@Br...>]

> On Fri, Feb 20, 2004 at 10:23:48AM -0500, Jeffrey Morgan wrote:
> > 2) The tree control and related classes are a critical component
> > of the bindings.  Since Mark is busy I plan to spend next week
> > working on these classes.  Mark, you could really help by sending
> > an email that would provide an overview of these classes, how they
> > work together, what you were able to complete and what remains.  
> I'll try but I'm not sure when.
> 
> > During my review I added that we should change a couple of the 
> > classes to Interfaces since they are implemented this way in gtk. 
> > I did this for FileChooser and implemented a FileChooserHelper 
> > class to actually implement those methods so there was no 
> > duplication of code.  Does this make sence for the Tree widgets?
> I guess. We should probably do the same for the sortable interface for
> trees.

Do you think this is a wise move?  You know better than anybody how
complex these 

> 
> > Also, I am not real happy with the class name DataBlock.  
> What these 
> > really represent are column types.  I know this would break
> > a lot of code but we should discuss this before our API freeze.
> > Could we change this to something like ColumnType? Also, could
> > these be stored as members of the store so calls to setValue
> > would not need to pass them as a parameter.  setValue could then
> > just pass a 0 based column number. 
> 1) Having two things called columns related to the same widget is
> confusing. TreeViews have columns (things you see) and treemodels have
> columns (for storing a particular type of data). Perhaps DataColumn or
> DataStoreColumn would be better? 

DataStoreColumn seems fine to me.  What does everybody else think?

> It is not merely a 
> ColumnType since the
> integer value refers to a particular column; however, it is not an
> object which stores the data of a column, just acts like a pointer to
> the data.
> DataBlock might not be the best name, but I still think it's 
> better than
> ColumnType. 
> 
> 2) By using these rather than integers, we can enforce that 
> the correct
> type of object is being passed to setValue/getValue and so 
> can overload
> them.  I think this is the most important point. 

Good point.  I agree.

> 3) Having named object rather than integers is far more intuitive when
> programming.

Yes.  

> 
> What do you think?
> 
> -- 
>   .''`. Mark Howard
>  : :' :
>  `. `'  http://www.tildemh.com 
>    `-   mh...@de... | mh...@ti... | mh...@ca... 
> 

 NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended
only for the use of the individuals or entity to which it is addressed. If
you are not the intended recipient, or the person responsible for delivering
the message to the intended recipient, please return or delete it
immediately. Although this e-mail and any attachments are believed to be
free of any virus or other defect, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by us for
any loss or damage arising in any way from its unauthorized modification or
use.

[java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnome/gtk TODO.gtk,1.38,1.39

['Mark H. <mh...@ca...>]

Sorry for being a so slow with everything. I'm afraid I have to put
applying for jobs and doing uni work above java-gnome, even though those
things are a lot less fun.

On Fri, Feb 20, 2004 at 03:39:23PM -0500, Jeffrey Morgan wrote:
> > On Fri, Feb 20, 2004 at 10:23:48AM -0500, Jeffrey Morgan wrote:
> > > 2) The tree control and related classes are a critical component
> > > of the bindings.  Since Mark is busy I plan to spend next week
> > > working on these classes.  Mark, you could really help by sending
> > > an email that would provide an overview of these classes, how they
> > > work together, what you were able to complete and what remains.  
I think you know how they work already - there are also the javadocs if
you're unsure. I've not been able to complete much. What remains is
documented in the todo. 
The ones with the *'s are the most important. I think it's probably best
to leave the others for 2.8 - we don't have time for them. I have no
idea when I'll get time to do any of these, so please do take them if
you can. All that's really needed at this stage is the API design, but
it might require looking deep into the gtk documentation and possibly
even example apps in some cases. I will of course check anything and do
tend to spend time writing emails even when I don't have the time, so
feel free to ask me questions.

** SelectionData enhancements are almost certainly needed for treeDrag*
  TreeModel
****   The "rows-reordered" signal
	  row-changed signal
  TreePath 
	  various new methods
  TreeIter
**  - add ref to treeModel
**  - include many methods from treemodel
  TreeSelection
   // TODO: GtkTreeSelectionFunc ()
   // gtk_tree_selection_set_select_function ()
   tk_tree_selection_unselect_range
  TreeViewColumn
   gtk_tree_view_column_set_cell_data_func() (complex)
**  sort_column_id - should this be dataBlock??
*  gtk_tree_view_column_focus_cell  - since 2.2
  TreeView
   gtk_tree_view_map_expanded_rows ( ?? is it useful?
   gtk_tree_view_enable_model_drag_dest - ??
   gtk_tree_view_enable_model_drag_source -??
   gtk_tree_view_unset_rows_drag_source -??
   gtk_tree_view_unset_rows_drag_dest -??
   gtk_tree_view_set_drag_dest_row - no
   gtk_tree_view_get_drag_dest_row -no
   gtk_tree_view_get_dest_row_at_pos - no
   gtk_tree_view_set_search_equal_func - surely this is not useful?
*  signals: row-activated, row-collapsed, row-expanded
  TreeModelSort ('implements' treemodel and treesortable)
   -don't bother
  TreeModelFilter ('implements' treemdel)
   -complex - questionable
  CellLayout
   - GtkCellLayout is implemented by GtkTreeViewColumn, GtkEntryCompletion, GtkComboBoxEntry and GtkComboBox.
   - leave for 2.8? what's it for?
* CellEditable
*  implemented by GtkEntry and GtkSpinButton.
*  editing-done" signal
  CR Text
+	  - add lots of setProperty methods
	  - type enforcement for attributes??



> > > During my review I added that we should change a couple of the 
> > > classes to Interfaces since they are implemented this way in gtk. 
> > > I did this for FileChooser and implemented a FileChooserHelper 
> > > class to actually implement those methods so there was no 
> > > duplication of code.  Does this make sence for the Tree widgets?
> > I guess. We should probably do the same for the sortable interface for
> > trees.
> 
> Do you think this is a wise move?  You know better than anybody how
> complex these 
I'm not really sure what benefit it brings.
At the moment, ListStore and TreeStore will be the only TreeModels. We
will probably never have support for people to write their own in java
(as is commonly done in c). What benefits are there? I think we should
leave it for trees TBH - there are no immediate benefits and changing
this in the future would not be API-incompatible. 
Please check where treemodelfilter fits in though - i think it is a
wrapper class, but I'm not certain.

> > > Also, I am not real happy with the class name DataBlock.  
DataColumn sounds great. We should update the documentation sometime.
Have you looked at gtkmm documentation - it's very impressive.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] RE: [Java-gnome-checkins] CVS: java-gnome/gtk TODO.gtk,1.38,1.39

['Mark H. <mh...@ca...>]

On Fri, Feb 20, 2004 at 03:39:23PM -0500, Jeffrey Morgan wrote:
> DataStoreColumn seems fine to me.  What does everybody else think?

In case you're interested, it seems gtkmm do the same thing - they've
called them Gtk::TreeModelColumnBase classes. 
(I've found a few methods using ints still - I was checking that they
should be datacolumns. I will fix this now.)

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca...