Robert Leleu wrote:Thanks for the 2.5

For 2.6 I would appreciate to have the possibility to declare a form as "autoopen" when opening a project.

Good idea, --> bugs.kde.org

In the report edit mode, I would like the ability to move(position) multiple fields together using the precise X or Y values of the "Properties" tab. The same request for the form edit mode where it is located in the "Properties/Name/Geometry/X or Y". Currently, I have to move each field or label one by one by hand. The form edit mode allows the positioning of multiple fields (by eye) using the mouse but not the precise positioning in the "Properties" tab. One can do so if selecting only one field but not when selecting multiple fields.
I also agree that an "auto open" form would be nice, especially when the Project Navigator is crowded with queries, forms, reports, etc.

Kexian

More paper sizes, including enveloppe sizes, including a custom one.

and
The ability to prepare reports for printing labels (2 or 3 per row).

This last is available in Libreoffice accesss, says google
It was not in late Knoda, but I scripted the creation and population of an adhoc table whose each row include the datas for 2 or 3 rows of the main table.

Be able to copy forms and reports within a data base. This would allow to create easily slightly different widgets.

Robert Leleu wrote:Be able to copy forms and reports within a data base. This would allow to create easily slightly different widgets.

That's important feature indeed. There are several solutions:
- "Duplicate" action in the Navigator
- Copy/Cut/Paste actions in the Navigator
- "Save as" action in Design mode of any db object (Table, Form, etc.)

I am considering the third option for 2.6 and the second for more distant future.

Current workaround working only for queries and scripts is: copy definition text (SQL or script code, respectively) and paste it as a definition of a newly created object.

Thanks for 2.7
Here are some wishes

These comments are made while using a kexi based address-book.

Most of them are related to how to recover the data towards using them out of Kexi, usually within a word processor

Is there any word processor (Libreoffice, Calligra words) able to handle fields fed from a Kexi query ?

Once an occurence is selected in a query, there is no easy way to display a related form.
Either you have to re-design the query, copypasting the occurence ID to the right case in the design windows, saving and then displaying the form. Either copypaste the rownumber from the query to the form.

Once the form shows the wanted datas you have to copy them one at a time to the word processor you are working in. Since simultaneous selection of several fields in the form is possible it would be useful to copy the whole selection.

If you have choosen to re-design the query you can export (to file or to copyboard) all the fields, and once pasted you shall erase the information you don't need. Some way to select which fields to export would be useful.

Thanks for the feedback, Robert. I'll carefully note down the ideas.

A new idea

Have a zoom to work on reports. I use reports to print on A3 (er even slightly larger format). It would be nice to have a whole view when designing the report.

leleu wrote:Have a zoom to work on reports. I use reports to print on A3 (er even slightly larger format). It would be nice to have a whole view when designing the report.

Definitely, and it's not very hard to add.

It was filed at https://bugs.kde.org/show_bug.cgi?id=330217
@Adam?

PS: Even zooming for forms was reported: https://bugs.kde.org/show_bug.cgi?id=335688

Here are some wishes :

1. Some kind of "external object" to store the path of images, pdf files, a.s.o.

The reason:
Assume you have an online catalogue of several hundred or thousand of objects, and that you're editing it locally with Kexi.
In such case, it's absurd to load the pictures as BLOB inside the database.
It's much better to upload (only) the new pictures to the server and to store their relative path in the database.
This way, the size of the kexi file can be kept small and it can be quickly uploaded after each update.
In the settings, we should have two fields "local path" and "remote path".
Only the file names relative to the local path would be stored in the database.
Some "Export for the web" button could make a duplicate of the Kexi project, where the "remote path" would be appended to each of the stored paths.

2. The possibility to display a tree view of items stored in the database.

The reason: Items may belong do different categories, but a tree helps browsing them easily.

Suggestion for the implementation:
For each level in the tree, one should have the possibility to specify which table and field contains the category to display, which is the parent table and which are the two fields making the link between them.

3. Option buttons
Like checkboxes, but mutually exclusive if in the same group.

The reason: Often more convenient than a drop list as faster.

4. The possibility to store the data and the Kexi project in two separate files and give them a .sqlite3 extension.
For instance :

Code: Select all

- <my-project>.kexidata.sqlite3
- <my-project>.kexiproj.sqlite3

Benefits :
- possibility to drag and drop product catalogues to remote server without having to share the Kexi app and without having to remove the tables with SQLite Studio or equivalent the tables storing the GUI
- files directly included in filtered sqlite3 databases by SQLite Studio or equivalent.

Suggestion : still allowing storage of all data in one unique file if wanted ; separate sqlite3 files should be an option.

Julien Demigeek wrote:Here are some wishes :

Hi julien.
Let's discuss the requests one by one.
Below is just start.

http://bugs.kde.org is out bug/wish tracking system. Our project management system is at https://phabricator.kde.org/project/view/17 - once a wish or bug is in development, specific task may appear there with information on progress, discussion and code reviews.

By the way, visit http://bit.ly/kexiwishes to see unresolved Kexi wishes, visit http://bit.ly/kexibugs for unresolved bugs.

Julien Demigeek wrote:1. Some kind of "external object" to store the path of images, pdf files, a.s.o.

The reason:
Assume you have an online catalogue of several hundred or thousand of objects, and that you're editing it locally with Kexi.
In such case, it's absurd to load the pictures as BLOB inside the database.
It's much better to upload (only) the new pictures to the server and to store their relative path in the database.
This way, the size of the kexi file can be kept small and it can be quickly uploaded after each update.

Fully agree. This is reported at https://bugs.kde.org/show_bug.cgi?id=355199 I think. Feel free to add more info there (note: text once posted there is for some reason not editable)

A subset of this wish is I think hyperlinks support (e.g. hyperlinks to documents) was already implemented in 2012: https://community.kde.org/Kexi/Plugins/ ... hyperlinks. Form buttons can be bound to fields providing hyperlinks.
As you can see the wiki https://community.kde.org/Kexi is used by us for more detailed design documents. I encourage to use it for such purposes.

https://community.kde.org/Kexi/Plugins/ ... hyperlinks is an equivalent for tables, not yet implemented.

Julien Demigeek wrote:In the settings, we should have two fields "local path" and "remote path".
Only the file names relative to the local path would be stored in the database.
Some "Export for the web" button could make a duplicate of the Kexi project, where the "remote path" would be appended to each of the stored paths.

[/quote]

We need to find easy (usable) approach here. More thinking and spliting to parts may be useful here.

I'll be back to the other requests later.