Places/StatusMeetings/2007-02-08
From MozillaWiki
< Places | StatusMeetings
[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