This reverts commit 6da71b6788.
This was causing just too many problems for one. The ones I noticed
were:
- Messing up the table view when scrolling down very large table where
the prefetching code is triggered.
- Crashing when setting an auto increment PK in the Edit Table dialog
because the sqlitetablemodel is used for a check in there.
- Probably more crashed in other places but for the same reason.
- Easy to fix but an issue nonetheless: when doing plotting a number of
empty rows would be inserted into the data browser.
- It just feels a little laggy.
This moves the data fetching code into a separate thread for
asynchronous execution. The Browse Data and the Execute SQL tabs are
affected by this.
Note that this is a somewhat naive implementation that is meant for some
first testing.
This adds a new dock to the main window that contains all the remote
functionality (or is supposed to contain it all in the future).
It also adds a directory browsing feature which allows you to browse
through the folders and files on the dbhub server.
By double clicking a database you can download and open it. The Open
Remote menu action isn't needed anymore and has been removed.
This also fixes an issue with pushing databases where, after sending the
file is completed, the save dialog was opened.
Note that this is still WIP and is far from polished.
This adds two new options to the cmake script which, when set, force
cmake to use the version of the Antlr or QScintilla library in our
repository and not search for a system-wide version of the library.
See issue #961.
Just like the Edit Table dialog, this dialog handles both creating and
editing. For consistency's sake this dialog is therefore renamed to Edit
Index dialog.
This cleans up the main window class a bit which was getting quite large
and a bit harder to maintain than necessary.
This commit also includes two minor fixes to the plot system:
- The plot widgets are now disabled when no database file is opened.
- The progress bar shown when fetching all data is now initialised with
the correct row numbers.
Other than that this commit should in theory not change any
functionality.
This adds basic support for fetching databases via HTTPS using client
certificates. You can include CA certificates to verify any responses
from a server. For now, one test CA certificate is included but it's
easy to add more.
It's also possible to authentify the client using a client certificate,
a client key and a password. As of this commit all three items are
hardcoded.
It's still possible to access any remote database via HTTP but if a
request URL starts with 'https' this new mechanism will be used.
All certificates, keys, and password included in here are taken from my
node.js test server repository. They will be replaced soon-ish.
This adds some initial support for opening remote files. You can enter a
URL and DB4S will try to download the file. When successful you'll be
able to specify a place and name to save the file under, and after
saving it locally to disk it'll be opened just like any local database
file.
See the included TODO comments for missing features. Most notably
missing is the HTTPS and certificate handling code. Also any support
for storing the remote source of a database is lacking.
This should update the master branch to use "DB Browser
for SQLite" naming, and fix the problem with the
uninstaller not showing up in Add/Remove programs on
Windows (issue #742)
See issue #621 for details.
I built a new installation package and during installation on Windows 7
I could see that the previously unquoted path is now quoted.
When changing a filter value delay the application of the new value on
the table for a couple of milliseconds. This makes the filter process
much smoother for fast typing users working on large tables.
See issue #415.
This is a proof-of-concept or even a basic first implementation of a new
feature I'd like to have in DB4S which at the moment I call display
formats.
The idea here is to allow the user to change the data in the Browse Data
tab on a per column basis before displaying it. This means even though
the data is stored in format X in the database it can be shown in format
Y in the browser. This should be useful in cases where the original
format X is hard to read or just not useful in a particular case.
This first implementation allows the user to right click on the header
of a column and open a new dialog for setting the display format which
offers a (limited) list of pre-defined formats. The selected format is
then integrated into the SELECT statement which is sent to SQLite.
While it works, this draft implementation lacks a number of features.
Here are the most prominent ones I'm currently aware of:
* Data not editable (or only via the Edit Dialog) because it isn't
transformed back yet.
* More display formats needed; maybe customizable ones, too.
* No indication in the UI for which columns a format has been set.
* Could _maybe_ be integrated into the import/export etc. for optional
use.
Martin Kleusberg