Kexi/Spreadsheets

#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!