On Sat, Sep 17, 2005 at 02:44:43PM +0200, jiho wrote:
Here is a summary of different posts about OS X,
It appears we will be at least three doing some OS X builds (which is great!) Jonathan Chetwynd Michael Wybrow myself (Jean-Olivier Irisson by the way ;-) )
Personally, I still need CVS access:
Sure I can set him up; what's the SF id?
Bryce, my SF id is: irisson
Okay, you're added.
Instructions for building inkscape are in the wiki as Kees pointed out:
In the CVS tree, there is packaging/osx-app.sh, and in the Wiki there is http://wiki.inkscape.org/cgi-bin/wiki.pl?CompilingMacOsX
But compared to what Michael told me this wiki is out of date (and a bit of a mess in addition). I'll be glad to modify it if I am authorized to do so. I guess that the whole bottom part of the page could go in a News/History section (or even suppressed completely??) and that the top of the page could be transformed a real "How to".
No authorization is needed to update wiki pages. If you spot something that needs changed, be bold and change it. :-)
Also, if there's stuff that's no longer relevant, please delete it rather than move it into an archives. A risk with wiki's is that they can get overly cluttered; this is because sociologically it feels easier to add than to delete (and risk angering someone). However, as it grows, it will get so full of irrelevant stuff that it becomes difficult to use; information is hard to find, navigating through it takes too many clicks, and the data is misleading or confusing, so you end up not really being able to trust it.
In a previous project I was in, we used wiki quite heavily and ran headlong into this issue. We were using the wiki to manage the main website in addition to collecting random ideas and so forth. It was nice that it was easy to edit, but it quickly got so clogged with good ideas, notes, partial documentation, and so forth, that EVERYONE complained about the website, and things got really messy and contentious.
That experience was one of the reasons why with Inkscape I set things up with both a traditional cvs-based, fairly static php website, plus an auxillary wiki. This has worked well; the wiki is mostly "hidden" from the general public, so the issues of clutter have been more manageable.
However, I see the wiki being more and more relied on, and more linking from the main page into the wiki. I think this is fine, but we need to be aware that we are running the clutter risk.
I think that a good way for us to avoid the dangers is to be a bit more proactive at *deleting* stuff from the wiki. I've gone through and done some pruning a few times in the past, but would encourage others to also participate in this. Find pages that are disorderly and spend an hour or two reformatting them, copyediting the grammar and spelling, and so forth. Look for ways to make pages more consistent with each other; for example, use the same format for headings, examples, and comments across all pages. Look for ideas, requests, or documentation that hasn't changed in a long time; probably these are no longer relevant and could be removed. Find a few small pages that seem to all address the same issue, and merge them into a single comprehensive article.
Then the web site has to be changed in the development build section. I could change the downloads_en.php and eventually the french one when it comes out (or translate it myself if needed) but not the german one. I tried to catch up on the web site translation process but I didn't manage to understand everything. Did it involves .po file or is it just a matter of writing a downloads_fr.php file? To change them do I commit in cvs or do I create a patch file (now that I know how to do it thanks to the great wiki!)
I think there was a good proposal to do it via po files, which I think is going to be the right way to do it. However I don't think this procedure has been implemented yet, so currently it still requires writing a downloads_fr.php file. Obviously, if you guys want to go with the po file, this would be a good time to get that sorted out and set up.
For changing the website, yes go ahead and commit directly to CVS.
(For changing inkscape itself, currently you'd want to submit patches, since we're in feature freeze mode, but that's orthogonal to the website editing.)
Finally, I remarked that inkscape interface is very slow in OS X compared to other equally memory hungry X11 applications (like the gimp). My guess is that it's because Inkscape icons are parsed from an svg file whereas gimp icons are from png files. does anybody thinks this can be the case? if yes: 1- would it be possible to use png icons in the OS X build to make it more usable? if it is possible would it be desirable? in that case what are the changes to make? 2- do you think that "simpler" svg icons would change anything?
Heh, this is a topic that has received a lot of discussion. In short, I investigated this possibility about a year ago, and I agree that the parsing of icons from svg files is probably a performance issue during startup, and may be hogging memory that would be better saved. However, the general concensus in the previous discussion was that it was not worth the effort to change - or rather, that no one was particularly motivated to change it. Some efforts at exploring alternate approaches was explored during the gtkmm work, but those experiments ended up getting discarded for various (good) reasons.
An advantage to keeping the icons in SVG and rendering them with the Inkscape renderer at startup is that it makes it smooth and easy for developers (and users) to edit, add, and remove icons.
Anyway, I think the take away point is that it may well be the case that the icons are a performance issue, but fixing it would require a non-trivial amount of work. The reaction I got from my previous investigation into this is that in order to have changes to this be accepted, you'd need to really do your homework to show that it really is an issue, and to propose a solution that improves it without losing any of the advantages of the current system or introducing new issues. I'd love to see this changed, but certainly it would be a tough challenge to do.
Bryce