DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=sbcglobal.net;
	b=L1tHvvVzl6RDkpkPIbIP/CTVNnAzALpfkjN1L2fpzKsi+YKX0KsUMrw3hd3z1Tv7s6rQ9+q/D3+5/8t+6kn1xnM6Wt1ac8BGwxoTOtkZVofSIMfm0UIkDZmKHHydOlIwJm92i2cehOh8lYR7u/jy4H3TnqJuMC6kMRFrHS2T4cjlOQL8+dDXIyJElfW5vfj/OCTwF15yNBhcshr7ORfrDxCw8HeTWbUFTwX0DTAlHnFnqn8CLXgNl/X2cz31IpBOQjWBcO8HOq4xlGLIRSLOd2j8fXzl+WdR5tS/PM8Mjt6ZbFm7zVQAuEgTDnXJUoLaOChvIBxUKlf0lSd8T48saA==;
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [geda-user] Pin Type Dialog
From: Edward Hennessy <ehennes AT sbcglobal DOT net>
In-Reply-To: <lrplem$beb$1@ger.gmane.org>
Date: Tue, 5 Aug 2014 18:53:32 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <88F10991-84E0-4E8A-AF38-3E4E3846D764@sbcglobal.net>
References: <399B159D-C237-45F0-947B-90C91E30C7DD AT sbcglobal DOT net> <20140804105713 DOT GH24580 AT localhost DOT localdomain> <F8F84CB2-551D-4D4D-A544-56986B1442CF AT sbcglobal DOT net> <lrplem$beb$1 AT ger DOT gmane DOT org>
To: geda-user AT delorie DOT com
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk


On Aug 4, 2014, at 9:09 PM, Kai-Martin Knaak <kmk AT familieknaak DOT de> wrote:

> Edward Hennessy wrote:
> 
>> 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/

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.)

>> 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. 

>> Is there a another dialog that it could be merged into?
> 
> Yes:
> 
> * the "Single_Attribute_Editor" and the "Edit_Attributes" dialog

I'll add these to the list.

> * 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.

> * "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