Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: Dries Status: patch Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 23:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the new and required markers to look the same). Someone with enough time on his hands might be able to partition the new marker to a real new marker and a changed marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is. Goba Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 22:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the new and required markers to look the same). Someone with enough time on his hands might be able to partition the new marker to a real new marker and a changed marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. ------------------------------------------------------------------------ January 27, 2005 - 07:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) ------------------------------------------------------------------------ January 27, 2005 - 08:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers2.patch (7.29 KB) Wups, forgot to adjust one usage of node_is_new(). Plus renamed it to node_marker(), since it is not anymore only about checking on whether it is new or not... Goba Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 22:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the new and required markers to look the same). Someone with enough time on his hands might be able to partition the new marker to a real new marker and a changed marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. ------------------------------------------------------------------------ January 27, 2005 - 07:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) ------------------------------------------------------------------------ January 27, 2005 - 08:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: ------------------------------------------------------------------------ January 27, 2005 - 12:41 : Goba Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is. ------------------------------------------------------------------------ January 27, 2005 - 13:57 : Dries Committed to HEAD. ------------------------------------------------------------------------ January 27, 2005 - 18:40 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers.patch (6.48 KB) Suprise :) In real incremental patching sense, here is a patch to introduce the different new and updated makers. It operates with passing on the info to theme('mark'), and then letting it decide on what to do with it. This also enables people to do 'read' markers, if so desired (displaying different icons for read, uread and updated content). Renamed the 'new' marker to 'content', so that it is not misleading, and introduced some constants, to help along the way. 'node' might be a better name instead of 'content', but it is just a search and replace in the patch, so Dries can fix it up, if needed. Also introduced the unkown maker for anonymous users. The practice before was that by setting the last view time to time(), markers are always displayed as 'read' for anonymous users. But with the different icons possibility in mind, it is important to distinguish the case when we cannot decide on whether a content is new/updated or not, because we have no data. This is why the unkown marker is introduced. I admit I have not tested the patch, but it should work well, theoretically. Kept the original interface behaviour, which does not expose much from the power of the markers, but preserves the currently expected output. -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Markers are only important for logged in users, yes. We need to somehow omit the markers. We can check for the user in theme_mark(), but we need to check for the user in node_marker() anyway, since otherwise we would do an unnecessery database lookup for each marker. So we can return MARKER_READ in node_marker() and omit the marker regardless of the $marker if the $type is 'new' and the user is not logged in. So we need to check for the user in the theme function too... BTW the terminology I introduced seems to be inconsitent: node_marker() vs. theme_mark(). It might be desireable to rename the theme function, or use MARK_ constants and node_mark(). Pick the way. Goba Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 22:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the new and required markers to look the same). Someone with enough time on his hands might be able to partition the new marker to a real new marker and a changed marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. ------------------------------------------------------------------------ January 27, 2005 - 07:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) ------------------------------------------------------------------------ January 27, 2005 - 08:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: ------------------------------------------------------------------------ January 27, 2005 - 12:41 : Goba Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is. ------------------------------------------------------------------------ January 27, 2005 - 13:57 : Dries Committed to HEAD. ------------------------------------------------------------------------ January 27, 2005 - 18:40 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers.patch (6.48 KB) Suprise :) In real incremental patching sense, here is a patch to introduce the different new and updated makers. It operates with passing on the info to theme('mark'), and then letting it decide on what to do with it. This also enables people to do 'read' markers, if so desired (displaying different icons for read, uread and updated content). Renamed the 'new' marker to 'content', so that it is not misleading, and introduced some constants, to help along the way. 'node' might be a better name instead of 'content', but it is just a search and replace in the patch, so Dries can fix it up, if needed. Also introduced the unkown maker for anonymous users. The practice before was that by setting the last view time to time(), markers are always displayed as 'read' for anonymous users. But with the different icons possibility in mind, it is important to distinguish the case when we cannot decide on whether a content is new/updated or not, because we have no data. This is why the unkown marker is introduced. I admit I have not tested the patch, but it should work well, theoretically. Kept the original interface behaviour, which does not expose much from the power of the markers, but preserves the currently expected output. ------------------------------------------------------------------------ January 27, 2005 - 18:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers2.patch (7.29 KB) Wups, forgot to adjust one usage of node_is_new(). Plus renamed it to node_marker(), since it is not anymore only about checking on whether it is new or not... ------------------------------------------------------------------------ January 27, 2005 - 19:57 : Anonymous Shouldn't 'MARKER_UNKOWN' be 'MARKER_UNKNOWN'? Why do we need an "unknown" possibility anyway? Wouldn't we just omit markers for anonymous users? -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: andremolnar Status: patch I think it might be helpful if you expanded the phpdocs for the constant definitions to describe when, where, how they are used. Right now the text only says 'Markers used to designate content.' andremolnar Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 21:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the <em>new</em> and <em>required</em> markers to look the same). Someone with enough time on his hands might be able to partition the <em>new</em> marker to a real <em>new</em> marker and a <em>changed</em> marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. ------------------------------------------------------------------------ January 27, 2005 - 06:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) ------------------------------------------------------------------------ January 27, 2005 - 07:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: <?php return t("The fields with a '%marker' are required to fill in.", array('%marker' => theme('mark', 'required'))); ?> Under the tables of tracker, node, comment, and whereever items/users or whatever may be marked as new, i expect: <?php return t("The fields with a '%marker' are new.", array('%marker' => theme('mark', 'new'))); return t("The fields with a '%marker' are updated.", array('%marker' => theme('mark', 'updated'))); ?> What do ou guys think? ------------------------------------------------------------------------ January 27, 2005 - 11:41 : Goba Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is. ------------------------------------------------------------------------ January 27, 2005 - 12:57 : Dries Committed to HEAD. ------------------------------------------------------------------------ January 27, 2005 - 17:40 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers.patch (6.48 KB) Suprise :) In real incremental patching sense, here is a patch to introduce the different new and updated makers. It operates with passing on the info to theme('mark'), and then letting it decide on what to do with it. This also enables people to do 'read' markers, if so desired (displaying different icons for read, uread and updated content). Renamed the 'new' marker to 'content', so that it is not misleading, and introduced some constants, to help along the way. 'node' might be a better name instead of 'content', but it is just a search and replace in the patch, so Dries can fix it up, if needed. Also introduced the unkown maker for anonymous users. The practice before was that by setting the last view time to time(), markers are always displayed as 'read' for anonymous users. But with the different icons possibility in mind, it is important to distinguish the case when we cannot decide on whether a content is new/updated or not, because we have no data. This is why the unkown marker is introduced. I admit I have not tested the patch, but it should work well, theoretically. Kept the original interface behaviour, which does not expose much from the power of the markers, but preserves the currently expected output. ------------------------------------------------------------------------ January 27, 2005 - 17:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers2.patch (7.29 KB) Wups, forgot to adjust one usage of node_is_new(). Plus renamed it to node_marker(), since it is not anymore only about checking on whether it is new or not... ------------------------------------------------------------------------ January 27, 2005 - 18:57 : Anonymous Shouldn't 'MARKER_UNKOWN' be 'MARKER_UNKNOWN'? Why do we need an "unknown" possibility anyway? Wouldn't we just omit markers for anonymous users? ------------------------------------------------------------------------ January 27, 2005 - 21:55 : Goba Markers are only important for logged in users, yes. We need to somehow omit the markers. We can check for the user in theme_mark(), but we need to check for the user in node_marker() anyway, since otherwise we would do an unnecessery database lookup for each marker. So we can return MARKER_READ in node_marker() and omit the marker regardless of the $marker if the $type is 'new' and the user is not logged in. So we need to check for the user in the theme function too... BTW the terminology I introduced seems to be inconsitent: node_marker() vs. theme_mark(). It might be desireable to rename the theme function, or use MARK_ constants and node_mark(). Pick the way. ------------------------------------------------------------------------ January 29, 2005 - 17:37 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers3.patch (7.42 KB) Since noone hinted on a way to pick, I needed to decide myself :) Gone is the unkown marker, and now it is the theme's task to not display content markers for anonymous users (while still keeping the required marker for them). The contants and functions were renamed to use 'mark' instead of 'marker' in line with the existing theme_mark() function. Still the same functionality, but with less code compared with the previous patch. -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: tangent Status: patch I find the new "content" state to be less meaningful than the old "new" state. The word "new" is an adjective while "content" is a noun which, to me, applies to everything. Perhaps "unread" would be a more appropriate state since that is the content that the marker identifies. tangent Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 16:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the <em>new</em> and <em>required</em> markers to look the same). Someone with enough time on his hands might be able to partition the <em>new</em> marker to a real <em>new</em> marker and a <em>changed</em> marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. ------------------------------------------------------------------------ January 27, 2005 - 01:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) ------------------------------------------------------------------------ January 27, 2005 - 02:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: <?php return t("The fields with a '%marker' are required to fill in.", array('%marker' => theme('mark', 'required'))); ?> Under the tables of tracker, node, comment, and whereever items/users or whatever may be marked as new, i expect: <?php return t("The fields with a '%marker' are new.", array('%marker' => theme('mark', 'new'))); return t("The fields with a '%marker' are updated.", array('%marker' => theme('mark', 'updated'))); ?> What do ou guys think? ------------------------------------------------------------------------ January 27, 2005 - 06:41 : Goba Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is. ------------------------------------------------------------------------ January 27, 2005 - 07:57 : Dries Committed to HEAD. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers.patch (6.48 KB) Suprise :) In real incremental patching sense, here is a patch to introduce the different new and updated makers. It operates with passing on the info to theme('mark'), and then letting it decide on what to do with it. This also enables people to do 'read' markers, if so desired (displaying different icons for read, uread and updated content). Renamed the 'new' marker to 'content', so that it is not misleading, and introduced some constants, to help along the way. 'node' might be a better name instead of 'content', but it is just a search and replace in the patch, so Dries can fix it up, if needed. Also introduced the unkown maker for anonymous users. The practice before was that by setting the last view time to time(), markers are always displayed as 'read' for anonymous users. But with the different icons possibility in mind, it is important to distinguish the case when we cannot decide on whether a content is new/updated or not, because we have no data. This is why the unkown marker is introduced. I admit I have not tested the patch, but it should work well, theoretically. Kept the original interface behaviour, which does not expose much from the power of the markers, but preserves the currently expected output. ------------------------------------------------------------------------ January 27, 2005 - 12:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers2.patch (7.29 KB) Wups, forgot to adjust one usage of node_is_new(). Plus renamed it to node_marker(), since it is not anymore only about checking on whether it is new or not... ------------------------------------------------------------------------ January 27, 2005 - 13:57 : Anonymous Shouldn't 'MARKER_UNKOWN' be 'MARKER_UNKNOWN'? Why do we need an "unknown" possibility anyway? Wouldn't we just omit markers for anonymous users? ------------------------------------------------------------------------ January 27, 2005 - 16:55 : Goba Markers are only important for logged in users, yes. We need to somehow omit the markers. We can check for the user in theme_mark(), but we need to check for the user in node_marker() anyway, since otherwise we would do an unnecessery database lookup for each marker. So we can return MARKER_READ in node_marker() and omit the marker regardless of the $marker if the $type is 'new' and the user is not logged in. So we need to check for the user in the theme function too... BTW the terminology I introduced seems to be inconsitent: node_marker() vs. theme_mark(). It might be desireable to rename the theme function, or use MARK_ constants and node_mark(). Pick the way. ------------------------------------------------------------------------ January 29, 2005 - 12:37 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers3.patch (7.42 KB) Since noone hinted on a way to pick, I needed to decide myself :) Gone is the unkown marker, and now it is the theme's task to not display content markers for anonymous users (while still keeping the required marker for them). The contants and functions were renamed to use 'mark' instead of 'marker' in line with the existing theme_mark() function. Still the same functionality, but with less code compared with the previous patch. ------------------------------------------------------------------------ January 29, 2005 - 15:52 : andremolnar I think it might be helpful if you expanded the phpdocs for the constant definitions to describe when, where, how they are used. Right now the text only says 'Markers used to designate content.' ------------------------------------------------------------------------ January 29, 2005 - 16:02 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers4.patch (7.53 KB) Updated patch, which links to theme_mark() and node_mark(). Otherwise I think the names of the constants really tell everything. -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: Dries Status: patch Removing the unknown-marker makes sense to me. Personally, I'd split the function theme_mark() because 'required' and 'content' (read/new/updated) are really two different things now. I'd hard-code the required part in theme_form_element() using proper CSS-classes. IMO, that would simplify the code and make it a tad more readable. (Initially, I couldn't figure out what the 'content' parameter was for.) Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 23:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the <em>new</em> and <em>required</em> markers to look the same). Someone with enough time on his hands might be able to partition the <em>new</em> marker to a real <em>new</em> marker and a <em>changed</em> marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. ------------------------------------------------------------------------ January 27, 2005 - 08:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) ------------------------------------------------------------------------ January 27, 2005 - 09:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: <?php return t("The fields with a '%marker' are required to fill in.", array('%marker' => theme('mark', 'required'))); ?> Under the tables of tracker, node, comment, and whereever items/users or whatever may be marked as new, i expect: <?php return t("The fields with a '%marker' are new.", array('%marker' => theme('mark', 'new'))); return t("The fields with a '%marker' are updated.", array('%marker' => theme('mark', 'updated'))); ?> What do ou guys think? ------------------------------------------------------------------------ January 27, 2005 - 13:41 : Goba Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is. ------------------------------------------------------------------------ January 27, 2005 - 14:57 : Dries Committed to HEAD. ------------------------------------------------------------------------ January 27, 2005 - 19:40 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers.patch (6.48 KB) Suprise :) In real incremental patching sense, here is a patch to introduce the different new and updated makers. It operates with passing on the info to theme('mark'), and then letting it decide on what to do with it. This also enables people to do 'read' markers, if so desired (displaying different icons for read, uread and updated content). Renamed the 'new' marker to 'content', so that it is not misleading, and introduced some constants, to help along the way. 'node' might be a better name instead of 'content', but it is just a search and replace in the patch, so Dries can fix it up, if needed. Also introduced the unkown maker for anonymous users. The practice before was that by setting the last view time to time(), markers are always displayed as 'read' for anonymous users. But with the different icons possibility in mind, it is important to distinguish the case when we cannot decide on whether a content is new/updated or not, because we have no data. This is why the unkown marker is introduced. I admit I have not tested the patch, but it should work well, theoretically. Kept the original interface behaviour, which does not expose much from the power of the markers, but preserves the currently expected output. ------------------------------------------------------------------------ January 27, 2005 - 19:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers2.patch (7.29 KB) Wups, forgot to adjust one usage of node_is_new(). Plus renamed it to node_marker(), since it is not anymore only about checking on whether it is new or not... ------------------------------------------------------------------------ January 27, 2005 - 20:57 : Anonymous Shouldn't 'MARKER_UNKOWN' be 'MARKER_UNKNOWN'? Why do we need an "unknown" possibility anyway? Wouldn't we just omit markers for anonymous users? ------------------------------------------------------------------------ January 27, 2005 - 23:55 : Goba Markers are only important for logged in users, yes. We need to somehow omit the markers. We can check for the user in theme_mark(), but we need to check for the user in node_marker() anyway, since otherwise we would do an unnecessery database lookup for each marker. So we can return MARKER_READ in node_marker() and omit the marker regardless of the $marker if the $type is 'new' and the user is not logged in. So we need to check for the user in the theme function too... BTW the terminology I introduced seems to be inconsitent: node_marker() vs. theme_mark(). It might be desireable to rename the theme function, or use MARK_ constants and node_mark(). Pick the way. ------------------------------------------------------------------------ January 29, 2005 - 19:37 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers3.patch (7.42 KB) Since noone hinted on a way to pick, I needed to decide myself :) Gone is the unkown marker, and now it is the theme's task to not display content markers for anonymous users (while still keeping the required marker for them). The contants and functions were renamed to use 'mark' instead of 'marker' in line with the existing theme_mark() function. Still the same functionality, but with less code compared with the previous patch. ------------------------------------------------------------------------ January 29, 2005 - 22:52 : andremolnar I think it might be helpful if you expanded the phpdocs for the constant definitions to describe when, where, how they are used. Right now the text only says 'Markers used to designate content.' ------------------------------------------------------------------------ January 29, 2005 - 23:02 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers4.patch (7.53 KB) Updated patch, which links to theme_mark() and node_mark(). Otherwise I think the names of the constants really tell everything. ------------------------------------------------------------------------ January 29, 2005 - 23:14 : tangent I find the new "content" state to be less meaningful than the old "new" state. The word "new" is an adjective while "content" is a noun which, to me, applies to everything. Perhaps "unread" would be a more appropriate state since that is the content that the marker identifies. ------------------------------------------------------------------------ January 29, 2005 - 23:39 : Goba Updated is not unread. Also there could be 'read' marks. Your email client has marks for read and unread messages doesn't it? Drupal will allow this too. If we rename 'content' to 'unread', then the unread marker would be able to signify that something is changed (while it was already read) and that it was read (which is odd for an unread mark you must admit :). -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: tangent Status: patch Updated is not unread. Also there could be 'read' marks. Your email client has marks for read and unread messages doesn't it? Drupal will allow this too. If we rename 'content' to 'unread', then the unread marker would be able to signify that something is changed (while it was already read) and that it was read (which is odd for an unread mark you must admit :). Goba I am not quite following your meaning the way you've worded it. Here are the different "states" which a node can have, with respect to a specific user, as I understand it. I have attempted list possible labels for each state. New or Unread The node has never been viewed by the current authenticated user. Updated or Modified The node has been previously viewed by the current authenticated user but has since been modified. This would include having its "body" or "teaser" fields modified (any other fields?) but would not include attached content. Appended or Extended or The node has had content (e.g., a comment, a file) appended to it. Read or Unchanged The node has been previously viewed by the current authenticated user and has not been modified or had any attachments modified. Note that we currently lump the modified and appended states together. It may be desirable in some circumstances to differentiate between them. tangent Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 16:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the new and required markers to look the same). Someone with enough time on his hands might be able to partition the new marker to a real new marker and a changed marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. ------------------------------------------------------------------------ January 27, 2005 - 01:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) ------------------------------------------------------------------------ January 27, 2005 - 02:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: <?phpreturn t("The fields with a '%marker' are required to fill in.", array('%marker' => theme('mark', 'required')));?> Under the tables of tracker, node, comment, and whereever items/users or whatever may be marked as new, i expect: <?phpreturn t("The fields with a '%marker' are new.", array('%marker' => theme('mark', 'new')));return t("The fields with a '%marker' are updated.", array('%marker' => theme('mark', 'updated')));?> What do ou guys think? ------------------------------------------------------------------------ January 27, 2005 - 06:41 : Goba Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is. ------------------------------------------------------------------------ January 27, 2005 - 07:57 : Dries Committed to HEAD. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers.patch (6.48 KB) Suprise :) In real incremental patching sense, here is a patch to introduce the different new and updated makers. It operates with passing on the info to theme('mark'), and then letting it decide on what to do with it. This also enables people to do 'read' markers, if so desired (displaying different icons for read, uread and updated content). Renamed the 'new' marker to 'content', so that it is not misleading, and introduced some constants, to help along the way. 'node' might be a better name instead of 'content', but it is just a search and replace in the patch, so Dries can fix it up, if needed. Also introduced the unkown maker for anonymous users. The practice before was that by setting the last view time to time(), markers are always displayed as 'read' for anonymous users. But with the different icons possibility in mind, it is important to distinguish the case when we cannot decide on whether a content is new/updated or not, because we have no data. This is why the unkown marker is introduced. I admit I have not tested the patch, but it should work well, theoretically. Kept the original interface behaviour, which does not expose much from the power of the markers, but preserves the currently expected output. ------------------------------------------------------------------------ January 27, 2005 - 12:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers2.patch (7.29 KB) Wups, forgot to adjust one usage of node_is_new(). Plus renamed it to node_marker(), since it is not anymore only about checking on whether it is new or not... ------------------------------------------------------------------------ January 27, 2005 - 13:57 : Anonymous Shouldn't 'MARKER_UNKOWN' be 'MARKER_UNKNOWN'? Why do we need an "unknown" possibility anyway? Wouldn't we just omit markers for anonymous users? ------------------------------------------------------------------------ January 27, 2005 - 16:55 : Goba Markers are only important for logged in users, yes. We need to somehow omit the markers. We can check for the user in theme_mark(), but we need to check for the user in node_marker() anyway, since otherwise we would do an unnecessery database lookup for each marker. So we can return MARKER_READ in node_marker() and omit the marker regardless of the $marker if the $type is 'new' and the user is not logged in. So we need to check for the user in the theme function too... BTW the terminology I introduced seems to be inconsitent: node_marker() vs. theme_mark(). It might be desireable to rename the theme function, or use MARK_ constants and node_mark(). Pick the way. ------------------------------------------------------------------------ January 29, 2005 - 12:37 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers3.patch (7.42 KB) Since noone hinted on a way to pick, I needed to decide myself :) Gone is the unkown marker, and now it is the theme's task to not display content markers for anonymous users (while still keeping the required marker for them). The contants and functions were renamed to use 'mark' instead of 'marker' in line with the existing theme_mark() function. Still the same functionality, but with less code compared with the previous patch. ------------------------------------------------------------------------ January 29, 2005 - 15:52 : andremolnar I think it might be helpful if you expanded the phpdocs for the constant definitions to describe when, where, how they are used. Right now the text only says 'Markers used to designate content.' ------------------------------------------------------------------------ January 29, 2005 - 16:02 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers4.patch (7.53 KB) Updated patch, which links to theme_mark() and node_mark(). Otherwise I think the names of the constants really tell everything. ------------------------------------------------------------------------ January 29, 2005 - 16:14 : tangent I find the new "content" state to be less meaningful than the old "new" state. The word "new" is an adjective while "content" is a noun which, to me, applies to everything. Perhaps "unread" would be a more appropriate state since that is the content that the marker identifies. ------------------------------------------------------------------------ January 29, 2005 - 16:39 : Goba Updated is not unread. Also there could be 'read' marks. Your email client has marks for read and unread messages doesn't it? Drupal will allow this too. If we rename 'content' to 'unread', then the unread marker would be able to signify that something is changed (while it was already read) and that it was read (which is odd for an unread mark you must admit :). ------------------------------------------------------------------------ January 29, 2005 - 16:55 : Dries Removing the unknown-marker makes sense to me. Personally, I'd split the function theme_mark() because 'required' and 'content' (read/new/updated) are really two different things now. I'd hard-code the required part in theme_form_element() using proper CSS-classes. IMO, that would simplify the code and make it a tad more readable. (Initially, I couldn't figure out what the 'content' parameter was for.) ------------------------------------------------------------------------ January 29, 2005 - 17:16 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers5.patch (8.14 KB) OK, Dries is right again :) Updated patch with markers separated. The form required marker has it's own CSS styling now, and only the content markers are printed by theme_mark(). Also changed the comment code a bit to delegate marker display to the theme function. This does add an extra space after the comment subject if a marker is not printed, so it might not be desirable. Note though that there has always been these kind of extra spaces after the node titles in tracker and node modules on the user interface, and after comment titles on the admin interface. So I don't think this is becoming a problem. I hope this patch is going to be fine. :) -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: tangent Status: patch 1. I suggested "unread" as opposed to "content" only because you seemed to think that "new" was not meaningful. Either "new" or "unread" convey nearly the same thing to me, though "new" also could be interpreted as being created with a certain time frame (e.g., created within the last 24 hours) which is not it's actual meaning. Unread conveys, to me, only that the current user has never viewed the node.\n 2. I apologize for not having looked at your latest patch before posting my last comment to see that you had changed the label back to "new".\n 3. Distinguishing between "modified" and "appended" is not the job of this theme function. However the calling code wants to handle this is a separate issue.\n 4. Both of your questions about when a mode has been modified are equal according to my definition. If the "body" column of the record has been changed then the node would be considered "modified". Of course revisions throw a curveball at this definition so it would have to be added to the definition. Adding a paragraph or simply respelling an existing word are equal in terms of the definition.\n tangent Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 16:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the /new/ and /required/ markers to look the same). Someone with enough time on his hands might be able to partition the /new/ marker to a real /new/ marker and a /changed/ marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though.\n ------------------------------------------------------------------------ January 27, 2005 - 01:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.)\n ------------------------------------------------------------------------ January 27, 2005 - 02:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: <?phpreturn t("The fields with a '%marker' are required to fill in.", array('%marker' => theme('mark', 'required')));?> \n Under the tables of tracker, node, comment, and whereever items/users or whatever may be marked as new, i expect: <?phpreturn t("The fields with a '%marker' are new.", array('%marker' => theme('mark', 'new')));return t("The fields with a '%marker' are updated.", array('%marker' => theme('mark', 'updated')));?> \n What do ou guys think?\n ------------------------------------------------------------------------ January 27, 2005 - 06:41 : Goba Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is.\n ------------------------------------------------------------------------ January 27, 2005 - 07:57 : Dries Committed to HEAD.\n ------------------------------------------------------------------------ January 27, 2005 - 12:40 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers.patch (6.48 KB) Suprise :) In real incremental patching sense, here is a patch to introduce the different new and updated makers. It operates with passing on the info to theme('mark'), and then letting it decide on what to do with it. This also enables people to do 'read' markers, if so desired (displaying different icons for read, uread and updated content).\n Renamed the 'new' marker to 'content', so that it is not misleading, and introduced some constants, to help along the way. 'node' might be a better name instead of 'content', but it is just a search and replace in the patch, so Dries can fix it up, if needed. Also introduced the unkown maker for anonymous users. The practice before was that by setting the last view time to time(), markers are always displayed as 'read' for anonymous users. But with the different icons possibility in mind, it is important to distinguish the case when we cannot decide on whether a content is new/updated or not, because we have no data. This is why the unkown marker is introduced.\n I admit I have not tested the patch, but it should work well, theoretically. Kept the original interface behaviour, which does not expose much from the power of the markers, but preserves the currently expected output.\n ------------------------------------------------------------------------ January 27, 2005 - 12:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers2.patch (7.29 KB) Wups, forgot to adjust one usage of node_is_new(). Plus renamed it to node_marker(), since it is not anymore only about checking on whether it is new or not...\n ------------------------------------------------------------------------ January 27, 2005 - 13:57 : Anonymous Shouldn't 'MARKER_UNKOWN' be 'MARKER_UNKNOWN'? Why do we need an "unknown" possibility anyway? Wouldn't we just omit markers for anonymous users?\n ------------------------------------------------------------------------ January 27, 2005 - 16:55 : Goba Markers are only important for logged in users, yes. We need to somehow omit the markers. We can check for the user in theme_mark(), but we need to check for the user in node_marker() anyway, since otherwise we would do an unnecessery database lookup for each marker. So we can return MARKER_READ in node_marker() and omit the marker regardless of the $marker if the $type is 'new' and the user is not logged in. So we need to check for the user in the theme function too...\n BTW the terminology I introduced seems to be inconsitent: node_marker() vs. theme_mark(). It might be desireable to rename the theme function, or use MARK_ constants and node_mark(). Pick the way.\n ------------------------------------------------------------------------ January 29, 2005 - 12:37 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers3.patch (7.42 KB) Since noone hinted on a way to pick, I needed to decide myself :) Gone is the unkown marker, and now it is the theme's task to not display content markers for anonymous users (while still keeping the required marker for them). The contants and functions were renamed to use 'mark' instead of 'marker' in line with the existing theme_mark() function. Still the same functionality, but with less code compared with the previous patch.\n ------------------------------------------------------------------------ January 29, 2005 - 15:52 : andremolnar I think it might be helpful if you expanded the phpdocs for the constant definitions to describe when, where, how they are used. Right now the text only says 'Markers used to designate content.'\n ------------------------------------------------------------------------ January 29, 2005 - 16:02 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers4.patch (7.53 KB) Updated patch, which links to theme_mark() and node_mark(). Otherwise I think the names of the constants really tell everything.\n ------------------------------------------------------------------------ January 29, 2005 - 16:14 : tangent I find the new "content" state to be less meaningful than the old "new" state. The word "new" is an adjective while "content" is a noun which, to me, applies to everything.\n Perhaps "unread" would be a more appropriate state since that is the content that the marker identifies.\n ------------------------------------------------------------------------ January 29, 2005 - 16:39 : Goba Updated is not unread. Also there could be 'read' marks. Your email client has marks for read and unread messages doesn't it? Drupal will allow this too. If we rename 'content' to 'unread', then the unread marker would be able to signify that something is changed (while it was already read) and that it was read (which is odd for an unread mark you must admit :).\n ------------------------------------------------------------------------ January 29, 2005 - 16:55 : Dries Removing the unknown-marker makes sense to me. Personally, I'd split the function theme_mark() because 'required' and 'content' (read/new/updated) are really two different things now. I'd hard-code the required part in theme_form_element() using proper CSS-classes. IMO, that would simplify the code and make it a tad more readable. (Initially, I couldn't figure out what the 'content' parameter was for.)\n ------------------------------------------------------------------------ January 29, 2005 - 17:16 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers5.patch (8.14 KB) OK, Dries is right again :) Updated patch with markers separated. The form required marker has it's own CSS styling now, and only the content markers are printed by theme_mark(). Also changed the comment code a bit to delegate marker display to the theme function. This does add an extra space after the comment subject if a marker is not printed, so it might not be desirable. Note though that there has always been these kind of extra spaces after the node titles in tracker and node modules on the user interface, and after comment titles on the admin interface. So I don't think this is becoming a problem.\n I hope this patch is going to be fine. :)\n ------------------------------------------------------------------------ January 29, 2005 - 17:22 : tangent " Updated is not unread. Also there could be 'read' marks. Your email client has marks for read and unread messages doesn't it? Drupal will allow this too. If we rename 'content' to 'unread', then the unread marker would be able to signify that something is changed (while it was already read) and that it was read (which is odd for an unread mark you must admit :). Goba\n" I am not quite following your meaning the way you've worded it.\n Here are the different "states" which a node can have, with respect to a specific user, as I understand it. I have attempted list possible labels for each state. *New* or *Unread* The node has never been viewed by the current authenticated user.\n *Updated* or *Modified* The node has been previously viewed by the current authenticated user but has since been modified. This would include having its "body" or "teaser" fields modified (any other fields?) but would not include attached content.\n *Appended* or *Extended* or The node has had content (e.g., a comment, a file) appended to it.\n *Read* or *Unchanged* The node has been previously viewed by the current authenticated user and has not been modified or had any attachments modified.\n \n Note that we currently lump the modified and appended states together. It may be desirable in some circumstances to differentiate between them.\n ------------------------------------------------------------------------ January 29, 2005 - 17:48 : Goba Tangent, you do suggested 'unread' as a replacement to 'content' above. Or at least I tried to read your comment multiple times, and understood this suggestion. The latest patch has no 'content' in it, so your remarks are not applicable anymore.\n If Dries wishes to replace MARK_NEW with MARK_UNREAD, then it is fine with me, it is just a simple search and replace in the patchfile. I think NEW vs. UPDATED is better distinction then UNREAD vs. UPDATED, but the way I originally choose was not what is reflected in the current patcfile, and it changed for the better :)\n Tangent, if you now a way to distinguish between the appended/extended state and the updated/modified state, then feel free to work on the patch more. I have no idea on how one would be able to distinguish between these two. If I add a paragraph to a node, is it a change or an extension of the content? If I modify a sentence and add three words in? Is it a modification or an extension?\n -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: tangent Status: patch Sorry for all the noise and confusion. The latest patch looks great. I don't think differentiating between "changed" and "appended" is needed enough to belabor at this time. tangent Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 16:47 : Goba Attachment: http://drupal.org/files/issues/Drupal-allow-different-markers.patch (4.21 KB) This simple and straightforward patch adds the ability to define different types of markers (while retaining the old default behaviour of the /new/ and /required/ markers to look the same). Someone with enough time on his hands might be able to partition the /new/ marker to a real /new/ marker and a /changed/ marker (since node_is_new() returns TRUE even if nodes changed, and not only when they are new). This is the base on which the new patch can be worked though. ------------------------------------------------------------------------ January 27, 2005 - 01:19 : Dries Being able to differentiate between 'updated' and 'new' would be a plus. (Basecamp does it for example, and it has been suggested repeatedly by Kika/Kristjan.) ------------------------------------------------------------------------ January 27, 2005 - 02:45 : stefan nagtegaal First of all, i like the patch.. Another usability improvement wou be to have a little helptext at the bottom of the form which tell you something like: <?phpreturn t("The fields with a '%marker' are required to fill in.", array('%marker' => theme('mark', 'required')));?> Under the tables of tracker, node, comment, and whereever items/users or whatever may be marked as new, i expect: <?phpreturn t("The fields with a '%marker' are new.", array('%marker' => theme('mark', 'new')));return t("The fields with a '%marker' are updated.", array('%marker' => theme('mark', 'updated')));?> What do ou guys think? ------------------------------------------------------------------------ January 27, 2005 - 06:41 : Goba Stefan, markers are not necesserily inline. At one of my sites, we use a right floated block element to indicate that something is new. So this kind of help text will not work... The marker however can contain some help in itself in a title="" attribute, so that those hovering over it with their mouse can get an idea on what it is. ------------------------------------------------------------------------ January 27, 2005 - 07:57 : Dries Committed to HEAD. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers.patch (6.48 KB) Suprise :) In real incremental patching sense, here is a patch to introduce the different new and updated makers. It operates with passing on the info to theme('mark'), and then letting it decide on what to do with it. This also enables people to do 'read' markers, if so desired (displaying different icons for read, uread and updated content). Renamed the 'new' marker to 'content', so that it is not misleading, and introduced some constants, to help along the way. 'node' might be a better name instead of 'content', but it is just a search and replace in the patch, so Dries can fix it up, if needed. Also introduced the unkown maker for anonymous users. The practice before was that by setting the last view time to time(), markers are always displayed as 'read' for anonymous users. But with the different icons possibility in mind, it is important to distinguish the case when we cannot decide on whether a content is new/updated or not, because we have no data. This is why the unkown marker is introduced. I admit I have not tested the patch, but it should work well, theoretically. Kept the original interface behaviour, which does not expose much from the power of the markers, but preserves the currently expected output. ------------------------------------------------------------------------ January 27, 2005 - 12:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers2.patch (7.29 KB) Wups, forgot to adjust one usage of node_is_new(). Plus renamed it to node_marker(), since it is not anymore only about checking on whether it is new or not... ------------------------------------------------------------------------ January 27, 2005 - 13:57 : Anonymous Shouldn't 'MARKER_UNKOWN' be 'MARKER_UNKNOWN'? Why do we need an "unknown" possibility anyway? Wouldn't we just omit markers for anonymous users? ------------------------------------------------------------------------ January 27, 2005 - 16:55 : Goba Markers are only important for logged in users, yes. We need to somehow omit the markers. We can check for the user in theme_mark(), but we need to check for the user in node_marker() anyway, since otherwise we would do an unnecessery database lookup for each marker. So we can return MARKER_READ in node_marker() and omit the marker regardless of the $marker if the $type is 'new' and the user is not logged in. So we need to check for the user in the theme function too... BTW the terminology I introduced seems to be inconsitent: node_marker() vs. theme_mark(). It might be desireable to rename the theme function, or use MARK_ constants and node_mark(). Pick the way. ------------------------------------------------------------------------ January 29, 2005 - 12:37 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers3.patch (7.42 KB) Since noone hinted on a way to pick, I needed to decide myself :) Gone is the unkown marker, and now it is the theme's task to not display content markers for anonymous users (while still keeping the required marker for them). The contants and functions were renamed to use 'mark' instead of 'marker' in line with the existing theme_mark() function. Still the same functionality, but with less code compared with the previous patch. ------------------------------------------------------------------------ January 29, 2005 - 15:52 : andremolnar I think it might be helpful if you expanded the phpdocs for the constant definitions to describe when, where, how they are used. Right now the text only says 'Markers used to designate content.' ------------------------------------------------------------------------ January 29, 2005 - 16:02 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers4.patch (7.53 KB) Updated patch, which links to theme_mark() and node_mark(). Otherwise I think the names of the constants really tell everything. ------------------------------------------------------------------------ January 29, 2005 - 16:14 : tangent I find the new "content" state to be less meaningful than the old "new" state. The word "new" is an adjective while "content" is a noun which, to me, applies to everything. Perhaps "unread" would be a more appropriate state since that is the content that the marker identifies. ------------------------------------------------------------------------ January 29, 2005 - 16:39 : Goba Updated is not unread. Also there could be 'read' marks. Your email client has marks for read and unread messages doesn't it? Drupal will allow this too. If we rename 'content' to 'unread', then the unread marker would be able to signify that something is changed (while it was already read) and that it was read (which is odd for an unread mark you must admit :). ------------------------------------------------------------------------ January 29, 2005 - 16:55 : Dries Removing the unknown-marker makes sense to me. Personally, I'd split the function theme_mark() because 'required' and 'content' (read/new/updated) are really two different things now. I'd hard-code the required part in theme_form_element() using proper CSS-classes. IMO, that would simplify the code and make it a tad more readable. (Initially, I couldn't figure out what the 'content' parameter was for.) ------------------------------------------------------------------------ January 29, 2005 - 17:16 : Goba Attachment: http://drupal.org/files/issues/Drupal-differentiate-content-markers5.patch (8.14 KB) OK, Dries is right again :) Updated patch with markers separated. The form required marker has it's own CSS styling now, and only the content markers are printed by theme_mark(). Also changed the comment code a bit to delegate marker display to the theme function. This does add an extra space after the comment subject if a marker is not printed, so it might not be desirable. Note though that there has always been these kind of extra spaces after the node titles in tracker and node modules on the user interface, and after comment titles on the admin interface. So I don't think this is becoming a problem. I hope this patch is going to be fine. :) ------------------------------------------------------------------------ January 29, 2005 - 17:22 : tangent " Updated is not unread. Also there could be 'read' marks. Your email client has marks for read and unread messages doesn't it? Drupal will allow this too. If we rename 'content' to 'unread', then the unread marker would be able to signify that something is changed (while it was already read) and that it was read (which is odd for an unread mark you must admit :). Goba " I am not quite following your meaning the way you've worded it. Here are the different "states" which a node can have, with respect to a specific user, as I understand it. I have attempted list possible labels for each state. *New* or *Unread* The node has never been viewed by the current authenticated user. *Updated* or *Modified* The node has been previously viewed by the current authenticated user but has since been modified. This would include having its "body" or "teaser" fields modified (any other fields?) but would not include attached content. *Appended* or *Extended* or The node has had content (e.g., a comment, a file) appended to it. *Read* or *Unchanged* The node has been previously viewed by the current authenticated user and has not been modified or had any attachments modified. Note that we currently lump the modified and appended states together. It may be desirable in some circumstances to differentiate between them. ------------------------------------------------------------------------ January 29, 2005 - 17:48 : Goba Tangent, you do suggested 'unread' as a replacement to 'content' above. Or at least I tried to read your comment multiple times, and understood this suggestion. The latest patch has no 'content' in it, so your remarks are not applicable anymore. If Dries wishes to replace MARK_NEW with MARK_UNREAD, then it is fine with me, it is just a simple search and replace in the patchfile. I think NEW vs. UPDATED is better distinction then UNREAD vs. UPDATED, but the way I originally choose was not what is reflected in the current patcfile, and it changed for the better :) Tangent, if you now a way to distinguish between the appended/extended state and the updated/modified state, then feel free to work on the patch more. I have no idea on how one would be able to distinguish between these two. If I add a paragraph to a node, is it a change or an extension of the content? If I modify a sentence and add three words in? Is it a modification or an extension? ------------------------------------------------------------------------ January 29, 2005 - 18:03 : tangent 1. I suggested "unread" as opposed to "content" only because you seemed to think that "new" was not meaningful. Either "new" or "unread" convey nearly the same thing to me, though "new" also could be interpreted as being created with a certain time frame (e.g., created within the last 24 hours) which is not it's actual meaning. Unread conveys, to me, only that the current user has never viewed the node. 2. I apologize for not having looked at your latest patch before posting my last comment to see that you had changed the label back to "new". 3. Distinguishing between "modified" and "appended" is not the job of this theme function. However the calling code wants to handle this is a separate issue. 4. Both of your questions about when a mode has been modified are equal according to my definition. If the "body" column of the record has been changed then the node would be considered "modified". Of course revisions throw a curveball at this definition so it would have to be added to the definition. Adding a paragraph or simply respelling an existing word are equal in terms of the definition. ------------------------------------------------------------------------ January 29, 2005 - 18:11 : Goba 1. Tangent you *should* interpret new "as being created with a certain time frame" AND also being unread. Once a node becomes too old, it is not marked NEW anymore, regardless of one reading it or not. This behaviour was Drupal's own for quite a long time now. 2. No, I have not changed back the label to 'new'! The 'new' label was always there. You misunderstood something. Dries was also confused :) 3. We are not just modifying a theme function, but also introducing a node function, which does provide the node state. It *is* the task of that function to decide on state. Please look and the explanation carefully. I have described this earlier and the code for the node function is also in the patch. If you would have looked to the patch, you would have not been confused by the meaning of NEW (see point 1 above). -- View: http://drupal.org/node/16253 Edit: http://drupal.org/project/comments/add/16253