This commit removes the File -> Remote menu entirely. The only menu item
that was left was the Save to Remote item which is replaces by a button
in the remote dock.
The button is only enabled when a database file is opened and the user
has logged in using a certificate.
Clicking the button opens the same dialog and performs the same actions
as before. The only difference is that we don't use the first client
certificate - no matter which one it is - but instead use the client
certificate that was used for logging in.
This adds a new context menu option that allows unlocking views for
updating. This requires appropriate triggers to be in place and the user
to type in a column name that can be used as a 'primary key' for the
view. By default views are still locked from editing.
Inserting into and deleting from views isn't supported yet.
See issue #141.
This adds a local database to keep track of all the cloned databases.
For now we only use this information to prevent exactly the same
database being downloaded twice.
Move the network part of the automatic version check code into the
dbhub.io parts. While semantically this doesn't make a lot of sense it
simplifies the code a bit, reduces the size of the main window class,
and avoids duplication of code e.g. when introducing proxy support.
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.
Improve the Create Index dialog so that it allows creating as well as
editing indices.
Chenge the code for the main window to allow editing existing indices.
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.
Change the layout of the preferences dialog a bit.
Remove the server selection combo box from the preferences dialog as it
will probably never be required. The way we do logins using certificates
kind of makes this obsolete, I think.
Restructure the whole remote code a little bit. Also add helper
functions here and there.
Show a list of our the CA certificates built into the application in the
preferences dialog. This list is read only of course but still
informative as it tells the user which sites are supported ny DB4S.
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.
Store and restore the plot settings for each table - just like the
filter values or the column widths. This way you can have multiple
plots, one for each table.
Also, save these settings in the project files.
Make the reload shortcut (at the moment F5 and Ctrl+R) dependent on the
currently active tab. This way it always performs some meaningful task,
depending on the current context.
See issue #759.
We used to reload the database schema whenever it might have been
changed and the latest version was required. For example: when the user
switches to the Structure tab we need the current schema; so we just
reloaded it to be safe - it might have been changed in the Execute SQL
tab or wherever.
With this commit we don't reload the database schema anymore when an
up-to-date version is needed but instead when it was changed by the
application. So in the example above it's not reloaded at all anymore.
Only if and when the user would execute some structure changing SQL it
would be reloaded.
Benefits:
- Better performance
- State of the structure tree view isn't lost as frequently
- Structure tree view gets updated when changing the structure in the
Execute SQL tab
Downsides:
- Less error proof (testing!)
- No 'automatic' updates when the db is changed by an external
application.
Any suggestions welcome!
This adds some basic functionality for exporting JSON files by extending
the CSV export dialog. There is still a bit of work required for
fine-tuning the JSON export feature though. But a standard export of a
table s working well already.
See issue #688.
This hopefully helps to simplify and restructure the code. If it turns
out to make things only worse we can undo it. This *should* make no
changes for the user.
Prior to this PR, we've had the Edit Cell be available both in a "dock"
and "window" mode. Both at the same time. (!)
The "dock" mode already had tear off window functionality and was more
complete, whereas the "window" mode was buggy and didn't really add
anything new.
This PR removes the "window" version of the dock, and cleans up the
handling of "dock" mode, so there's just one Edit Cell dock now. It
can be torn off and used as a window, docked to the main UI (by double
clicking its title bar), and toggled on/off with Ctrl-E (Cmd-E on OSX).
* Allow viewing via the EditDialog for executed sql statements
Editing is disallowed, becuase we do not know which table the freeform
query operates on
* Fix whitespace
* Don't crash when changing to 'Execute SQL' tab when no database selected
* Add double click action
* A small usability improvement and indentation changes suggested by @MKleusberg
Add a new option for replacing the edit data dialog by an edit data dock
widget which is added to the main window and remains visible. This might
be interesting for people who otherwise would have to open the edit
dialog many times by doing tons of double clicks.
Add a new menu option to the Browse Data tab for changing the encoding
of all tables instead of just the one table.
Also check if the encoding the user typed in exists before trying to use
it to prevent a crash when an invalid encoding is used.
See issue #414.
When browsing and editing a table in the Browse Data tab allow the user
to change the assumed encoding of the text in the table. We'll then try
to convert from this encoding to Unicode for display purposes and to
convert from Unicode to this encoding for editing purposes. This way the
UI and all tools will keep using Unicode while the database format is
still respected. I hope the amount conversions generated this way won't
affect the performance too much.
See issue #414.
See issue #408.
This isn't working reliably yet on my system: If you enable the fix
restoring the previous settings when going back to a table doesn't work
and if you disable it that very way is the only way to change the
option. Don't know what's going on there :(
When opening a read only database file show a 'Read only' note in the
status bar of the main window and disable all editing buttons in the UI.
See issue #402.
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.
When changing the table in the Browse Data tab we used to remember the
column widths for that particular table. When changing the tab and then
coming back or when pressing the refresh button we used to save the
filters (but not for a table change). The sort order wasn't remembered
at all. I think this behaviour doesn't make any sense.
With this patch we remember column widths, sort order and filter values
for each table individually and restore it when the user switches back to
the table. All the settings are handled the same way and as much
information as possible is stored. It gets also saved in our project
file format.
Add a tooltip to the database browser when you hover a cell with a
foreign key set in order to show the referenced table and column.
When clicking on such a cell while holding the Ctrl and Shift key (only
one of them won't work because they are for multiselection and Alt
doesn't do the trick on my system because it's just for grabbing and
moving the window) try to jump to the table and row which is referenced
in the clicked cell.
See issue #192.
In the Database Structure tab of the main window, add a new action to
the popup menu which open upon right clicking the tree view to allow
directly changing to the Browse Data tab with the current table being
selected automatically.
See issue #246.
