+1 to exactly what Mark described in his last email for a system wide preference.
Although I'm curious how you leave read-only mode and get into edit mode? And how do you leave edit mode and go back to read-only mode? On one hand, if I do not intend to edit the graph and I accidentally move a processor I probably don't want it to prompt me "do you want to enter edit mode?" -In read-only mode, I think it would be a nice user experience to click anywhere on the graph(including on a processor) and it moves the entire graph. On the other hand, if I right click a processor and hit configure I'd like to leave read-only mode and go into edit mode. I'm not sure I'd even want to be prompted with "do you want to enter edit mode?" here since I obviously do. Dan Bress Software Engineer ONYX Consulting Services ________________________________________ From: Mark Payne <marka...@hotmail.com> Sent: Monday, August 10, 2015 3:43 PM To: dev@nifi.apache.org Subject: RE: [DISCUSS] Feature proposal: Read-only mode as default 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: a...@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.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. >>
