[geda-user] Pin Type Dialog

Post by Edward Hennessy
When converting the pin type dialog into a non-modal and
instant-apply, it doesn't seem like a single setting should be in a
dialog box by itself.

Ack.

Post by Edward Hennessy
Should it be merged into the color/line type/fill type dialog?

Yes, please.

Just my two cents from user perspective.

---<)kaimartin(>---

Vladimir Zhbanov

2014-08-04 10:57:13 UTC

Post by Edward Hennessy
All,
When converting the pin type dialog into a non-modal and
instant-apply, it doesn't seem like a single setting should be
in a dialog box by itself.

Why not?

Post by Edward Hennessy
Should it be merged into the
color/line type/fill type dialog? If not, what should it be
merged with?

I think no. I see no reason to merge pin settings with anything
else. Pins have no properties appropriate to other primitives and
vice versa.

Edward Hennessy

2014-08-04 16:53:11 UTC

Sent from my iPhone

Post by Vladimir Zhbanov

Post by Edward Hennessy
When converting the pin type dialog into a non-modal and
instant-apply,
Should it be merged into the
color/line type/fill type dialog? If not, what should it be
merged with?

I think no. I see no reason to merge pin settings with anything
else. Pins have no properties appropriate to other primitives and
vice versa.

Non-modal dialogs can be left open during the entire session while editing schematics. I believe the issue becomes the number of mon-modal dialogs open at the same time, and the inconvenience for the user to arrange/manage them.

Is there a another dialog that it could be merged into?

Ed

Vladimir Zhbanov

2014-08-04 18:31:41 UTC

On Mon, Aug 04, 2014 at 09:53:11AM -0700, Edward Hennessy wrote:
...

Post by Edward Hennessy
Non-modal dialogs can be left open during the entire session while
editing schematics. I believe the issue becomes the number of
mon-modal dialogs open at the same time, and the inconvenience for the
user to arrange/manage them.
Is there a another dialog that it could be merged into?

The pin type editing dialog is rarely used. I don't see a point why it
should be always open. (I may be wrong, but I don't even consider the
"bus pin" to be somewhere useful.)

I like the way dialogs are done in inkscape. Any different settings have
appropriate dialogs which you can attach to the main window. And the
toolbar shown, which depends on the active tool, has the mostly required
settings.

In general, I think 'bus pins' and 'net pins' should be separate
objects, the same way as buses and nets are different.

Edward Hennessy

2014-08-05 04:50:33 UTC

Post by Vladimir Zhbanov
...

The pin type editing dialog is rarely used. I don't see a point why it
should be always open. (I may be wrong, but I don't even consider the
"bus pin" to be somewhere useful.)

I haven't used busses or bus pins in gEDA.

I think the pin types need to be exposed in a consistent GUI format,
until the functionality is changed (or removed) in the future.

The new dialogs provide expander widgets to hide sections. I can look
at using the mechanism that stores dialog locations to also store the
preference to keep sections hidden for the users that don't need them.
This way, the for the users that don't need the pin type, it will
remain hidden.

Cheers,
Ed

Vladimir Zhbanov

2014-08-05 05:11:54 UTC

On Mon, Aug 04, 2014 at 09:50:33PM -0700, Edward Hennessy wrote:
...

Post by Edward Hennessy
I think the pin types need to be exposed in a consistent GUI format,
until the functionality is changed (or removed) in the future.

Agreed.

Post by Edward Hennessy
The new dialogs provide expander widgets to hide sections. I can look
at using the mechanism that stores dialog locations to also store the
preference to keep sections hidden for the users that don't need them.
This way, the for the users that don't need the pin type, it will
remain hidden.

This would be nice.

Kai-Martin Knaak

2014-08-05 04:09:57 UTC

Post by Edward Hennessy
Non-modal dialogs can be left open during the entire session while
editing schematics.

ack.
Modal dialogs are considered inferior UI style since at least the
start of the century. Along the same lines, "apply" buttons are
discouraged. See for example the Gnome2 Human Interface Guidelines
(HIG).
https://developer.gnome.org/hig-book/stable/

Post by Edward Hennessy
I believe the issue becomes the number of
mon-modal dialogs open at the same time, and the inconvenience for
the user to arrange/manage them.

That's why most drawing applications use dedicated areas rather than
separate dialogs these days.

Post by Edward Hennessy
Is there a another dialog that it could be merged into?

Yes:

* the "Single_Attribute_Editor" and the "Edit_Attributes" dialog

* the "Edit_Text_Properties", the "Edit_Line_Width&Type", the
"Colour_Edit" and the "Edit_Fill_Type" dialog should be merged into a
generalized properties dialog.

* "Find Specific Text", "Show Specific Text", "Hide_Specific_Text"

While at it, the "Text_Entry" dialog should be replaced by in-place
editing.

---<)kaimartin(>---

Girvin Herr

2014-08-05 19:28:25 UTC

On 08/04/2014 09:09 PM, Kai-Martin Knaak wrote:
<snip>

Post by Kai-Martin Knaak
While at it, the "Text_Entry" dialog should be replaced by in-place
editing. ---<)kaimartin(>---

+1
wysiwyg is much preferable than hit-and-miss text placement on a
drawing. Especially when the text is more than one line, as in notes.
i.e. - Where is the right margin located in the current dialog? You
don't know until the dialog is closed. In-place editing would solve that.

Then, pet peeve #2: maybe the printed text could match the text entries
on the drawing, instead of overlapping and needing "adjustment"?!
Again, wysiwyg is needed.
Girvin Herr

Edward Hennessy

2014-08-06 01:53:32 UTC

Post by Edward Hennessy
Non-modal dialogs can be left open during the entire session while
editing schematics.

I'm currently using section 3.3.1 as guidelines for these windows.

However, I couldn't get a mechanism to instant-apply from a TextView
widget. Unfortunately, that individual widget still has an apply
at the moment. It looks like the next step to get rid of the apply
button is a custom keypress filter.

What should the behavior be? (e.g. Shift return inserts a newline
into the text; Return applies the content to the schematic.)

Post by Edward Hennessy
I believe the issue becomes the number of
mon-modal dialogs open at the same time, and the inconvenience for
the user to arrange/manage them.

That's why most drawing applications use dedicated areas rather than
separate dialogs these days.

I'm all for docking these windows into the main window, but we would
need to pull in another external dependency. If we limit it to two
panes, we might be able to get by with a GtkPaned.

If we can reach an agreement on adding the external dependency that
contains this functionality, I can make the dialogs work with it.

Post by Edward Hennessy
Is there a another dialog that it could be merged into?

* the "Single_Attribute_Editor" and the "Edit_Attributes" dialog

I'll add these to the list.

Post by Kai-Martin Knaak
* the "Edit_Text_Properties", the "Edit_Line_Width&Type", the
"Colour_Edit" and the "Edit_Fill_Type" dialog should be merged into a
generalized properties dialog.

The last three have been merged and checked into source control.

The text properties is still a separate dialog with a text view to
edit the content of the text. With in place text editing, it seems
logical to move it to the general properties dialog. My opinion is
to leave it separate until the in-place editing is available.

Post by Kai-Martin Knaak
* "Find Specific Text", "Show Specific Text", "Hide_Specific_Text"
While at it, the "Text_Entry" dialog should be replaced by in-place
editing.

I can't commit to these at this time.

Cheers,
Ed

Britton Kerin

2014-08-06 04:52:30 UTC

Post by Edward Hennessy
Non-modal dialogs can be left open during the entire session while
editing schematics.

I'm currently using section 3.3.1 as guidelines for these windows.
However, I couldn't get a mechanism to instant-apply from a TextView
widget. Unfortunately, that individual widget still has an apply
at the moment. It looks like the next step to get rid of the apply
button is a custom keypress filter.
What should the behavior be? (e.g. Shift return inserts a newline
into the text; Return applies the content to the schematic.)

Gnumeric uses alt-enter to insert a newline into a cell. I don't know how
widespread that behavior is accross gtk/gnome apps.

Britton

Kai-Martin Knaak

2014-08-06 23:18:19 UTC

Post by Kai-Martin Knaak
discouraged. See for example the Gnome2 Human Interface Guidelines
(HIG).
https://developer.gnome.org/hig-book/stable/

I'm currently using section 3.3.1 as guidelines for these windows.

:-)
Looking forward to the results!

Post by Edward Hennessy
However, I couldn't get a mechanism to instant-apply from a TextView
widget

glabels is a fairly simple gtk application that manages to instantly
update the view of text. Its source may be worth a peek
http://glabels.sourceforge.net/download/

Post by Edward Hennessy
What should the behavior be? (e.g. Shift return inserts a newline
into the text; Return applies the content to the schematic.)

If instant apply is no option, then this would be my preferred mode. You
may add a tool tip somewhere at the bottom of the dialog. Or even better:
a button that brings up a concise help page. There may be more hidden
features and tricks.

Post by Edward Hennessy
I'm all for docking these windows into the main window, but we would
need to pull in another external dependency. If we limit it to two
panes, we might be able to get by with a GtkPaned.

In my humble opinion, the number or size of dependencies is not
necessarily the relevant metric. It is their quality in terms of
portability, availability and dependability. A lib that is used by many
major cross OS projects will most likely pose no additional load to geda
users and maintainers. By contrast, lib that lacks such a large user base
may be problematic. Unfortunately, this is the case with guile2. It does
not readily crosscompile. So it currently represents a road block to the
release of an up-to-date windows version of geda/gaf.

Post by Edward Hennessy
If we can reach an agreement on adding the external dependency that
contains this functionality, I can make the dialogs work with it.

Looking at the dependencies of glabels, I guess, that in this case
libgtk3 does the trick. However, gtk3 is not in the list of packages that
the cross compile environment mxe supports out of the box.
http://mxe.cc/#packages
Since one of my projects is to host a windows installer of the geda suite,
I'd be grateful, if additional dependencies were picked from this list.

Post by Kai-Martin Knaak
* the "Single_Attribute_Editor" and the "Edit_Attributes" dialog

I'll add these to the list.

Post by Kai-Martin Knaak
* the "Edit_Text_Properties", the "Edit_Line_Width&Type", the
"Colour_Edit" and the "Edit_Fill_Type" dialog should be merged into a
generalized properties dialog.

The last three have been merged and checked into source control.

So a git pull of the current git head would already give me this
improvement?

Post by Edward Hennessy
The text properties is still a separate dialog with a text view to
edit the content of the text. With in place text editing, it seems
logical to move it to the general properties dialog. My opinion is
to leave it separate until the in-place editing is available.

Fair enough.
There still may be a way to improve the user experience. Currently, free
text and attributes behave differently on "EE". When issued on free text,
the "Edit_Text_Properties" dialog pops up and allows me to manipulate
color, size and alignment. The same command on an attribute pops the
"Single_attribute_editor", which just deals with the text string and
visibility. If I want to edit color, size and alignment, I have to type
"EX".
I see students get mildly frustrated by this difference.

Again, I am happy to see the GUI evolve for the better!

---<)kaimartin(>---

--
Kai-Martin Knaak tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211
Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de
GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get

Shashank Chintalagiri

2014-08-07 00:56:22 UTC

My 2 cents, possibly somewhat off-topic.

I've always felt that some sort of 'Attribute Painter' tool could come
in handy - with or without a dialog of it's own. There have been times
when I've had to make a consistent change across attributes of many
components. This could be something along the line of the autonumber
text feature, or built in together. Having something of that sort
could be useful for pin types as well, as long as the interface,
whether modal or not, can be kept sufficiently generic.

On Thu, Aug 7, 2014 at 4:48 AM, Kai-Martin Knaak

Post by Kai-Martin Knaak
discouraged. See for example the Gnome2 Human Interface Guidelines
(HIG).
https://developer.gnome.org/hig-book/stable/

I'm currently using section 3.3.1 as guidelines for these windows.

:-)
Looking forward to the results!

Post by Edward Hennessy
However, I couldn't get a mechanism to instant-apply from a TextView
widget

glabels is a fairly simple gtk application that manages to instantly
update the view of text. Its source may be worth a peek
http://glabels.sourceforge.net/download/

Post by Edward Hennessy
What should the behavior be? (e.g. Shift return inserts a newline
into the text; Return applies the content to the schematic.)

If instant apply is no option, then this would be my preferred mode. You
a button that brings up a concise help page. There may be more hidden
features and tricks.

Post by Edward Hennessy
If we can reach an agreement on adding the external dependency that
contains this functionality, I can make the dialogs work with it.

Post by Kai-Martin Knaak
* the "Single_Attribute_Editor" and the "Edit_Attributes" dialog

I'll add these to the list.

Post by Kai-Martin Knaak
* the "Edit_Text_Properties", the "Edit_Line_Width&Type", the
"Colour_Edit" and the "Edit_Fill_Type" dialog should be merged into a
generalized properties dialog.

The last three have been merged and checked into source control.

So a git pull of the current git head would already give me this
improvement?

Fair enough.
There still may be a way to improve the user experience. Currently, free
text and attributes behave differently on "EE". When issued on free text,
the "Edit_Text_Properties" dialog pops up and allows me to manipulate
color, size and alignment. The same command on an attribute pops the
"Single_attribute_editor", which just deals with the text string and
visibility. If I want to edit color, size and alignment, I have to type
"EX".
I see students get mildly frustrated by this difference.
Again, I am happy to see the GUI evolve for the better!
---<)kaimartin(>---
--
Kai-Martin Knaak tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211
Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de
GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get

--
Chintalagiri Shashank
Indian Institute of Technology, Kanpur

http://blog.chintal.in

Edward Hennessy

2014-08-07 16:08:42 UTC

Post by Edward Hennessy
What should the behavior be? (e.g. Shift return inserts a newline
into the text; Return applies the content to the schematic.)

If instant apply is no option, then this would be my preferred mode. You
a button that brings up a concise help page. There may be more hidden
features and tricks.

Ok, I'll add these to the list.

I agree.

Post by Edward Hennessy
If we can reach an agreement on adding the external dependency that
contains this functionality, I can make the dialogs work with it.

I'll look into this more, later.

Post by Kai-Martin Knaak
* the "Edit_Text_Properties", the "Edit_Line_Width&Type", the
"Colour_Edit" and the "Edit_Fill_Type" dialog should be merged into a
generalized properties dialog.

The last three have been merged and checked into source control.

So a git pull of the current git head would already give me this
improvement?

Yes. I've got the following items done, so far:

- Line, fill and color dialogs are merged, non-modal and instant-apply.
- Text properties is non-modal and instant-apply.
- Snap size is non-modal and instant apply.
- Grid mode and snap mode have been added to the snap size dialog and instant-apply.