X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 7 Oct 2015 16:21:34 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] Stop playing stupid political games with gEDA
In-Reply-To: <20151007134152.9597.qmail@stuge.se>
Message-ID: <alpine.DEB.2.00.1510071600380.7137@igor2priv>
References: <201510020041 DOT t920fM6o031268 AT envy DOT delorie DOT com> <560DE183 DOT 4060305 AT jump-ing DOT de> <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>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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
Precedence: bulk



On Wed, 7 Oct 2015, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] wrote:

> gedau AT igor2 DOT repo DOT hu wrote:
>> Yes, I think GTK is a bad idea long term (for any application)
>
> Essentially you're saying that you would like a toolkit with a
> lifetime of "forever" - which I can understand, but I also think
> it is a bit unreasonable. The world changes and our software will
> need to change with it. Not much, but some, every now and then.

I am not against change, if it's driven by a real need. What I dislike is 
changing the GUI [in an app] not because we want to change it, not because 
we want to have a better GUI or want to exploit the new features, but 
because the GUI has a newer version and the old version we use is simply 
obsolete and will not be easily available in the near future.

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.

>
> We can be the most lazy if we have clever interfaces in the right
> places. The PCB hid abstraction might well be just that. Yes,
> implementation may diverge if there isn't a lot of development
> going on, that's OK, life goes on.

I fully agree. I wouldn't replace existing HIDs in pcb-rnd with a new one, 
only add the new one as an alternative.

>
>> For my own amusement I'm working on a small UI toolkit based on SDL2.
>
> That's a large project.

Yup, it's large. I've spent considerable time on it already and have some 
widgets working.

>> It'll take a long time to finish the toolkit, tho.
>
> 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++.

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 want mine to 
look the same everywhere, so leaving the backend issue to SDL looked like 
a better choice.

Before I started, I looked at what's available, especially for SDL. The 
requirements I went with:

- coded in plain C, for it's easer to port and maintaain (... for me, I 
really do not want to trigger a C vs. C++ flame war); preferrably C89 or 
C99

- supports hbox/vbox layout building

- doesn't have too many dependencies, especially not on big, largish libs

- the whole implementation is small and simple (even if it does not 
provide much eye candy or "advanced" features like docking)

- it doesn't require GL

- if it is not using SDL, it is readily available on all major platforms

Unfortunately I didn't find anything that fulfilled all these 
requirements, that's why I decided to write one. Coding GUI is not my 
favorite pass time activity, so I'm still open to find an existing project 
but I don't want to make bad compromises.


Regards,

Igor2