Bug report #16845
Layers missing when project opened in Linux master 7d67b02, works fine in master 313ec55
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||Xubuntu 17.10||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||duplicate|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||24744|
I have not supplied sample data because it can be loaded if I make 181 of the layers inaccessible to the project when it is loaded, then it loads all the layers that were missing when it tried to load the full project.
Now in #16049 it was first noted that the Linux version of this software imposes some arbitrary layer limit that does not exist in the Windows version of the software and it would now seem to be the case that the latest master for Linux has further squeezed down this limit, now how about actually addressing this problem otherwise why have a Linux version that is arbitrarily crippled so as to be unusable.
#2 Updated by Giovanni Manghi over 3 years ago
- Status changed from Open to Feedback
So what is needed to replicate this on linux/qgis master? a project with a least how many layers? shapefiles? other type of datasources?
The limit is not in QGIS itself, but in rather in the operatying system, afaik. And when you open a shapefile you are actually opening at least 3 files (shp, shx and dbf, and possibly also prj).
#3 Updated by Patrick Dunford over 3 years ago
Oh this is an easy fix
Your developer in the case of bug 16873 has said it's very simple
"We don't care if you have a project file produced from an older 2.99 release. We have introduced a new incompatible project file format and we aren't supporting the old one any more. If it doesn't import all the features of the previous release that's just tough" (in effect).
I do not know how you encourage people to become beta testers and run your development versions of software because it is actually very difficult and time consuming to maintain multiple different versions of project files across the same project, right now it would be a 2.18 version and it would appear multiple 2.99 versions of project files that are incompatible with each other. This difficulty has led me to invest a lot of effort in having enough different VMs running different versions to work around all of the bugs that are in the 2.99 releases so I can use my real world projects to test the software out, and only have to maintain hopefully one up to date (2.99) version of the project file.
As it happens 2.18 can read enough data from a 2.99 project file to be able to display all the data, it becomes more complicated when trying to use some of the GUI editor features when some of the data like value maps (drop down lists) won't transfer back, then it is too much work to hand copy the data from the 2.99 file to the 2.18 so for this reason I have put a lot of effort into keeping a working (currently older) version of 2.99 that can do everything.
Every time up until now when a new 2.99 release came out it automagically imported the older project file and migrated it to the new version, now apparently that is too hard to do, it won't happen any more. My response it is too hard for me to maintain multiple different versions of a 2.99 project file and hand migrate data from a newer version back to an older version, I need the older versions in order to be able to guard against new bugs being introduced that make it unstable. Because for the first time I can remember this new format simply ignores some of the data in the older project file and you have to fix the settings by hand, it would appear. It simply isn't possible to open the older project file and display the maps without tweaking a pile of settings by hand.
So my perspective is surely it's not that hard to migrate an older 2.99 project file, just make it easier for me to test your development software, because I can stop testing it right now and refuse to upgrade to the latest development release and migrate the project files until 3.0 comes out.
#4 Updated by Regis Haubourg over 3 years ago
Patrick, some thoughts. You provide hard work in testing, which is very valuable for all of us, but in the same time you make harsh judgments, which may be counter productive.
When you say "Your developer", please note that there is no big corp' with people paied by QGIS.
All contributors and developer do a massive FREE job dealing feature request, issue management and code review on their FREE time because we trust in a collaborative project we build together. QGIS is one of the most welcoming and open minded project I've seen, but this relies on everyone's behavior.
Please keep being positive and keep in mind that when you ask for QGIS master, which is under heavy refactor to be as reliable as a minor release, when this is a major change, we may answer you that early testing comes with accepting project or data loss.. T
You can consider also getting commercial support if you need things that are not provided for free by the community.