Hi Agus:
While I totally agree with your "bottom line" i.e.:
[quoted from below]
"I think that QGIS is not far from such an operational point and that
making an effort on reaching it rather than on developing newer tools for a
while would make a lot of sense... for users. Obviously, developers will do
what they will be willing to do. All what users can do is telling other
users
what the situation is. "
your criticism might be a bit harsh in getting there.
The problem you raise here is one specific (external) plugin. That poor
student who has to submit his project in 24 hr. is indeed caught in a
bad situation. Still qgis devs should focus on core functionality, and
stability, leaving the new not-fully-tested stuff to the plugin
architecture.
Also...
Agustin Lobo wrote:
I think this issue is equivalent to the one on having
Mrsid and ecw support under linux. From
I don't think this comparison is correct. Support for mrsid and ecw is,
I believe, a widely requested feature that should be considered *core
functionality*. With your help and encouragement, we had a simple gdal
plugin on ubuntu 9.04, and hopefully that will soon be available on 9.10
also, like it is on the OSGeo windows installer.
Regards,
Micha
a developer point of view (Jurgen), the fact that plugin Scatter plot
does not work because of a python-qwt5 problem is not "a qgis problem".
But from the user perspective, anything making qgis not working properly
or not fulfilling a set of minimum operational requirements must
be "a qgis problem".
In this particular case, if the situation is that there is no
python-qwt5 package able to let a given plugin work, then either
the qgis developers accept that making an specially-tuned binary
version of
the python-qwt5 package is a TODO task, or the "qgis book of style of
python
plugins"
must state that no plugins should be made relying on that package, and
thus
an alternative for the current Scatter plot plugin should be in the
agenda.
In general terms, I think that the qgis developers should discuss and
get to an agreement
on whether the goal is having an operational package or a testbed
for newer developments and proofs of concepts where reaching an
operational reliability is not a main issue.
Both options are valid, but they are different, and users must know the
choice.
I totally disagree with the comments posted by Tim Sutton and Paolo
Cavallini few weeks ago:
"> The counter side to the 'FOSS developers expect users to be compiling
> geeks' debate is that users always want things at no effort and now
:-)
Tim: agreed fully. Too often we have requests from users, too rarely we
have help"
Users must put their effort on using QGIS, and their satisfaction is
the main reason for QGIS to exist. With no or few users, qgis will
decay. And users do a lot of effort on using QGIS, as they often must
deal with
problems that are not present in commercial software and sometimes
find, with
frustration, that their processing chain gets interrupted
in an step where qgis tools are not working (and the only answer they get
is "this is solved in svn trunk". A pretty satisfactory answer for a
developer,
but a totally devastating answer for an student with his/her exercise
to be due
in 24h). For some users, this is the price to pay because they cannot
afford
paying the licenses
but for some others, having several alternatives of commercial licenses
paid as campus licenses, this is the price they pay for actively
collaborating
on a public domain tool which, they believe, will be better on the
long run.
We must all acknowledge the contribution made by developers. We must all
acknowledge the contribution made by of users.
The question is reaching a point in which a minimal set of critical
operations
are reliably and efficiently done by QGIS (independently of other
software such
as GRASS: QGIS+GRASS is already operational, but this is because GRASS
reached
operational status 20 years ago). From this point on, people having
stable jobs (i.e., GIS technicians at universities, professors,
researchers...)
will put a significant part of their paid time on debugging, enhancing
and
extending QGIS. This is the case of R, which is, i my opinion, the
paramount
example of success of public domain software, at least in science. I
do not
know the exact numbers, but I think that despite the significant
direct funding,
the most important source of funding for R comes from paid working time
invested by academic personnel with stable jobs).
I'm working on a web page in which I will propose a set of critical tasks
to be accomplished by a GIS software, along with an score of
operationality and
comments for the specific case of QGIS on the different OS for which
binary
versions exist. Hopefully other users will add their opinions.
In an equivalent way, I'll try to set up another page for the plugins,
so that
users can have a fast check on the degree of operationality of a
giving plugin
prior to actually installing it.
I think that QGIS is not far from such an operational point and that
making an effort on reaching it rather than on developing newer tools
for a
while would make a lot of sense... for users. Obviously, developers
will do
what they will be willing to do. All what users can do is telling
other users
what the situation is.
Hopefully this message reaches enough "controversiality degree" for
you to
comment during the hackfest
Have fun!
Agus
Jürgen E. Fischer wrote:
Hi Agus,
On Tue, 27. Oct 2009 at 17:42:28 +0100, Agustin Lobo wrote:
Hmm... all I get is that building of qt3 should be avoided. Perhaps I
should wait until a general solution is set, perhaps during
your hackfest? Hopefully...
I doubt that it is a qgis problem at all. You probably just need proper
python-qwt5 packages.
Jürgen
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
This mail was received via Mail-SeCure System.
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
