MIME-Version: 1.0
In-Reply-To: <lrud3r$1ct$1@ger.gmane.org>
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>
	<88F10991-84E0-4E8A-AF38-3E4E3846D764 AT sbcglobal DOT net>
	<lrud3r$1ct$1 AT ger DOT gmane DOT org>
Date: Thu, 7 Aug 2014 06:26:22 +0530
Message-ID: <CALT8Ef6cXAE+rtkQfk7ZCoosdYg4VdGF1sPU-UVtckEuo8zRXg@mail.gmail.com>
Subject: Re: [geda-user] Pin Type Dialog
From: Shashank Chintalagiri <shashank DOT chintalagiri AT gmail DOT com>
To: geda-user AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

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
<knaak AT iqo DOT uni-hannover DOT de> wrote:
> Edward Hennessy wrote:
>
>>> 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!
>
>
>> 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/
>
>
>> 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.
>
>
>> 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.
>
>
>> 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.
>
>
>>> * 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.
>
> So a git pull of the current git head would already give me this
> improvement?
>
>
>> 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
>
>
>


-- 

Chintalagiri Shashank
Indian Institute of Technology, Kanpur

http://blog.chintal.in