Places/StatusMeetings/2007-02-08

From MozillaWiki
Jump to: navigation, search
[2:02pm] sspitzer: ok, meeting time?
[2:02pm] sspitzer: I actually have a question to raise!
[2:03pm] v_thunder: meeting time.
[2:03pm] v_thunder: what's your question?
[2:03pm] sspitzer: ok:
[2:03pm] sspitzer: so, with history side bar and the bookmarks side bar
[2:03pm] sspitzer: and probably also with the organize bookmark dialog
[2:04pm] sspitzer: we have issues persisting the expanded/collapsed state of containers
[2:04pm] sspitzer: this used to persist in localstore.rdf, back in fx 2.
[2:04pm] sspitzer: but, in fx 3 land
[2:04pm] sspitzer: we have a nsITreeView
[2:04pm] sspitzer: not on top of the xul template builder
[2:05pm] sspitzer: so, where should we persist the state of containers?  note, it is per view. 
[2:05pm] dietrich joined the chat room.
[2:05pm] sspitzer: let me copy and paste that to dietrich.
[2:05pm] sspitzer: sspitzerok, meeting time?
[2:05pm] sspitzer: sspitzerI actually have a question to raise!
[2:05pm] sspitzer: v_thundermeeting time.
[2:05pm] sspitzer: v_thunderwhat's your question?
[2:05pm] sspitzer: sspitzerok:
[2:05pm] sspitzer: sspitzerso, with history side bar and the bookmarks side bar
[2:05pm] sspitzer: sspitzerand probably also with the organize bookmark dialog
[2:05pm] sspitzer: sspitzerwe have issues persisting the expanded/collapsed state of containers
[2:05pm] sspitzer: sspitzerthis used to persist in localstore.rdf, back in fx 2.
[2:05pm] sspitzer: sspitzerbut, in fx 3 land
[2:05pm] sspitzer: sspitzerwe have a nsITreeView
[2:05pm] sspitzer: sspitzernot on top of the xul template builder
[2:05pm] sspitzer: sspitzerso, where should we persist the state of containers?  note, it is per view. 
[2:05pm] sspitzer: *dietrich (dietrich@moz-A8CDE328.office.mozilla.org) has joined #places
[2:06pm] sspitzer: oops
[2:06pm] sspitzer: that was supposed to be in a private msg to dietrich.
[2:06pm] v_thunder: :)
[2:06pm] dietrich: i got it anyways :)
[2:07pm] dietrich: treeview attributes cannot be persisted in localstore.rdf?
[2:10pm] dietrich: http://developer.mozilla.org/en/docs/XUL:tree#a-statedatasource
[2:11pm] dietrich: although yeah that's not per view
[2:11pm] sspitzer: take the bookmarks sidebar, we are resetting the view
[2:11pm] dietrich: we'll need state elsewhere as well, like the MRU folders for the addbookmarks dialog, and such
[2:11pm] sspitzer: actually, the "place" attribute, right?
[2:11pm] sspitzer: on a search.
[2:12pm] sspitzer: so we will be doing a new query
[2:12pm] sspitzer: but the open/close state of containers is lost when we go back to the non-search place
[2:14pm] sspitzer: additionally, state is persisted between sessions for the same reason.  (if I expand a bookmarks folder in the sidebar in fx 2, exit and restart, that persists.)
[2:14pm] sspitzer: (I'm thinking about fx 2 ui compatibility)
[2:14pm] v_thunder: yeah, we need that
[2:15pm] v_thunder: I'm not sure I understand, though
[2:15pm] sspitzer: in fx 2, since we are using the xul tempalte builder, we have content that we can persist attribute on
[2:15pm] v_thunder: if I set satedatasource in the bookmarks tree
[2:15pm] v_thunder: will that save what we want?
[2:16pm] v_thunder: except for searches
[2:16pm] myk: sspitzer: could you annotate the state?
[2:18pm] sspitzer: interesting, for fx 2
[2:18pm] sspitzer: this is how it appears to work:
[2:18pm] sspitzer:  <RDF:Description RDF:about="rdf:#$6wPhC3"
[2:18pm] sspitzer:                   NC:open="true" />
[2:18pm] sspitzer: that's in my localstore.rdf for every bookmark in the bookmark side bar that is open
[2:19pm] philor joined the chat room.
[2:20pm] v_thunder: so, we'd need dietrich's patch to do something similar?
[2:20pm] v_thunder: or does that id not refer to a bookmark the way I'm thinking?
[2:24pm] sspitzer: note, in fx 2
[2:24pm] sspitzer: that persisted state
[2:24pm] sspitzer: affected the organize bookmarks dialog as well
[2:24pm] sspitzer: which makes sense, if you look at what we are persisting:
[2:24pm] sspitzer: this bookmark container is "open"
[2:25pm] sspitzer: about myks point
[2:25pm] sspitzer: thinking about the history sidebar
[2:25pm] sspitzer: we don't have places for the groups-by-date and group-by-site containers
[2:26pm] sspitzer: the way that state was persisted in fx 2 was
[2:26pm] sspitzer:  <RDF:Description RDF:about="find:datasource=history&match=AgeInDays&method=is&text=0&groupby=Hostname"
[2:26pm] sspitzer:                   NC:open="true" />
[2:27pm] Mano: it's per contaner or per view?
[2:27pm] sspitzer: per container
[2:27pm] Mano: if it's per each container we can use anno's or the db itself
[2:27pm] Mano: s/each/
[2:27pm] sspitzer: not per view.
[2:28pm] Mano: note: fx2 also does so for history
[2:28pm] sspitzer: yes
[2:28pm] sspitzer: see my comment above
[2:28pm] Mano: anno's are the harder way to this.
[2:28pm] Mano: yet another field to the db.
[2:28pm] myk: sspitzer: it's not per-container and per-view?
[2:29pm] sspitzer: it is per container
[2:29pm] sspitzer: it is not per view
[2:29pm] sspitzer: I confirmed, noticing how an expanded state of a container effects side bar and organize bookmarks dialog
[2:29pm] sspitzer: (but not, of course, the personal toolbar, which is also a view)
[2:29pm] sspitzer: (but state doesn't persist there)
[2:30pm] Mano: toolbar has no treeview object though ;)
[2:30pm] sspitzer: menu.xml, right
[2:30pm] sspitzer: (toolbar.xml?)
[2:30pm] sspitzer: I've spent too much time on the MOZILLA_1_8_BRANCH!
[2:30pm] Mano: both, really
[2:31pm] sspitzer: can we use the localstore.rdf to persist this attribute:  given a place url (since all nodes in the history sidebar tree, bookmarks sidebar tree, and organize bookmakrs dialog), store the state?
[2:31pm] sspitzer: like we do in fx 2?
[2:31pm] Mano: I don't think we should
[2:32pm] Mano: our trees are not RDF based
[2:32pm] sspitzer: we shouldn't or we can't?
[2:32pm] sspitzer: about using the db (for either an anno or a field)
[2:33pm] sspitzer: what about history containers?
[2:33pm] sspitzer: those aren't in the db.
[2:33pm] Mano: sspitzer: hosts/"days" are not in the db!?
[2:34pm] Mano: i.e. you cannot annonate a host?
[2:35pm] sspitzer: they are not in the db
[2:35pm] sspitzer: we create the result container
[2:36pm] sspitzer: http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsNavHistory.cpp#3369
[2:36pm] sspitzer: on the fly
[2:36pm] sspitzer: (you could come up with a unique place: uri for each one, I think)
[2:36pm] sspitzer: same with host
[2:36pm] sspitzer: does that make sense?
[2:37pm] Mano: well, can you annonate based on a place: uri
[2:37pm] sspitzer: don't we exlcude them, or is that only in history?
[2:37pm] sspitzer: (I think only in history)
[2:38pm] Mano: exculde what?
[2:38pm] dietrich left the chat room. (Connection reset by peer)
[2:38pm] dietrich joined the chat room.
[2:38pm] sspitzer: but, will the place: for the container be in db?
[2:38pm] sspitzer: we'll have ot add it.
[2:38pm] sspitzer: we exlude place: urls from the history results
[2:38pm] Mano: ah.
[2:38pm] Mano: dietrich would know.
[2:39pm] sspitzer: I should know the answer here, but I'll demonstrate my ignorance once again:
[2:40pm] sspitzer: I think mailnews has a similar problem
[2:40pm] sspitzer: I think the persist the state in their db.
[2:40pm] sspitzer: (for thread state)
[2:40pm] sspitzer: I'll ping mscott / bienvenu for some insight
[2:42pm] sspitzer: back to our problem, I'll log some bugs
[2:42pm] Mano: sspitzer: you had a chance to look at the tree-view update bug?
[2:42pm] sspitzer: about fx 2 ui parity with container state persistenace
[2:43pm] sspitzer: Mano:  not yet, what was the bug #?  I'm a little behind on reviews, sorry.
[2:43pm] Mano: sspitzer: bug, not a patch.
[2:43pm] Mano: sspitzer: bug 366136
[2:44pm] firebot: Mano: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=366136 nor, --, ---, nobody@mozilla.org, NEW, organize bookmarks dialog (for --enable-places-bookmarks) New items don't appear in the tree view as
[2:44pm] Mano: might be affected by bug 369253  as well
[2:44pm] firebot: Mano: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=369253 nor, --, Firefox 3 alpha2, dietrich@mozilla.com, NEW, Rebuild isssues in the toolbar view
[2:46pm] Mano: incremental update seems to be generally broken, esp. for trees.
[2:47pm] sspitzer: I have no looked at this stuff yet.  is this the thing we thought was a cocoa bug, but really, it;s a place bug?
[2:47pm] sspitzer: s/place/places?
[2:47pm] Mano: right
[2:48pm] philor left the chat room. (Ping timeout)
[2:48pm] sspitzer: ok, sorry, I have not gotten to it yet.
[2:48pm] sspitzer: it affects tree and toolbar
[2:49pm] Mano: by the way,
[2:49pm] Mano: we need to make the toolbar folder a child of the bookmark menu folder
[2:49pm] Mano: for Fx2-parity.
[2:57pm] mconnor: so it shows up in the bookmark menu?
[2:57pm] Mano: right
[3:00pm] Mano: and at the same point rename the bookmarks menu folder back to Bookmarks.
[3:17pm] Mano: dietrich: can you land your patch from https://bugzilla.mozilla.org/show_bug.cgi?id=367035
[3:17pm] firebot: Mano: Bug 367035 nor, P2, Firefox 3 alpha2, mano@mozilla.com, RESO FIXED, No "Bookmark This Tab" and "Bookmark All Tabs" menuitms in the tabbar context menu
[3:28pm] sspitzer: Mano:  dietrich stpped out, but he's coming back
[3:28pm] sspitzer: Mano:  let's take the discussion about persistance to bugzilla, I'll log a bug and cc you guys
[3:29pm] Mano: ok, cool.
[3:31pm] sspitzer: anything else today?  sorry to hijack this meeting
[3:31pm] sspitzer: I have plans to land dmills patch in about 30 minutes
[3:39pm] v_thunder: woo patch landing
[3:39pm] v_thunder: thanks
[3:50pm] dietrich left the chat room. (Connection reset by peer)
[3:50pm] dietrich joined the chat room.
[4:01pm] dietrich left the chat room. (Ping timeout)
[4:09pm] dietrich joined the chat room.
[4:12pm] stevee left the chat room. (Quit: Miranda Instant Messenger -- icq/msn/aim/yahoo/irc/etc -- small, free & powerful -- www.miranda-im.org)
[4:37pm] sspitzer left the chat room. (Quit: This computer has gone to sleep)
[4:38pm] sspitzer joined the chat room.
[5:28pm] You left the chat by being disconnected from the server.
[5:30pm] sspitzer: [17:06] oops
[5:30pm] sspitzer: [17:07] that was supposed to be in a private msg to dietrich.
[5:30pm] v_thunder: [17:07] :)
[5:30pm] dietrich: [17:07] i got it anyways :)
[5:30pm] dietrich: [17:07] treeview attributes cannot be persisted in localstore.rdf?
[5:30pm] dietrich: [17:11] http://developer.mozilla.org/en/docs/XUL:tree#a-statedatasource
[5:30pm] dietrich: [17:11] although yeah that's not per view
[5:30pm] sspitzer: [17:12] take the bookmarks sidebar, we are resetting the view
[5:30pm] dietrich: [17:12] we'll need state elsewhere as well, like the MRU folders for the addbookmarks dialog, and such
[5:30pm] sspitzer: [17:12] actually, the "place" attribute, right?
[5:30pm] sspitzer: [17:12] on a search.
[5:30pm] sspitzer: [17:12] so we will be doing a new query
[5:30pm] sspitzer: [17:13] but the open/close state of containers is lost when we go back to the non-search place
[5:30pm] sspitzer: [17:14] additionally, state is persisted between sessions for the same reason.  (if I expand a bookmarks folder in the sidebar in fx 2, exit and restart, that persists.)
[5:30pm] sspitzer: [17:14] (I'm thinking about fx 2 ui compatibility)
[5:30pm] v_thunder: [17:15] yeah, we need that
[5:30pm] v_thunder: [17:15] I'm not sure I understand, though
[5:30pm] sspitzer: [17:16] in fx 2, since we are using the xul tempalte builder, we have content that we can persist attribute on
[5:30pm] v_thunder: [17:16] if I set satedatasource in the bookmarks tree
[5:30pm] v_thunder: [17:16] will that save what we want?
[5:30pm] v_thunder: [17:16] except for searches
[5:30pm] myk: [17:17] sspitzer: could you annotate the state?
[5:30pm] sspitzer: [17:19] interesting, for fx 2
[5:30pm] sspitzer: [17:19] this is how it appears to work:
[5:30pm] sspitzer: [17:19]  <RDF:Description RDF:about="rdf:#$6wPhC3"
[5:30pm] sspitzer: [17:19]                    NC:open="true" />
[5:30pm] sspitzer: [17:19] that's in my localstore.rdf for every bookmark in the bookmark side bar that is open
[5:30pm] #places: [17:19] philor (ringnalda@moz-D69C69A1.eug.or.uspops.net) joined the channel
[5:30pm] v_thunder: [17:20] so, we'd need dietrich's patch to do something similar?
[5:30pm] v_thunder: [17:21] or does that id not refer to a bookmark the way I'm thinking?
[5:30pm] sspitzer: [17:24] note, in fx 2
[5:30pm] sspitzer: [17:24] that persisted state
[5:30pm] sspitzer: [17:25] affected the organize bookmarks dialog as well
[5:30pm] sspitzer: [17:25] which makes sense, if you look at what we are persisting:
[5:30pm] sspitzer: [17:25] this bookmark container is "open"
[5:30pm] sspitzer: [17:25] about myks point
[5:30pm] sspitzer: [17:26] thinking about the history sidebar
[5:30pm] sspitzer: [17:26] we don't have places for the groups-by-date and group-by-site containers
[5:30pm] sspitzer: [17:27] the way that state was persisted in fx 2 was
[5:30pm] sspitzer: [17:27]  <RDF:Description RDF:about="find:datasource=history&match=AgeInDays&method=is&text=0&groupby=Hostname"
[5:30pm] sspitzer: [17:27]                    NC:open="true" />
[5:30pm] Mano: [17:27] it's per contaner or per view?
[5:30pm] sspitzer: [17:28] per container
[5:30pm] Mano: [17:28] if it's per each container we can use anno's or the db itself
[5:30pm] Mano: [17:28] s/each/
[5:30pm] sspitzer: [17:28] not per view.
[5:30pm] Mano: [17:28] note: fx2 also does so for history
[5:30pm] sspitzer: [17:28] yes
[5:30pm] sspitzer: [17:28] see my comment above
[5:30pm] Mano: [17:28] anno's are the harder way to this.
[5:30pm] Mano: [17:29] yet another field to the db.
[5:30pm] myk: [17:29] sspitzer: it's not per-container and per-view?
[5:30pm] sspitzer: [17:29] it is per container
[5:30pm] sspitzer: [17:29] it is not per view
[5:30pm] sspitzer: [17:30] I confirmed, noticing how an expanded state of a container effects side bar and organize bookmarks dialog
[5:30pm] sspitzer: [17:30] (but not, of course, the personal toolbar, which is also a view)
[5:30pm] sspitzer: [17:30] (but state doesn't persist there)
[5:30pm] Mano: [17:30] toolbar has no treeview object though ;)
[5:30pm] sspitzer: [17:30] menu.xml, right
[5:30pm] sspitzer: [17:31] (toolbar.xml?)
[5:30pm] sspitzer: [17:31] I've spent too much time on the MOZILLA_1_8_BRANCH!
[5:30pm] Mano: [17:31] both, really
[5:30pm] sspitzer: [17:31] can we use the localstore.rdf to persist this attribute:  given a place url (since all nodes in the history sidebar tree, bookmarks sidebar tree, and organize bookmakrs dialog), store the state?
[5:30pm] sspitzer: [17:32] like we do in fx 2?
[5:30pm] Mano: [17:32] I don't think we should
[5:30pm] Mano: [17:32] our trees are not RDF based
[5:30pm] sspitzer: [17:33] we shouldn't or we can't?
[5:30pm] sspitzer: [17:33] about using the db (for either an anno or a field)
[5:30pm] sspitzer: [17:33] what about history containers?
[5:30pm] sspitzer: [17:33] those aren't in the db.
[5:30pm] Mano: [17:34] sspitzer: hosts/"days" are not in the db!?
[5:30pm] Mano: [17:34] i.e. you cannot annonate a host?
[5:30pm] sspitzer: [17:36] they are not in the db
[5:30pm] sspitzer: [17:36] we create the result container
[5:30pm] sspitzer: [17:36] http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsNavHistory.cpp#3369
[5:30pm] sspitzer: [17:36] on the fly
[5:30pm] sspitzer: [17:37] (you could come up with a unique place: uri for each one, I think)
[5:30pm] sspitzer: [17:37] same with host
[5:30pm] sspitzer: [17:37] does that make sense?
[5:30pm] Mano: [17:37] well, can you annonate based on a place: uri
[5:30pm] sspitzer: [17:38] don't we exlcude them, or is that only in history?
[5:30pm] sspitzer: [17:38] (I think only in history)
[5:30pm] Mano: [17:38] exculde what?
[5:30pm] #places: [17:38] dietrich (dietrich@moz-A8CDE328.office.mozilla.org) joined the channel
[5:30pm] sspitzer: [17:38] but, will the place: for the container be in db?
[5:30pm] sspitzer: [17:38] we'll have ot add it.
[5:30pm] sspitzer: [17:38] we exlude place: urls from the history results
[5:30pm] Mano: [17:39] ah.
[5:30pm] Mano: [17:39] dietrich would know.
[5:30pm] sspitzer: [17:40] I should know the answer here, but I'll demonstrate my ignorance once again:
[5:30pm] sspitzer: [17:40] I think mailnews has a similar problem
[5:30pm] sspitzer: [17:40] I think the persist the state in their db.
[5:30pm] sspitzer: [17:40] (for thread state)
[5:30pm] sspitzer: [17:41] I'll ping mscott / bienvenu for some insight
[5:30pm] sspitzer: [17:42] back to our problem, I'll log some bugs
[5:30pm] Mano: [17:43] sspitzer: you had a chance to look at the tree-view update bug?
[5:30pm] sspitzer: [17:43] about fx 2 ui parity with container state persistenace
[5:30pm] sspitzer: [17:43] Mano:  not yet, what was the bug #?  I'm a little behind on reviews, sorry.
[5:30pm] Mano: [17:44] sspitzer: bug, not a patch.
[5:30pm] Mano: [17:44] sspitzer: bug 366136
[5:30pm] firebot: [17:44] Mano: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=366136 nor, --, ---, nobody@mozilla.org, NEW, organize bookmarks dialog (for --enable-places-bookmarks) New items don't appear in the tree view as
[5:30pm] Mano: [17:44] might be affected by bug 369253  as well
[5:30pm] firebot: [17:44] Mano: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=369253 nor, --, Firefox 3 alpha2, dietrich@mozilla.com, NEW, Rebuild isssues in the toolbar view
[5:30pm] Mano: [17:47] incremental update seems to be generally broken, esp. for trees.
[5:30pm] sspitzer: [17:48] I have no looked at this stuff yet.  is this the thing we thought was a cocoa bug, but really, it;s a place bug?
[5:30pm] sspitzer: [17:48] s/place/places?
[5:30pm] Mano: [17:48] right
[5:30pm] sspitzer: [17:48] ok, sorry, I have not gotten to it yet.
[5:30pm] sspitzer: [17:49] it affects tree and toolbar
[5:30pm] Mano: [17:49] by the way,
[5:30pm] Mano: [17:50] we need to make the toolbar folder a child of the bookmark menu folder
[5:30pm] Mano: [17:50] for Fx2-parity.
[5:30pm] mconnor: [17:57] so it shows up in the bookmark menu?
[5:30pm] Mano: [17:58] right
[5:30pm] Mano: [18:01] and at the same point rename the bookmarks menu folder back to Bookmarks.
[5:30pm] Mano: [18:17] dietrich: can you land your patch from https://bugzilla.mozilla.org/show_bug.cgi?id=367035
[5:30pm] firebot: [18:17] Mano: Bug 367035 nor, P2, Firefox 3 alpha2, mano@mozilla.com, RESO FIXED, No "Bookmark This Tab" and "Bookmark All Tabs" menuitms in the tabbar context menu
[5:30pm] sspitzer: [18:28] Mano:  dietrich stpped out, but he's coming back
[5:30pm] sspitzer: [18:29] Mano:  let's take the discussion about persistance to bugzilla, I'll log a bug and cc you guys
[5:30pm] Mano: [18:30] ok, cool.
[5:30pm] sspitzer: [18:32] anything else today?  sorry to hijack this meeting
[5:30pm] sspitzer: [18:32] I have plans to land dmills patch in about 30 minutes
[5:30pm] v_thunder: [18:39] woo patch landing
[5:30pm] v_thunder: [18:39] thanks