On Thu, May 27, 2010 at 6:16 PM, Chris Martin <chris@...> wrote:
> Opening the properties dialog, with the rule set is a problem as
> the properties do take up so much space, so a way to separate the properties
> from the rule set needs to be provided.
> how about single click brings up the rule-set
> If double click brinigs up the properties.
> This way we can still have consistent behaviour.
this is the single feature that caused the greatest number of
complaints in fwbuilder 3.0. If things open on single click, then they
do open when you really wanted to drag an object into a rule. If
single click applies only to rule set objects, then this is
inconsistent.
--vk
> ----------------------------------------------------------
> Chris Martin
> m: 0419812371
> ----------------------------------------------------------
>
>
> On Fri, May 28, 2010 at 8:55 AM, Vadim Kurland <vadim@...>
> wrote:
>>
>> Does anyone want to offer an opinion on this UI design subject ?
>>
>> To remind:
>>
>> in the released v4.0.0 double click on a Policy, NAT or Routing rule
>> set object opens it in the rule set view. To open this object in the
>> editor panel, you need to double click on it again.
>>
>> some time around v4.0.1 build 2900 this has changed because I've got
>> feedback from users who said this was inconsistent with the behavior
>> of the UI for other objects where double click always opens object in
>> the editor. So now double click on a Policy, NAT or Routing object
>> opens it in the rule set view and in the editor. Behavior is now
>> consistent, in that double click on an object in the tree always opens
>> it in the editor panel. If editor panel was closed, it opens up.
>>
>> Tom says this is bad and I should revert back to the behavior
>> implemented in v4.0.0
>>
>> Since opinions seem to be divided, I solicit more feedback from the
>> users on the mailing list. Please speak up and let us know which way
>> you think is more convenient.
>>
>> Note that object can be opened in the editor using context menu as
>> well. Just right mouse click on the object in the tree and use menu
>> item "Edit" to open it in the editor. Policy, NAT and Routing objects
>> have two menu items though, item "Edit" opens them in the editor and
>> item "Open" opens them in the rule set view but not in the editor. So
>> it is possible to just switch object in rule set view without changing
>> it in the editor or opening editor panel if it was closed.
>>
>>
>> To make things even more confusing, I would like to offer third option:
>>
>> what if I make the program never open editor panel on double click if
>> it is closed ? Double clicking on a policy, nat or routing object will
>> just switch it in the rule set view, double clicking on any other kind
>> of object will do nothing. If you need to edit objects, you would need
>> to open editor panel either using context menu item "Edit" or main
>> menu View/Editor Panel. Then, when editor panel is open, double
>> clicking would switch object opened in it, including policy, nat and
>> routing objects.
>>
>> It appears that most of the time the workflow is divided onto two
>> different tasks: we either edit policy by moving objects from the tree
>> and adding, removing or modifying rules, or we edit objects. Editor
>> panel gets in the way when we work with rules and it would be good if
>> it was possible to close it and make sure it stays out of the way.
>> However it is easy to open it again by double clicking on an object in
>> the tree. This seems to be the main complain and this is what I am
>> trying to address.
>>
>>
>>
>>
>> Thanks
>> --vk
>>
>>
>>
>> On Sat, May 22, 2010 at 10:34 AM, Vadim Kurland <vadim@...>
>> wrote:
>> > I can see you point. It is true that in most cases user just wants to
>> > switch from one rule set to another and not edit it. I can change
>> > behavior back to what it was prior to build 2892 but lets hear from
>> > other users too.
>> >
>> > About dependencies in rpms: I made the latest fwbuilder rpms depend on
>> > libfwbuilder rpms, taking into account version number (4.0.1) and
>> > build number. Please let me know if this fixed the problem with
>> > automatic dependencies on upgrade.
>> >
>> > --vk
>> >
>> >
>> > On Fri, May 21, 2010 at 8:15 PM, Tom Diehl <tdiehl@...> wrote:
>> >> On Fri, 21 May 2010, Vadim Kurland wrote:
>> >>
>> >>> On Fri, May 21, 2010 at 4:59 AM, Tom Diehl <tdiehl@...>
>> >>> wrote:
>> >>>>
>> >>>> Hi Vadim,
>> >>>>
>> >>>> Back in the 4.0 beta ver 2721 you made fwb stop opening the editor
>> >>>> window
>> >>>> when I
>> >>>> double click policy, NAT or routing.
>> >>>>
>> >>>> I am not sure when it started opening the editor again but in 2907
>> >>>> and
>> >>>> 2909
>> >>>> the editor opens when I double click on policy, NAT or routing. Is
>> >>>> there
>> >>>> any
>> >>>> possibility you can fix fwb so that it only switches from policy to
>> >>>> NAT,
>> >>>> etc
>> >>>> on the first double click?
>> >>>>
>> >>>> In case I am not being clear we discussed it in this thread:
>> >>>>
>> >>>>
>> >>>> http://sourceforge.net/mailarchive/message.php?msg_name=fa89f9d81003160041r393ffec1q3e6a24209ead1323%40mail.gmail.com
>> >>>>
>> >>>
>> >>> I had the opposite feedback, people were saying the behavior was
>> >>> inconsistent. For most objects double click opened them in the editor,
>> >>> but for the rule set objects it did not.
>> >>
>> >> But what is the point of opening the editor for the rule set objects
>> >> only
>> >> to have to close it again. It covers up the rules and now I have to
>> >> find
>> >> the x to close it EVERY time I switch between policy and NAT.
>> >>
>> >> To be honest, I prefer the behavior in fwb3 but since you said it
>> >> creates
>> >> other issues, the compromise was the double click. If there was
>> >> actually
>> >> something there to edit it might be different but 99.9999999% of the
>> >> time
>> >> all I am trying to do is switch the view. Actually in thinking about
>> >> this
>> >> a little more I liked the tabs in fwb2 the best but I will admit that
>> >> tabs would be difficult to do with multiple firewalls.
>> >>
>> >> As to the inconsistencies, I argue that the policy, Nat and routing
>> >> selections
>> >> are different than all of the other selections because those selections
>> >> have a dual function. Selecting anything else does not have the same
>> >> effect.
>> >>
>> >> Another change I noticed is that if I create a new object it no longer
>> >> opens
>> >> up in the editor window. Was this change deliberate? I find that also
>> >> kind
>> >> of annoying since when you create a new object you have to edit it in
>> >> order to for it to be useful. Old behavior was in my opinion better.
>> >>
>> >>> Lets have mini-opinion poll.
>> >>>
>> >>> What behavior of the GUI is more convenient with regards to the
>> >>> double click on a Policy, NAT or Routing object in the tree:
>> >>>
>> >>> - double click on one of these objects opens Policy, NAT or Routing
>> >>> object in the rule set view AND in the editor
>> >>> - first double click on one of these objects opens it in the rule set
>> >>> view (so you see the rules) but does not open it in the editor. Second
>> >>> double click on the object opens it in the editor.
>> >>
>> >> Obviously I am for the second one. :-)
>> >>
>> >>> There are also some subtleties, such as what to do if the editor panel
>> >>> is already open with some other object ? Should the first double click
>> >>> open rule set object in the editor in this case ?
>> >>
>> >> I am not sure I understand the above but in looking at current behavior
>> >> I do
>> >> not see a problem.
>> >>
>> >>>> Also, would it be possible to add a dependency to the rpms so that if
>> >>>> I
>> >>>> do
>> >>>> yum update fwbuilder it also pulls in libfwbuilder with it?
>> >>>
>> >>> spec file already has
>> >>>
>> >>> Requires: libfwbuilder = 4.0.1
>> >>>
>> >>>
>> >>> when I try "yum install fwbuilder", I get this:
>> >>>
>> >>> Dependencies Resolved
>> >>>
>> >>>
>> >>> ==========================================================================
>> >>> Package Arch Version
>> >>> Repository Size
>> >>>
>> >>> ==========================================================================
>> >>> Installing:
>> >>> fwbuilder i586 4.0.1-b2914.fc11
>> >>> fwbuilder-testing 7.8 M
>> >>> Installing for dependencies:
>> >>> libfwbuilder i586 4.0.1-b2914.fc11
>> >>> fwbuilder-testing 715 k
>> >>>
>> >>> Transaction Summary
>> >>>
>> >>> ==========================================================================
>> >>> Install 2 Package(s)
>> >>> Upgrade 0 Package(s)
>> >>
>> >> The problem is on upgrade. When I do yum update fwbuilder it does not
>> >> pull in the updated libfwbuilder. The only way I get libfwbuilder is if
>> >> I do
>> >> yum update \*fwbuilder. Just to be clear, the version of fwbuilder and
>> >> libfwbuilder must match. Is this correct?
>> >>
>> >> I suspect the problem is that I already have libfwbuilder 4.01
>> >> installed
>> >> but not libfwbuilder 4.0.1-b2914. I am pretty sure you could say
>> >> something
>> >> like Requires: libfwbuilder = %{version}-%{release} and that should
>> >> keep
>> >> them in sync.
>> >>
>> >>>
>> >>>
>> >>> It seems to work. I do not why would not it work on a different
>> >>> rpm-based distribution, but I can try. Which one do you use ?
>> >>
>> >> I use Fedora but I doubt that they are really different. I am just
>> >> invoking
>> >> it differently than you are. The problem with Fedora is that they push
>> >> mega amounts of updates and I quite frequently only update individual
>> >> packages
>> >> as opposed to doing yum update.
>> >>
>> >> Thanks for taking the time to consider my requests.
>> >>
>> >> Regards,
>> >>
>> >> --
>> >> Tom Diehl tdiehl@... Spamtrap address
>> >> mtd123@...
>> >>
>> >
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Fwbuilder-discussion mailing list
>> Fwbuilder-discussion@...
>> https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion
>
>
|