Scattergram with compiled qwt5.2.0

[Agustin Lobo]

Plugin scattergram requires python-qwt5.
As the available binaries of python-qwt5-qt3 5.1.0 for ubuntu jaunty
cannot be installed because rely on python < 2.6,
I've compiled PyQwt v5.2.0 according to:
http://pyqwt.sourceforge.net/doc5/installation.html

Nevertheless, the plugin installer still complains that
"this plugin requires a missing module (Qt5)"

Any idea on what to do?

Thanks

Agus
_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Jürgen E. Fischer]

Hi Agus,

On Tue, 27. Oct 2009 at 15:19:57 +0100, Agustin Lobo wrote:
> Nevertheless, the plugin installer still complains that
> "this plugin requires a missing module (Qt5)"

> Any idea on what to do?

Build a new package?  See [1] starting with 07:54:57, [2] and [3]

[1] http://logs.qgis.org/slogs/%23qgis.2009-10-25.log
[2] http://paste.debian.net/49897/
[3] http://paste.debian.net/49902/


Jürgen

--
Jürgen E. Fischer         norBIT GmbH               Tel. [phone]
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. [phone]
Software Engineer         D-26506 Norden               http://www.norbit.de

--
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Agustin Lobo]

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...

Agus

Jürgen E. Fischer wrote:

> Hi Agus,
>
> On Tue, 27. Oct 2009 at 15:19:57 +0100, Agustin Lobo wrote:
>  
>> Nevertheless, the plugin installer still complains that
>> "this plugin requires a missing module (Qt5)"
>>    
>
>  
>> Any idea on what to do?
>>    
>
> Build a new package?  See [1] starting with 07:54:57, [2] and [3]
>
> [1] http://logs.qgis.org/slogs/%23qgis.2009-10-25.log
> [2] http://paste.debian.net/49897/
> [3] http://paste.debian.net/49902/
>
>
> Jürgen
>
>  

[alobolistas.vcf]

---

begin:vcard
fn:Agustin Lobo
n:Lobo;Agustin
org:Institut de Ciencies de la Terra "Jaume Almera" CSIC
adr:;;Lluis Sole Sabris s/n;Barcelona;;08028;Spain
email;internet:[hidden email]
url:http://www.ija.csic.es/gt/obster
version:2.1
end:vcard

---

_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Agustin Lobo]

I think this issue is equivalent to the one on having
Mrsid and ecw support under linux. From
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Paolo Cavallini]

On Sat, 07 Nov 2009 12:41:06 +0100, Agustin Lobo <[hidden email]>
wrote:

> 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".

Agreed.

> 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.

This is not true: without developer it would decay, with lots of devs and
no user (admittedly, a paradoxical situation) qgis would be just as good :)

And users do a lot of effort on using QGIS, as they often must deal


> but a totally devastating answer for an student with his/her exercise to
be
> due

This is not true: anybody can use trunk from previous day, with no effort,
even on windows.

> We must all acknowledge the contribution made by developers. We must all
> acknowledge the contribution made by of users.

Correct: I just posted such an acknowledgement. But there are thousands of
users that do not contribute the slightest to the project; this is a
weakness of all free project, and their own responsibility.
If all QGIS users would be as active as you, lots of problems would be
already solved.
All the best, and keep on helping!
--
http://faunalia.it/pc
_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Carson Farmer]

My two cents:

On Sat, Nov 7, 2009 at 11:41 AM, Agustin Lobo <[hidden email]> wrote:
> I think this issue is equivalent to the one on having
> Mrsid and ecw support under linux. From
> 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".

Perhaps not a qgis "problem"... but a qgis "issue" certainly ;-)

> 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"

I think the only possibly solution is the latter... qgis devs barely
have time for qgis
issues, let alone Python-Qt problems. In fact, we are currently
working on guidelines
for Python plugins in qgis, and it will have to be up to the plugin
authors to make sure
their plugins obey these guidelines. Qgis main developers simply can't
support plugins
introduced by all plugin authors, and in fact, the author(s) of the
problem plugins
should be contacted directly (note that there are actually very few
officially supported
plugins in the official repo).

> 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 this particular case, the scatterplot plugin is really just a
contributed plugin that is
there for those who need it, but is not 'part of qgis' and as such
isn't currently on the
agenda at all. Right now I think stability of current tools (and
improvement of current
functionality) is a more important agenda item...

> 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.

Certainly it is already the former... the proofs of concept and
cutting edge stuff is almost always
plugins (at least to start with), and again, plugins are something
separate to the core qgis. I
think what we are seeing quite a bit of the time is users and
contributors focusing more
on developing plugins, and the devs are focused much more on the core
libraries. This is how it
should be (in my opinion), and the fact that some plugins are unstable
is simply an artifact of the
fact that there is currently no rigorous guidelines from submitting plugins

> Both options are valid, but they are different, and users must know the
> choice.

The goal is to move towards a fully stable, operational GIS... plugins
and extra features (such as scatterplots)
are simply nice extensions at the moment..

> 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.
Hmm, I don't think I agree with this, those new users are certainly important!

> 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.

We must also acknowledge that QGIS is a 'work in progress'. There are
going to be many features
that are lacking, and when users submit bug reports, these features
get added (maybe not always
'right now'). We simply don't have the funding to build a fully
functional platform right off the bat. We
also have to acknowledge that QGIS is still a relatively young
project, and as it grow, the number of
users/contributors/developers will grow... meaning these features that
are lacking will start to be
added faster and faster (which I think we're already seeing).

Indeed, the contributions of all are important... but we also have to
note that developers
do not 'serve the users', they are users themselves, and are
volunteering their time to work
on things that 'they need'. If they can, they will also implement
things that other users need,
but in the end, there is only so much time in the day.

> 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.

Great, this is the type of thing that helps clarify what needs to be done.
I also think it's important to acknowledge that plugins are indeed a
separate thing, and many
*are* simply proofs of concepts, *not* ready for production use. It's
up to users to tell the plugin
authors they are interested, and to support further development!

> 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.

Agreed!


Carson
--
Carson Farmer
National Centre for Geocomputation
John Hume Building,
National University of Ireland, Maynooth,
Maynooth,
Co. Kildare,
Ireland.
www.carsonfarmer.com
_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Barry Rowlingson]

On Sat, Nov 7, 2009 at 11:41 AM, Agustin Lobo <[hidden email]> wrote:

> 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.

 [legal note] R (and Qgis) is not 'public domain software'. 'Public
domain' is a legal term that generally means out of copyright and with
no usage restrictions. R and the packages in CRAN are under a variety
of open-source licenses including the GPL, and are copyright of
various authors and institutions - it is this copyright that allows
authors to place works under the GPL. [ends]

 My 2 euros:

 Packages are accepted into CRAN only if they pass various QC checks
and if they have an active maintainer. If a maintainer gives up on a
package it disappears from CRAN. This doesn't happen often since an
outgoing maintainer will advertise and a keen user will take it up.
Qgis is similar - Clearly a problem with a plugin in a third-party
repo is not a Qgis issue, and shouldn't be tracked in the qgis trac.
If the developer doesn't fix it then it's open source -- the user can
fix it themselves or pay to get it fixed. Plugins in the qgis repo are
a qgis problem, and if they can't be fixed by maintainers then should
be 'orphaned'.

 Your problem with a student having trouble getting their coursework
done because of a software bug also occurs in proprietary software but
worse - I've seen bugs - serious bugs - in a proprietary stats package
go unfixed for years. Just trying to find a place to report bugs is
often impossible. I had to resort to emailing an old friend who worked
for the company after being unable to find a bug report email address
on their website. I suspected the company thought their program had no
bugs. Try finding a bug tracker or support forum for SPSS even today!

 The situation with R is often that the gap between developer and user
is very small. Packages are often written because that person wants to
use a particular functionality (often from theory they have
developed). With Qgis mostly the theory is well-developed (raster
algebra, geometry calculations) and users just want to use it, and the
motivation for developers is less since they can probably do it all in
Grass anyway.

 Actually I don't know what drove half a dozen or so to gather in
Vienna this week! You're all mad! :)


Barry
_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Micha Silver]

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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
> This mail was received via Mail-SeCure System.
>
>

_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user