GNOME Bugzilla – Bug 596545
Add a "name" field to frame widgets
Last modified: 2009-12-27 09:28:09 UTC
Created attachment 144142 [details] [review] Proposed patch to add a name field to frame widgets The attached patch adds a "name" field to the properties dialog of frame widget sheet objects. This string value is used to set the "name" property of the associated GtkFrame widget. The rationale behind this is that it makes it possible to use frame widgets in plugins to add functionality to the widget. E.g., employing GtkGLExt the frame might be used in a plugin to add an OpenGL-enabled drawing area as the child of the frame and then render an OpenGL scene in that area. (The Pure plugin actually provides a function to do this, see http://code.google.com/p/pure-lang/wiki/Addons#gnumeric-pure). In order to provide that kind of functionality, a plugin function must offer the user a way to designate the desired frame widget. This is done most conveniently through a string. Now frame objects already have a label in Gnumeric, but that is often not very suitable for identifying the frame, because the label is what's shown on the screen, which might not match the requirements to uniquely identify the frame object in all cases. With the proposed "name" property this becomes easy, as the user can tag all his frame widgets with unique identifiers which may then be passed to plugin functions.
Created attachment 144143 [details] ChangeLog entry
I think adding a "name field" will be very confusing to users since it is completely unclear where the name would be used. (In fact there is no use of that name at all in gnumeric's source tree.) I don't see why the label could not be used to select the correct frame if access to the frame is needed from a plugin. If there is really a need for a name, we should at least ensure that it is unique when set and hide the name entry field in the properties dialog unless a special preference is set.
> I don't see why the label could not be used to select the correct frame if > access to the frame is needed from a plugin. Well, you might want to have no label at all shown on the frame widgets, how do you distinguish them in that case? > If there is really a need for a name, we should at least ensure that it is > unique when set and hide the name entry field in the properties dialog unless a > special preference is set. I agree with that. Or there might be some kind of "More options" button in the dialog.
I share Andreas' concern that this will be a GUI item confusing most users. Also, why frames and not all other widgets? Instead, would it be possible to come up with a method of automatically generating a name from workbook+sheet+something else?
might be interesting to access charts and other objects in the future.
It's a requirement for scripting. VBA interfaces access the objects by these names. We round trip them for xls.
Jody: I understand that it is needed for scripting, but as long as we don't have a scripting interface inside gnumeric it will just confuse users. Even afterwards it should be made clear that those names are used for scripting. Perhaps using a "Scripting Options" button inside the dialog to show additional features.
Jody: If we roundtrip them for xls, where do we put them? Note that the patch above introduces a new field: typedef struct { SheetObjectWidget sow; - char *label; + char *label, *name; } SheetWidgetFrame; and if we already have some names somewhere we should not do that!
Morten: > I share Andreas' concern that this will be a GUI item confusing most > users. As I already said, one might hide this option and add a something like a "More options" button to the dialog. > Also, why frames and not all other widgets? I'm testing the water first. :) Of course one might add such a property to the other widgets as well. > Instead, would it be possible to come up with a method of automatically > generating a name from workbook+sheet+something else? The problem is that I see no obvious choice for "something else". (Other than a running counter, which is a bad idea since these numbers will be assigned internally and thus are not readily accessible to the user.)
Andreas: > I understand that it is needed for scripting, but as long as we don't > have a scripting interface inside gnumeric it will just confuse users. Let me reiterate: Gnumeric *is* already perfectly scriptable through the plugin interface, so there's already a need for this.
It looks like the widgets in objs.xls have names. For example, visible name ---------------------- opt1 OButton1 spin SPIN arrow ARROW checktext CHECK List LIST ...
The claim that we round-trip the names cannot currently be verified. ./ssconvert ../samples/excel/objs.xls ../objs-copy.xls ** (/home/welinder/gnome-src/gnumeric/src/.libs/lt-ssconvert:29005): WARNING **: Not sure why label is NULL here. (Four times.) The resulting file crashes Excel, :-0
The problems of comment 12 have been worked around by not exporting filled objects with no text. We do not export widgets to xls at all. I am guessing that "We round trip them for xls" was a reference to VBA scripts. So, if widget names are important we should add the field to the relevant structure and figure out how to import and perhaps export them. Then we can worry about a GUI for editing.
Comment on attachment 144142 [details] [review] Proposed patch to add a name field to frame widgets Sheet objects now have names. * No check for name clashes. * Import/export from .gnumeric * Import from .xls
Thanks Morten, that's very useful. So now all we need is a way to actually set the name of an object in Gnumeric. Have you thought about a GUI for that yet?
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. There is still no check for name clashes but you can now set the name in the size dialog accessible from the sheet object context menu.