Re: [Qgis-developer] Ugly jumping maps while zooming
On Tue, Dec 23, 2014 at 02:12:48PM +0100, Matthias Kuhn wrote: > I think we need to distinguish a bit more in several categories of bugs > and features. > > *Regression bugs* > These are the bugs that affect previously working functionality. Like > the "ugly jumping maps while zooming". If something like this happens > it's normally tagged as blocker and a good reason to revert a commit > (unless fixed in a timely manner). The "ugly jumping..." has been fixed > (although in a way that I understood is not "perfect" but seems to be > "good enough"). Are there other bugs like this left? None that I know of. Nothing like this filed on hub. > *New-feature-not-yet-polished-enough bugs* > Like the one "rotation not reset after loading new project". They do not > affect users that don't touch the new features. IMO such bugs should not > keep a feature out of master but could justify an "experimental" tag and > explicit turning on the feature (we should get the config dialog to not > clutter the options with it). E.g. firefox has a number of features that > are only available via "about:config". I'm ready to work on implementing such configuration as next step. Someone suggested a command-line only way to enable it. I'd go further suggesting an environment variable. > *Feature does things the wrong way* > That is, a new feature takes code-wise or usability-wise an approach > that is not desirable. Such a thing should normally be spotted by the > reviewer but we cannot guarantee that the reviewer spots it so it should > also be possible to come up with this after merging. However, reasons > for this have to be stated so a developer can understand either _how_ he > can improve the code or _why_ it is not desirable at all. Are there > things that fall into this category with the rotation feature? I think a couple of issues could fall in this category: - PAL labeling support for rotation. Larry suggested to pre-rotate vectors before labeling, which makes sense to me. This is tracked here: http://hub.qgis.org/issues/11814 - MapCanvasItem size and position tracking Martin suggested a way to add knowledge about rotation which is currently missing. This is tracked here: http://hub.qgis.org/issues/11909 --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Error in new Metasearch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 19/12/2014 14:45, Tom Kralidis ha scritto: > Hi Paolo: FYI we have now merged MetaSearch into QGIS core. Can > you try now from there? Hi Tom, just upgraded to nightly; I get the service info, but I cannot get any result from the search. With plain 2.6.1 it was working fine. All the best, and thanks. - -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlSZwAkACgkQ/NedwLUzIr7bGQCfdIf67mzXrplY1tIP8FzMXDHj s2UAoK2//6ar9pdqf9p9/eCEGoKi+R6m =pP6y -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis 2.6.1 does not compile - error related to Python
Hi all (again), strike my last email. Python sources must be configured with ./configure --enable-shared I re-built Python eventually and a shared object file was generated. Correspondingly, I had to configure qgis with the following command instead: ccmake -D PYTHON_EXECUTABLE=/usr/local/bin/python2.7 -D PYTHON_INCLUDE_PATH=/usr/local/include/python2.7/ -D PYTHON_LIBRARY=/usr/local/lib/libpython2.7.so .. Regards, Sebastian Am 23.12.2014 um 18:50 schrieb Sebastian M. Ernst: > Hi all, > > I am running into some odd error related to Python while trying to > compile QGIS 2.6.1 from source on Linux-x86 using GCC 4.5.0. I can only > guess that I made a mistake of some sort when I compiled and installed > Python 2.7.9 in parallel to my Linux distribution's original Python > 2.6.5 previously, though it works as far as I can tell. Any pointers > towards what I am looking at exactly are greatly appreciated. > > Thanks, regards, > Sebastian > > > user@computer:~/Desktop/qgis-2.6.1/build-master> ccmake -D > PYTHON_EXECUTABLE=/usr/local/bin/python2.7 -D > PYTHON_INCLUDE_PATH=/usr/local/include/python2.7/ -D > PYTHON_LIBRARY=/usr/local/lib/libpython2.7.a .. > [...] > user@computer:~/Desktop/qgis-2.6.1/build-master> make > [...] > [ 85%] Built target offlineeditingplugin > [ 85%] Built target heatmapplugin > [ 85%] Built target spitplugin > Linking CXX shared library ../../output/lib/libqgispython.so > /usr/local/lib/libpython2.7.a(dynload_shlib.o): In function > `_PyImport_GetDynLoadFunc': > > /home/user/Desktop/Python-2.7.9/Python/dynload_shlib.c:94: undefined > reference to `dlsym' > /home/user/Desktop/Python-2.7.9/Python/dynload_shlib.c:130: undefined > reference to `dlopen' > /home/user/Desktop/Python-2.7.9/Python/dynload_shlib.c:141: undefined > reference to `dlsym' > /home/user/Desktop/Python-2.7.9/Python/dynload_shlib.c:133: undefined > reference to `dlerror' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_acquire_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:324: undefined > reference to `sem_wait' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_release_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:350: undefined > reference to `sem_post' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_start_new_thread': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:184: undefined > reference to `pthread_attr_setstacksize' > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:194: undefined > reference to `pthread_create' > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:210: undefined > reference to `pthread_detach' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_allocate_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:269: undefined > reference to `sem_init' > /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_free_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:294: undefined > reference to `sem_destroy' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_acquire_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:326: undefined > reference to `sem_trywait' > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:324: undefined > reference to `sem_wait' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_release_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:350: undefined > reference to `sem_post' > /usr/local/lib/libpython2.7.a(thread.o): In function > `_pythread_pthread_set_stacksize': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:497: undefined > reference to `pthread_attr_setstacksize' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_allocate_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:269: undefined > reference to `sem_init' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_acquire_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:324: undefined > reference to `sem_wait' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_release_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:350: undefined > reference to `sem_post' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_acquire_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:324: undefined > reference to `sem_wait' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_release_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:350: undefined > reference to `sem_post' > /usr/local/lib/libpython2.7.a(thread.o): In function > `PyThread_allocate_lock': > /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:269: undefined > reference to `sem_init' > collect2: ld returned 1 exit status > make[2]: *** [output/lib/libqgispython.so.2.6.1] Fehler 1 > make[1]: *** [src/python/CMakeFiles/qgispython.dir/all] Fehler 2 > make: *** [all] Fehler 2 > user@compute
[Qgis-developer] qgis 2.6.1 does not compile - error related to Python
Hi all, I am running into some odd error related to Python while trying to compile QGIS 2.6.1 from source on Linux-x86 using GCC 4.5.0. I can only guess that I made a mistake of some sort when I compiled and installed Python 2.7.9 in parallel to my Linux distribution's original Python 2.6.5 previously, though it works as far as I can tell. Any pointers towards what I am looking at exactly are greatly appreciated. Thanks, regards, Sebastian user@computer:~/Desktop/qgis-2.6.1/build-master> ccmake -D PYTHON_EXECUTABLE=/usr/local/bin/python2.7 -D PYTHON_INCLUDE_PATH=/usr/local/include/python2.7/ -D PYTHON_LIBRARY=/usr/local/lib/libpython2.7.a .. [...] user@computer:~/Desktop/qgis-2.6.1/build-master> make [...] [ 85%] Built target offlineeditingplugin [ 85%] Built target heatmapplugin [ 85%] Built target spitplugin Linking CXX shared library ../../output/lib/libqgispython.so /usr/local/lib/libpython2.7.a(dynload_shlib.o): In function `_PyImport_GetDynLoadFunc': /home/user/Desktop/Python-2.7.9/Python/dynload_shlib.c:94: undefined reference to `dlsym' /home/user/Desktop/Python-2.7.9/Python/dynload_shlib.c:130: undefined reference to `dlopen' /home/user/Desktop/Python-2.7.9/Python/dynload_shlib.c:141: undefined reference to `dlsym' /home/user/Desktop/Python-2.7.9/Python/dynload_shlib.c:133: undefined reference to `dlerror' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_acquire_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:324: undefined reference to `sem_wait' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_release_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:350: undefined reference to `sem_post' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_start_new_thread': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:184: undefined reference to `pthread_attr_setstacksize' /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:194: undefined reference to `pthread_create' /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:210: undefined reference to `pthread_detach' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_allocate_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:269: undefined reference to `sem_init' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_free_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:294: undefined reference to `sem_destroy' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_acquire_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:326: undefined reference to `sem_trywait' /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:324: undefined reference to `sem_wait' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_release_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:350: undefined reference to `sem_post' /usr/local/lib/libpython2.7.a(thread.o): In function `_pythread_pthread_set_stacksize': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:497: undefined reference to `pthread_attr_setstacksize' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_allocate_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:269: undefined reference to `sem_init' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_acquire_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:324: undefined reference to `sem_wait' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_release_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:350: undefined reference to `sem_post' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_acquire_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:324: undefined reference to `sem_wait' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_release_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:350: undefined reference to `sem_post' /usr/local/lib/libpython2.7.a(thread.o): In function `PyThread_allocate_lock': /home/user/Desktop/Python-2.7.9/Python/thread_pthread.h:269: undefined reference to `sem_init' collect2: ld returned 1 exit status make[2]: *** [output/lib/libqgispython.so.2.6.1] Fehler 1 make[1]: *** [src/python/CMakeFiles/qgispython.dir/all] Fehler 2 make: *** [all] Fehler 2 user@computer:~/Desktop/qgis-2.6.1/build-master> ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Compilation qgis2.7.0 with VS2010 and Qt 5.3.2
Hi Anatoliy, Does that mean that it worked fine before PR #1743? In general Qt5 support is still pretty new and did not receive much testing. I don't know how many people have run such a setup on Windows. It requires to also link dependencies like qwt, qwtpolar and qscintilla against Qt5. That said, it is very welcome if people test and improve Qt5 support. But if you want to stay out of the way of problems you are better off if you stick to the well-tested Qt4. Anyway, the problem you have here looks like a linker problem to the MSVCRT, so Windows specific and not Qt5 specific. As I seldom use Windows I can't offer more help than this hint, sorry. Regards, Matthias On 12/23/2014 02:34 PM, Anatoliy Golubev wrote: > Hi list! > Im trying to compile qgis 2.7.0 with Qt 5.3.2. After applying PR #1743 > all compiles fine (except qspatialite), but linking executables failed > with errors like this: > >Link: > C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\link.exe > /ERRORREPORT:PROMPT > /OUT:"D:\Projects\other\qgis\qt5\build-debug\output\Debug\qgis_help.exe" > /INCREMENTAL /NOLOGO > /LIBPATH:"D:/Projects/other/qgis/qt5/build-debug/src/core" > /LIBPATH:"D:/Projects/other/qgis/qt5/build-debug/src/core/Debug" > /LIBPATH:"D:/Projects/other/qgis/qt5/build-debug/src/gui" > /LIBPATH:"D:/Projects/other/qgis/qt5/build-debug/src/gui/Debug" > kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib > oleaut32.lib uuid.lib comdlg32.lib advapi32.lib > ..\core\Debug\qgis_core.lib d:\OSGeo4w\root\lib\sqlite3_i.lib > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Concurrentd.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5PrintSupportd.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Svgd.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Xmld.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5WebKitWidgetsd.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Widgetsd.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5WebKitd.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Guid.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Networkd.lib" > "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Cored.lib" wsock32.lib > "C:\Program Files\Microsoft SDKs\Windows\v7.0A\Lib\SetupAPI.Lib" > "C:\Qt\QScintilla-2.8.4\build-vs2010-qt5.3.2-debug\lib\qscintilla2d.lib" > d:\OSGeo4w\root\lib\proj_i.lib d:\OSGeo4w\root\lib\geos_c.lib > d:\OSGeo4w\root\lib\gdal_i.lib d:\OSGeo4w\root\lib\spatialindex_i.lib > d:\OSGeo4w\root\lib\libexpat.lib d:\OSGeo4w\root\lib\sqlite3_i.lib > d:\OSGeo4w\root\lib\spatialite_i.lib /MANIFEST > /ManifestFile:"qgis_help.dir\Debug\qgis_help.exe.intermediate.manifest" > /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG > /PDB:"D:/Projects/other/qgis/qt5/build-debug/output/Debug/qgis_help.pdb" > /SUBSYSTEM:WINDOWS /TLBID:1 /DYNAMICBASE /NXCOMPAT > /IMPLIB:"D:/Projects/other/qgis/qt5/build-debug/src/helpviewer/Debug/qgis_help.lib" > /MACHINE:X86 qgis_help.dir\Debug\qgis_win32.res > qgis_help.dir\Debug\qgis_help.exe.embed.manifest.res > qgis_help.dir\Debug\main.obj > qgis_help.dir\Debug\qgshelpviewer.obj > qgis_help.dir\Debug\moc_qgshelpviewer.obj > qgis_help.dir\Debug\qrc_images.obj /machine:X86 /debug > 1>MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external > symbol _WinMain@16 referenced in function ___tmainCRTStartup > 1>D:\Projects\other\qgis\qt5\build-debug\output\Debug\qgis_help.exe > : fatal error LNK1120: 1 unresolved externals > 1>Done Building Project > "D:\Projects\other\qgis\qt5\build-debug\src\helpviewer\qgis_help.vcxproj" > (build target(s)) -- FAILED. > > After some googling i find suggestion to change /SUBSYSTEM to CONSOLE, > but i dont think that this can help. > Any thoughts? > > System: Win 7 x86, VS2010, CMake 3.1.0, Qwt 6.1.1, Qwtpolar 1.1.1, > QScintilla 2.8.4, other libs from OSGeo4w > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGIS Server and external WMS through Proxy
Hi, I have a external WMS server, that I can access with user/password, but I can access to it only with our proxy server. It seems that I cannot configure QGIS Server to use proxy, is it right? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Compilation qgis2.7.0 with VS2010 and Qt 5.3.2
Hi list! Im trying to compile qgis 2.7.0 with Qt 5.3.2. After applying PR #1743 all compiles fine (except qspatialite), but linking executables failed with errors like this: Link: C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\link.exe /ERRORREPORT:PROMPT /OUT:"D:\Projects\other\qgis\qt5\build-debug\output\Debug\qgis_help.exe" /INCREMENTAL /NOLOGO /LIBPATH:"D:/Projects/other/qgis/qt5/build-debug/src/core" /LIBPATH:"D:/Projects/other/qgis/qt5/build-debug/src/core/Debug" /LIBPATH:"D:/Projects/other/qgis/qt5/build-debug/src/gui" /LIBPATH:"D:/Projects/other/qgis/qt5/build-debug/src/gui/Debug" kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib ..\core\Debug\qgis_core.lib d:\OSGeo4w\root\lib\sqlite3_i.lib "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Concurrentd.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5PrintSupportd.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Svgd.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Xmld.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5WebKitWidgetsd.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Widgetsd.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5WebKitd.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Guid.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Networkd.lib" "C:\Qt\Qt-online\5.3\msvc2010_opengl\lib\Qt5Cored.lib" wsock32.lib "C:\Program Files\Microsoft SDKs\Windows\v7.0A\Lib\SetupAPI.Lib" "C:\Qt\QScintilla-2.8.4\build-vs2010-qt5.3.2-debug\lib\qscintilla2d.lib" d:\OSGeo4w\root\lib\proj_i.lib d:\OSGeo4w\root\lib\geos_c.lib d:\OSGeo4w\root\lib\gdal_i.lib d:\OSGeo4w\root\lib\spatialindex_i.lib d:\OSGeo4w\root\lib\libexpat.lib d:\OSGeo4w\root\lib\sqlite3_i.lib d:\OSGeo4w\root\lib\spatialite_i.lib /MANIFEST /ManifestFile:"qgis_help.dir\Debug\qgis_help.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"D:/Projects/other/qgis/qt5/build-debug/output/Debug/qgis_help.pdb" /SUBSYSTEM:WINDOWS /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"D:/Projects/other/qgis/qt5/build-debug/src/helpviewer/Debug/qgis_help.lib" /MACHINE:X86 qgis_help.dir\Debug\qgis_win32.res qgis_help.dir\Debug\qgis_help.exe.embed.manifest.res qgis_help.dir\Debug\main.obj qgis_help.dir\Debug\qgshelpviewer.obj qgis_help.dir\Debug\moc_qgshelpviewer.obj qgis_help.dir\Debug\qrc_images.obj /machine:X86 /debug 1>MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup 1>D:\Projects\other\qgis\qt5\build-debug\output\Debug\qgis_help.exe : fatal error LNK1120: 1 unresolved externals 1>Done Building Project "D:\Projects\other\qgis\qt5\build-debug\src\helpviewer\qgis_help.vcxproj" (build target(s)) -- FAILED. After some googling i find suggestion to change /SUBSYSTEM to CONSOLE, but i dont think that this can help. Any thoughts? System: Win 7 x86, VS2010, CMake 3.1.0, Qwt 6.1.1, Qwtpolar 1.1.1, QScintilla 2.8.4, other libs from OSGeo4w ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Ugly jumping maps while zooming
Hi all, I think we need to distinguish a bit more in several categories of bugs and features. *Regression bugs* These are the bugs that affect previously working functionality. Like the "ugly jumping maps while zooming". If something like this happens it's normally tagged as blocker and a good reason to revert a commit (unless fixed in a timely manner). The "ugly jumping..." has been fixed (although in a way that I understood is not "perfect" but seems to be "good enough"). Are there other bugs like this left? *New-feature-not-yet-polished-enough bugs* Like the one "rotation not reset after loading new project". They do not affect users that don't touch the new features. IMO such bugs should not keep a feature out of master but could justify an "experimental" tag and explicit turning on the feature (we should get the config dialog to not clutter the options with it). E.g. firefox has a number of features that are only available via "about:config". *Feature does things the wrong way* That is, a new feature takes code-wise or usability-wise an approach that is not desirable. Such a thing should normally be spotted by the reviewer but we cannot guarantee that the reviewer spots it so it should also be possible to come up with this after merging. However, reasons for this have to be stated so a developer can understand either _how_ he can improve the code or _why_ it is not desirable at all. Are there things that fall into this category with the rotation feature? All the best, Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Ugly jumping maps while zooming
To be fair to all, there should probably be an agreed upon understanding on what would need fixing/implementing for the rotation feature to sticik prior to 2.8, and if it can't be achieved by then revert the commits until next dev cycle? I can't be the judge of that, senior devs needed :) On 23 Dec 2014 19:06, "Nathan Woodrow" wrote: > >> I agree with Paolo, and also see the value of Sandro's argument that > developing such functionality in a branch get's much less > testing/viewing and is very hard to merge back. Myself I only had a > serious look at it when it was in master... > > Sometimes it's not about other people testing, sometimes it's about having > time for other developers to review the code, even just by eyeing it over, > before it is merged in. Other people might be able to pick up things that > you might miss and save you the effort of bug fixing it later, or you might > be doing it completely wrong to start with. > > Sometimes it is also about not having a feature until it is ready, some > things just need to wait until they are ready. > > I also understand that sometimes things seem simple but lead to more > issues then you expect, we have all been there, however that is why we have > testing branches It makes the user experience in QGIS a lot nicer. > > I am in no way against the feature, it is a good one, in fact I have a use > for it in Roam, and I do not wish to undermine Sandro's efforts rotation is > a big task, however as it has the possibility of introducing regressions it > should be treated with care - also merging a feature in and then trying to > get more funding for bugs is IMO not a cool move. > > If you write code that has small impact, import/export bookmarks for > example, I don't care if something like that is merged right in, small foot > print, small use case, easy fix, but for something that touches a major > core part of the code I think reviews should be done. > > - Nathan > > On Tue Dec 23 2014 at 8:10:18 PM Richard Duivenvoorde > wrote: > >> On 23-12-14 08:06, Paolo Cavallini wrote: >> > Hi Nyall, >> > >> > Il 22/12/2014 23:47, Nyall Dawson ha scritto: >> > >> >> I disagree - while there may be an issue with the difficulty of getting >> >> wide testing of pull requests, the solution isn't to allow broken code >> >> into master. >> > >> > You're right, we're big boys now, must behave. However: >> > * the code is in good shape, not broken; works smoothly in a variety of >> > situations >> > * it opens a whole set of new and exciting applications, e.g. live >> > tracking, drone monitoring, etc. >> > * there are unsupported functions, as pointed out >> > * if we remove it from master, it will soon become unmergeable, and will >> > probably get lost; it happened several times in the past that what we >> > left out of the door was never recovered. >> > Overall, I still believe keeping it, but letting conscious users >> > activate it when necessary, is a good compromise. >> > In the meantime, we can start raising funds to complete the set of >> > necessary features (I do not think it's a huge amount of work, once the >> > money is found we have time to implement these for 2.8). >> > All the best, and thanks for your thoughts. >> >> I agree with Paolo, and also see the value of Sandro's argument that >> developing such functionality in a branch get's much less >> testing/viewing and is very hard to merge back. Myself I only had a >> serious look at it when it was in master... >> >> So as long as we can hide it for normal users (even without tickbox, we >> can make a cli-option for it :-) ), AND nothing is broken I'm in favour >> of letting it in master. >> >> I think Sandro should hide the spinbox in the statusbar for now, and >> nay-sayers should now try to find bugs related to rotation work? >> >> There is a PSC-meeting on 2th januari, let's make the final decision >> there. >> >> Regards, >> >> Richard Duivenvoorde >> ___ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Ugly jumping maps while zooming
>> I agree with Paolo, and also see the value of Sandro's argument that developing such functionality in a branch get's much less testing/viewing and is very hard to merge back. Myself I only had a serious look at it when it was in master... Sometimes it's not about other people testing, sometimes it's about having time for other developers to review the code, even just by eyeing it over, before it is merged in. Other people might be able to pick up things that you might miss and save you the effort of bug fixing it later, or you might be doing it completely wrong to start with. Sometimes it is also about not having a feature until it is ready, some things just need to wait until they are ready. I also understand that sometimes things seem simple but lead to more issues then you expect, we have all been there, however that is why we have testing branches It makes the user experience in QGIS a lot nicer. I am in no way against the feature, it is a good one, in fact I have a use for it in Roam, and I do not wish to undermine Sandro's efforts rotation is a big task, however as it has the possibility of introducing regressions it should be treated with care - also merging a feature in and then trying to get more funding for bugs is IMO not a cool move. If you write code that has small impact, import/export bookmarks for example, I don't care if something like that is merged right in, small foot print, small use case, easy fix, but for something that touches a major core part of the code I think reviews should be done. - Nathan On Tue Dec 23 2014 at 8:10:18 PM Richard Duivenvoorde wrote: > On 23-12-14 08:06, Paolo Cavallini wrote: > > Hi Nyall, > > > > Il 22/12/2014 23:47, Nyall Dawson ha scritto: > > > >> I disagree - while there may be an issue with the difficulty of getting > >> wide testing of pull requests, the solution isn't to allow broken code > >> into master. > > > > You're right, we're big boys now, must behave. However: > > * the code is in good shape, not broken; works smoothly in a variety of > > situations > > * it opens a whole set of new and exciting applications, e.g. live > > tracking, drone monitoring, etc. > > * there are unsupported functions, as pointed out > > * if we remove it from master, it will soon become unmergeable, and will > > probably get lost; it happened several times in the past that what we > > left out of the door was never recovered. > > Overall, I still believe keeping it, but letting conscious users > > activate it when necessary, is a good compromise. > > In the meantime, we can start raising funds to complete the set of > > necessary features (I do not think it's a huge amount of work, once the > > money is found we have time to implement these for 2.8). > > All the best, and thanks for your thoughts. > > I agree with Paolo, and also see the value of Sandro's argument that > developing such functionality in a branch get's much less > testing/viewing and is very hard to merge back. Myself I only had a > serious look at it when it was in master... > > So as long as we can hide it for normal users (even without tickbox, we > can make a cli-option for it :-) ), AND nothing is broken I'm in favour > of letting it in master. > > I think Sandro should hide the spinbox in the statusbar for now, and > nay-sayers should now try to find bugs related to rotation work? > > There is a PSC-meeting on 2th januari, let's make the final decision there. > > Regards, > > Richard Duivenvoorde > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Ugly jumping maps while zooming
On 23-12-14 08:06, Paolo Cavallini wrote: > Hi Nyall, > > Il 22/12/2014 23:47, Nyall Dawson ha scritto: > >> I disagree - while there may be an issue with the difficulty of getting >> wide testing of pull requests, the solution isn't to allow broken code >> into master. > > You're right, we're big boys now, must behave. However: > * the code is in good shape, not broken; works smoothly in a variety of > situations > * it opens a whole set of new and exciting applications, e.g. live > tracking, drone monitoring, etc. > * there are unsupported functions, as pointed out > * if we remove it from master, it will soon become unmergeable, and will > probably get lost; it happened several times in the past that what we > left out of the door was never recovered. > Overall, I still believe keeping it, but letting conscious users > activate it when necessary, is a good compromise. > In the meantime, we can start raising funds to complete the set of > necessary features (I do not think it's a huge amount of work, once the > money is found we have time to implement these for 2.8). > All the best, and thanks for your thoughts. I agree with Paolo, and also see the value of Sandro's argument that developing such functionality in a branch get's much less testing/viewing and is very hard to merge back. Myself I only had a serious look at it when it was in master... So as long as we can hide it for normal users (even without tickbox, we can make a cli-option for it :-) ), AND nothing is broken I'm in favour of letting it in master. I think Sandro should hide the spinbox in the statusbar for now, and nay-sayers should now try to find bugs related to rotation work? There is a PSC-meeting on 2th januari, let's make the final decision there. Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Minimal rotation support (was: Ugly jumping maps while zooming)
On Tue, Dec 23, 2014 at 09:40:59AM +1100, Nyall Dawson wrote: > As it stands right now, what is the use of this feature? It can't be used > for presentation (no composer support) nor for analysis or querying use > (broken selection and info tools). Without addressing these issues this > feature has no current use case (I may be missing something here, feel free > to fill me in if I am). In order to plan for fundraising we need a clear view on what's the minimal support state for the feature in order to be accepted in the 2.8 release. I've tried to tag all rotation-related issues with the "rotation" tag so it's easier to see them (sorry but I don't see the URL with embedded query from hub to include here). Could you please help adding the missing tickets (for example I see nothing about composer nor info tool) and mark those you think are extremely necessary as "blocker" ? Right now a single one is marked as such, and is about the rotation value being retained when starting a new project. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
