Bug 335154 - Lack of Report Design toolbar
Summary: Lack of Report Design toolbar
Status: CONFIRMED
Alias: None
Product: KEXI
Classification: Applications
Component: Reports and Printouts (show other bugs)
Version: 2.9 Alpha
Platform: Mint (Ubuntu based) Linux
: NOR normal
Target Milestone: ---
Assignee: Kexi Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-21 18:09 UTC by Ian Balchin
Modified: 2021-03-09 23:43 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
view of kexi report design mode (59.06 KB, image/png)
2014-05-21 18:40 UTC, Ian Balchin
Details
view of kexi report design mode running postgresql with --style=oxygen (100.58 KB, image/png)
2014-06-03 07:26 UTC, Ian Balchin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Balchin 2014-05-21 18:09:39 UTC
The Report Design Tutorial (for kexi 2.2)

http://userbase.kde.org/Kexi/Tutorials/Reports/Kexi_Reports_for_Beginners

shows a rich selection of icons to create various features in a report, The 7th image from the top shows that application features the following icons:

Label
Field
Text
Line
Barcode
Image
Chart
Shape
Check

This version is limited to:

Cut
Copy
Paste
Delete
Edit Sections
lower
Raise

Although the format of the version used in the tutorial has changed, we seem to have lost features in the process.

Reproducible: Always

Steps to Reproduce:
1. Open existing or new Report in Design mode
2. Look at the icons above the data area & immediately below the tab
Actual Results:  
Lack of (icons for) report design features compared to kexi 2.2 . Not even an icon for 'field' - must copy and paste - fortunately one field is provided to start off with (my first and key field)

Expected Results:  
Naturally we expect the same or better than in version 2.2

Have we regressed?
Comment 1 Jarosław Staniek 2014-05-21 18:33:55 UTC
Confirmed. The issue is related to the widget style used. It should be fixed, Kexi should work with any widget style on any graphical environment.
Comment 2 Ian Balchin 2014-05-21 18:40:22 UTC
Created attachment 86750 [details]
view of kexi report design mode
Comment 3 Jarosław Staniek 2014-05-21 18:43:16 UTC
This applies to the cleanlooks widget style.
Comment 4 Jarosław Staniek 2014-05-21 19:16:04 UTC
Run 'kexi --style cleanlooks' to reproduce the bug.
Comment 5 Jarosław Staniek 2014-06-01 16:03:13 UTC
Hmm confused the bug with https://bugs.kde.org/show_bug.cgi?id=335149. In fact the bug would be called like "Lack of Report Design toolbar".

Unfortunately I am unable to reproduce this one, with oxygen and eg. when I am using kexi --style cleanlooks.
Comment 6 Jarosław Staniek 2014-06-01 16:04:54 UTC
@Ian Do you see the same issue when using oxygen style?
Comment 7 Ian Balchin 2014-06-01 17:15:34 UTC
Hi.

I can confirm this bug is still apparent irrespective of whenthe oxygen or cleanlooks.

regards
Ian
Comment 8 Jarosław Staniek 2014-06-01 19:57:21 UTC
@Ian Do you see this issue in Kexi 2.8.3? (I guess I need to first help you to build 2.8.3 using your source code-based setup)
Comment 9 Ian Balchin 2014-06-02 07:27:36 UTC
right, Jaroslaw, I could try that this evening if I have detailed instructions on how to revert.

Ian
Comment 10 Ian Balchin 2014-06-02 08:11:00 UTC
Jaroslaw,

We have no hope here, the situation has normalised. Whatever I open, whether on postgresql or sqlite, we have the toolbar back - sometimes!

I was trying to determine if the lack of the toolbar was specific to either an sqlite or a postgresql database. At the time it looked as if the behaviour was specific to the one postgresql database that I have - that is where the behaviour was found when first creating a new report. The various little databases I am testing under sqlite all showed the toolbar.

Returning to the postgresql database and attempting to create a report, we crashed. This has happened several times in a row. I sent a new bug report with details from the first crash.

However, I have now reopened, can look at an existing report in Design or open a new Design, and we have the toolbar back!

If I have another crash today I will send a new bug report, I see it checks automatically to see if this is a repeat bug.

Ian
Comment 11 Ian Balchin 2014-06-02 08:52:11 UTC
I think you had better ignore that, sorry. I will get a pen & paper to hand to keep better notes.

In my 2 sqlite databases, opening a new Report in Design shows the toolbar.

In my postgresql database, opening a new Report in Design does not show the toolbar.

New Info.
An apparent repeat of this crash, with the crash handler window behaving oddly in that the kexi window was still open. When I finished with the bug report, which was not submitted, I carried on using kexi!

Ian
Comment 12 Jarosław Staniek 2014-06-02 21:08:51 UTC
@Ian "In my postgresql database, opening a new Report in Design does not show the toolbar" - do you have any screenshot?
Comment 13 Jarosław Staniek 2014-06-02 21:11:41 UTC
(asking because with postgresql database I see truncated buttons for the cleanlooks styles but the toolbar isn't completely hidden)
Comment 14 Ian Balchin 2014-06-03 07:19:05 UTC
Jaroslaw, good morning.

the image attached to this bug report shows the postgresql example

Ian
Comment 15 Jarosław Staniek 2014-06-03 07:24:17 UTC
OK, thanks. Set for 2.8.4. 

Isn't the current workaround like this? 
- create empty report, save it
- close and re-open
Comment 16 Ian Balchin 2014-06-03 07:26:59 UTC
Created attachment 86982 [details]
view of kexi report design mode running postgresql with --style=oxygen

extra image showing same lack of toolbar while running under oxygen. the other image is of kexi running under cleanlooks.

Ian
Comment 17 Ian Balchin 2014-06-03 07:43:41 UTC
jaroslaw,

Reply to comment 15.

Nope. The report where this bug surfaced has been opened-edited-saved-closed-opened many many times without causing the toolbar to appear.

To be sure I made a new  one-field report, and followed this procedure, but the situation remains the same for this as for the other report. I am in oxygen style for the record.

Ian
Comment 18 Jarosław Staniek 2014-06-04 22:15:13 UTC
@Ian Could you try to create a new postgresql project with Kexi and try again?
If it works ok, then an SQL dump of at least kexi__* tables from the original pgsql project would be useful for me (private email is fine).
Comment 19 Ian Balchin 2014-06-06 19:04:18 UTC
Jaroslaw,

I created a new database in postgresql (not a new table in the existing database).

Having created a table, then a matching form to get some population into the table, then a report, I can confirm that report design in this new database does show the 'Report Design' tab with relevant icons.

I now see that this bug seems related to my original database which stubbornly does not show the 'Report Design' tab. The new postgresql database and the sqlite database both allow normal Report design. 

I will organise an SQL dump soonest.

Ian

Ian
Comment 20 Ian Balchin 2014-08-05 20:21:55 UTC
Jaroslaw,

What is the status here? I did send an original dump, but you said that it was not good (no data?) Was certainly a big enough file to have data. I did send another but not sure where we stand now except that I still have no toolbar in my main original postgresql project.

Ian
Comment 21 Jarosław Staniek 2014-08-05 20:36:31 UTC
I plan to look, this week.  I am sorry for the delay.
Comment 22 Ian Balchin 2014-09-15 20:50:45 UTC
commit bd6461d3b93eaaf8307a26520a24e757c0a8f1d1
now running.

thought I would check this bug out and on my postgresql database we have the design icons. Touch wood that this is permanent ;)

ian
Comment 23 Ian Balchin 2014-09-22 17:59:04 UTC
commit 5513c16d57ac34933cb41da1419b437224f70d07
i am afraid it isn't
Report design toolbar not to be seen in postgresql  project.
:(
Ian
Comment 24 Ian Balchin 2014-12-04 14:45:27 UTC
commit c4875b5037567eb4f56cc1c5e3842f17b694e4dd

report design toolbar still  not to be seen :(
Comment 25 Jarosław Staniek 2014-12-05 08:31:46 UTC
I believe you :)
Comment 26 Ian Balchin 2014-12-21 13:00:22 UTC
commit 556a8748a7109668106baf401b42e4a580da665d

report design toolbar still not to be seen in the original database reports - old or new :(
but ok in the sqlite and newly created postgresql ones

I need to add some fields to 'books' table so now plan that to drop the existing tables and recreate a new database from scratch will kill two birds with one stone as it were. This is not going to happen just yet, and I in the meantime I can & do work around this since i can manage with simple report requirements.
Comment 27 Jarosław Staniek 2014-12-21 19:57:18 UTC
We're not done with this bug. It unfortunately takes more time. In the meantime if you re-create the database, data can be copied from the previous database by dumping it to an SQL script (in pgadmin?) and executing in a new database. Should work even if there are new columns in the new database assuming they don't have NOT NULL flags.
Comment 28 Ian Balchin 2014-12-22 06:53:44 UTC
Hello, Jarosław,

Thanks for the tip about NOT NULL.

I didn't know that and have a script to add spare delimiters on
the end of a record as needed which does work fine.

Ian


On Sun, 21 Dec 2014 19:57:18 +0000
Jarosław Staniek <staniek@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=335154
> 
> --- Comment #27 from Jarosław Staniek <staniek@kde.org> ---
> We're not done with this bug. It unfortunately takes more time. In
> the meantime if you re-create the database, data can be copied from
> the previous database by dumping it to an SQL script (in pgadmin?)
> and executing in a new database. Should work even if there are new
> columns in the new database assuming they don't have NOT NULL flags.
> 


-----
Ian Balchin
Fables Bookshop, Grahamstown.
Comment 29 Jarosław Staniek 2014-12-22 10:45:14 UTC
Cool. Future proof scripts can be used as follows:
1. Table T is (a int, b text);
2. You export data by generating script S such as:
INSERT INTO T (a, b) VALUES (1, 'foo');
INSERT INTO T (a, b) VALUES (1, 'bar');
..

Note the "(a, b)" explicitly specified.

3. Then if add columns so T is (a int, b text, c text) the script S will still work (as stated before, as long as the new column isn't NOT NULL. You can use the script as is, without appending extra empty values.

In contrast, CSV is less precise. In the future we'll want to have it possible to specify what column of CSV goes to what field on data importing. This specification could be also useful if it's saved somewhere.
Comment 30 Jarosław Staniek 2014-12-22 10:45:59 UTC
The milestone is set 2.9, but more precisely it's most likely 2.9.x, x>0.
Comment 31 Justin Zobel 2021-03-09 23:43:26 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.