www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/10/07/11:21:08

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20151007152048.17589.qmail@stuge.se>
Date: Wed, 7 Oct 2015 17:20:48 +0200
From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: "Peter Stuge \(peter AT stuge DOT se\) \[via geda-user AT delorie DOT com\]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] Toolkits
Mail-Followup-To: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
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>
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.1510071600380.7137@igor2priv>
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

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.

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 also don't think it would require much effort. Certainly less than
writing a new toolkit from scratch.

(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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019