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" <marka...@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: 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. > >> >
