Re: Setting the properties of multiple selected objects in stead of just one (the first or only selected->data)
From: Hans Breuer <hans breuer org>
To: pvanhoof gnome org
Cc: discussions about usage and development of dia <dia-list gnome org>
Subject: Re: Setting the properties of multiple selected objects in stead of just one (the first or only selected->data)
Date: Fri, 14 Jan 2005 00:12:53 +0100
On 11.01.2005 01:54, Philip Van Hoof wrote:
On Mon, 2005-01-10 at 19:52 +0100, Philip Van Hoof wrote:
[subject]: This patch will do that.
This new one fixes some issues Hans explained on the mailinglists.
Aside from the issue's this one also adds undo/redo history support for
new functionality.
I haven't yet introduced a checkbox before each property that could
allow the user to choose whether or not setting it should be shared
across all selected instances of objects.
I'd rather create a new menu "Object" and a submenuitem "Properties" and
leave the "Objects->Properties" menu the way after applying this patch.
It sounds like a much more convenient and more "usable in terms of
usability"-solution to me, than to introduce a checkbox before each
property in the intersection of properties of the selected objects.
I tend to disagree - and Aplle, not really known for bad useability
appears to do as well. The link below shows how multiple selection
edits (of mp3s) are handled in iTunes :
Beside the checkboxes there is also another thing reflecting different
states of different objects. Fields which share the same value are
initialized to it - different entries fields are empty.
It's clear to the user that the menu selection "Objects->Properties" is
about setting the properties of all object in the current selection. If
the user dislikes that, she'd probably search for a menu "Object->
Properties" rather than "Objects->Properties".
Personally I dislike this idea (but it wouldn't stop me
commiting the patch ;)
>
[... skipping one-person-usability-test ..]
About the fact that there's already a python plugin that does this: I
wouldn't do this in a plugin.
Sure this shouldn't be done as a plugin, as already noted the plugin
was not meant to be the final thing but just a prototype (also coded
to have some interesting example with some use :-)
> [...]
To Hans Breuer: My first example wasn't a patch already. It was more a
sneak preview for the concept which I had in mind. It basically was my
question to the group linked to the "but"-paragraph in the HACKING file:
Feel free to hack away at dia, but you're advised to contact
the dia maintainers and/or the mailing list if you do any
larger work --- this is in everyone's interest so that work is
not duplicated.
.. Indeed. So I did.
Yes, thanks.
Since I wanted to code something this evening already, I finished it in
the hopes that it might just get accepted. I wouldn't have bothered with
the python plugin since I don't think writing a plugin for everything is
really a solution for every bug/feature request. As I stated above, this
feels to me like core functionality. Not like an extension.
Do I really need to say once more, it is a *prototype*.
The C++ style comments weren't suppose give the idea that I would have
committed it on approval. It where comments that I had put there while
writing the E-mail. Nevertheless I've made sure there aren't any
C++ style comments left in this new patch. I also removed the extern
function declaration. I actually copied it from another file which I
haven't yet altered. So it wouldn't be only me decreasing code quality:
So .. I recommend removing it from propdialogs.c to increase code
quality of that file.
Done.
While improving the python protoype I noticed the necessity to filter
out property values which look the same when directly comparing them
so there was added the compare by string representation. Sure it was
a hack, but working ...
Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it. -- Dilbert