On 14 December 2015 at 13:48, Swarup <dinban...@sprynet.com> wrote:
> On 12/14/2015 07:22 AM, Jaroslaw Staniek wrote:
> On 14 December 2015 at 13:13,  <c...@isbd.net> wrote:
> Jaroslaw Staniek <stan...@kde.org> wrote:
> The exclusive group or RAD users is not small but severely distributed
> so quite hard to reach. Misused spreadsheets for example are
> competitors too. There's always room for IT projects without any
> reasonable budget assigned.
> Yes, that's my pet hate, people using spreadsheets for storing tables
> of text information.  :-)
> That triggered creation of this chapter of the handbook:
> https://userbase.kde.org/Kexi/Handbook/Introduction_to_Databases/Database_and_Spreadsheet
> Nothing revolutionary and can be further extended :)
> PS: And I am unsure why would the LV claim there's no client-server
> architecture in such RAD tools if all database engines (but SQLite)
> have always been client-server. Maybe it's about the app and GUI on
> the server side?
> A good, easy to use front-end (like Kexi may become or MS Access sort
> of is) would encourage more use of databases.
> I've been searching for a decent replacement for MS Access for ages
> and still haven't found one.
> My fundamental requirement is soemthing like Access' table view that
> allows very simple creation and updating of a table.  I've yet to find
> anything.
> Yes, sometimes I am looking into ways to make Kexi even simpler to
> use, so if user wants it - it can be in the middle between a
> spreadsheet and a db creation app. Ad-hoc creating table designs
> (while entering the data) is one of the things, quite hard to
> implement though. Interesting, after the idea came MSA (maybe 2003?)
> added similar feature.
> But before it's reality we probably need to get reliable alter-table
> feature to work.
> What exact features of simple table creation do you mean?
> I feel this middle ground between a spreadsheet and a db creation app is
> incredibly important and will increase the value and use of Kexi among the
> general linux user base exponentially. My estimation is the the majority of
> potential Kexi users will be wanting it for this feature. That is what a
> great number of Access users use Access for. These people are not terribly
> technically inclined, and like the table format of Access better than a
> spreadsheet format, for their purpose of storing text-based data. I am one
> such person, and as a Linux user have been using Kexi for this middle ground
> for several users-- although frankly it is far from satisfactory compared
> with Access, due to lack of ability to alter the configuration or appearance
> of a table after it has been created.

Yes, that's a #1 wish from many people
[1] https://bugs.kde.org/show_bug.cgi?id=125253

> So in short, I agree with you Chris, that for this middle ground between a
> spreadsheet and a db creation app, what I think you mean by the alter-table
> feature, is more important than the simple table creation. Going into data
> view to make the initial table is no big deal. But after the table is made,
> then on the fly the following features are I think critically imporant:
> 1. Ability to create new rows and columns later on, in table view.
> 2. Ability to rename columns later on.
> 3. Ability to hide columns and rows in table view.
> 4. Ability to move columns in table view.
> 5. Ability to alter the number of characters allowed in a cell after the
> table is made, without losing all the data.
> 6. Ability to highlight and copy the cells of limited number of rows and
> columns, i.e. a sub-section of the table.

Of course physically creating table from scratch based on data the
user entered is trivial. The points you listed are similar to the ones
in the [1] wish.
It's even known how to get there:

Just the development is more expensive than not :)

> Some of these features may have already been implemented in your later
> versions, as in Ubuntu I cannot upgrade to later versions (fixing this is
> also incredibly needed). I am running version 2.8.5, although I would love
> to be able to upgrade if there were a reasonable way to do so.

Kexi 3 will be in separate repository and won't have too many
dependencies of KDE frameworks.
I do expect this will simplify preparation of binaries for most
popular OSes like Krita has, distributed alternatively. Maybe this
include some Linux packages -- contributions in this area is more than

The goal is that user's will no longer be forced to stay with ancient
versions -- this isn't freedom :)

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