Messages - IainB [ switch to compact view ]

Pages: prev1 ... 58 59 60 61 62 [63] 64 65 66 67 68 ... 1318next
311
N.A.N.Y. 2019 / Re: [N.A.N.Y. 2019] - Process Lister [status=done]
« on: October 24, 2018, 05:34 AM »
@KodeZwerg:
Thankyou.
...Kind of a challenge to proof that scaling (playing with DPI/PPI) works since you mentioned that it aint good :-]  ...
Now that's rather interesting. What it seems to imply is that scaling at the OS level may be broken somehow.
Tell me:
  • Instead of stepped scaling (e.g., at doubled or quadrupled steps), are you able to make the scaling gradual and incrementally variable between lower and upper limits, through rolling the mousewheel? (Zoom in, zoom out.)
  • If you can do that, can you apply it to work on any open window in other applications? (For an interesting example, try to zoom in/out using Ctrl+mousewheel on the Windows Desktop.)

On another subject, if you can display the "new" information re Process Creation time, could you also display columns which provide:
  • (a) the current Running Time for currently running processes - i.e., the dynamic calculated result of current time minus Process Creation time?
  • (b) the total running time of historical processes (in this session) which had earlier started and now have stopped?
That could be quite useful information.

312
N.A.N.Y. 2019 / Re: [N.A.N.Y. 2019] - Process Lister - Requirements?
« on: October 23, 2018, 07:57 PM »
@KodeZwerg:
For me, the double-sized print is very legible - a bit too big maybe - and the quad-sized print is humungous, but there would probably be many people with severe visual impairment who could be glad to have that size and who might otherwise usually have to rely on the Windows Magnifier tool.

In terms of providing a process/task listing though, ProcessLister would seem to fall well behind a pack of some already-established and serious contenders - e.g., including:
  • Windows TaskManager,
  • SysInternals ProcessExplorer
  • Wn Jia Liu's ProcessHacker
- the latter is the one I prefer to use as it best meets my peculiar ergonomic needs as well as my user requirements for a process/task manager.

And that is the point, really - i.e., what are one's user requirements?
From training in systems analysis, I would usually tag user business requirements in a systematic manner, using the ABC prioritisation method, where:
  • A = Mandatory (Urgent and Important)
  • B = Highly desirable (Important, but NOT Urgent)
  • C = Nice-to-have (Neither Important NOR Urgent)
(Anything outside of these 3 classes is purely imaginary and not related to an operational  business need/requirement per se.)

I don't really have a defined set of "business/user requirements" for ProcessLister per se, but if I did, then it would match the user requirements that I might have and which had been met/exceeded by ProcessHacker. Though I use the thing on a daily basis and it is an invaluable tool for monitoring and managing the operation of the Windows system, it is still just a utility - a useful tool - and I do not consider it worthwhile to sit down and define/document those requirements. I have found by trialling the above tools that ProcessHacker seems to be the most useful tool for my peculiar purposes, but someone else might have different requirements/purposes, so it might not be so useful to those people - i.e., YMMV (Your Mileage May Vary).

By the way, because PIM (Personal Information Management) is a very important matter for me in my personal and work life, I have defined and documented my requirements - e.g., in evaluating CHS (Clipboard Help and Spell) I applied the above method:
@mouser - by the way, there is still this: User Requirements for CHS

It could be used to save repetition by different/new CHS users. I put quite a bit of effort into that. Have not updated it in ages as no-one seemed interested. I think I left it as public and editable.
- which has apparently caused some readers to experience such traumatic mind-expansion and neural damage that it induces a temporary state of profound sleep from which the reader awakens with a complete loss of memory of ever having seen it in the first place. (This is the way Nature helps us to recover from traumatic experiences.)

313
Cross-posted her for information/relevance, from another discussion thread on the DC forum:
@phillie08:
Yes, the simple explanation would seem to be that the cached thumbnails that are of concern to you - and which do not contain the latest artefacts in the original image and that were added to that image - could probably be of an earlier version of the image. One can only suppose as to why the cached thumbnail was not updated.

Those thumbnails will have been created by the Windows OS and stored in a database/cache - which is an accumulator and will contain thumbnails of since-deleted/changed image files.
It is thus generally a good housekeeping practice to periodically run cleanmgr.exe (in Admininstrator mode and set to to clean up system files). When doing this, ensure that there is a tick against the "Thumbnails" item. For example:

24_412x509_F576AFBA.png
The example screenshot above shows 26.0MB of Thumbnails - which is not much really and is usually larger (I had already not long ago run cleanmgr.exe before taking this screenshot).
It can be educational to search the system with Everything for files with "thumb  .db" (with the embedded space). That will identify all the Thumbnail-related files that comprise the 26.0MB  - in my case, they are mostly/all in:
C:\Users\[UserID]\AppData\Local\Microsoft\Windows\Explorer\

Those files will have names with "thumbcache" in them - e.g. "thumbcache_768.db".

An Everything search will also be able to show you where all the "Thumb" and "Thumb  .db' named files are, so that you can delete them as necessary. Generally, system "Thumbs.db" files are to be found in all those directories where images are stored. They are Windows OS system files (caches), but it doesn't hurt to periodically sweep them up in a housekeeping run - e.g., using Everything to identify them prior to deletion - since they are accumulators and could contain thumbnails of since-deleted/changed image files (hence the problem discussed here), so that, over time, they could become bloated with useless garbage. The Windows OS will recreate anew the deleted thumbnail cache - with up-to-date thumbnails - as and when it is forced to open those image files again for any purpose.

If you use third party image file managers - e.g., (say) Picasa3 - then, from experience, you will generally find that they create and update their own peculiar thumbnail caches/databases. For example, in my case, Picasa3 builds several thumbnail and preview database files (caches) that are approx 2GB in size.    :o

So, in my case, I would therefore tend to leave well enough alone there, since Picasa3 will have done a lot of work to deliberately build those caches, rather than rely on the Windows OS thumbnail caching system. So far, Picasa3 never seems to have displayed for me the outdated cached thumbnail problem discussed here. I suspect that the Picasa3 cache build and maintenance processes will have been designed for optimum performance (efficiency and speed) - i.e., with garbage removed periodically by Picasa3 systematically updating the thumbnails cache after an image is deleted/changed.

314
Screenshot Captor / Re: Thumbnails don't show embedded objects
« on: October 23, 2018, 06:05 PM »
@phillie08:
Yes, the simple explanation would seem to be that the cached thumbnails that are of concern to you - and which do not contain the latest artefacts in the original image and that were added to that image - could probably be of an earlier version of the image. One can only suppose as to why the cached thumbnail was not updated.

Those thumbnails will have been created by the Windows OS and stored in a database/cache - which is an accumulator and will contain thumbnails of since-deleted/changed image files.
It is thus generally a good housekeeping practice to periodically run cleanmgr.exe (in Admininstrator mode and set to to clean up system files). When doing this, ensure that there is a tick against the "Thumbnails" item. For example:

24_412x509_F576AFBA.png

The example screenshot above shows 26.0MB of Thumbnails - which is not much really and is usually larger (I had already not long ago run cleanmgr.exe before taking this screenshot).
It can be educational to search the system with Everything for files with "thumb  .db" (with the embedded space). That will identify all the Thumbnail-related files that comprise the 26.0MB  - in my case, they are mostly/all in:
C:\Users\[UserID]\AppData\Local\Microsoft\Windows\Explorer\

Those files will have names with "thumbcache" in them - e.g. "thumbcache_768.db".

An Everything search will also be able to show you where all the "Thumb" and "Thumb  .db' named files are, so that you can delete them as necessary. Generally, system "Thumbs.db" files are to be found in all those directories where images are stored. They are Windows OS system files (caches), but it doesn't hurt to periodically sweep them up in a housekeeping run - e.g., using Everything to identify them prior to deletion - since they are accumulators and could contain thumbnails of since-deleted/changed image files (hence the problem discussed here), so that, over time, they could become bloated with useless garbage. The Windows OS will recreate anew the deleted thumbnail cache - with up-to-date thumbnails - as and when it is forced to open those image files again for any purpose.

If you use third party image file managers - e.g., (say) Picasa3 - then, from experience, you will generally find that they create and update their own peculiar thumbnail caches/databases. For example, in my case, Picasa3 builds several thumbnail and preview database files (caches) that are approx 2GB in size.    :o

So, in my case, I would therefore tend to leave well enough alone there, since Picasa3 will have done a lot of work to deliberately build those caches, rather than rely on the Windows OS thumbnail caching system. So far, Picasa3 never seems to have displayed for me the outdated cached thumbnail problem discussed here. I suspect that the Picasa3 cache build and maintenance processes will have been designed for optimum performance (efficiency and speed) - i.e., with garbage removed periodically by Picasa3 systematically updating the thumbnails cache after an image is deleted/changed.

EDIT: Also cross-posted this (for relevance) to the DC forum discussion thread: Google Picasa "Sunset" version - Mini-Review and anchor-point.

315
N.A.N.Y. 2019 / Re: [N.A.N.Y. 2019] - Process Lister [status=done]
« on: October 22, 2018, 03:42 AM »
@KodeZwerg:
...For now, me will read your Tips&Tricks Thread and see what I can do to realize everything in a good manner. ...
Thanks! Please don't feel you have to fix it to meet my requirements, but I shall be interested in what you come up with.
By the way, changing the DPI scaling seems to be of zero use, as you may gather from reading the thread I linked to.

Pages: prev1 ... 58 59 60 61 62 [63] 64 65 66 67 68 ... 1318next
Go to full version