Re: [Qgis-user] Re: [Qgis-developer] JOIN error
Thanks for the double check, I open a ticket. Could Vector/Data Management Tools/Join Attributes be made available again? Agus 2011/12/19 Ramon Andiñach cust...@westnet.com.au: On 19/12/2011, at 6:57, Ramon Andiñach cust...@westnet.com.au wrote: On 19/12/2011, at 03:15 , Agustin Lobo wrote: I use Properties/JOINS to join a dbf table to a vector layer (fields ISO and ISO3 respectively). The Join works, but I get the following error when I try to save the vector layer as a new shapefile: Export to vector file failed. Error: Feature write errors: Invalid variant type for field X[11]: received void with type Invalid variant type for field X[11]: received void with type (many times repeated) Only 24 of 246 features written. The new layer is actually written (despite claiming Export to vector failed) but only those countries with data in the dbf are available Instead, the old Vector/Data Management Tools/Join Attributes works fine. I suggest having that part of the Vector plugin back, even if redundant, until we reach operational equivalence. I provide the layer and dbf: https://sites.google.com/site/filestemp2/home/wrld_simpl.zip https://sites.google.com/site/filestemp2/home/owlslive.dbf I'm using 1.7.3 from ubuntigis-unstable binaries for ubuntu 10.04 I can confirm this. I also tried removing the X column from the dbf file, but the error moved to the next field with nulls (GMI_CNTRY), which was a string. I'm a little puzzled why a null value would be a problem if the file did save successfully. fwiw, this also fails if you reprocess the owl data as csv (with a csvt). And confirmed with some internal datasets. (that said, I can understand why you would want to save the joined file, but generally I use this as an intermediate step.) -ramon.___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Built-in attribute form validation
Hi all,
I have been working on this idea over the last couple days which I think
would be cool/handy to have in QGIS and I would be interested to get some
feedback with what people think.
The general idea is to add a form of field validation to the built-in
attribute forms. The use case for this is pretty clear I think, being able
to let the user/admin of any layer define validation rules to check against
the data entered on the attribute form when the user presses OK providing
instant feedback. I normally do this on my PostGIS tables but you don't
get errors until you try and commit the data and even then it's a simple
there is a error, if you have added more then 1 item you have to check
each one to work out what is wrong, and this method only applies to a
PostGIS layer. The idea I have been drafting would work on any layer, as
it's at the QGIS level vs at the datasource level.
My idea is to use simple a simple Python file with basic functions that
will be called for each field in the attribute form that is editable. I'm
a big fan of convention over configuration so my idea uses conventions to
define what functions are used to validate what fields. The function will
return False and an error message that can be shown to the user if
something is wrong.
The functions use the following syntax: validate{FieldName} or
validate{FieldIndex} for naming (plus some other styles) e.g
def validateName():
if value == :
return (False,Name can't be NULL)
return True
You would place the function in a python file e.g PeopleRules.py and then
tell QGIS to use this file to look for validation rules, pretty much the
same as we do now for having custom Python forms.
Overview of logic:
1. Define Python file with rules
2. Tell QGIS to use the rules file for the layer.
3. Open attribute form
4. Edit some values
5. Press OK
6. QGIS calls each function in the rules file to validate each field
that is defined with a rule
7. If there are errors: cancel the accept() action and show the errors.
If there are no errors go though like normal.
My thoughts for using Python are:
- Easy to read and write
- Not limited to what we have in QgsExpression and easier to expand.
- Can add documentation to validation rules.
- Can add more complex validation rules e.g. regex, parsing, database
checks etc
My overall goal with this is to reduce the need to create custom Python Qt
forms when doing data entry, and doing validation is one of the reasons I
tend to make custom Python Qt forms but then you loose the ease of QGIS
doing most of the form work for you.
I have attached two files which have a example of what the idea is.
fieldChecks.py is an example rules file with comments to explain each
section, runMe.py has the logic for reading and executing the rules for
each field. Run: python runMe.py to see the running logic and output.
What love to get peoples thoughts about this, users and devs a like.
- Nathan
#!/usr/bin/env python
''' Validation rules are listed here and called from the qgis.validation module as needed.
Each rule follows a convention based naming style in order to picked up as a validation
rule.
Syntax is validate{FieldName} or validate{ID} the validation module will auto resolve the
mehtod from the field name or index
You can also have a different name to the field being validated and use a doc string
to tell qgis.validation what field it validates. Add Validate:{Name} or Validate:{ID}
to the __doc__ string, see validatePersonIsNotBruce() as example
'''
def validateY():
if value attributes[x]:
return True
return (False,Y must be greater then X)
def validateName():
''' This method will be called when the name field is needed to be validated
Function naming convention is validate{FieldName} or validate{FieldNo}
'''
if not value == :
return True
return (False,Name must not be null)
def validate1():
''' This method will be called when the field no 1 is needed to be validated
'''
if value == Hello World:
return True
return False
def validatePersonIsNotBruce():
'''
Validate:Person
The Validate:{FieldName or ID} can be used to name the function different
to what is getting validated.
Function name must still start with validate
'''
if value == Bruce:
return (False,Person must not be 'Bruce')
return True
#!/usr/bin/env python
import re
class QgsAttributeDialog:
def accept(self):
first = {FirstField:Hello,
Name:Joe,
Y:1234,
x:12,
'Person':'Bruce'
}
second = {FirstField:,
Name:,
Y:122134,
x:12132151232,
'Person':'Joe'
}
third = {FirstField:,
Name:Bill,
Y:122134,
Re: [Qgis-developer] Built-in attribute form validation
Nathan,
I do like your idea, it in fact would reduce the need for custom Uis.
How about saving the check as part of the project or qml file similar to
the edit-widget option in the layer properties. Because for my feeling
that would be the place where it belongs and I cannot be sure that
anyone loading my qml file has the python file available in the same
path as I do.
Probably there is only a limited number of checks which cover the
majority of use cases e.g.
- NOT NULL
- range (for Numbers)
- range (for dates)
- max length (for strings)
- contains regex/string (for strings)
Multiple rules could be applied to any field in the fields tab of the
layer properties. For special cases you would still need a custom Ui,
though.
just my two cents
Bernhard
Am 20.12.2011 12:41, schrieb Nathan Woodrow:
Hi all,
I have been working on this idea over the last couple days which I think
would be cool/handy to have in QGIS and I would be interested to get some
feedback with what people think.
The general idea is to add a form of field validation to the built-in
attribute forms. The use case for this is pretty clear I think, being able
to let the user/admin of any layer define validation rules to check against
the data entered on the attribute form when the user presses OK providing
instant feedback. I normally do this on my PostGIS tables but you don't
get errors until you try and commit the data and even then it's a simple
there is a error, if you have added more then 1 item you have to check
each one to work out what is wrong, and this method only applies to a
PostGIS layer. The idea I have been drafting would work on any layer, as
it's at the QGIS level vs at the datasource level.
My idea is to use simple a simple Python file with basic functions that
will be called for each field in the attribute form that is editable. I'm
a big fan of convention over configuration so my idea uses conventions to
define what functions are used to validate what fields. The function will
return False and an error message that can be shown to the user if
something is wrong.
The functions use the following syntax: validate{FieldName} or
validate{FieldIndex} for naming (plus some other styles) e.g
def validateName():
if value == :
return (False,Name can't be NULL)
return True
You would place the function in a python file e.g PeopleRules.py and then
tell QGIS to use this file to look for validation rules, pretty much the
same as we do now for having custom Python forms.
Overview of logic:
1. Define Python file with rules
2. Tell QGIS to use the rules file for the layer.
3. Open attribute form
4. Edit some values
5. Press OK
6. QGIS calls each function in the rules file to validate each field
that is defined with a rule
7. If there are errors: cancel the accept() action and show the errors.
If there are no errors go though like normal.
My thoughts for using Python are:
- Easy to read and write
- Not limited to what we have in QgsExpression and easier to expand.
- Can add documentation to validation rules.
- Can add more complex validation rules e.g. regex, parsing, database
checks etc
My overall goal with this is to reduce the need to create custom Python Qt
forms when doing data entry, and doing validation is one of the reasons I
tend to make custom Python Qt forms but then you loose the ease of QGIS
doing most of the form work for you.
I have attached two files which have a example of what the idea is.
fieldChecks.py is an example rules file with comments to explain each
section, runMe.py has the logic for reading and executing the rules for
each field. Run: python runMe.py to see the running logic and output.
What love to get peoples thoughts about this, users and devs a like.
- Nathan
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Built-in attribute form validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I normally do this on my PostGIS tables but you don't get errors until you try and commit the data and even then it's a simple there is a error, if you have added more then 1 item you have to check each one to work out what is wrong Yes, you are right. I do not know how others deal with this. I saw many times that editor had to rather drop all updated/created features rather than checking for error. My idea is to use simple a simple Python file with basic functions that will be called for each field in the attribute form that is editable. + 1 from me. - -- Ivan Mincik, Gista s.r.o. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk7wfZIACgkQVqso/9cUsCyCFQCgpnuDO3hJlLSfVchQls6Wi4qf FJ4AoJ3QECnJ9UIqfu7l5q7YRQ2M0j0o =ug55 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Built-in attribute form validation
Maybe it would be good to have a merge of the two ideas. Have a set of
pre-built rules (non-python) that you can supply in the fields tab with the
ability to also supply a Python file which has more complex rules e.g
if field1 == Hello WOrld and field2 field3 then error
etc
Thoughts?
P.S
I cannot be sure that anyone loading my qml file has the python file
available in the same path as I do
Normally I would store the python file in the same folder as the project
file and ship it with the project but I get what you mean.
- Nathan
On Tue, Dec 20, 2011 at 10:10 PM, bernhard.stro...@jena.de wrote:
Nathan,
I do like your idea, it in fact would reduce the need for custom Uis. How
about saving the check as part of the project or qml file similar to the
edit-widget option in the layer properties. Because for my feeling that
would be the place where it belongs and I cannot be sure that anyone
loading my qml file has the python file available in the same path as I do.
Probably there is only a limited number of checks which cover the majority
of use cases e.g.
- NOT NULL
- range (for Numbers)
- range (for dates)
- max length (for strings)
- contains regex/string (for strings)
Multiple rules could be applied to any field in the fields tab of the
layer properties. For special cases you would still need a custom Ui,
though.
just my two cents
Bernhard
Am 20.12.2011 12:41, schrieb Nathan Woodrow:
Hi all,
I have been working on this idea over the last couple days which I think
would be cool/handy to have in QGIS and I would be interested to get some
feedback with what people think.
The general idea is to add a form of field validation to the built-in
attribute forms. The use case for this is pretty clear I think, being
able
to let the user/admin of any layer define validation rules to check
against
the data entered on the attribute form when the user presses OK providing
instant feedback. I normally do this on my PostGIS tables but you don't
get errors until you try and commit the data and even then it's a simple
there is a error, if you have added more then 1 item you have to check
each one to work out what is wrong, and this method only applies to a
PostGIS layer. The idea I have been drafting would work on any layer, as
it's at the QGIS level vs at the datasource level.
My idea is to use simple a simple Python file with basic functions that
will be called for each field in the attribute form that is editable. I'm
a big fan of convention over configuration so my idea uses conventions to
define what functions are used to validate what fields. The function will
return False and an error message that can be shown to the user if
something is wrong.
The functions use the following syntax: validate{FieldName} or
validate{FieldIndex} for naming (plus some other styles) e.g
def validateName():
if value == :
return (False,Name can't be NULL)
return True
You would place the function in a python file e.g PeopleRules.py and then
tell QGIS to use this file to look for validation rules, pretty much the
same as we do now for having custom Python forms.
Overview of logic:
1. Define Python file with rules
2. Tell QGIS to use the rules file for the layer.
3. Open attribute form
4. Edit some values
5. Press OK
6. QGIS calls each function in the rules file to validate each field
that is defined with a rule
7. If there are errors: cancel the accept() action and show the errors.
If there are no errors go though like normal.
My thoughts for using Python are:
- Easy to read and write
- Not limited to what we have in QgsExpression and easier to expand.
- Can add documentation to validation rules.
- Can add more complex validation rules e.g. regex, parsing, database
checks etc
My overall goal with this is to reduce the need to create custom Python Qt
forms when doing data entry, and doing validation is one of the reasons I
tend to make custom Python Qt forms but then you loose the ease of QGIS
doing most of the form work for you.
I have attached two files which have a example of what the idea is.
fieldChecks.py is an example rules file with comments to explain each
section, runMe.py has the logic for reading and executing the rules for
each field. Run: python runMe.py to see the running logic and output.
What love to get peoples thoughts about this, users and devs a like.
- Nathan
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
__**_
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://lists.osgeo.org/mailman/listinfo/qgis-developer
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail Server.
Re: [Qgis-developer] Built-in attribute form validation
Hi Nathan, you know that the initUI function is also called for standard forms? So you could add QValidators to the fields and/or connect to their edit signals and attach validation functions. I imagine it should be possible to do have a generic initUI function that does most of what you've described. Just that it wouldn't allow to enter invalid values in the first place instead of complaining about invalid values on OK. Currently it's not possible to intercept accept(). Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 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-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Compile error
Hi I get the following error when I try to compile qgis master on ubuntu 10.04: [ 7%] Built target t2tdoc [ 8%] Built target pluginstaller [ 8%] Built target compile_python_files [ 8%] Built target mapserverexport [ 8%] Built target ftools [ 9%] Built target ftools_tools make[2]: *** Keine Regel vorhanden, um das Target »../python/plugins/GdalTools/icons/raster-paletted.png«, benötigt von »python/plugins/GdalTools/resources_rc.py«, zu erstellen. Schluss. make[1]: *** [python/plugins/GdalTools/CMakeFiles/gdaltools.dir/all] Fehler 2 make[1]: *** Warte auf noch nicht beendete Prozesse... [ 10%] Built target gdaltools_tools make: *** [all] Fehler 2 regards Stefan Freundliche Grüsse Stefan Ziegler Leiter amtliche Vermessung Amt für Geoinformation Amtliche Vermessung Rötistrasse 4 4500 Solothurn Telefon +41 32 627 75 96 Telefax +41 32 627 75 98 stefan.zieg...@bd.so.ch http://www.so.ch ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Built-in attribute form validation
Am 20.12.2011 13:58, schrieb Nathan Woodrow:
Maybe it would be good to have a merge of the two ideas. Have a set of
pre-built rules (non-python) that you can supply in the fields tab with the
ability to also supply a Python file which has more complex rules e.g
if field1 == Hello WOrld and field2 field3 then error
etc
Thoughts?
I was thinking of that, too so the majority of cases is probably covered
by the built-in functions
P.S
I cannot be sure that anyone loading my qml file has the python file
available in the same path as I do
Normally I would store the python file in the same folder as the project
file and ship it with the project but I get what you mean.
that is not feasible because the project file stores the DB user's
username and password. So I advice my users to not exchange project
files but qmls. That is why I think it should be placed in there.
Bernhard
- Nathan
On Tue, Dec 20, 2011 at 10:10 PM,bernhard.stro...@jena.de wrote:
Nathan,
I do like your idea, it in fact would reduce the need for custom Uis. How
about saving the check as part of the project or qml file similar to the
edit-widget option in the layer properties. Because for my feeling that
would be the place where it belongs and I cannot be sure that anyone
loading my qml file has the python file available in the same path as I do.
Probably there is only a limited number of checks which cover the majority
of use cases e.g.
- NOT NULL
- range (for Numbers)
- range (for dates)
- max length (for strings)
- contains regex/string (for strings)
Multiple rules could be applied to any field in the fields tab of the
layer properties. For special cases you would still need a custom Ui,
though.
just my two cents
Bernhard
Am 20.12.2011 12:41, schrieb Nathan Woodrow:
Hi all,
I have been working on this idea over the last couple days which I think
would be cool/handy to have in QGIS and I would be interested to get some
feedback with what people think.
The general idea is to add a form of field validation to the built-in
attribute forms. The use case for this is pretty clear I think, being
able
to let the user/admin of any layer define validation rules to check
against
the data entered on the attribute form when the user presses OK providing
instant feedback. I normally do this on my PostGIS tables but you don't
get errors until you try and commit the data and even then it's a simple
there is a error, if you have added more then 1 item you have to check
each one to work out what is wrong, and this method only applies to a
PostGIS layer. The idea I have been drafting would work on any layer, as
it's at the QGIS level vs at the datasource level.
My idea is to use simple a simple Python file with basic functions that
will be called for each field in the attribute form that is editable. I'm
a big fan of convention over configuration so my idea uses conventions to
define what functions are used to validate what fields. The function will
return False and an error message that can be shown to the user if
something is wrong.
The functions use the following syntax: validate{FieldName} or
validate{FieldIndex} for naming (plus some other styles) e.g
def validateName():
if value == :
return (False,Name can't be NULL)
return True
You would place the function in a python file e.g PeopleRules.py and then
tell QGIS to use this file to look for validation rules, pretty much the
same as we do now for having custom Python forms.
Overview of logic:
1. Define Python file with rules
2. Tell QGIS to use the rules file for the layer.
3. Open attribute form
4. Edit some values
5. Press OK
6. QGIS calls each function in the rules file to validate each field
that is defined with a rule
7. If there are errors: cancel the accept() action and show the errors.
If there are no errors go though like normal.
My thoughts for using Python are:
- Easy to read and write
- Not limited to what we have in QgsExpression and easier to expand.
- Can add documentation to validation rules.
- Can add more complex validation rules e.g. regex, parsing, database
checks etc
My overall goal with this is to reduce the need to create custom Python Qt
forms when doing data entry, and doing validation is one of the reasons I
tend to make custom Python Qt forms but then you loose the ease of QGIS
doing most of the form work for you.
I have attached two files which have a example of what the idea is.
fieldChecks.py is an example rules file with comments to explain each
section, runMe.py has the logic for reading and executing the rules for
each field. Run: python runMe.py to see the running logic and output.
What love to get peoples thoughts about this, users and devs a like.
- Nathan
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
__**_
Re: [Qgis-developer] Compile error
Hi Stefan, 2011/12/20 Ziegler Stefan stefan.zieg...@bd.so.ch: I get the following error when I try to compile qgis master on ubuntu 10.04: ... make[2]: *** Keine Regel vorhanden, um das Target »../python/plugins/GdalTools/icons/raster-paletted.png«, benötigt von »python/plugins/GdalTools/resources_rc.py«, zu erstellen. Schluss. make[1]: *** [python/plugins/GdalTools/CMakeFiles/gdaltools.dir/all] Fehler 2 that file was removed in 94fb18be and the resources.qrc was updated according to that change. You have to run ccmake .. from the build folder before running make again. Regards. make[1]: *** Warte auf noch nicht beendete Prozesse... [ 10%] Built target gdaltools_tools make: *** [all] Fehler 2 regards Stefan Freundliche Grüsse Stefan Ziegler Leiter amtliche Vermessung Amt für Geoinformation Amtliche Vermessung Rötistrasse 4 4500 Solothurn Telefon +41 32 627 75 96 Telefax +41 32 627 75 98 stefan.zieg...@bd.so.ch http://www.so.ch ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
AW: [Qgis-developer] Compile error
Hi Giuseppe Thanks! Regards Stefan -Ursprüngliche Nachricht- Von: brush.ty...@gmail.com [mailto:brush.ty...@gmail.com] Im Auftrag von Giuseppe Sucameli Gesendet: Dienstag, 20. Dezember 2011 15:51 An: Ziegler Stefan Cc: qgis-developer@lists.osgeo.org Betreff: Re: [Qgis-developer] Compile error Hi Stefan, 2011/12/20 Ziegler Stefan stefan.zieg...@bd.so.ch: I get the following error when I try to compile qgis master on ubuntu 10.04: ... make[2]: *** Keine Regel vorhanden, um das Target »../python/plugins/GdalTools/icons/raster-paletted.png«, benötigt von »python/plugins/GdalTools/resources_rc.py«, zu erstellen. Schluss. make[1]: *** [python/plugins/GdalTools/CMakeFiles/gdaltools.dir/all] Fehler 2 that file was removed in 94fb18be and the resources.qrc was updated according to that change. You have to run ccmake .. from the build folder before running make again. Regards. make[1]: *** Warte auf noch nicht beendete Prozesse... [ 10%] Built target gdaltools_tools make: *** [all] Fehler 2 regards Stefan Freundliche Grüsse Stefan Ziegler Leiter amtliche Vermessung Amt für Geoinformation Amtliche Vermessung Rötistrasse 4 4500 Solothurn Telefon +41 32 627 75 96 Telefax +41 32 627 75 98 stefan.zieg...@bd.so.ch http://www.so.ch ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugin reorganization (again)
Hi all, finally I push all changes to master. This include: - new methods to add/remove plugins from Raster menu addPluginToRasterMenu(QString, QAction) removePluginRasterMenu(QString, QAction) - new methods to add/remove plugin buttons from Raster toolbar addRasterToolBarIcon(QAction) removeRasterToolBarIcon(QAction) - new Vector menu and toolbar - new methods to add/remove plugins from Vector menu addPluginToVectorMenu(QString, QAction) removePluginVectorMenu(QString, QAction) - new methods to add/remove plugin buttons from Vector toolbar addVectorToolBarIcon(QAction) removeVectorToolBarIcon(QAction) - new Database toolbar - new methods to add/remove plugin buttons from Database toolbar addDatabaseToolBarIcon(QAction) removeDatabaseToolBarIcon(QAction) - core plugins reorganized and moved under appropriate menus/toolbars. There are some issues with plugins that match to several categories, e.g. Zonal Statistics plugin. Also some plugins still remain in Plugins menu. - introduced new plugin metadata entry category. This entry currently used only in informational purposes to inform user where he should look for plugin. Placing plugin under appropriate menu remains developer task and can be done with new methods described above. If no category specified Python plugin will get default one - Plugins. Also updated QgsPlugin class to handle this new metadata, so C++ plugins must be updated and recompiled (looks like an API break) - updated Plugin Manager to display hint based on category metadata Hope, I didn't break anything. -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugin reorganization (again)
Super!, Just a minor thing, all the remove methods are called removeXXX but the add methods are AddToXXX wouldn't it be more consistent to have either AddXXX or RemoveFromXXX? Ciao and thanks a lot On Dec 20, 2011 6:55 PM, Alexander Bruy alexander.b...@gmail.com wrote: Hi all, finally I push all changes to master. This include: - new methods to add/remove plugins from Raster menu addPluginToRasterMenu(QString, QAction) removePluginRasterMenu(QString, QAction) - new methods to add/remove plugin buttons from Raster toolbar addRasterToolBarIcon(QAction) removeRasterToolBarIcon(QAction) - new Vector menu and toolbar - new methods to add/remove plugins from Vector menu addPluginToVectorMenu(QString, QAction) removePluginVectorMenu(QString, QAction) - new methods to add/remove plugin buttons from Vector toolbar addVectorToolBarIcon(QAction) removeVectorToolBarIcon(QAction) - new Database toolbar - new methods to add/remove plugin buttons from Database toolbar addDatabaseToolBarIcon(QAction) removeDatabaseToolBarIcon(QAction) - core plugins reorganized and moved under appropriate menus/toolbars. There are some issues with plugins that match to several categories, e.g. Zonal Statistics plugin. Also some plugins still remain in Plugins menu. - introduced new plugin metadata entry category. This entry currently used only in informational purposes to inform user where he should look for plugin. Placing plugin under appropriate menu remains developer task and can be done with new methods described above. If no category specified Python plugin will get default one - Plugins. Also updated QgsPlugin class to handle this new metadata, so C++ plugins must be updated and recompiled (looks like an API break) - updated Plugin Manager to display hint based on category metadata Hope, I didn't break anything. -- Alexander Bruy ___ 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] Plugin reorganization (again)
2011/12/20 Alexander Bruy alexander.b...@gmail.com: Hi all, finally I push all changes to master. This include: - new methods to add/remove plugins from Raster menu addPluginToRasterMenu(QString, QAction) [...] I'm not sure I got it right, does this metadata also apply to python plugins ? If not, please ignore this message, if yes I guess I should update the web python plugin app to take category metadata into account. A few questions arise in this case: 1 - are there any plan for making any use of the plugin tags metadata as was planned in Lisbon ? 2 - the new optional category metadata can be any value or the choice will be a limited set (vector databases etc.) 3 - do you think that the category will ever be a tree data structure or it will always be a flat list ? Thanks -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
