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.
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". Creating custom widgets
which massive amounts of checkboxes and a jungle of options isn't going
to make it more easy for her to understand what exactly is going to
happen. I did the test with my girlfriend using a prototype of such a
dialogbox quickly created with Glade-2. I can assure you that the
usability-aspect of my prototyped dialogbox was below low. She didn't
understand a thing about that checkbox next to each object-property. I
needed multiple minutes to explain it to her. Insane!
About the fact that there's already a python plugin that does this: I
wouldn't do this in a plugin. It's clear that this most requested
feature isn't unworthy to get into the main-code and therefor shouldn't
be done as a plugin. Let alone a python-plugin which even requires the
availability of extra libraries like a Python environment and PyGtk.
Thats like requiring a webbrowser for the feature "selecting objects on
a diagram". It might make sense to us, developers. I promise you,
however, it wont make any sense to a moral common user. And it
shouldn't. I won't expect from my girlfriend to EVER understand such
things about "computers". I'll just code them for her, so that she can
USE them. Thats the purpose of my life as a programmer, right? To make
computers USEable for USERs.
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.
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.
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:
[freax lort lib]$ grep pdtpp_is_visible_no_standard propdialogs.c
extern gboolean pdtpp_is_visible_no_standard(const PropDescription
*pdesc);
props = prop_list_from_descs(pdesc,pdtpp_is_visible_no_standard);
[freax lort lib]$
So .. I recommend removing it from propdialogs.c to increase code
quality of that file. As you noticed in my patch, newcomer developers
exploring the current sources might get confused by such things in the
current code while trying to fix or add something trivial like I've been
trying to do. Here's a little patch that will remove the line:
Index: propdialogs.c
===================================================================
RCS file: /cvs/gnome/dia/lib/propdialogs.c,v
retrieving revision 1.10
diff -u -r1.10 propdialogs.c
--- propdialogs.c 21 May 2004 15:48:34 -0000 1.10
+++ propdialogs.c 11 Jan 2005 00:40:53 -0000
@@ -289,7 +289,6 @@
}
}
-extern gboolean pdtpp_is_visible_no_standard(const PropDescription *pdesc);
static void
prop_dialog_fill(PropDialog *dialog, DiaObject *obj, gboolean is_default) {
const PropDescription *pdesc;
I tested this. It compiles without the extern declaration.
--
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
Attachment:
dia_objectS_properties_02.patch
Description: Text Data