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.w...@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 <b...@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" <trk...@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 < > >>> computertech2...@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.w...@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. >
