On 14 December 2015 at 15:57,  <c...@isbd.net> wrote:
> Jaroslaw Staniek <stan...@kde.org> wrote:
>> >>
>> > My main reason for not persevering with Kexi (I did try it a while
>> > ago) is that it is effectively proprietary in the way it uses
>> > databases.  You really can't share data between Kexi and other
>> > applications.  I have, for example, a lot of sqlite3 databases created
>> > by a DokuWiki plugin.  I'd love to be able to access and use them with
>> > Kexi, but I can't.  I could import them into Kexi but then the
>> > Dokuwiki plugin could no longer access them.
>> >
>> > Simply by making kexi databases have the unique .kexi suffix I believe
>> > you are putting a lot of people off.  If one could at least *read* a
>> > Kexi database directly it would help.
>> Thanks for the notes Chris.
>> Agree here and this is planned as a major new feature of Kexi 3, and
>> has been discussed on the forum:
>> https://forum.kde.org/viewtopic.php?f=221&t=109559
>> (Note, the Predicate component is now called KDb)
>> Features such as importing SQLite filed won't be needed then:
>> https://bugs.kde.org/show_bug.cgi?id=125843
> Excellent.  I think separating the 'actual data' tables from the
> Kexi configuration is what's necessary.  I've used other applications
> which seem to manage this OK.  I suppose it's easier with a database
> server as opposed to sqlite because each app can create tables on the
> server and there's little risk of them disappearing whereas sqlite
> files might get moved or deleted.

There will always be a benefit from storing metadata. There are no
standards for storing info about width of columns in tabular view for
example. We're using separate kexi__* tables and nothing more. There's
nothing that stops user to keep these tables in separate database is
she needs to for whatever reason (for example if the main database
schema is read-only for her). You're right that compared to servers,
the main purpose of SQLite format compared is compactness,
self-contained format. So the cost of accepting outside edits of db
schema will be that Kexi needs to deal with cases like this:
1. User removes column C from a table using 3rd-party tool
2. Kexi loads the table and while showing it needs to realize that
there's no column C. It needs to go back to defaults regarding the
column. If there were scripts or macros (future!)  that refer to C,
they may require manual or automatic adjustment.

In addition, configuration of Kexi (like shortcuts, look/feel,
paths/limitations) can be extended to many levels and this is what I
noted long ago, at least:
- Kexi app defaults (defined by implementation and default kexirc
file), can depend on the Kexi installation/version
- Kexi app config at user's account level, i.e. per-user-account kexirc file
- configuration per project, for all users, that means a project
admin/developer can alter setting for all users
- configuration per project, for given user, possibly kept on a
server, that means user that connects from any OS from any Kexi app
instance/version should have the configuration applied
- default configuration defined on a server used as a template when
creating new projects for this server

Priorities can define what level has precedence over others. There may
be some inheritance too. I also understand there's no

>> >>
>> >> What exact features of simple table creation do you mean?
>> >>
>> > I want to be able to edit a table in place on a tabular form.  Table
>> > creation I am quite happy to do by other means, I just want simple,
>> > straightforward data entry the way that Access does it by default.
>> >
>> > Having created the table one is presented with a 'spreadsheet' form
>> > where existing data is displayed (scrolling if required) and I can
>> > edit existing entries directly and add new rows.  By default Access
>> > shows a 'new entry' blank line at the bottom of the table.
>> >
>> > Editing entries needs to be very straightforward, just click on a
>> > field and enter/delete text.  No pop-up forms, double-clicks or
>> > anything.
>> >
>> That's the way of Kexi, right? Especially the "new record" line.
>> Kexi: http://i.imgur.com/O1W6l4L.png
> ?? I went to the above URL and got what looks like a single field
> entry in the middle of a blank screen.
>> If I remember correctly there are no popups except one for asking
>> about removing record(s) which is better handled in Kexi I think
>> because there's a checkbox to dismiss the question for the future
>> cases. In Access you need to use VBA or separate design mode options
>> to disable the questions.
>> Feel free to explain what is exactly missing in the area of data
>> entry/editing as this is very important part of Kexi.
>> The only difference to Access is that Kexi is closer to spreadsheets
>> when editing a cell: you need to 2xclick or press F2 to edit existing
>> value. This difference is a result of observation that navigation and
>> copying/pasting of data is much easier.
> I think that's one thing I don't like, I *HATE* double-click in all
> its forms.  I want to just click in field and start typing, also I
> expect to be able to TAB to the next field with no mouse interaction
> needed at all.

True, 100% Keyboard interaction is the major requirement.
The question is whether to have the MSA behaviour as default or not.
So far the spreadsheet's behaviour is what we have. And you have F2 shortcut.

The spreadsheet's behaviour also opens possibility of multi-cell
selections (Shift-Arrows shortcuts), another convenient thing already
supported by MSA. Clipboard-copy/paste can work then. To be
implemented I think.

BTW, Tab/Backtab works since maybe 10 years. For complete list of
shortcuts please refer to

regards, Jaroslaw Staniek

: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Kexi mailing list

Reply via email to