Kexi/Spreadsheets
< Kexi
#koffice, 2008-04-14
jstaniek so will you let me repeat this in a form of a scenario? piggz yes ingwa_ jstaniek: go ahead piggz maybe we need an interactive whiteboard to draw pictures to eachother jstaniek exactly jstaniek 1. user has a db table, named employees with id, name, surname jstaniek that'd be enough now jstaniek 2. the table is saved in a kexi-compatible way, so she can somewhat point to a db file and select the table jstaniek user wants to perform additional processing of the table's data using familiar tool, namely kspread, because she needs some flexibility or so jstaniek that was 3. jstaniek 4. user executes a command like 'insert tabular data' to achieve the goal jstaniek (the command is somewhat different compared to tpical 'import' or 'paste' commands, because kspread can remember the original datab source, and could perform two-way updates if desired) ingwa_ ok jstaniek 5. and now there's a moment where we have to think what happens jstaniek I'd give two possible cases jstaniek 5.1. User can see a typical spreadsheet range filled with 'imported/linked' data from emploees table; here we have a number of problems to address; e.g. what to do to avoid overwritting existing cells if there is no space in the given range; how to present the range in an unbofuscated way (another type of border!!!??) :) jstaniek s/exiting/existing nonempty/ jstaniek (in short, we cannot ask user to predict if the range is big enough) jstaniek 5.2. Another sheet is created for user, preferably with 'employees' name jstaniek user can take advantage all the features of spreadsheets without playing with ranges jstaniek (on technical level, the dump od data for the new spreadsheet can be saved in odf-compatible way, and in the same time extra metadata for data sources can be kept with this single sheet; moreover ODF provides some of the connectivity parameters already) jstaniek In fact 5.3 would be to paint a data table shape, but this is so MSO-like, makes the iface unnecessarily multilayered, and filed with special cases we all hate. jstaniek <eof> bullgard4 jstaniek: [Kexi, GNOME] The 'Search' dialog is open. The field 'Look in:' contains an entry (for exmple) 'field3'. If I change my workspace and return to the old workspace, 'field3' will be replaced with 'all fields'. This is rather annoying. Do you know this deficiency? jstaniek bullgard4: in kexi 1.x? josim jstaniek: so you're saying that using kspread to display a chart with data from a database is not the best way to go? josim or more generally, to use kspread to paste data from a database piggz i think the 'more general' case? jstaniek josim: sure it is if you want to compose it with other data and shapes using kspread bullgard4 jstaniek: Kexi 1.1.3 (KOfiice 1.6.3) (KDE 3.5.8) josim *if* you want to compose it with other data and shapes, yes jstaniek bullgard4: please report this to bugs.kde.org.. we have so many todos josim but not for the report tool, right? piggz no bullgard4 jstaniek: Yes, ok. I will do. Thank you. -->| Mek_ ([email protected]) has joined #koffice jstaniek josim: if the reporting itself is enough, and no kspread-specific features are needed, then I'd say go with full reporting; that would be more natural interface jstaniek spreadhees are often fo too ad-hoc use cases, yet this property makes them so incompatible each other... jstaniek s/fo/for josim exactly josim i actually never said we need a kspread shape to chart the data from a db josim that's why i was a little confused <--| KRF has left #koffice jstaniek we are mixing the two worlds, spreadsheet, and abstract, dynamically changing, tabular data sources; that needs to be designed with users' sanity in mind... josim you mean, we *should* mix them? jstaniek I am curious how kspread would look like if it allowed for many different types of 'sheet' tabs, just like kexi; odf compatibility can be still there because it is the presentation, what make them differ each other jstaniek yes, we think about mixing jstaniek as short story: MS wanted to mix that very deeply too, but that was as costly as 100M$+ for patents ;) josim hahaha josim too bad jstaniek hahaha, gr8 fun may be costly josim jstaniek: you said "go with full reporting".. what do you consider 'full' reporting? josim to use the db directly, instead of indirectly giving it to the chart using a kspread shape? jstaniek 1. light reporting is what MS did (and oo.org copied) regarding inserting floating widgets/fields into the spreadsheet directly josim right, like in this screen http://www.microsoft.com/library/media/1033/technet/images/prodtechnol/sql/2000/deploy/figure32_big.gif jstaniek 2. example of full reporting is piggz's work or (a bit worse example :) ) MSA reports |<-- Mek has left chat.freenode.net (Read error: 110 (Connection timed out)) josim "Drop series fields here" josim i see jstaniek yes, MS is trapped. Trapped by itself. So many ways to achieve average effect. josim I should take a closer look at your reporting feature, piggz jstaniek so people liked iworks, simplified stuff. jstaniek josim: btw, to say how much i value spreadsheets, otoh, I'll mention that often users ask "how to enter a furmula into my kexi table field", the usual answer is exactly - more close collaboration between the two apps, on realtime jstaniek So in kexi we shall give up with many features that are more naturally bound to spreadsheets. josim heh josim mh, in that sense, 'full' reporting would mean less functionality jstaniek josim: btw, the same as for reports is valid for forms, you know; this is MS's trap again. josim jstaniek: to be more precisely: what functionality do you not want to have for charting data in a report, that you have when charting data from a spreadsheet jstaniek josim: I treat charing shape as a whole, no need to degrade it jstaniek what I mean is e.g. that we wouldn't be happy with extending relational db model with things like recursive computation typical to spreadsheets jstaniek people not accustomed with db, start using dbs anyway thanks to simple iface like kexi, but they want to think about it as a spreadsheet, that is not too safe piggz jstaniek: heh, yeah, i hate badly designed dbs :) jstaniek say, if people want to escape from one-datatype-per-column model, they would go with importing the 'live db link' int okspread and alter the data jstaniek colorize that, etc. josim yeah jstaniek but if they are ok with the rules, reporting or even forms can display charts too, there's nothing in charts we cannot support josim db functionality and spreadsheet functionality clearly need to be separated, especially in an office suite with both of these apps, kspread and kexi jstaniek yes, especially that kde advertises good WM, we should not glue everything in one window, thus quickly running off of the available space CyrilleB tsss caught while designing for a specific WM ;p josim jstaniek: so, giving the user the ability to add additional fields from the db to the chart later on josim did that make sense to you, or did it *not*? piggz i dont see that as a problem josim well, I'm not sure if jstaniek considered that to be one of the clearly spreadsheet-typical functionalities jstaniek josim: well, if we finish 'alter table' feature in kexi, you can add/remove/rename columns and thus you can alter charts CyrilleB boud: did it solve your issue in the test ? jstaniek even without alter-table I cannot see a problem with altering chart's properties afterwards josim well, a chart does not always show *all* the data from a table piggz jstaniek: id expect the chart to be bound to a query, so wouldnt need tables to be altered (unless ofcourse the data set drastically changes) josim but only the data in the selected fields piggz exactly |<-- bullgard4 has left chat.freenode.net ("leaving") josim ok, good we agree on that :) josim i'm off to bed now, gotta get up early tomorrow jstaniek piggz: yes, moreover, even tables as you can see them, are actually queries, you know that :) josim see you!