Changes introduced starting since version 2.0.0 (August 2016)

1 - Importing and exporting Shapefiles and DBF files

The default behavior of libspatialite's C API implementing the import and export of Shapefiles and DBF files has recently changed (please see: C API SHP and DBF changes).
As a direct consequence all GUI wizards supporting SHP and DBF files will now adopt the default rules adopted by libspatialite itself:

when importing a SHP or DBF file all DB column names will be automatically converted to full lowercase.
when exporting all column names within the DBF file will be left unchanged as they are defined into the corresponding DB Table.

The GUI wizards respectively implementing SHP and DBF import supports a more flexible range of options which you are free to choose between:

converting column names to full lowercase (the default setting).
converting column names to full uppercase.
never changing the column names (corresponding to the old behavior implemented by all previous versions).

For exporting, no similar option is offered by the GUI wizards, using never changing !!
If a more finely controlled DBF column name rule is needed (such as full uppercase or full lowercase) you must use the appropriate SQL functions: ExportSHP() and ExportDBF().

Note: there is a further interesting side effect of this recent update: Layer Statistics can be updated when using the Import Shapefile wizard.

2 - Importing EXIF-GPS geotagged images

From many years spatialite_gui has a GUI wizard allowing the importation of a whole folder of JPEG/EXIF digital images, automatically extracting all of the EXIF metadata and saving them into a set of correlated DB Tables.
In recent years smartphones, incorporating both a digital camera and a GPS sensor, have become universally widespread commodities. For this reason a further GUI wizard has been added, and it's specifically intended to create and populate a DB Table containing geotagged EXIF-GEOTAG digital images.

To clarify the difference between the two wizards:

the classic EXIF tool is intended to collect all EXIF metadata, including the specific photographic tags such as: shutter speed, focal length, lens aperture, ISO sensitivity etc.
All EXIF tags and the image pixelmap are stored into a set of correlated DB Tables in a substantially raw form, to allow the user apply any further post-processing as needed.
It's more flexible and powerful since no assumptions as to the final use are being made.
The new EXIF-GPS tool is intended only as a simple, user friendly, import of geotagged images; but unsophisticated and not well suited for any advanced post-processing task.

Quick how-to guide about the new EXIF-GPS import tool:

step #1 You can start the new EXIF-GPS Import wizard by clicking the ToolBar's button shown by the side figure. Alternatively you can start it from the Files / Advanced menu.
step #2 After selecting some JPEG file the dialog box shown on the side will appear. You simply have to complete the dialog's fields then confirming: Which files to select: the selected file only. all files in the folder. Only valid Exif-GEOTAGed images will be selected. Table and column-names to import to A new TABLE will be created if it does not exist With Spatial Index If the TABLE does not exist With Update Layer Statistics After importing the found images
step #3 any DB Table created by the Import EXIF-GPS wizard will always have the following columns: id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, unique identifier name TEXT NOT NULL, name of the imported image. height INTEGER NOT NULL width INTEGER NOT NULL, dimensions (measured in pixels) of the image. photo BLOB NOT NULL, the JPEG/EXIF-GEOTAG image itself. timestamp TEXT, date and time from the geotags. geometry POINT, location (SRID=4326, WGS 84) from the GPS tags. The Import wizard will only append new images into an existing DB Table that corresponds to the above layout. Should the given Table be found with a different layout, a failure message will be given.
step #5 as you can directly check by using the BlobExplorer tool each imported image will still preserve its original EXIF-GEOTAGs.

3 - Edit Table now supporting user defined SQL filters

All previous versions of spatialite_gui traditionally supported the so called Edit Table mode, i.e. the capability to implicitly execute INSERT, UPDATE and DELETE statements when the users directly changes some cell into the grid GUI widget used in order to display the resultset queried from some DB Table.

Note: not all gridded resultsets can support Edit Table.
Such an advanced capability can be enabled only when the gridded resultset directly corresponds to a single Table and each cell of the grid can be safely identified by well known Primary Key (or ROWID) and Column name.
A generic SQL query (may well be one hand-composed by the user) can never ensure such very strict requirements, and consequently cannot safely support Edit Table and will be always considered to be read-only.
In other words: only a query internally generated by spatialite_gui itself after evaluating the specific layout declared by some DB Table can support Edit Table.
So the standard behavior of Table Edit is to always start by executing an SQL query of the following form:

SELECT ROWID,"column_1", "column_2", ... "column_N"
FROM "my_table"
ORDER BY ROWID;

Experience shows that such an approach doesn't work well under most conditions; it's too inflexible to be really usable, most notably on datasets containing many rows.
Let's see how the recently introduced SQL filters can effectively help to support a flexible and more usable Edit tool.

step #1 We'll start as usual by activating the Edit Table tool from the context menu corresponding to some DB Table.
step #2 We can now apply some appropriate filters so to conveniently arrange the gridded resultset as we wish better. You just have to click the button shown on the side figure.
step #3 The SQL filters wizard will appear, allowing you to freely set the most appropriate settings to be applied in order to restrict the resultset. Notice that the (read-only) SQL statement's WHERE clause, displayed on the top of the wizard, will be dynamically updated to reflect your actions.
step #4 You can eventually order the resultset as you wish better. In this case the SQL statement's ORDER BY clause, displayed by the wizard, will be dynamically updated.
step #5 Once you apply the SQL filters a new gridded resultset will be returned, which will be editable. You can change the current filters, when required, by just re-calling the wizard and modifying its settings. Removing all filters is equally simple: just call the wizard and then disable all options.
step #6.a An even more advanced feature is available for advanced users possessing at least some basic SQL competency. You can eventually hand-write your own WHERE and / or ORDER BY clauses as you wish. In this case the full SELECT statement, displayed on the wizard upper widget, will be dynamically updated to reflect what you are typing. Note: you are expected to just add WHERE and /or ORDER BY clauses; any attempt to define other SQL clauses such as JOIN, GROUP BY, UNION etc will surely lead to a malfunctioning query with possibly unpredictable results.
step #6.b When using free-hand WHERE and / or ORDER BY clauses the wizard will never attempt to check, in any way, if the resulting SELECT statement is syntactically valid or not. Since the wizard only pastes the automatically generated, specific fields of one table together with the free-hand supplied WHERE / ORDER BY, it is your responsibility to insure the validity of the SQL clause. If the resulting SELECT is malformed the final result will be some SQL error, as in this example.
step #7 Edit mode now also supports Writable Views Recall: all Views are always considered to be *read-only* by SQLite, except when an adequate set of Triggers is defined. Such Triggers must properly dispatch all INSERT, UPDATE and DELETE operations to the underlying real Table referenced by the View, for which a reliable validity/sanity check is not possible. SpatiaLite requires that any Writable View must be always properly registered into the views_geometry_columns meta-table by declaring read_only=0.