Patch to show Available Packages by category on pfsense 2.1



  • As 2.1 is branched, new features are included on future 2.2

    Recently I've submitted a packages by catergory change.

    To apply it on 2.1, follow these steps:

    • Install 'system patcher' pacakge

    • Access it after install and click on "plus" icon to add a new patch

    • On description field, insert "Packages by category" for example

    • ON url/ID field , paste 3740c81012

    • Save config

    • On system patcher main screen, you can see description and patch url

    • Following the sequence, click on fetch, test and apply

    If you do not got any errors, available packages will now have category tabs  :)





  • Nice job like it :)



  • Marcelloc The Dude! Very nice!  8)



  • Marcelloc, FYI

    /usr/bin/patch --directory=/ -f -p1 -i /var/patches/51aadc41d462a.patch --check --reverse 
    
    Hmm...  Looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    |From 9b4df982f3e28ceeb8a7a0face1852976d95d9c7 Mon Sep 17 00:00:00 2001
    |From: marcelloc 
    |Date: Wed, 22 May 2013 13:15:31 -0300
    |Subject: [PATCH] Add dynamic category tabs for better listing all available
    | packages
    |
    |---
    | etc/inc/pkg-utils.inc     |  33 ++++++
    | usr/local/www/pkg_mgr.php | 266 +++++++++++++++++++++++-----------------------
    | 2 files changed, 167 insertions(+), 132 deletions(-)
    |
    |diff --git a/etc/inc/pkg-utils.inc b/etc/inc/pkg-utils.inc
    |index a7e8cc0..644eba9 100644
    |--- a/etc/inc/pkg-utils.inc
    |+++ b/etc/inc/pkg-utils.inc
    --------------------------
    Patching file etc/inc/pkg-utils.inc using Plan A...
    Hunk #1 failed at 1333.
    1 out of 1 hunks failed--saving rejects to etc/inc/pkg-utils.inc.rej
    Hmm...  The next patch looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    |diff --git a/usr/local/www/pkg_mgr.php b/usr/local/www/pkg_mgr.php
    |index bfb6d46..cf1a26c 100755
    |--- a/usr/local/www/pkg_mgr.php
    |+++ b/usr/local/www/pkg_mgr.php
    --------------------------
    Patching file usr/local/www/pkg_mgr.php using Plan A...
    Hunk #1 failed at 3.
    Hunk #2 failed at 69.
    Hunk #3 failed at 109.
    Hunk #4 failed at 241.
    4 out of 4 hunks failed--saving rejects to usr/local/www/pkg_mgr.php.rej
    Hmm...  Ignoring the trailing garbage.
    done
    


  • What pfSense version are you using and how many times did you tried to apply the patch?



  • Version:
    2.0.3-RELEASE (i386)
    built on Fri Apr 12 10:22:57 EDT 2013
    FreeBSD 8.1-RELEASE-p13

    Tried three times to Fetch and Test it. Every time same message.



  • @xudus:

    Version:
    2.0.3-RELEASE (i386)

    Take a look on topic subject:
    Patch to show Available Packages by category on pfsense 2.1



  • Ooops.


  • Rebel Alliance Developer Netgate

    It would still be best to have an "all" tab and default to that. People will miss/ignore the tabs and wonder where packages went.

    IMHO, time would be better spent on a search function to match/filter on the name and description to make things easier to find. Tabs help people browsing to see what packages exist and such but more often than not people know what they want it's just hard to scroll to find them in the list (and ctrl+f helps, but could be better)

    The usefulness of tabs also depend on people accurately categorizing the packages, which isn't always the case, and some are very ambiguous/overlap.



  • Nice job marcelloc…. in this scenario it works and I'm not complaining, but sense the topic came up here are my alternate thoughts on it.

    • Add icon legend at top of page

    • Add a category column to the table.

    • In the category table for the package, apply all icons which apply.

    Or

    • Add icon legend at top of page

    • Simply add icons in the Description table which already exist.

    As jimp stated some packages overlap… so you might have multiple categories a package might qualify for.

    @jimp:

    The usefulness of tabs also depend on people accurately categorizing the packages, which isn't always the case, and some are very ambiguous/overlap.

    Random Example icons ….. apply all category icons which apply to package in the appropriate table.




  • @jimp:

    The usefulness of tabs also depend on people accurately categorizing the packages, which isn't always the case, and some are very ambiguous/overlap.

    I think this is a first step to get usefull category options, there are almost 100 packages today and IMHO it's getting some time to find a package if you are looking for  a tool instead of a package you know the name.

    Renato suggested to include an  "All packages" tab or a search field. What do you think?


  • Rebel Alliance Developer Netgate

    Defaulting to a restricted one-category list tab does a few bad things (and probably more I'm not thinking of):
    1. As mentioned previously, people will not see the tabs and wonder where packages disappeared to.
    2. People will have to hunt through multiple tabs to find a package if they don't know and can't correctly guess the package category. What took two clicks before suddenly takes half a dozen and a lot more time.
    3. It makes it less obvious just how many awesome packages there are. The giant list makes us look good there. :-)

    I would not use tabs at all, but do search and include categories in the search. Your "tabs" could now just be shortcut links to search the category, or a search filter that does the same job.

    Best thing, I think, would be that the default should be 'all packages' but have a search box right at the top. Maybe a drop down to restrict by category but it would have "All packages" as its first choice.

    Perhaps something like:

    [ Text Box For Search ] [Category Drop-Down] [ "Go"/"Search" button ]

    Enter search terms to filter the list, or select the category from the box, press search (no text entry) would display all packages in the category.

    Since the entire list of packages is known before the page is rendered, that could all be done in javascript and could do autocomplete or immediate filtering (meaning it could look like AJAX but doesn't actually make additional calls)