[Kexi-devel] [Kexi] Some bugs and suggestions

Custodis Custodis at zonnet.nl
Mon Jan 23 20:57:59 CET 2006


Hi Jaroslaw (and all others off course),

Thanks for your response.

Jarosław Staniek wrote:
> On Saturday 21 January 2006 08:13, Custodis wrote:
>
>   
>> If you don’t mind, I will list the bugs I found here. Don’t see them a
>> criticism, I’m just trying to help to improve the program. I think it’s
>> amazing so few people can do such a great job in such little time. I’m
>> working with version 2005 LT v4 on windows xp.
>>
>>     
>
> Robby, thanks for these tests. Below I will try to add some more info. For any 
> non-trivial defect you found, please consider reporting it on the 
> bugs.kde.org web site (registering needed) so others will be able to track 
> the overall progress.
> I'll refer to Kexi 1.0 beta1 (aka 2006) if there's a given bug fixed "almost 
> for sure".
>
>   
I've Googled, but couldn't find this version to download. So I can't 
confirm it. But good work! It will help to give Kexi trustworthy image.

>> Bugs
>>
>> - In the 10 hours I worked with Kexi, the program crashed about 10. I’ve
>> tried to find out who this happened, but I’m not sure. It seems to have
>> to do something whit the length of a session. When Kexi runs a few
>> hours, it suddenly gets a bit in responsive, when the user clicks again
>> and again to get a command running, Kexi stops without warning. Data
>> loss occurs. I don’t have lots of data jet (just one row in two tables
>> and two forms; no queries).
>>     
>
> You may have such problems because, for instance: 
> - Kexi stole 100% of CPU time when closing a window with large data set. Fixed 
> in 1.0. The same for opening such a window.
> - There was missing memory freeing when you close a form. Fixed in 1.0.
> - A few points where Kexi crashes are fixed in 1.0. Maybe you've discovered 
> one of them. After the fixing, while actively tested last two months in, it 
> was hard to crash Kexi in everyday use.
>
>   
Good work!
>> - I’ve made a multiple form. The undo function does not always work
>> here. Sometimes the undo function skips one action or don’t remember the
>> location of widgets right (this happened in a “group box”)
>>     
>
> This is true. What we may need from you is a carefull noting down what action 
> is not possible to undo.
>
>   
I agree. I'm not sure if it is a specific action or a combination of 
actions. I think the latter. I'll try to find out. It would however make 
sense to test it in the beta release.
>> - When designing a form and making a widget smaller, the widget runs
>> over the screen to the right and then disappears out of the box.
>>     
>
> Could not reproduce for 1.0.
>   
Perhaps it's solved, lets hope so.
>   
>> - When creating a new data table; the length of the text variables are
>> not remembered. The all go back to the default value 200
>>     
>
> It appears to be fixed in 1.0. Anyway the property in not usied in Forms yet 
> and we're not restricting user input in table view yet as well.
>   
Oke. (By the way 200 is a very high default number. 50 would do fine also).
>   
>> - When changing the total font color of a tab, the tab itself remains gray.
>>     
>
> True, this looks like a special case we need to fix. Added as todo for 1.0 
> final.
>
>   
>> - In the Netherlands the function of a comma ( , ) and a point ( . ) are
>> switched. When entering a number like $ 22.50 we enter $ 22,50 This is
>> not working well.
>>     
>
> This depends on your system settings. On Windows, IIRC we're not mapping 
> system settings to Kexi (KDE) settings yet, that's because international 
> win32 version is in fact english version and I've not planned to support more 
> languages in the DEMO.
> On Linux, Control Center settings are used for displaying , or . Eg. I am 
> using polish settings that's similar to yours with no problem.
>   
Sorry, don't understand this. Other application can handle this, so my 
general settings seems to be fine. I understand it's not wise to support 
all languages (yet). But it would be nice when a user can choose this 
setting (apart from the language settings). Same thing for the way it 
handles dates (mm/dd/yyyy --> dd/mm/yyyy).
>  
>   
>> - When entering a database it isn’t possible to “save as” (for nothing
>> has changed jet).
>>     
>
> What's "entering a database" here? Do you mean "save table as" function?
>   
I mean opening it. And then "save table as" (you first have to change 
something before this option can be used).
>   
>> - Data entered is not always stored (but this may be my lack of
>> experience with the program).
>>     
>
> In your version, there are chances that query design can be saved with a bug. 
> In case of data, you have a guaranteed saving it properly (at record level) 
> or not saving it at all (moving to another row or pressing Shift+Enter saves 
> the data immediately). The latter can be (almost) only if you forget to save 
> the currently edited record and turn the computer immediately.
>   
What I did was entering a record in a form and than save. Than going to 
the table and seeing the data isn't there. I'll try to observe further 
when this happens. It may have to do something with wrong data type; for 
they were all entered by hand. No error message occurred.
>   
>> Suggestions, it would be nice if the user could …
>>
>> - enter the number of digits after the comma (f.i. $ 22,50 or 22,501) in
>> the datasource (I couldn’t find it).
>>     
>
> TODO for the next update.
>   
great!
>   
>> - select multiple widgets while designing a form, by selecting an area.
>>     
>
> This works if you drag your mouse on the form's surface but not yet if you're 
> drag inside a frame or other container.
>   
Oke
>   
>> - fix data if Kexi crashes
>>     
>
> In most cases - no need to d othis as described above. Database keeps data 
> uncorrupted all the time.
>   
!!!! sounds good
>   
>> - select the last used database when kexi starts
>>     
>
> TODO for the next update. For now you can create a shortcut to your database 
> on your Desktop.
>   
>> - switch between design view and data view could be combined in one button
>>     
>
> Any problems with current three buttons? This can be usability problem. Only 
> MS Access users knew unusual type of button used there (I, as former user, 
> really detest this). In case of Query Designer there are even three views, 
> not two. With Kexi you only need to find appropriate button and click once. 
> In MS Access you need to click on 5-pixel-wide-dropdown-area (!) + find 
> appropriate list item and click again.
>   
What I mean is one button: activate = design view; deactivate = data 
view (perhaps a mater of taste). In general the user interface feels 
good, logical and natural to me.

While I'm working on...
- it seems to me the possibility to use a input box in witch you can 
choose several input values, would be nice to.
- will it be possible to add extensions to the program? It might attract 
developers to do program small parts without insight in the total 
program code, and without the need to compile for every new option.

thanks for making this nice program and..... porting it to Windows! I 
hope other Koffice applications will follow you on this.



More information about the Kexi-devel mailing list