Hi
On Thu, Oct 6, 2011 at 9:50 PM, Camilo Polymeris cpolyme...@gmail.com wrote:
Hello all,
just wanted to let you know that work on the QGIS processing framework
is continuing. This week I have fixed some simple, but long-pending
issues, like sorting of paramters, distinction between
Hi Camilo
generally I agree with Julien's comments.
I do not fully understand what do you mean with Module instance serialization.
On Fri, Jul 8, 2011 at 9:04 PM, Camilo Polymeris cpolyme...@gmail.com wrote:
I agree with your analysis : being able to access the QGis layers for the
El , Martin Dobias wonder...@gmail.com escribió:
Hi Camilo
generally I agree with Julien's comments.
I do not fully understand what do you mean with Module instance
serialization.
Storing presets (sets of values for parameters). I think this could be
either by pickling,
Hi
Sorry I just caught up on this thread now. I share Martin's concern
about dropping C++ support by adopting traits directly. Have you made
a decision on this, is C++ still on the cards?
Regards
Tim
On Fri, Jul 8, 2011 at 7:46 AM, MALIK Julien julien.ma...@c-s.fr wrote:
Hello Camilo,
Some
Hi
Sorry I just caught up on this thread now. I share Martin's concern
about dropping C++ support by adopting traits directly. Have you made
a decision on this, is C++ still on the cards?
Regards
Tim
On Fri, Jul 8, 2011 at 7:46 AM, MALIK Julien julien.ma...@c-s.fr wrote:
Hello Camilo,
Some
On Fri, Jul 8, 2011 at 1:25 AM, Paolo Cavallini cavall...@faunalia.it wrote:
Il 07/07/2011 23:06, Camilo Polymeris ha scritto:
identify a few and compile a short list[1], to try to keep focused
List missing ;)
Oops.
[1] https://github.com/polymeris/qgis/wiki/Timeline
On Fri, Jul 8, 2011 at 2:53 AM, Tim Sutton li...@linfiniti.com wrote:
Hi
Sorry I just caught up on this thread now. I share Martin's concern
about dropping C++ support by adopting traits directly. Have you made
a decision on this, is C++ still on the cards?
Yes, it still is -- I intend to
Hello everyone,
the end of GSoC's first term is nearing and while I think we have made
a significant progress, many things are still pending. I have tried to
identify a few and compile a short list[1], to try to keep focused
during the next few weeks.
I'll try to create a proper timeline with
Il 07/07/2011 23:06, Camilo Polymeris ha scritto:
identify a few and compile a short list[1], to try to keep focused
List missing ;)
--
Paolo Cavallini: http://www.faunalia.it/pc
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
Hello Camilo,
Some feedback about your todo list :
- constraints and validator is low priority to me : it can be handled
by the underlying implementation for now
- user level is low priority to me as it will probably be easy to add
this feature later when the big things will be in shape
-
I don't know if this is relevant to the crashes you have been getting, but
TraitsUI and most other Enthought Qt-oriented GUI projects use version 2 of
the SIP QString and QVariant APIs:
https://github.com/enthought/pyface/blob/master/pyface/qt/__init__.py
This is done so they can swap
On Sat, Jul 2, 2011 at 2:37 PM, Camilo Polymeris cpolyme...@gmail.comwrote:
I have now invested a week trying to reconcile traits the processing
framework, without satisfying results. It may have to do with me not
having any experience with traits.. but I must admit, I am quite
confused and
Hi Camilo
I hope I am not coming too late to join the discussion... I have not
studied the Traits documentation yet, but from what I read in the
intro it seems that the framework is tightly bound to Python. Earlier
I have suggested to start prototyping the framework in Python, though
it would be
On Mon, Jun 27, 2011 at 3:59 PM, Camilo Polymeris cpolyme...@gmail.com wrote:
Given that there are no objections I have studied the traits docs
without finding any reason against it, I'll start migration of the
framework.
Having trouble with that.. QGIS segfaults when I try to load any of
the
Il giorno mar, 28/06/2011 alle 03.09 -0400, Camilo Polymeris ha
scritto:
On Mon, Jun 27, 2011 at 3:59 PM, Camilo Polymeris cpolyme...@gmail.com
wrote:
Given that there are no objections I have studied the traits docs
without finding any reason against it, I'll start migration of the
Hi all,
Reading a thread on qgis-users from yesterday (Sextante library), I
discovered the existence of a Python library called Traits :
http://code.enthought.com/projects/traits/
I read
http://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.html
and came
On Tue, 21 Jun 2011 12:19:18 +0200, Julien Malik julien.ma...@c-s.fr
wrote:
I read
http://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.html
and came out with a Are we reinventing the wheel ? feeling.
I don't know at what point it can be customized, if it
It seems that PyQT is probably just new. Hence, we have not heard about this,
Currently, the supported GUI toolkits are wxPython and PyQt. While
both toolkits funtion with Traits, integration with wxPython is
currently more complete. All future development, however, will focus
on supporting PyQt.
On Tue, Jun 21, 2011 at 7:28 AM, Noli Sicad nsi...@gmail.com wrote:
It seems that PyQT is probably just new. Hence, we have not heard about this,
Currently, the supported GUI toolkits are wxPython and PyQt. While
both toolkits funtion with Traits, integration with wxPython is
currently more
One point somewhere in this thread was about having (in the future) the
framework in core, implemented in C++, with a Python binding on top of it.
This would go against it, but I'm not sure now whether the C++ side is a
must-have or not.
All the tools listed for possible inclusion in this
On Tue, Jun 21, 2011 at 9:31 AM, Julien Malik julien.ma...@c-s.fr wrote:
One point somewhere in this thread was about having (in the future) the
framework in core, implemented in C++, with a Python binding on top of it.
This would go against it, but I'm not sure now whether the C++ side is a
Hi !
Yes, you are correct, the processing.Plugin class does nothing -- does
no harm either, but agree on removing it.
If it does nothing, then it does harm that I'm obliged to inherit from it ;)
Also remove the arguments from the processing. Module constructor, and
have e.g. saga.Module
Il 14/06/2011 12:22, Julien Malik ha scritto:
Also remove the arguments from the processing. Module constructor, and
have e.g. saga.Module override paramters(), name(), tags(), etc, so
that the relevant code only gets executed when necessary.
Each plugin would then be responsible for
Il 13/06/2011 02:03, Camilo Polymeris ha scritto:
Or should perhaps everything gui-related be
moved into the plugin?
Did this. It is probably cleaner to keep gui code out of the framework.
Sounds reasonable to me.
Thanks.
--
Paolo Cavallini: http://www.faunalia.it/pc
Hello,
Here are some remarks :
- It's good to have deleted the Library class. I had no use of it.
This makes the code much more simpler.
- Is the Plugin class really necessary ? It does nothing now. Maybe
it's better to remove it also, so each plugin can do what he wants
during the
On Mon, Jun 13, 2011 at 10:15 AM, MALIK Julien julien.ma...@c-s.fr wrote:
Hello,
Hello, Julien.
You bring up some very important points.
Here are some remarks :
- It's good to have deleted the Library class. I had no use of it. This
makes the code much more simpler.
- Is the Plugin class
- Even though its clear that the main objective is to have this framework
well integrated in Qgis, it would be nice if it could be accessed without
running Qgis, at least for the back end part. Being able to access it
through a standard Python shell would be very usefull. I think it converges
Il giorno gio, 28/04/2011 alle 17.56 +0200, Martin Dobias ha scritto:
on WPS. In my vision WPS should be simply another provider of
processing modules next to SAGA, OTB or various other smaller plugins.
WPS itself simply cannot deliver the rich user interface that we would
like to provide.
Il giorno ven, 29/04/2011 alle 10.45 +0200, Soeren Gebbert ha scritto:
IMHO installing a WPS server with different back-ends is no magic. The
web server, the WPS server and the back-ends can be bundled and
installed as easy as QGIS with all its plugins and libraries and third
party
Hi Martin !
The point is actually not to provide every possible parameter type in
the framework. IMO we should have a base parameter type with several
common types such as integer, string, vector layer, enumeration. Such
types are used widely and QGIS would come with default edit widgets
for
Il giorno ven, 29/04/2011 alle 12.43 +0200, Julien Malik ha scritto:
Anyway, I agree with the fact that there shall be a lot of ideas to get
inspiration from, so that :
- WPS services can be integrated in the Qgis framework out of the box
- Any Qgis processing modules can be wrapped in a
Hi Soeren
thanks for your further input.
On Fri, Apr 29, 2011 at 10:45 AM, Soeren Gebbert
soerengebb...@googlemail.com wrote:
- WPS servers are IMHO not really widespread yet(?). Surely you can
install your own on a local computer but I don't think that an average
user is able to manage it
On Fri, Apr 29, 2011 at 12:31 PM, Julien Malik julien.ma...@c-s.fr wrote:
Then, each library might require some additional parameter types that
might also require special editing widgets. The plugin implementing
support for such library will provide these types and editing widgets,
however
On Fri, Apr 29, 2011 at 7:31 AM, Julien Malik julien.ma...@c-s.fr wrote:
Hi Martin !
The point is actually not to provide every possible parameter type in
the framework. IMO we should have a base parameter type with several
common types such as integer, string, vector layer, enumeration. Such
Il giorno gio, 28/04/2011 alle 00.11 +0200, MALIK Julien ha scritto:
If I understand Paolo's point right, there would be also a config
toggle, where the end user can configure which parameters he wants
standard, and which he wants advanced.
Sorry I was unclear: I meant to have a general
Looks very good, and in principle similar to what I was doing (or
trying to do) with SAGA, see github repo. But, from what I can tell,
is very OTB-specific. I am not sure how we can integrate this into a
common framework.
We will find a way...
I feel in general QGIS should handle the GUI
Well, you're not alone :)
Paolo is right!
Yes, I have noted there is a great deal of interest in this project!
Thanks for all the support,
Camilo
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
Hi Camilo
On Tue, Apr 26, 2011 at 9:46 PM, Camilo Polymeris cpolyme...@gmail.com wrote:
Hello everyone,
I was accepted as a student in GSoC to implement a SAGA interface for QGIS.
First of all congratulations to you and to other accepted students for
the Summer of Code programme!
There are
Il giorno mer, 27/04/2011 alle 11.20 +0200, Martin Dobias ha scritto:
into C++ and add Python bindings. The idea is not to waste time with
writing and rewriting various c++ classes when the API is not clear
yet. Consider this as a suggestion, not a command how to do it :-)
Agreed; it will
Hello,
I'm currently publishing what we have (the specs we made and the code of
our new framework), so that we can see what can be merged and how.
More extensive inputs and reaction to current ideas this afternoon...
Julien
Le 27/04/2011 11:30, Paolo Cavallini a écrit :
Il giorno mer,
Thanks, Martin, for your well-thought-out response!
https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework
Would that more or less fit what you have in mind? Please comment/criticize.
The discussion was not going into implementation details, we were
mostly collecting the ideas how
Hi Camilo, Hi all,
First of all congratulation for your GSoC project !
Some apologies for the delay in my response, we are approaching the next
OTB release so I'm busy on fixing little stuff/builds here and there.
Please don't expect real time answers in the next week or two.
But it's nice
Il giorno mer, 27/04/2011 alle 12.00 -0400, Camilo Polymeris ha
scritto:
Good point. SAGA, as far as I know, does not provide information on
which parameters are considered basic and which are advanced. Perhaps
a list of parameters considered advanced can be included with the
plugin. Not very
Le mercredi 27 avril 2011 à 20:46 +0200, Paolo Cavallini a écrit :
Il giorno mer, 27/04/2011 alle 12.00 -0400, Camilo Polymeris ha
scritto:
Good point. SAGA, as far as I know, does not provide information on
which parameters are considered basic and which are advanced. Perhaps
a list of
On Wed, Apr 27, 2011 at 4:58 PM, Mayeul Kauffmann
mayeul.kauffm...@free.fr wrote:
Le mercredi 27 avril 2011 à 20:46 +0200, Paolo Cavallini a écrit :
Il giorno mer, 27/04/2011 alle 12.00 -0400, Camilo Polymeris ha
scritto:
Good point. SAGA, as far as I know, does not provide information on
W dniu 27.04.2011 23:25, Paolo Cavallini pisze:
Il giorno mer, 27/04/2011 alle 17.15 -0400, Camilo Polymeris ha
scritto:
Wow. This is getting more and more ambitious. Will have to see what
fits in only 1 summer :)
Well, you're not alone :)
Paolo is right!
After such great discussion your
Hi
On Tue, Apr 26, 2011 at 9:46 PM, Camilo Polymeris cpolyme...@gmail.com wrote:
Hello everyone,
I was accepted as a student in GSoC to implement a SAGA interface for QGIS.
There are also proyects that try to interface QGIS with GRASS and the
Orfeo Toolbox (OTB). Paolo has informed me that
47 matches
Mail list logo
