There would probably be more users creating custom sheets and custom
symbols
if the process were more intuitive, or documentation were embedded as a
pop-up
within dia itself.
Question...is it a good idea to have embedded sheets and symbols in
dia...or should
they all be added in the user's home directory (/$HOME/.dia in Linux)?
Moving
everything to the user's home directory makes it easier for each user
to have
his own custom sheets & symbols. This is useful in multi-user
systems, and possibly
in single-user systems that are used by multiple people. Having all
sheets and
symbols in the user's home directory does add an additional step to the
installer
but it also makes the system totally customizable for and by each
user. This raises
issues about documentation and gives the possibility of a customized
leg of dia
just for making new, or modifying old, sheets & symbol libraries.
Arv
_._
On 08/01/2010 06:02 AM, Hans Breuer wrote:
At
23.07.2010 00:09, demurgets free fr wrote:
Quoting Hans Breuer<hans breuer org>:
[...]
Still, my point is: do you really need to
create multiple custom sheets (100%
custom or derived from system sheets)? This is nice, but are there any
users
really exploiting this?
Apparently there are at least two :)
This involves a lot of code, including a
startup warning dialog if the
< system
sheet is newer and if you want to
overwrite your local customizations.
To me this code complexity appears to be necessary, if the use case is
considered usefull.
That's exactly my point: you're the maintainer, so it's up to you to
choose. Do
you think this is a real use case?
Yes, I think so. And I tried to explain it in my earlier mail.
My proposal is to replace the dialog by a
simpler, "Favorites" where one would
only have one sheet on the left : "Favorites".
To me the whole Sheets & Objects dialog appears to be overkill for
a simple, single Favorites target sheet. Wouldn't just a bookmark menu
entry for objects be enough?
I'd go for that:
1) a GtkToolPalette with a default sheet set as of today (Assorted,
UML,
Flowchart), with a button to customize the Sheets displayed.
Sounds interesting, but might end up less convenient than what we have
today, at least for people often switching between lots of sheets.
Also the use of GtkToolPalette would force us to bump the required Gtk+
version to the most recent one. I'd like to keep Dia running with older
Gtk+ versions as long as feasible.
2) the palette would always contain an empty
"Favorites" section, closed by
default, with a hint saying to go to the "Favorites" dialog or
right-click add
or drag and drop an item in the section for fast access.
3) the actual sheets customization dialog would only have the Favorites
on the
left to simplify it. It would be the equivalent of drag and dropping
but easier
to discover and use with the keyboard.
4) This dialog could also feature something to download/install
additional
shapes set, from http://dia-installer.de/shapes.html for instance.
See attached (awful) mockups to make for an easier explanation.
The basis of your mockups is already an outdated version of the
Sheets&Object dialog (git master has a different button
distribution).
If you are doing patches, please create them against git master.
I'd like to improbe the UI in light of
removing deprecated widgets.
This should be basically the replacment of GtkOptionMenu with
GtkComboBox.
sorry, I meant: removing deprecated widgets is a good opportunity to
improve the
UI more deeply while we are at it.
Still I prefer manageable steps :) If for example we could not agree on
the final appearance for "Favorites" wouldn't it be nice to at least
get rid of the deprecated widgets on the way?
[...]
If I'm not mistaken, customizing system
sheets should be ruled-out, even if
they
are a lot of items.
I dont follow (although I'm only using it to shake out bugs;)).
I really hope you've understood me by now :)
In this specific point my understanding did not change. The ability to
customize system sheets and to create new sheets are IMO useful
features we should not throw away.
Creating custom sheets is nice, but you
need to write shape files.
Not really. You can just create them by the shape exporter. (Some XML
editing is still necessary to create good shapes.)
Ho, I did not know about this feature: is this File> Export as
.shape file?
Yes.
Still, this can be an option to import in the
"Favorites" section. Anyway, a
user can create a whole new sheet by editing XML files anyway.
A user can also create a Favorites sheets by editing XML files, but
that's not the point ...
The whole purpose of the Favorites is
optimizing the workflow for most of the
users.
But improving one workflow should be possible without completely
loosing other ones.
Wouldn't it make it simpler to have:
- some sort of bookmarks (a la Firefox) lying in this dialog first
*and*
accessible from a popup in the palette directly to quickly bookmark an
item
- the bookmarks go in a unique "Custom" sheet (ideally always
visible)
- when you have 1+ bookmark, you automatically get this "Custom"
sheet
Looks like a useful feature in itself, but I don't see this as
necessarily
coupled with the Sheets&Objects dialog. Although sooner or later
the user
might have more bookmarks than viable for a flat structure (one sheet).
Mhh ... I thought a bit about that, and I do not see a reason to
structure more
using 2 or more custom sheets.
Here is our fundamental disagreement. It solely depends on the number
of different sheets and objects (aka diagram types) you are using.
I'd prefer not making the current sheets
handling more complex by layering a
"Favorites" on top of it, but replacing it instead.
I think your favorites idea could well be completely independent of the
Sheets&Objects dialog.
[...]
Talking with users in LUGs, almost nobody
noticed this dialog until I talk about
it.
Yes, it is addressing advanced users.
[...]
I do not want to rush in contributing stuff
in C that's going to be frowned upon
as soon as I have proposed a patch: I'd better discuss it before :)
Fair enough.
If you do not like this proposal because it's
making the system not flexible
enough, I can understand, and I'll try to proceed with just porting the
comboboxes
first.
That would be appreciated.
For the GtkCombobox port, I'll certainly
present things differently since the
tooltip support is not really up to par vs. GtkOptionMenu.
I never noticed, but looking at
https://bugzilla.gnome.org/show_bug.cgi?id=80980
it should not be too difficult to overcome that limitation nowadays.
Thanks,
Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it. -- Dilbert
_______________________________________________
dia-list mailing list
dia-list gnome org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://live.gnome.org/Dia/Faq
Main page at http://live.gnome.org/Dia
|
