one of my users just pointed me to the fact that some file actions are
missing on the manifest widget, particularly when showing the working
directory pseudo-revision. For example, the "copy" and "rename"
commands are not accessible through the manifest dialog.
So I'm wondering if it would make sense to make the manifest widget
use the wctxactions rather than the filectxactions when the manifest
window points to the working directory. Alternatively, we could just
add some of the missing actions to filectxactions, although we'd need
a way to only show some of them when the working directory is being
shown.
On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
> one of my users just pointed me to the fact that some file actions are
> missing on the manifest widget, particularly when showing the working
> directory pseudo-revision. For example, the "copy" and "rename"
> commands are not accessible through the manifest dialog.
> So I'm wondering if it would make sense to make the manifest widget
> use the wctxactions rather than the filectxactions when the manifest
> window points to the working directory. Alternatively, we could just
> add some of the missing actions to filectxactions, although we'd need
> a way to only show some of them when the working directory is being
> shown.
IMHO, manifest widget is not good for modification of working directory.
Since it was implemented to handle read-only static data, it lacks
support for _live_ data.
If you start using manifest as a replacement for commit widget, you'll
soon notice inconsistency between manifest and actual file.
On Wed, Aug 1, 2012 at 6:24 PM, Yuya Nishihara <y...@tcha.org> wrote:
> On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
>> one of my users just pointed me to the fact that some file actions are
>> missing on the manifest widget, particularly when showing the working
>> directory pseudo-revision. For example, the "copy" and "rename"
>> commands are not accessible through the manifest dialog.
>> So I'm wondering if it would make sense to make the manifest widget
>> use the wctxactions rather than the filectxactions when the manifest
>> window points to the working directory. Alternatively, we could just
>> add some of the missing actions to filectxactions, although we'd need
>> a way to only show some of them when the working directory is being
>> shown.
> IMHO, manifest widget is not good for modification of working directory.
> Since it was implemented to handle read-only static data, it lacks
> support for _live_ data.
> If you start using manifest as a replacement for commit widget, you'll
> soon notice inconsistency between manifest and actual file.
> Regards,
That is true. However I'd like the workbench to be able to do
everything that you can do with the Windows Explorer (or Nautilus,
etc) context menus. Currently you can call rename for clean files if
you enable them on the commit widget, but that is quite cumbersome. If
you could do that from the manifest widget itself it would be much
cleaner and easier to discover.
On Mon, 6 Aug 2012 00:04:42 +0200, Angel Ezquerra wrote:
> On Wed, Aug 1, 2012 at 6:24 PM, Yuya Nishihara <y...@tcha.org> wrote:
> > On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
> >> one of my users just pointed me to the fact that some file actions are
> >> missing on the manifest widget, particularly when showing the working
> >> directory pseudo-revision. For example, the "copy" and "rename"
> >> commands are not accessible through the manifest dialog.
> >> So I'm wondering if it would make sense to make the manifest widget
> >> use the wctxactions rather than the filectxactions when the manifest
> >> window points to the working directory. Alternatively, we could just
> >> add some of the missing actions to filectxactions, although we'd need
> >> a way to only show some of them when the working directory is being
> >> shown.
> > IMHO, manifest widget is not good for modification of working directory.
> > Since it was implemented to handle read-only static data, it lacks
> > support for _live_ data.
> > If you start using manifest as a replacement for commit widget, you'll
> > soon notice inconsistency between manifest and actual file.
> That is true. However I'd like the workbench to be able to do
> everything that you can do with the Windows Explorer (or Nautilus,
> etc) context menus. Currently you can call rename for clean files if
> you enable them on the commit widget, but that is quite cumbersome. If
> you could do that from the manifest widget itself it would be much
> cleaner and easier to discover.
But even if manifest can rename files,
- use manifest widget to rename known files
- use commit widget to handle unknown files
which is a bit confusing.
Instead, isn't it nice if we can easily rename files from commit widget,
i.e. making it easily discoverable to show clean files ?
On Tue, Aug 7, 2012 at 3:49 PM, Yuya Nishihara <y...@tcha.org> wrote:
> On Mon, 6 Aug 2012 00:04:42 +0200, Angel Ezquerra wrote:
>> On Wed, Aug 1, 2012 at 6:24 PM, Yuya Nishihara <y...@tcha.org> wrote:
>> > On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
>> >> one of my users just pointed me to the fact that some file actions are
>> >> missing on the manifest widget, particularly when showing the working
>> >> directory pseudo-revision. For example, the "copy" and "rename"
>> >> commands are not accessible through the manifest dialog.
>> >> So I'm wondering if it would make sense to make the manifest widget
>> >> use the wctxactions rather than the filectxactions when the manifest
>> >> window points to the working directory. Alternatively, we could just
>> >> add some of the missing actions to filectxactions, although we'd need
>> >> a way to only show some of them when the working directory is being
>> >> shown.
>> > IMHO, manifest widget is not good for modification of working directory.
>> > Since it was implemented to handle read-only static data, it lacks
>> > support for _live_ data.
>> > If you start using manifest as a replacement for commit widget, you'll
>> > soon notice inconsistency between manifest and actual file.
>> That is true. However I'd like the workbench to be able to do
>> everything that you can do with the Windows Explorer (or Nautilus,
>> etc) context menus. Currently you can call rename for clean files if
>> you enable them on the commit widget, but that is quite cumbersome. If
>> you could do that from the manifest widget itself it would be much
>> cleaner and easier to discover.
> But even if manifest can rename files,
> - use manifest widget to rename known files
> - use commit widget to handle unknown files
> which is a bit confusing.
> Instead, isn't it nice if we can easily rename files from commit widget,
> i.e. making it easily discoverable to show clean files ?
> Regards,
I think that is a very good point. However my main concern however is
how to handle "clean" files. Those are not normally shown on the
commit widget, while they are shown on the manifest widget...
On Tue, 7 Aug 2012 16:17:58 +0200, Angel Ezquerra wrote:
> On Tue, Aug 7, 2012 at 3:49 PM, Yuya Nishihara <y...@tcha.org> wrote:
> > On Mon, 6 Aug 2012 00:04:42 +0200, Angel Ezquerra wrote:
> >> On Wed, Aug 1, 2012 at 6:24 PM, Yuya Nishihara <y...@tcha.org> wrote:
> >> > On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
> >> >> one of my users just pointed me to the fact that some file actions are
> >> >> missing on the manifest widget, particularly when showing the working
> >> >> directory pseudo-revision. For example, the "copy" and "rename"
> >> >> commands are not accessible through the manifest dialog.
> >> >> So I'm wondering if it would make sense to make the manifest widget
> >> >> use the wctxactions rather than the filectxactions when the manifest
> >> >> window points to the working directory. Alternatively, we could just
> >> >> add some of the missing actions to filectxactions, although we'd need
> >> >> a way to only show some of them when the working directory is being
> >> >> shown.
> >> > IMHO, manifest widget is not good for modification of working directory.
> >> > Since it was implemented to handle read-only static data, it lacks
> >> > support for _live_ data.
> >> > If you start using manifest as a replacement for commit widget, you'll
> >> > soon notice inconsistency between manifest and actual file.
> >> That is true. However I'd like the workbench to be able to do
> >> everything that you can do with the Windows Explorer (or Nautilus,
> >> etc) context menus. Currently you can call rename for clean files if
> >> you enable them on the commit widget, but that is quite cumbersome. If
> >> you could do that from the manifest widget itself it would be much
> >> cleaner and easier to discover.
> > But even if manifest can rename files,
> > - use manifest widget to rename known files
> > - use commit widget to handle unknown files
> > which is a bit confusing.
> > Instead, isn't it nice if we can easily rename files from commit widget,
> > i.e. making it easily discoverable to show clean files ?
> I think that is a very good point. However my main concern however is
> how to handle "clean" files. Those are not normally shown on the
> commit widget, while they are shown on the manifest widget...
How about this?
It displays "Show unmodified files" link so that you can easily know
there's a way to show clean files by a single action.
If it sounds good, I'll rewrite this clumsy implementation.
diff --git a/tortoisehg/hgqt/status.py b/tortoisehg/hgqt/status.py
--- a/tortoisehg/hgqt/status.py
+++ b/tortoisehg/hgqt/status.py
@@ -241,7 +241,7 @@ class StatusWidget(QWidget):
if model and model.rowCount(QModelIndex()):
smodel = self.tv.selectionModel()
curidx = smodel.currentIndex()
- if curidx.isValid():
+ if curidx.isValid() and curidx.row() != model.rowCount() - 1:
curpath = model.getRow(curidx)[COL_PATH]
else:
curpath = None
@@ -401,6 +401,10 @@ class StatusWidget(QWidget):
#@pyqtSlot(QModelIndex, QModelIndex)
def onCurrentChange(self, index, old):
'Connected to treeview "currentChanged" signal'
+ if index.row() == self.tv.model().rowCount() - 1:
+ # assume that "show unmodified" link clicked
+ self.statusfilter.setStatus(self.statusfilter.status() + 'C')
+ return
row = index.model().getRow(index)
if row is None:
return
@@ -627,10 +631,10 @@ class WctxModel(QAbstractTableModel):
self.rows = rows
self.checkable = checkable
def check(self, files, state=True):
for f in files:
@@ -652,6 +656,8 @@ class WctxModel(QAbstractTableModel):
def data(self, index, role):
if not index.isValid():
return QVariant()
+ if index.row() == len(self.rows):
+ return self._epilogueData(index, role)
+ def _epilogueData(self, index, role):
+ if index.column() != COL_PATH_DISPLAY:
+ return
+ if role == Qt.DisplayRole:
+ # XXX should only be available if 'clean' files are hidden
+ return _('Show unmodified files...')
+ if role == Qt.SizeHintRole:
+ return QSize(80, 30) # XXX just want to increase height
+ # imitate hyper-link style
+ if role == Qt.ForegroundRole:
+ return QBrush(QColor('blue'))
+ if role == Qt.FontRole:
+ font = QFont()
+ font.setItalic(True)
+ font.setUnderline(True)
+ return font
+
def headerData(self, col, orientation, role):
if role != Qt.DisplayRole or orientation != Qt.Horizontal:
return QVariant()
@@ -690,6 +713,8 @@ class WctxModel(QAbstractTableModel):
return QVariant(self.headers[col])
def flags(self, index):
+ if index.row() == len(self.rows):
+ return Qt.ItemIsEnabled
flags = Qt.ItemIsSelectable | Qt.ItemIsEnabled | Qt.ItemIsDragEnabled
if index.column() == COL_PATH and self.checkable:
flags |= Qt.ItemIsUserCheckable
> On Tue, 7 Aug 2012 16:17:58 +0200, Angel Ezquerra wrote:
> > On Tue, Aug 7, 2012 at 3:49 PM, Yuya Nishihara <y...@tcha.org> wrote:
> > > On Mon, 6 Aug 2012 00:04:42 +0200, Angel Ezquerra wrote:
> > >> On Wed, Aug 1, 2012 at 6:24 PM, Yuya Nishihara <y...@tcha.org> wrote:
> > >> > On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
> > >> >> one of my users just pointed me to the fact that some file
actions are
> > >> >> missing on the manifest widget, particularly when showing the
working
> > >> >> directory pseudo-revision. For example, the "copy" and "rename"
> > >> >> commands are not accessible through the manifest dialog.
> > >> >> So I'm wondering if it would make sense to make the manifest
widget
> > >> >> use the wctxactions rather than the filectxactions when the
manifest
> > >> >> window points to the working directory. Alternatively, we could
just
> > >> >> add some of the missing actions to filectxactions, although we'd
need
> > >> >> a way to only show some of them when the working directory is
being
> > >> >> shown.
> > >> > IMHO, manifest widget is not good for modification of working
directory.
> > >> > Since it was implemented to handle read-only static data, it lacks
> > >> > support for _live_ data.
> > >> > If you start using manifest as a replacement for commit widget,
you'll
> > >> > soon notice inconsistency between manifest and actual file.
> > >> That is true. However I'd like the workbench to be able to do
> > >> everything that you can do with the Windows Explorer (or Nautilus,
> > >> etc) context menus. Currently you can call rename for clean files if
> > >> you enable them on the commit widget, but that is quite cumbersome.
If
> > >> you could do that from the manifest widget itself it would be much
> > >> cleaner and easier to discover.
> > > But even if manifest can rename files,
> > > - use manifest widget to rename known files
> > > - use commit widget to handle unknown files
> > > which is a bit confusing.
> > > Instead, isn't it nice if we can easily rename files from commit
widget,
> > > i.e. making it easily discoverable to show clean files ?
> > I think that is a very good point. However my main concern however is
> > how to handle "clean" files. Those are not normally shown on the
> > commit widget, while they are shown on the manifest widget...
> How about this?
> It displays "Show unmodified files" link so that you can easily know
> there's a way to show clean files by a single action.
> If it sounds good, I'll rewrite this clumsy implementation.
I think that's a quite clever of unconventional solution!
One think I would change is that I would say "Show unmodified (clean)
entries", to make sure people understand that unmodified files are called
"clean" on the Mercurial jargon.
Also, I think that perhaps the link could have a "temporary" effect. That
is, rather than being the same as clicking on the "Clean" entry on the
filter drop down, which has a "permanent" effect (as in "it won't change
until the entry is clicked again"), clicking on that link could take effect
only until the user selects a different widget so that when he comes back
to the commit wisher the clean dukes are hidden again (as they should in
most cases). What do you think?
On Sat, 11 Aug 2012 13:24:18 +0200, Angel Ezquerra wrote:
> On Aug 11, 2012 12:06 PM, "Yuya Nishihara" <y...@tcha.org> wrote:
> > On Tue, 7 Aug 2012 16:17:58 +0200, Angel Ezquerra wrote:
> > > On Tue, Aug 7, 2012 at 3:49 PM, Yuya Nishihara <y...@tcha.org> wrote:
> > > > On Mon, 6 Aug 2012 00:04:42 +0200, Angel Ezquerra wrote:
> > > >> On Wed, Aug 1, 2012 at 6:24 PM, Yuya Nishihara <y...@tcha.org> wrote:
> > > >> > On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
> > > >> >> one of my users just pointed me to the fact that some file
> actions are
> > > >> >> missing on the manifest widget, particularly when showing the
> working
> > > >> >> directory pseudo-revision. For example, the "copy" and "rename"
> > > >> >> commands are not accessible through the manifest dialog.
> > > >> >> So I'm wondering if it would make sense to make the manifest
> widget
> > > >> >> use the wctxactions rather than the filectxactions when the
> manifest
> > > >> >> window points to the working directory. Alternatively, we could
> just
> > > >> >> add some of the missing actions to filectxactions, although we'd
> need
> > > >> >> a way to only show some of them when the working directory is
> being
> > > >> >> shown.
> > > >> > IMHO, manifest widget is not good for modification of working
> directory.
> > > >> > Since it was implemented to handle read-only static data, it lacks
> > > >> > support for _live_ data.
> > > >> > If you start using manifest as a replacement for commit widget,
> you'll
> > > >> > soon notice inconsistency between manifest and actual file.
> > > >> That is true. However I'd like the workbench to be able to do
> > > >> everything that you can do with the Windows Explorer (or Nautilus,
> > > >> etc) context menus. Currently you can call rename for clean files if
> > > >> you enable them on the commit widget, but that is quite cumbersome.
> If
> > > >> you could do that from the manifest widget itself it would be much
> > > >> cleaner and easier to discover.
> > > > But even if manifest can rename files,
> > > > - use manifest widget to rename known files
> > > > - use commit widget to handle unknown files
> > > > which is a bit confusing.
> > > > Instead, isn't it nice if we can easily rename files from commit
> widget,
> > > > i.e. making it easily discoverable to show clean files ?
> > > I think that is a very good point. However my main concern however is
> > > how to handle "clean" files. Those are not normally shown on the
> > > commit widget, while they are shown on the manifest widget...
> > How about this?
> > It displays "Show unmodified files" link so that you can easily know
> > there's a way to show clean files by a single action.
> > If it sounds good, I'll rewrite this clumsy implementation.
> I think that's a quite clever of unconventional solution!
> One think I would change is that I would say "Show unmodified (clean)
> entries", to make sure people understand that unmodified files are called
> "clean" on the Mercurial jargon.
Good catch.
> Also, I think that perhaps the link could have a "temporary" effect. That
> is, rather than being the same as clicking on the "Clean" entry on the
> filter drop down, which has a "permanent" effect (as in "it won't change
> until the entry is clicked again"), clicking on that link could take effect
> only until the user selects a different widget so that when he comes back
> to the commit wisher the clean dukes are hidden again (as they should in
> most cases). What do you think?
That may be possible but we'll have to think about how to represent
"temporary" effect on filter drop down menu.
In any case, the implementation won't be much difference. For "temporary"
effect, I guess it just need to restore status filter on reload or refresh.
On Sun, Aug 12, 2012 at 2:37 PM, Yuya Nishihara <y...@tcha.org> wrote:
> On Sat, 11 Aug 2012 13:24:18 +0200, Angel Ezquerra wrote:
>> On Aug 11, 2012 12:06 PM, "Yuya Nishihara" <y...@tcha.org> wrote:
>> > On Tue, 7 Aug 2012 16:17:58 +0200, Angel Ezquerra wrote:
>> > > On Tue, Aug 7, 2012 at 3:49 PM, Yuya Nishihara <y...@tcha.org> wrote:
>> > > > On Mon, 6 Aug 2012 00:04:42 +0200, Angel Ezquerra wrote:
>> > > >> On Wed, Aug 1, 2012 at 6:24 PM, Yuya Nishihara <y...@tcha.org> wrote:
>> > > >> > On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
>> > > >> >> one of my users just pointed me to the fact that some file
>> actions are
>> > > >> >> missing on the manifest widget, particularly when showing the
>> working
>> > > >> >> directory pseudo-revision. For example, the "copy" and "rename"
>> > > >> >> commands are not accessible through the manifest dialog.
>> > > >> >> So I'm wondering if it would make sense to make the manifest
>> widget
>> > > >> >> use the wctxactions rather than the filectxactions when the
>> manifest
>> > > >> >> window points to the working directory. Alternatively, we could
>> just
>> > > >> >> add some of the missing actions to filectxactions, although we'd
>> need
>> > > >> >> a way to only show some of them when the working directory is
>> being
>> > > >> >> shown.
>> > > >> > IMHO, manifest widget is not good for modification of working
>> directory.
>> > > >> > Since it was implemented to handle read-only static data, it lacks
>> > > >> > support for _live_ data.
>> > > >> > If you start using manifest as a replacement for commit widget,
>> you'll
>> > > >> > soon notice inconsistency between manifest and actual file.
>> > > >> That is true. However I'd like the workbench to be able to do
>> > > >> everything that you can do with the Windows Explorer (or Nautilus,
>> > > >> etc) context menus. Currently you can call rename for clean files if
>> > > >> you enable them on the commit widget, but that is quite cumbersome.
>> If
>> > > >> you could do that from the manifest widget itself it would be much
>> > > >> cleaner and easier to discover.
>> > > > But even if manifest can rename files,
>> > > > - use manifest widget to rename known files
>> > > > - use commit widget to handle unknown files
>> > > > which is a bit confusing.
>> > > > Instead, isn't it nice if we can easily rename files from commit
>> widget,
>> > > > i.e. making it easily discoverable to show clean files ?
>> > > I think that is a very good point. However my main concern however is
>> > > how to handle "clean" files. Those are not normally shown on the
>> > > commit widget, while they are shown on the manifest widget...
>> > How about this?
>> > It displays "Show unmodified files" link so that you can easily know
>> > there's a way to show clean files by a single action.
>> > If it sounds good, I'll rewrite this clumsy implementation.
>> I think that's a quite clever of unconventional solution!
>> One think I would change is that I would say "Show unmodified (clean)
>> entries", to make sure people understand that unmodified files are called
>> "clean" on the Mercurial jargon.
> Good catch.
>> Also, I think that perhaps the link could have a "temporary" effect. That
>> is, rather than being the same as clicking on the "Clean" entry on the
>> filter drop down, which has a "permanent" effect (as in "it won't change
>> until the entry is clicked again"), clicking on that link could take effect
>> only until the user selects a different widget so that when he comes back
>> to the commit wisher the clean dukes are hidden again (as they should in
>> most cases). What do you think?
> That may be possible but we'll have to think about how to represent
> "temporary" effect on filter drop down menu.
> In any case, the implementation won't be much difference. For "temporary"
> effect, I guess it just need to restore status filter on reload or refresh.
> Regards,
Some programs change the background color of lists when a temporary
filter is applied. My current email client (NEO Pro, which is really
awesome, BTW) works that way and is great.
<angel.ezque...@gmail.com> wrote:
> On Sun, Aug 12, 2012 at 2:37 PM, Yuya Nishihara <y...@tcha.org> wrote:
>> On Sat, 11 Aug 2012 13:24:18 +0200, Angel Ezquerra wrote:
>>> On Aug 11, 2012 12:06 PM, "Yuya Nishihara" <y...@tcha.org> wrote:
>>> > On Tue, 7 Aug 2012 16:17:58 +0200, Angel Ezquerra wrote:
>>> > > On Tue, Aug 7, 2012 at 3:49 PM, Yuya Nishihara <y...@tcha.org> wrote:
>>> > > > On Mon, 6 Aug 2012 00:04:42 +0200, Angel Ezquerra wrote:
>>> > > >> On Wed, Aug 1, 2012 at 6:24 PM, Yuya Nishihara <y...@tcha.org> wrote:
>>> > > >> > On Mon, 30 Jul 2012 09:15:44 +0200, Angel Ezquerra wrote:
>>> > > >> >> one of my users just pointed me to the fact that some file
>>> actions are
>>> > > >> >> missing on the manifest widget, particularly when showing the
>>> working
>>> > > >> >> directory pseudo-revision. For example, the "copy" and "rename"
>>> > > >> >> commands are not accessible through the manifest dialog.
>>> > > >> >> So I'm wondering if it would make sense to make the manifest
>>> widget
>>> > > >> >> use the wctxactions rather than the filectxactions when the
>>> manifest
>>> > > >> >> window points to the working directory. Alternatively, we could
>>> just
>>> > > >> >> add some of the missing actions to filectxactions, although we'd
>>> need
>>> > > >> >> a way to only show some of them when the working directory is
>>> being
>>> > > >> >> shown.
>>> > > >> > IMHO, manifest widget is not good for modification of working
>>> directory.
>>> > > >> > Since it was implemented to handle read-only static data, it lacks
>>> > > >> > support for _live_ data.
>>> > > >> > If you start using manifest as a replacement for commit widget,
>>> you'll
>>> > > >> > soon notice inconsistency between manifest and actual file.
>>> > > >> That is true. However I'd like the workbench to be able to do
>>> > > >> everything that you can do with the Windows Explorer (or Nautilus,
>>> > > >> etc) context menus. Currently you can call rename for clean files if
>>> > > >> you enable them on the commit widget, but that is quite cumbersome.
>>> If
>>> > > >> you could do that from the manifest widget itself it would be much
>>> > > >> cleaner and easier to discover.
>>> > > > But even if manifest can rename files,
>>> > > > - use manifest widget to rename known files
>>> > > > - use commit widget to handle unknown files
>>> > > > which is a bit confusing.
>>> > > > Instead, isn't it nice if we can easily rename files from commit
>>> widget,
>>> > > > i.e. making it easily discoverable to show clean files ?
>>> > > I think that is a very good point. However my main concern however is
>>> > > how to handle "clean" files. Those are not normally shown on the
>>> > > commit widget, while they are shown on the manifest widget...
>>> > How about this?
>>> > It displays "Show unmodified files" link so that you can easily know
>>> > there's a way to show clean files by a single action.
>>> > If it sounds good, I'll rewrite this clumsy implementation.
>>> I think that's a quite clever of unconventional solution!
>>> One think I would change is that I would say "Show unmodified (clean)
>>> entries", to make sure people understand that unmodified files are called
>>> "clean" on the Mercurial jargon.
>> Good catch.
>>> Also, I think that perhaps the link could have a "temporary" effect. That
>>> is, rather than being the same as clicking on the "Clean" entry on the
>>> filter drop down, which has a "permanent" effect (as in "it won't change
>>> until the entry is clicked again"), clicking on that link could take effect
>>> only until the user selects a different widget so that when he comes back
>>> to the commit wisher the clean dukes are hidden again (as they should in
>>> most cases). What do you think?
>> That may be possible but we'll have to think about how to represent
>> "temporary" effect on filter drop down menu.
>> In any case, the implementation won't be much difference. For "temporary"
>> effect, I guess it just need to restore status filter on reload or refresh.
>> Regards,
> Some programs change the background color of lists when a temporary
> filter is applied. My current email client (NEO Pro, which is really
> awesome, BTW) works that way and is great.
That would probably be helpful for the graph widget when it is showing
a filtered graph