GNOME Bugzilla – Bug 303677
Property editor should support editing of multiple widgets simultainiously
Last modified: 2018-03-26 14:59:11 UTC
Allow for shift+select to select multiple objects for copy/cut/move etc.
Property window should make available any properties the selected objects have in common so that they could be changed togeather.
glade-3 has multiple selection already working, actually; I just added support for paste to work with multiple selected widgets in the clipboard. Changing this bug to "Property editor should support editing of multiple widgets simultainiously" Although I'm not so sure if we should have this feature; It might be more confusing than helpfull, I'll just leave this idea on the table for a while.
Yeah, I came across that while reading some code. I had missed it previously because I had been trying shift + click. The shift click functionality is cool too : ) My preference though would be to switch the ctrl and shift functions to be more consistent with other apps, but perhaps im just used to different apps than other folks.
*** Bug 331659 has been marked as a duplicate of this bug. ***
*** Bug 331660 has been marked as a duplicate of this bug. ***
Ok there is a good purpose and some demand for this feature. Some notes on the subject/feature: o we should attempt to offer support for all properties available in the common ancestor class (according to the least common denomanator class in the selection) o some properties it probably doesnt make sence for (notably the 'name' property of GtkWidgetClass); they should be omitted by configuration in the catalog. o we should optionally change properties relatively to the property being manipulated (like the coordinates of a widget inside a GtkFixed). This last point is really the cherry on top, this feature would still be very usefull but just somewhat incomplete without it ;-)
(In reply to comment #6) > Some notes on the subject/feature: > o we should attempt to offer support for all properties > available in the common ancestor class (according to the least > common denomanator class in the selection) sure, common properties should be shown and the usual "multiselect" behaviour should be followed. If a given property exists in all selected widgets and their value differ, the entry should be 'gray' (or some other visible effect), without showing the actual value, if the user clicks on the entry, it becomes editable and all selected widgets will be set to the entered new value regardless of their original value. If the user does not click on the entry, it remains gray which means 'do not touch', in which case the value of that property is not changed in any of the selected widgets. If the value of a given property is the same among the selected set of widgets, the entry should indicate this visibly (e.g. not becoming gray), and containing the value. Again editing the entry will set the value of the property in all selected widgets. > o some properties it probably doesnt make sence for (notably the > 'name' property of GtkWidgetClass); they should be omitted > by configuration in the catalog. sure. Most times you don't want to edit 'name' anyway. > o we should optionally change properties relatively to the > property being manipulated (like the coordinates of a widget > inside a GtkFixed). I don't feel the importance of this myself, though it is a nice thing to have for sure. It seems to be very difficult (for me at least) to find an intuitive interface for this though.
> If the value of a given property is the same among the selected set of > widgets, the entry should indicate this visibly (e.g. not becoming gray), > and containing the value. Again editing the entry will set the > value of the property in all selected widgets. Now thats a cool idea, I've been thinking about using colors more in the editor (marking some properties as "more important" or relevent than others etc... or "edit with caution" kind of thing; maybe by using the desctiption text colour or an icon accompanied by a tooltip...). We'd have to use something other than grey (since that is already the insensitive property colour) but that is just a detail. > sure. Most times you don't want to edit 'name' anyway. You are right for most cases, somehow I overlook that since I'm in the habit of generating UIs with GtkFixed for embedded kiosk like systems where everything is explicitly skinned by name... but anyway the support should still be there to avoid it on any properties that dont make sence ;-) > I don't feel the importance of this myself, though it is a nice thing to have > for sure. It seems to be very difficult (for me at least) to find an intuitive > interface for this though. Yeah; if this is too complex I'd rather have it out, I think the UI for it wouldnt be too hard (maybe using the Linked/Broken chain icon to set if your properties are being set absolute or relateve.. with a usefull tooltip) But this is more popular in imaging softwares I think; it may be pointless for glade if there arent enough concievable properties that would make use of relative property changes (in which case, better avoid the added complexity).
I've been taking a look on the code. We have glade-editor-table working and glade_util_get_selection working too. To find the intersection of multiple widgets is just a matter of implementing something like a counting filter. What's backing us from implementing this?
Some basic things need to be taken care of first. For instance, the GladeProperty project data has a concept of sensitivity, the backend set's some properties to be insensitive and stores an informative tooltip showing why the property is insensitive. If the property additionally goes insensitive because it does not correspond to other selected widgets, then the GladeEditorProperty needs to reflect the insensitivity with a new tooltip... removing widgets from the selection needs to make sensitivity come back *or* the old tooltip to fall back in place. Nothing really "holds us back" from implementing this stuff but, it has to be done right, and it's a feature that in itself requires alot of thought... like... when modifying the X coordinate of a group of widgets, one should not set the X coordinate of every widget in the selection to be "the new value", instead we would need to have a concept of value offsets (i.e. moving widget "a" ten pixels to the left moves each of the widgets in the group also 10 pixels to the left)... or at least we through packing properties out the window for this kind of editing. For now I dont think I have time to think of this, if you have time to make a project out of this (however I'd rather you expand on the previewer and add some important new options there first), then I suggest you analyze the use cases and the code involved very carefully and form a proposal of how you would want to approach this (would we use the editors already created and cached per-class ? or would we create an "on-the-fly" editor for these purposes ?)... list the details and bring it up on the list.
I want to sketch an implementation plan for this feature. Looking at the code, it looks like the magic should begin in glade-app.c in the function on_project_selection_changed_cb. The check: if (num == 1 && !GLADE_IS_PLACEHOLDER (list->data)) [...] else glade_editor_load_widget (app->priv->editor, NULL); Must be changed to something like: if (num == 1 && !GLADE_IS_PLACEHOLDER (list->data)) [...] else if (num == 1 && !GLADE_IS_PLACEHOLDER (list->data)) glade_editor_load_multiple_widget([...]); else glade_editor_load_widget (app->priv->editor, NULL); Then, glade_editor_load_multiple_widget_real and glade_editor_load_multiple_widget must be written. I still don't know what kind of extra information should be stored in glade-editor to handle multiple widgets. I propose to use a new GList* called loaded_widgets that will point to NULL if there is only one widget selected or to a list of selected widgets (project->priv->selection) otherwise. I don't know which callback is called when a setting is modified in glade-editor but, changing the same property on every selected widget, seem to be a simple iteration over a list. Maybe glade-command will have to be modified so that it can handle changes to multiple widgets. Is there any problem with my implementation plan?
I dont like it. a.) I want to get rid of GladeApp as much as possible Glade already makes too many buggy assumptions about the "active project", I'd like to nuke the active project concept all together... this should be done completely at the GladeProject level and below. b.) At first sight I dont like the idea of adding editor api, instead of doing a "load_multiple" approach, there should be a distinction between what is the "project selection" (0...N objects) and what is the "cursor object" (can only be 1 object at a time)... the cursor object has it's property editor shown and modify the sibling selection objects in an undoable way when that editor is modifying properties. c.) A GladeEditable is not _only_ comprised of GladeEditorProperties many editors add their own properties and widgets to interact with the Glade project model, these cases need to be considered for every editor so, that might require some semantics on the GladeEditable interface or at least all custom editors (found in plugins/gtk+/*.c and created for adaptors by way of glade_widget_adaptor_create_editable()) need to be updated to handle these possibilities.
I (most likely) won't do it anytime soon, but it would be good to have a simple (if possible clear) implementation plan for this. What do you have in mind?
What if we limit it to only edit properties if all the widgets/objects in the selection are of the same kind? This way all properties are common and it is easy to check/set. It is a somewhat incomplete implementation, but still functional and simple.
Please implement this feature like it is implemented in Qt designer!
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glade/issues/3.