X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=hAhnoSGXe0e13QwZF2Wn6an0HSqdHHr4sCC6VFkByts=;
	b=t01EUJgXWAUt9SvM3vXGXrR+HAEHfX6RA2qXnik3fH0IrmCPLk8XxS9k6RaE2WHL93
	PBqN+FCK+4Nt6/bY0FG/Wcw3lvCLHGIEnJGI5E5uCczWLawb2TlWSVazP1+SoGoRdUz7
	EMZXooo8KTNZ04yRiruEpoEE2JnwHsTVEvYUTFoqguWZkPVz7GsgqGCjfsASnKIDZ83W
	uld5ZW4HjY6rtbKO3QNrpHVFBhknXi6ubuvbMPbUB+KX1gtGSfUNi/oN1M4lnBlcOwMP
	S8YMKfReTG2NV29KWty3vnH0PAzCkcsB3fKwC+Lj2d2PyyGvHYHcgbFoqxVzuTeYBGl0
	r3iQ==
MIME-Version:	1.0
X-Received:	by 10.112.134.73 with SMTP id pi9mr911596lbb.83.1444232079063;
	Wed, 07 Oct 2015 08:34:39 -0700 (PDT)
In-Reply-To:	<20151007152048.17589.qmail@stuge.se>
References:	<5BF9C4DF-32C7-4C06-9F96-8F82C935254E AT sbcglobal DOT net>
	<560EAEE1 DOT 6020701 AT jump-ing DOT de>
	<3E72AC35-5862-41B9-A8FD-6804E89E9FFB AT sbcglobal DOT net>
	<20151003210144 DOT GA21262 AT localhost DOT localdomain>
	<56104E16 DOT 3050006 AT jump-ing DOT de>
	<20151003222928 DOT GC4287 AT localhost DOT localdomain>
	<CAM2RGhSuaNy3PQ7CJJjTbzTM6TckNGRShobchRj42Vk10ixPGQ AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1510040356140 DOT 7137 AT igor2priv>
	<20151007134152 DOT 9597 DOT qmail AT stuge DOT se>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1510071600380 DOT 7137 AT igor2priv>
	<20151007152048 DOT 17589 DOT qmail AT stuge DOT se>
Date:	Wed, 7 Oct 2015 11:34:39 -0400
Message-ID:	<CAM2RGhQK=BQWH1BP78dWAKZ=7L7-Ga3ZDDeam1ON72Q89=GAUg@mail.gmail.com>
Subject:	Re: [geda-user] Toolkits
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	gEDA users mailing list <geda-user AT delorie DOT com>
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, Oct 7, 2015 at 11:20 AM, Peter Stuge (peter AT stuge DOT se) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> gedau AT igor2 DOT repo DOT hu wrote:
>> What I dislike is changing the GUI [in an app] .. because the GUI
>> has a newer version
>
> I agree with you here, I don't think the mere availability of a new
> product (toolkit) is a good reason to start using it. My threshold
> for the value of being "modern" is rather high - it takes a lot more
> than just availability.
>
> Others will have a different emotional response, they will feel that
> it's very important to use the latest and greatest. The only thing we
> must keep in mind is that we need to work hard so that neither group
> gets to block the other, because there is no technical reason to do
> so. (I don't think there's a problem with this in pcb.)
>
>
>> and the old version we use is simply obsolete and will not be
>> easily available in the near future.
>
> This is full of uncertanity, and has a passive consumer perspective
> regarding the toolkit.
>
> Your approach to DIY a toolkit is the other extreme, an active
> producer perspective.
>
> There is at least one more way, in between the two: If at some point
> gtk2 is no longer easily available but we still want to use it then
> *we* can make it available. We can even go so far as bundle it into
> our source tarballs. That's not ideal, but nothing ever is.

That bloats our stuff a lot because you will need all of GTK2
including a lot of its dependencies. Keep in mind we want to package
binaries for distros to use. So that is a lot of waisted space.

> I am quite sure that we would not be the only group of developers who
> had this problem, and I think we would get lots of unexpected help if
> we took responsibility for maintaining a legacy gtk2 package. :)

I think this is being smarter than other people.

> I also don't think it would require much effort. Certainly less than
> writing a new toolkit from scratch.

libgeda has it's own problems and changing them always starts a war.

> (Please note, I don't want to discourage your effort, and I know that
> it's also for fun, go for it, I think your goals and design decisions
> are good.)
>
>
>> I,  also find it unsustainable long term that GUI libs get more and more
>> complex potentially causing application developers to spend more and more
>> time on just keeping up with their changes. I know this is an unpopular
>> opinion, especially from end user's perspective.
>
> Oh I don't know, yes "modern" is a value, but someone has to pay for it,
> I think users realize that.
>
>
>>> Yes. Did you look into fltk and solvespace?
>>
>> Thanks for the ideas.
>>
>> I did look at fltk, but I didn't consider solvespace.
>>
>> Both fltk and solvespace are written in C++ and I'd like to avoid C++.
>
> Oh, I didn't consider that. If fltk is otherwise a good fit then maybe
> a wrapper creating a C API would be a managable (still boring) effort?
>
>
>> They both seem to have their own frontends to X and win32, etc. It's a
>> good choice especially if you want the GUI to look native.
>
> I think only the drawing is abstracted in fltk, but each widget still
> draws itself.
>
> Solvespace certainly has its own UI look.
>
>
> //Peter



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

- Raw text -