Accidentally moving processors is the main reason that I like this idea. However, I would like to see it truly in read-only mode. If I go to Configure a processor, I may still not want to edit the processor. I may just want to view the configuration and I'd like to ensure that I don't accidentally change (or delete) something.
---------------------------------------- > Date: Mon, 10 Aug 2015 13:02:35 -0700 > From: b...@cloudera.com > To: dev@nifi.apache.org > Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default > > If we're talking about read-only mode as a way to avoid moving > processors when moving around on the graph, what about implementing > something slightly different? What about having a toggle between > drag-to-scroll and drag-to-move? Then users could keep the toggle in > drag-to-scroll most of the time (and undo would put things back when the > inevitable accident happens). > > Then deletes would be handled by more sophisticated rules, like not > deleting processors that are off the screen without confirmation. > > rb > > On 08/10/2015 12:58 PM, Dan Bress wrote: >> +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. >>>> > > > -- > Ryan Blue > Software Engineer > Cloudera, Inc.
