D7745: KDevelop (full) project parsing: defer until all projects have been loaded.

René J.V. Bertin noreply at phabricator.kde.org
Sun Sep 17 14:47:08 UTC 2017


rjvbb added a comment.


  >   Watching directories is quite essential when working with Git or other SCMs. When checking out another branch, I want KDevelop's file tree to be updated as well.
  
  My proposition doesn't make that impossible. It just makes it optional.
  
  Of course that option could be hidden/omitted on platforms where it doesn't make sense. I have no issue with that, but didn't propose it because I know many do have a grip with platform #ifdefs. I could of course disable and hide the checkbox on Linux if KDirWatch uses inotify. I don't really want to go the direction of doing this as a function of project size: too machine-specific and personal (and thus random).
  
  Unless we replace the checkbox with a file limit (where 0 would mean "always off")?
  
  >   That works if your main method to open files is to use the project manager. However, some people prefer opening files via the //Quick Open// bar. In that case you want to watch the entire tree, otherwise new files might be invisible for a long time.
  
  I work mainly on a platform where dirwatching doesn't work anyway, and I get by. It's not a big deal to do a (partial) reload of the project tree. Annoying sometimes, but I don't have any other choice anyway.
  (Reminder, dirwatching did work in KDevelop4 but ate file descriptors so had to be limited.)
  
  >   The difference between IMAP and our situation is that in the former case there is a network connection (usually WAN), while in the latter case all files are typically local.
  
  Yes, the cost of continuous syncing is in different things, but it can still be a cost that is best avoided.
  
  Does anyone know what the other costs are (on Linux), not in terms of project import duration but runtime costs that add up to become significant above a certain project size (memory, interrupts, file descriptors, gnomes, moonrays, whatever)?

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D7745

To: rjvbb, #kdevelop
Cc: aaronpuchert, arrowdodger, brauch, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170917/36364570/attachment.html>


More information about the KDevelop-devel mailing list