nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From johny casanova <computertech2...@gmail.com>
Subject RE: [DISCUSS] Feature proposal: Read-only mode as default
Date Mon, 10 Aug 2015 21:59:43 GMT
I agree I think Mark explained it right on the money what I was trying to
say before.
On Aug 10, 2015 3:44 PM, "Mark Payne" <markap14@hotmail.com> wrote:

> I'm definitely a +1. I accidentally drag processors all the time when I'm
> panning around a large graph.
>
> I can understand how someone would get annoyed with this, though, and I
> can also appreciate the desire
> to not start storing user preferences. However, I think we should probably
> at least supply a system-level
> configuration for whether or not to have "read-only" the default mode.
> Then administrators can turn it on
> or off, depending on the users of the system.
>
>
>
> ----------------------------------------
> > Date: Sat, 8 Aug 2015 20:50:07 -0400
> > Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default
> > From: adam@adamtaft.com
> > To: dev@nifi.apache.org
> >
> > Thinking about it some more, I don't mind the concept of "read only"
> > toggle. Maybe it's not set by default, but it could be a really easy UI
> > element to add somewhere. Just a little slider-toggle element. [1]
> >
> > In theory, this might be a UI only feature, it wouldn't strictly need
> > support in the backend api (just guessing). The logic is seemingly
> already
> > there, similar user experience as non-DFMs.
> >
> > Anyway, +1 to the concept of read-only toggle mode. -1 for making it
> > default, but the user interface element should be easy to work either
> way.
> >
> > Also agree that undo support might be free if versioning is added.
> >
> > [1]
> http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg
> >
> >
> >
> >
> > On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <joe.witt@gmail.com> wrote:
> >
> >> Ryan - the other useful case for read-only is basically when is
> >> scanning around the graph and accidentally moves a processor or
> >> relationship. By no means a big deal. The idea here was to make it
> >> explicit though that the user wishes to go into an edit mode.
> >>
> >> I do think the undo mechanism plays well and you're right that we can
> >> just focus on tightening up the delete case.
> >>
> >> Sounds like the prevailing view is to avoid read-only as a mode but
> >> rather to make it more explicit whenever we delete - and potentially
> >> move we could make more specific rather than simply them having
> >> clicked and dragged which is ambiguous with the process of panning.
> >>
> >> On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue <blue@cloudera.com> wrote:
> >>> I'm not a big fan of having a read-only mode by default. It sounds like
> >>> something that would be frustrating for users when they try to make
> >> changes
> >>> and then have to figure out how to switch modes.
> >>>
> >>> I think a clearer picture of the problem we're trying to solve would
> >> help my
> >>> understanding. I'm primarily thinking of the delete case you mentioned
> >> with
> >>> these comments...
> >>>
> >>> If we're talking about accidentally deleting processors, then the
> current
> >>> mechanisms (IIRC) work pretty well: not deleting a running processor,
> one
> >>> that has live incoming connections, etc. If those rules are
> >> insufficient, I
> >>> would explore extending them rather than having a global read-only
> mode.
> >>>
> >>> For the case where the wrong processor is selected because it is off
> the
> >>> screen, maybe having the confirmation pop up if anything affected
> wasn't
> >>> displayed to confirm? That way we don't have confirmations all the time
> >> but
> >>> still don't do unexpected things.
> >>>
> >>> I really like the idea of "undo" as well. If that is limited to
> >> processors
> >>> that weren't running (because you can't delete ones that are), then
> that
> >>> makes the undo operation easier to implement.
> >>>
> >>> rb
> >>>
> >>>
> >>> On 08/08/2015 11:31 AM, Joe Witt wrote:
> >>>>
> >>>> I can dig the user pref aspect but it would mean we start storing user
> >>>> prefs which is a bummer.
> >>>> On Aug 8, 2015 1:42 PM, "Tony Kurc" <trkurc@gmail.com> wrote:
> >>>>
> >>>>> Personally not a fan of the idea. Maybe something analogous to
> >> something
> >>>>> like 'lock the taskbar' in Windows that can have a system default
> >> setting
> >>>>> and a user preference of on or off.
> >>>>>
> >>>>> On Sat, Aug 8, 2015 at 11:44 AM, johny casanova <
> >>>>> computertech2124@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I agree it is easy to move it delete something by mistake. Some
> flows
> >>>>>> are
> >>>>>> huge or are using,more resources and are slower to load and
you can
> >>>>>> accidently do something by mistake. I believe the "are yous
sure u
> >> want
> >>>>>
> >>>>> to
> >>>>>>
> >>>>>> delete?" its a good start.
> >>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <joe.witt@gmail.com>
wrote:
> >>>>>>
> >>>>>>> Team,
> >>>>>>>
> >>>>>>> We've been hearing from users of nifi that it is too easy
to
> >>>>>>> accidentally move something on the flow or delete large
portions of
> >>>>>>> the flow. This is the case when panning the screen for example
and
> >>>>>>> accidentally having a processor selected instead.
> >>>>>>>
> >>>>>>> What is worth consideration then is the notion of making
the flow
> >>>>>>> 'read-only' by default. In this case the user would need
to
> >>>>>>> explicitly 'enable edit mode'. We would then also support
a
> >>>>>>> confirmation dialog or similar construct whenever deleting
> components
> >>>>>>> on the flow.
> >>>>>>>
> >>>>>>> Anyone have a strong objection to this concept? If so, do
you have
> >> an
> >>>>>>> alternative in mind that would help avoid accidental movement?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Joe
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Ryan Blue
> >>> Software Engineer
> >>> Cloudera, Inc.
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message