Single view instead of a split one

[Gal Szkolnik (Lockszmith-GH)]

My understanding of the 'flow'/logic of the application is as follows:

flowchart LR
    start([start])
    --> init[Initial filter settings]
    --> which{which view}
    which
        -->|Discover| ref-discover["refresh
              discover"]
        --> filter-discover[filter only non installed]
        --> cache-discover[("discover
              cache")]
        --> dicover
        -->|Search| ref-discover
    which
        -->|Updates | ref-updates["refresh
              updates"]
        --> filter-updates[filter only update pending]
        --> cache-updates[("updates
              cache")]
        --> updates
        -->|Search| filter-updates
    which
        -->|Setup   | ref-installed["refresh
              installed"]
        --> filter-installed[filter only installed]
        --> cache-installed[("installed
              cache")]
        --> installed
        --> |Search| filter-installed 

Loading

Would it make sense to have a single view, where a state column would distinguish between installed/available online/update available with a column that can be filtered?
And when searching, non-installed options will show (which can be filtered out as well)

I feel that a single-consistent view would streamline the entire application substantially.

I'm pretty sure you came about the three pane views view modes due to some limitation you encountered at first, so I'm curious whether you will entertain a different design to it?

I don't know if this diagram helps or not, but this is the flow I think would make working with UniGet most more smooth

flowchart LR
    start([start])

    subgraph data
        init(("init"))
        refresh(("refresh"))

        cache-discover[(
            discover
            cache
        )]
        cache-inst[(
            installed
            cache
        )]
        f[\
            filter
            installed/
            updates
        /]
    end
    unilist([
        Unified
        View
    ])
    action{action}
    search((search))
    filter((
        update
        filter
    ))

    init
        --> refresh
        --> cache-inst

    start
    %% Initializtion 
        -->|"(async)"| init
        -->|"reset"| cache-discover & f

    start
        -->|initialize| unilist

    %% Initializtion
    f ==o|"
            push update

            from cache to view
            (thorugh filter)
        "| cache-inst
    

    unilist ==o|
            push update
            from cache to view
        | cache-discover
        
    unilist ---> action
        
    action --> search
    action ----> filter
    action -----> refresh

    filter-.->|
        update
        filter
    | f --> unilist
    
    search -.->|
        update
        filter
    | f
    search -..->|
        query
        
        saerch criteria
    | cache-discover

Loading

[Martí Climent (marticliment)]

I don't understand what you mean. There is already a main view

[Gal Szkolnik (Lockszmith-GH)]

The main view is controlled by 3 modes: Dicover Package / Software Updates / Installed Packages.
Each of this views is controlled by a different search control.
They don't share any of the filters, sort options etc.

My suggestion is to have them combined into a single space, and have the filters distinguish between them.

[Martí Climent (marticliment)]

ah, I see.

There is an issue for a unified searchbar, perhaps the idea is the same

[Gal Szkolnik (Lockszmith-GH)]

If you mean #1054 (I found it now that you mentioned it), my suggestion will resolve that - yes.

I'm guessing that old issue comes from the same place.

I'm also looking at it from the app development side.
Holding only 2 lists in memory at all time:

1. that of all the apps installed.
2. IF a search term is provided, and available-to-install apps filter is on, list of avialable apps returned from the provider with the search term.

When rendering the list, # 1 is filtered through the search term in memory, and # 2 is presented 'as-is'.

The difference between these items are:

• Installed and Updates entries have Installed Versions values.
• Updates and non-installed entries have available versions values.
• Updates are the only type of entry that has both.

That's why it feels like a filter is the way to go, instead of the flashing re-rendering of the list we have today, as well as the search term being applied differently depending on the selected view.

[Martí Climent (marticliment)]

Yes, that is the issue I meant.

I will see what I can do

[Gal Szkolnik (Lockszmith-GH)]

Thanks for entertaining us 'needy users'.
And thanks for making such a useful and awesome tool. Even if you decide not to change a thing, this has improved the quality of life of anyone managing their own OS.