The Portable Freeware Collection Forums

Please consider adding the option to sort results in the database by Size (uncompressed) (Smallest first). Currently the options available to sort by are, Most recent first and Most popular first Thanks!

Well.. this could be useful if you're looking at a specific category e.g. "Text - Editors".

I agree that this would be nice as I often find myself wanting the smallest filesize for an app first.

Looking at a category of apps (as abc mentions above), it would be helpful to sort by other criteria, and uncompressed size would be high on my list.

I could see the criteria expanded, and made into something like a drop down list (to save space):

• Sort by

- Most recent
- Most popular
- Uncompressed size
- Unicode
- Stealth
- etc

Mentioned this in the "design" discussion as well, as it also involves design, but likely more appropriate here.

Another vote for this query.
Is there any current plan to implement this "Sort by app size" function?

Given multiple apps with equivalent functionalities, I tend to favor the more compact one.
"Sort-by-Size" would be very handy for quickly vetting the "smallest sized apps" returned by a query in the "ALL" software categories.

Thanks,

__philippe

+1 vote for sort options !

+1 vote here too to be able to sort by UNCOMPRESSED SIZE plus as I mentioned a while back I would love to see (~Memory Footprint) aside or below the Uncompressed Size so as to be able to compare performance of tiny apps which results in nimbleness and productivity.

Another dormant request rearing its pesky head yet again..."Sort DB Search Results by uncompressed Size"

DB search results usually include multiple likely candidate apps.

Given multiple apps with equivalent functionalities, I tend to favor the more compact one.
"Sort-by-Size" would be very handy for quickly vetting the "smallest sized apps" returned, for instance,
by a query for a specific software Category .

The idea would be to add a new "Sort by (Argument)" option alongside the existing
"Search results" "Newer first | Compact View | Display n entries" header line.

The potential Sort argument could be any of :

• "Size uncompressed" (sum total of distro package unpacked elements)
• "Date Released"
• "PE executable(s) size" (yet to-be-defined)
• "Memory footprint size" (yet to-be-defined)

This new "Sort by" function has been suggested before by a couple of members (well...seven, actually... ),
but I wonder whether unforeseen implementation ramifications do perhaps make this request decidedly impracticable, in view of the modest benefits expected ?

but I wonder whether unforeseen implementation ramifications do perhaps make this request decidedly impracticable, in view of the modest benefits expected ?

It's the latter. I just hate everything-but-the-kitchen-sink approach to options. Who else thinks this is a great idea?

Doctor's opinion :

• Diagnosis:      acute case of creeping optionitis
• Prognosis:      potential contagious propagation within whole community
• Prescription: isolate patient, sedate with one-shot "sort-by-size-uncompressed" placebo injection

Andrew Lee wrote:Who else thinks this is a great idea?

• You can add me. I usually follow the same line of reasoning so well expounded by __philippe in my fumblings...

Ahem...

"Sort-by-App-Size" new field request status: "in limbo"...

How about, instead, a relatively painless-to-implement, inconspicuous workaround :
ADD the DB's internal current field "Size(in bytes)" as a new column to the TPFC dump structure, which currently lacks such a field ?

I, for one, wouldn't mind tinkering now and then with the ensuing "enhanced" tpfc.CSV's...

__philippe wrote:Ahem...

"Sort-by-App-Size" new field request status: "in limbo"...

How about, instead, a relatively painless-to-implement, inconspicuous workaround :

ADD the DB's internal current field "Size(in bytes)" as a new column to the TPFC dump structure, which currently lacks such a field ?

I, for one, wouldn't mind tinkering now and then with the ensuing "enhanced" tpfc.CSV's...

As you wish, done!

Andrew Lee wrote:

__philippe wrote:Ahem...

"Sort-by-App-Size" new field request status: "in limbo"...

How about, instead, a relatively painless-to-implement, inconspicuous workaround :

ADD the DB's internal current field "Size(in bytes)" as a new column to the TPFC dump structure, which currently lacks such a field ?

I, for one, wouldn't mind tinkering now and then with the ensuing "enhanced" tpfc.CSV's...

As you wish, done!

The dump script now produces invalid CSV. The double-quote character is missing at the end of the size field.

Andrew Lee wrote: As you wish, done!

@Andrew
Wow ! That's customer service indeed !

Cheers ! (and please also see comments to SYSTEM's post)
(fixed smiley URL)