[Desktop-packages] [Bug 869793] Re: Nautilus is very slow when opening folders with many files

2019-07-23 Thread Deepinthekernel
I so agree with richardbrucebaxter on this. When I switched all my
computers from Windows 98 to Linux in the late 90's this was the biggest
practical difference. Now I know its not Linux or the file system but
Nautilus that is the problem. Its exactly the same today, load up a
large file on a windows system, bang its in your face, right there. On
Ubuntu, it several minutes wait.  This is a daily thing for me.

I hear all the arguments that say its bad practice to have large
directories, but sorry I need to do this and if other file managers can
cope why not Nautilus?

There are many avenues of attack, from better caching, to mult-thread,
to prioritization, but this should be fixed. Now we have many file
systems that are as fast as they get in this situation, Nautilus just
sits on the sidelines, its a terrible shame.

Linked to this, the whole thumbnail mechanism in Nautilus is broken,
because thumbnails are stored in one place per PC, when its obviously
better to store locally as windows does, so that if you make a copy of a
dirctory with a new name this metadata just gets copied and does not
have to be recalculated. It should also be that tif you move a
directory, there is no need to recalculate thumbnail metadata.

Most importantly, some of these things (large directories, local
thumbnails etc) are important to some people and not important to
others. Nautilus should be easily configurable to meet the needs of
users and users who need this stuff should be catered for, not told that
your use case is unimportant or bad practice, this argument is a
circular tautology (defines itself  to be true).

Please, Nautilus is a central part of the usability of Linux, please
could it not be stuck in the  90's ? Please could this be given some
priority, even if it is "hard".

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/869793

Title:
  Nautilus is very slow when opening folders with many files

Status in Nautilus:
  Invalid
Status in nautilus package in Ubuntu:
  Confirmed

Bug description:
  Opening folders with many files takes a long time with Nautilus, to the point 
it becomes unusable for folders with more than 5K files. 
  I've measured the time it takes for folders with different amount of files to 
open with Nautilus and Gnome Commander. It is ~6 times faster with GC on 
average. In folders with ~20K files, it takes 30s with nautilus versus 6! with 
GC. 

  With Nautilus
  ~3500 files tales 6 seconds
  ~7000 files takes 18 seconds
  ~15000 files takes 22 seconds
  ~2 files takes 30 seconds

  With Gnome Commander
  ~3500 files tales <1 second
  ~7000 files takes 1.5 seconds
  ~15000 files takes 3 seconds
  ~2 files takes 6 seconds

  These are mostly small dicom files (MRI images). I am using a 8 core 3.4Ghz 
and 16Gigs of RAM with Ubuntu 11.04 64-bits.
  Also, of course, things like selecting all files and copying them around is 
absurdly slow and makes nautilus unusable... but that would be another bug 
report (?).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nautilus/+bug/869793/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 221594] Re: Efficient use of screen is very poor when small

2018-05-22 Thread Deepinthekernel
I opened this bug many years ago. Nobody did anything about it in spite
of many people agreeing with me.

To be honest I would not bother these days, there is too many major
things wrong with Ubuntu to bother about trivial but obvious things.
Things that affect the on-the-ground user.

Back to this bug, this is the result of poor design and faulty design
theory, its wilful not accidental.  It ought to be obvious to the
designer once pointed out, the same way it is to everyone else.

And yet we wait many years until the bug expires, and call that fixed.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-system-monitor in Ubuntu.
https://bugs.launchpad.net/bugs/221594

Title:
  Efficient use of screen is very poor when small

Status in Gnome System Monitor:
  Expired
Status in gnome-system-monitor package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: gnome-system-monitor

  I have my screen resolution set at 1680x1050.  The smallest I can make
  this app is that it still occupies about 1/6 of the screen area.  This
  is really bad use of space - an app like this should be able to
  operate even when its window is taken down to the size of a postage
  stamp.

  Not only that, but when operating at its smallest size, - it shows 3
  graphs, the height of the graphs is in total less than 20% of the
  window height, the rest is just wasted space.

  The important things in the voids between the graphs, such as the key
  and the scales, should plip out of existance when the graph gets below
  a certain size.

  When the graph is bigger, these problems are mitigated somewhat.

  Ubuntu 8.04. 
  gnome-system-monitor

  ProblemType: Bug
  Architecture: i386
  Date: Fri Apr 25 00:59:36 2008
  DistroRelease: Ubuntu 8.04
  ExecutablePath: /usr/bin/gnome-system-monitor
  Package: gnome-system-monitor 2.22.0-1ubuntu3
  PackageArchitecture: i386
  ProcEnviron:
   
PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-system-monitor
  Uname: Linux 2.6.20-15-generic i686

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-system-monitor/+bug/221594/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp