Re: gEDA-user: gschem with cairo rendering

[Kai-Martin Knaak <kmk@xxxxxxxxxxxxxxx>]

On Mon, 05 May 2008 17:57:32 -0400, Stuart Brorson wrote:

> I suggest a target of ${DATE} - 4 years, which is pretty conservative,
> but reflects the update cycle of many desktop users. That is, whatever
> was prevelant on the usual distros 4 years ago should be our "lowest
> common denominator".

You suggest to target desktop users that use a distro, but choose to not 
update their system for the entire life time of the box. I don't know any 
non-windows user with such an attitude. Ease of update is one of the main 
benefits of sticking to a distro. For the sake of the argument, lets 
assume, there is a relevant population of this kind among the geda users. 
You imply, that these very users, who choose to live with dated versions 
of applications on their desktop wish to run the bleeding edge version of 
geda. Why would they? Wouldn't it be much more likely they simply 
continue to use the version of geda found in their dated distro?

Unless the file format is changed such that old versions of geda can't 
deal with files produced by the bleeding edge build, I see no reason why 
a user who chooses to use a dated system should not use a dated geda.

That said, geda (and pcb) should make sure, their bleeding edge version  
only depends on libs currently readily available for the targeted OSes. 
This includes of course, various unix flavors already mentioned in this 
thread. It should also include at least one of the possible ways to do a 
MS-Win version. 


> Of course, if developers want to include newer libraries into the code,
> then they can -- but must make sure their stuff is off by default.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
For what reason? 
New stuff should be on by default as it likely represents an improvement 
to the majority of users. If it doesn't, it should not have been pushed 
in the fist place. Features not activated by default at compile time are 
next to non-existent. 

If there is a relevant portion of target systems where some libs are not 
readily available, then the configure should set a flag and issue a note 
in the summary. 


> The point is that it's too easy for a developer to make libfoo a
> dependency for a project in order to get some shiny, whizzy feature. But
> if libfoo is experimental and not widely distributed in stock distros,

I have no problem with this general statement. However, it does not apply 
to the case this thread is about. Both, cairo and freetype are far from 
experimental, but widely adapted. This is 2008, not 2004 when cairo was 
proposed to enter the infrastructure of gnome. Both libs are definitely 
not linux only. To the contrary, cairo and freetype are both successful 
efforts to provide features independent of OS. 

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



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user