AdapterItemIds are too complicated. about gxui HOT 10 CLOSED

@crawshaw - I know you're still getting up to speed on this, but I'd appreciate any feedback you might have.

from gxui.

This is one of the things I was talking about in #26 and masking in interface{} is how I did this in https://github.com/dskinner/ui/blob/master/recycler.go#L35

though in that case, I masked the actual retrieval with a Selector interface that would be implemented on an adapter that is also composable with a Filterer interface (optionally implemented on the adapter).

The intent there is to trigger the filter action on the list and respond appropriately with animations and also be able to compose default implementations for some things with minimal developer input.

In the same breath, this could all be done on an adapter and the developer could keep around references for both the adapter and list, filter the adapter, and then notify the list.

My 2 cents

from gxui.

Removing the IDs and using equality on a user-defined type LGTM.

A few other related thoughts I've been having:

• I believe the Adaptor index is a flattened view of all of the children. Is this worth it? An adaptor could just index its direct children, and leave it up to the person querying the children to descend into the children.
• Only doing direct descendants raises the possibility of making Adapter a concrete type with a linked list in it, and it containing a general interface with the element/theme-specific implementation. For example, see how the html package represents nodes: http://godoc.org/golang.org/x/net/html#Node
• I can't think of a practical situation where you would want more than one theme operating in a process. That leads to a tempting simplification: create a global variable that holds the active theme. A lot of parameters could be removed.

Curious to hear what you think, but none of these thoughts should block this change. (I would usually send this to a mailing list, but we seem to be using github issues like a mailing list. We can keep trying this new world.)

from gxui.

Only doing direct descendants raises the possibility of making Adapter a
concrete type with a linked list in it

I think its a mistake to assume that just b/c a developer writes an adapter
that reports N items, that all of those items are actually loaded into
memory.

On Fri, Mar 20, 2015 at 3:06 PM David Crawshaw [email protected]
wrote:

Removing the IDs and using equality on a user-defined type LGTM.

A few other related thoughts I've been having:

I believe the Adaptor index is a flattened view of all of the
children. Is this worth it? An adaptor could just index its direct
children, and leave it up to the person querying the children to descend
into the children.

Only doing direct descendants raises the possibility of making Adapter
a concrete type with a linked list in it, and it containing a general
interface with the element/theme-specific implementation. For example, see
how the html package represents nodes:
http://godoc.org/golang.org/x/net/html#Node

I can't think of a practical situation where you would want more than
one theme operating in a process. That leads to a tempting simplification:
create a global variable that holds the active theme. A lot of parameters
could be removed.

Curious to hear what you think, but none of these thoughts should block
this change. (I would usually send this to a mailing list, but we seem to
be using github issues like a mailing list. We can keep trying this new
world.)

—
Reply to this email directly or view it on GitHub
https://github.com/google/gxui/issues/46#issuecomment-84131387.

from gxui.

Just because the adaptor instances exist doesn't mean a heavier, app specific backing object needs to have fully loaded.

It seems like a significant investment to parameterize these designs by "may be bigger than system memory". Millions of items can be easily represented in tens of megabytes. It is not obviously worth it to me for a UI system to cater to more than that.

Considering this a little more: one case where bigger than system memory comes up is editing files. I expect any decent text editor to be able to open a 10GB file. However there is no concept in such an editor that would create an enormous Adaptor. You cannot even count lines in a file if you expect to be able to load one of arbitrary size. And where you could, you could create a lot of objects.

from gxui.

hundreds of megabytes is easily represented by tens of items. Exploring
mobile, such concerns may be more valid when conflated with other UI, not
just "may be bigger than system memory".

On Fri, Mar 20, 2015 at 3:16 PM David Crawshaw [email protected]
wrote:

Just because the adaptor instances exist doesn't mean a heavier, app
specific backing object needs to have fully loaded.

It seems like a significant investment to parameterize these designs by
"may be bigger than system memory". Millions of items can be easily
represented in tens of megabytes. It is not obviously worth it to me for a
UI system to cater to more than that.

—
Reply to this email directly or view it on GitHub
https://github.com/google/gxui/issues/46#issuecomment-84133658.

from gxui.

• I believe the Adaptor index is a flattened view of all of the children. Is this worth it? An adaptor could just index its direct children, and leave it up to the person querying the children to descend into the children.

I'm guessing you're referring to the TreeAdapterNode?

If so - no, the index parameter of ItemAt is the index into the immediate descendants of that node [0 - Count-1]. ItemIndex is a little more complicated, in that it will return the index of the immediate descendants with that item or if that child contains the item indirectly.

• Only doing direct descendants raises the possibility of making Adapter a concrete type with a linked list in it, and it containing a general interface with the element/theme-specific implementation. For example, see how the html package represents nodes: http://godoc.org/golang.org/x/net/html#Node

If I follow you correctly, this doesn't really seem much like my idea of an Adapter, but more like another concrete wrapper around the dataset. I agree with @dskinner on this - one of the big wins with this interface is that data can be streamed. This is something that we could really benefit from on our project that uses GXUI.

• I can't think of a practical situation where you would want more than one theme operating in a process. That leads to a tempting simplification: create a global variable that holds the active theme. A lot of parameters could be removed.

Humm, interesting idea. I can't really think of one situation either. I'll mull it over.

(I would usually send this to a mailing list, but we seem to be using github issues like a mailing list. We can keep trying this new world.)

On my 4th day of using GitHub, I'm actually quite liking it. Some aspects of code-reviews is a bit clunky, but given how angry Gerrit has been making me recently, this is actually quite refreshing. I'm also liking the markdown links - it works really nicely.
Shall we give it another week and see?

from gxui.

For what it's worth, +1 on global theme. Referencing multiple themes sounds
wrong, but a theme that can reference multiple themes sound like how that
should go if the functionality was needed.

On Fri, Mar 20, 2015 at 4:08 PM Ben Clayton [email protected]
wrote:

• I believe the Adaptor index is a flattened view of all of the
  children. Is this worth it? An adaptor could just index its direct
  children, and leave it up to the person querying the children to descend
  into the children.

  I'm guessing you're referring to the TreeAdapterNode
  https://github.com/google/gxui/blob/rm_itemids/tree_adapter.go#L11?

If so - no, the index parameter of ItemAt
https://github.com/google/gxui/blob/rm_itemids/tree_adapter.go#L13 is
the index into the immediate descendants of that node [0 - Count
https://github.com/google/gxui/blob/rm_itemids/tree_adapter.go#L12-1].
ItemIndex
https://github.com/google/gxui/blob/rm_itemids/tree_adapter.go#L14 is a
little more complicated, in that it will return the index of the immediate
descendants with that item or if that child contains the item
indirectly.

• Only doing direct descendants raises the possibility of making
  Adapter a concrete type with a linked list in it, and it containing a
  general interface with the element/theme-specific implementation. For
  example, see how the html package represents nodes:
  http://godoc.org/golang.org/x/net/html#Node

  If I follow you correctly, this doesn't really seem much like my idea of
  an Adapter, but more like another concrete wrapper around the dataset. I
  agree with @dskinner https://github.com/dskinner on this - one of the
  big wins with this interface is that data can be streamed. This is
  something that we could really benefit from on our project that uses GXUI.

• I can't think of a practical situation where you would want more
  than one theme operating in a process. That leads to a tempting
  simplification: create a global variable that holds the active theme. A lot
  of parameters could be removed.

  Humm, interesting idea. I can't really think of one situation either.
  I'll mull it over.

(I would usually send this to a mailing list, but we seem to be using
github issues like a mailing list. We can keep trying this new world.)

On my 4th day of using GitHub, I'm actually quite liking it. Some aspects
of code-reviews is a bit clunky, but given how angry Gerrit has been making
me recently, this is actually quite refreshing. I'm also liking the
markdown links - it works really nicely.
Shall we give it another week and see?

—
Reply to this email directly or view it on GitHub
https://github.com/google/gxui/issues/46#issuecomment-84147440.

from gxui.

If you have a practical application of a streaming adaptor that obviously trumps any theoretical argument I can make.

(I'm still, more broadly, hunting for a way to mixins.)

from gxui.

Branch merged.

from gxui.