In the spirit of "patch first, ask later", I have edited the intro paragraphs at inkscape.org: added new features, removed mention of GTKmm (it's on hold, and in any case this is a too narrow technical aspect to deserve a front page mention), added more emphasis on usability and general availability (it's not for "open source community", it's for everyone!) and did a general copyedit. Feel free to change :)
Please restore mention of gtkmm. You may not put any value into it or people working on it, but some of us do. It is not on hold, and it is a major change that affects developers and users.
Bryce
On Wed, Aug 24, 2005 at 06:13:10PM -0300, bulia byak wrote:
In the spirit of "patch first, ask later", I have edited the intro paragraphs at inkscape.org: added new features, removed mention of GTKmm (it's on hold, and in any case this is a too narrow technical aspect to deserve a front page mention), added more emphasis on usability and general availability (it's not for "open source community", it's for everyone!) and did a general copyedit. Feel free to change :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 8/24/05, Bryce Harrington <bryce@...260...> wrote:
Please restore mention of gtkmm. You may not put any value into it or people working on it, but some of us do. It is not on hold, and it is a major change that affects developers and users.
Bryce, you seem to be oversensitive to this. I don't think I'm doing anything that could be described like this. You seem to be reading too much into my words, again :(
As for the front page, I'm strongly of the opinion that the second paragraph on the project front page is a wrong place for mentioning the language and/or the toolkit of the program (a user-oriented program, not a development tool). Especially when it mentions conversion between two scary sounding language/toolkit pairs, adding to the confusion. For most users this is just a meaningless alphabet soup.
Any other opinions?
On 8/24/05, bulia byak <buliabyak@...400...> wrote:
Especially when it mentions conversion between two scary sounding language/toolkit pairs, adding to the confusion.
And especially when these paragraphs never mention Inkscape being a fork, so the idea of a "conversion" sounds especially puzzling to a new visitor. Why do they need to "convert" anything in the first place? Why didn't they build it the right way from the beginning?
bulia byak wrote:
On 8/24/05, Bryce Harrington <bryce@...260...> wrote:
Please restore mention of gtkmm. You may not put any value into it or people working on it, but some of us do. It is not on hold, and it is a major change that affects developers and users.
Bryce, you seem to be oversensitive to this. I don't think I'm doing anything that could be described like this. You seem to be reading too much into my words, again :(
As for the front page, I'm strongly of the opinion that the second paragraph on the project front page is a wrong place for mentioning the language and/or the toolkit of the program (a user-oriented program, not a development tool). Especially when it mentions conversion between two scary sounding language/toolkit pairs, adding to the confusion. For most users this is just a meaningless alphabet soup.
Any other opinions?
I personally think that given the nature of OSS, it does tend to make sense to mention the toolkits/languages involved. BUT, in looking at a couple other big OSS projects, namely GAIM & GIMP, they don't mention that stuff on the front page... and if GIMP especially (the "mother" of gtk) doesn't say what it uses on the front page, do we really need to? I think we should have a link to a page all about the transition from C to C++ and gtk to gtkmm though. I personally put a lot of value in it (and I really think Bulia does too), but I don't know that anything other than a link to a "transition status" page is appropriate for the homepage. In the end, gtkmm will make all of our lives easier, and we all value it... but it's just a different priority for different people (high priority to me, but I'm still useless at converting the existing stuff... but I can whip up a "Hello World" for ya though ;)).
To sum it up, a link to a transition status page is my solution... Just my .02
Oh, and just FYI for everyone, I'm preparing the "literature" to post this evening to start the website redesign (head, footer, and maybe other CSS) contest...
-Josh
On Wed, Aug 24, 2005 at 06:52:20PM -0300, bulia byak wrote:
On 8/24/05, Bryce Harrington <bryce@...260...> wrote:
Please restore mention of gtkmm. You may not put any value into it or people working on it, but some of us do. It is not on hold, and it is a major change that affects developers and users.
Bryce, you seem to be oversensitive to this. I don't think I'm doing anything that could be described like this. You seem to be reading too much into my words, again :(
That may be, however there have been multiple opportunities to either express support or not about gtkmm, and you generally choose to express disfavor or reservations, so if I have misinterpreted your intent, it is due to the way you've expressed yourself previously. For example, while not all of the gtkmm work was completed for 0.42, there was a huge amount of work put into it, yet in the ReleaseNotes mention of it was reduced to merely a very brief mention of it at the very end of the notes. This is despite the fact that gtkmm was advertised as the primary objective for 0.42.
Also, I don't know why you referred to gtkmm as "on hold", because a lot of dialog gtkmm work was done and new dialogs are being developed with gtkmm. For instance, David Yip has converted some of the old Inkboard Gtk dialogs to Gtkmm. I'm also still working on the rest of the gtkmm infrastructure, just that I'm doing it in the background; I checked in a slew of changes for it early just few weeks ago. I just am no longer working on it as a primary focus, because I wanted to give attention to the 0.42 release, hooking up the donation system, setting up a testing effort, etc. The work is not on hold, it's just not being given as much visibility anymore.
As for the front page, I'm strongly of the opinion that the second paragraph on the project front page is a wrong place for mentioning the language and/or the toolkit of the program (a user-oriented program, not a development tool). Especially when it mentions conversion between two scary sounding language/toolkit pairs, adding to the confusion. For most users this is just a meaningless alphabet soup.
I know that as you mention, you personally care to only report things that will affect users directly, however I am strongly of the opinion that when you do this, you inadvertantly discourage work on other important areas that are less user-facing.
Remember that our audience is not only users, but also to people who contribute to Inkscape. In fact, I would argue that our primary audience is *only* people who contribute to inkscape in some form. (Essentially, if you trace the economics of where value comes from in an open source product, it's not in the form of money from users purchasing the software, but in the form of patches/bug reports/docs/suggestions from users and developers.)
Thus I think that advertising of internal changes such as gtkmm, DOM, code cleanup, refactoring work, language conversion, infrastructure change, etc. is just as important as features that impact users.
I guess my major issue is not so much that you don't care for the gtkmm work, but the worry that there may be many other really important internal work that people are doing that is getting suppressed because it is considered "non user facing".
I don't care about scaring away users or not; they'll use the program if it's useful to them, or they won't, and it doesn't cost me or you in any tangible way. Scaring away or discouraging developers is much more important, though, because if they go away, then when you need them to do packaging, or bug fixing, or answering questions about work they did, they won't be there, and it will be that much more trouble for the rest of us.
The risk is that if user facing areas are the only places where appreciation is shown, the project structure will adjust such that developers only work on user facing things, and that necessary underlying or structural work will not receive adequate encouragement, and thus may not get done.
Also, I would encourage you to take note of things that people mention about Inkscape in blog posts, magazine articles, and so forth. Yes, it is true that they remark about the new features, but they have also commented about language, toolkit, and so forth. So I don't think you can make blanket statements that it is meaningless to most users...
Bryce
Bryce
Just wanted to point out that other projects have a clear seperation of the developer pages. Not only does it give ordinary users a clearer message (what is inkscape? where to get it? and other news.) it also allows developers to skip straight to the raw information they really want. As Inkscape grows larger developer.inkscape.org [1] might be in order but in the meantime another page at inkscape.org/developer/ [2] might be a good for you to clarify things and draw more attention to important developer issues. I'm sure you and Bulia will an appropriate way to achieve both your goals.
Sincerely
Alan Horkan
[1] The GNU Image Manipulation program developers do this [2] The AbiSource Developers do this (but I am a little surprised they dont also make use of [1]).
On 8/24/05, Bryce Harrington <bryce@...260...> wrote:
That may be, however there have been multiple opportunities to either express support or not about gtkmm, and you generally choose to express disfavor or reservations, so if I have misinterpreted your intent, it is due to the way you've expressed yourself previously.
I generally just don't comment on this - it's not my domain, I cannot comment on everything. And naturally, when I do comment on it, this means it somehow crossed my way. It's not because I "do not put value in it". Absolutely the same situation, for example, is with makefiles or packaging - myself I'm unable to touch them at all and so never comment on them, _except_ when someone breaks something that I notice.
For example, while not all of the gtkmm work was completed for 0.42, there was a huge amount of work put into it, yet in the ReleaseNotes mention of it was reduced to merely a very brief mention of it at the very end of the notes. This is despite the fact that gtkmm was advertised as the primary objective for 0.42.
In Inkscape, everyone writes release notes for his/her stuff. I NEVER edited others' stuff out, I just made it more readable sometimes. And I spent a lot of energy asking people to write up their stuff. You were absolutely free to write as much about GTKmm as you saw fit.
Also, I don't know why you referred to gtkmm as "on hold"
Based on nothing else but your own announcement that the gtkmm work planned for 0.42 is not completed and will be postponed. Sorry if I misunderstood that.
I know that as you mention, you personally care to only report things that will affect users directly, however I am strongly of the opinion that when you do this, you inadvertantly discourage work on other important areas that are less user-facing.
If I _don't_ mention gtkmm on the front page, I don't think I'll discourage anyone from anything. But if I _do_, I will likely scare away some users.
Remember that our audience is not only users, but also to people who contribute to Inkscape.
Sure, but even if I'm developer, the first thing I'm interested in is what kind of project this is and what it can do. Based on that, I will decide whether to contribute or not. I don't think people contribute to Inkscape because they want to work on gtkmm; they do this because they like the program.
Thus I think that advertising of internal changes such as gtkmm, DOM, code cleanup, refactoring work, language conversion, infrastructure change, etc. is just as important as features that impact users.
Sure, but not up front. These two paragraphs were copypasted entirely in a LOT of places (do a google search), simply because it's the easiest way to add a blurb on Inkscape, and I'm sure 99% of people who quoted this had no idea of what gtkmm is, nor did their readers. So we were just contributing to the entropy of the universe :)
I guess my major issue is not so much that you don't care for the gtkmm work, but the worry that there may be many other really important internal work that people are doing that is getting suppressed because it is considered "non user facing".
I'm not "suppressing" anything. We're just dicussing the top of the front page contents, nothing else.
I don't care about scaring away users or not; they'll use the program if it's useful to them, or they won't, and it doesn't cost me or you in any tangible way. Scaring away or discouraging developers is much more important, though, because if they go away, then when you need them to do packaging, or bug fixing, or answering questions about work they did, they won't be there, and it will be that much more trouble for the rest of us.
I would say that if we scare away users, we scare away developers too. Nobody likes to work when his work is unused. Getting a huge userbase is one way to lure developers, if only because they would be honored to work for such a visible project.
On Thu, Aug 25, 2005 at 12:38:54AM -0300, bulia byak wrote:
I generally just don't comment on this - it's not my domain, I cannot comment on everything. And naturally, when I do comment on it, this means it somehow crossed my way. It's not because I "do not put value in it". Absolutely the same situation, for example, is with makefiles or packaging - myself I'm unable to touch them at all and so never comment on them, _except_ when someone breaks something that I notice.
I understand, however it is often useful to comment even on areas you don't normally touch if only to encourage the people who are working on those areas you you can continue not having to worry about it.
Also, I don't know why you referred to gtkmm as "on hold"
Based on nothing else but your own announcement that the gtkmm work planned for 0.42 is not completed and will be postponed. Sorry if I misunderstood that.
Yes, it was postponed until after 0.42, but I've continued work on it subsequent to the release. I've not really made much mention of it, so it was probably natural to misunderstand it.
I know that as you mention, you personally care to only report things that will affect users directly, however I am strongly of the opinion that when you do this, you inadvertantly discourage work on other important areas that are less user-facing.
If I _don't_ mention gtkmm on the front page, I don't think I'll discourage anyone from anything. But if I _do_, I will likely scare away some users.
I would assume the opposite to be honest. Besides, with the mention of XML, SVG, CSS, W3C, PNG, etc. whether gtkmm or C++ is listed there seems like it wouldn't make much difference. If the user is so weak as to be scared off by acronyms, they'll have been scared off long before they'd hit gtkmm. ;-)
Honestly, though, I think from a marketing perspective this qualifies as microoptimization. ;-) If there desire is to maximize users, then there are things that can be done that would have a much bigger effect on userbase size. (In fact, there is a possible opportunity I've learned of which may increase our userbase quite dramatically.)
I guess my major issue is not so much that you don't care for the gtkmm work, but the worry that there may be many other really important internal work that people are doing that is getting suppressed because it is considered "non user facing".
I'm not "suppressing" anything. We're just dicussing the top of the front page contents, nothing else.
Pretend that you *did* actually care about what widgetset, language, etc. the code was implemented in. For example, imagine you are a company considering contributing code to the project but need to find out if your code is going to be compatible with Inkscape. Now start from the current http://www.inkscape.org page and see how far you'd need to navigate to find this information.
I would say that if we scare away users, we scare away developers too. Nobody likes to work when his work is unused. Getting a huge userbase is one way to lure developers, if only because they would be honored to work for such a visible project.
Nah, you hardly ever hear from users you've scared away; you hear from users who have joined and are happy with it. I would argue that the more important point is that developers feel that their work will get attention, even if they are not working on user-visible features.
Also, for the purposes of gaining developers, I think it is more important for an open source project to appear developer-friendly than for it to have a huge userbase. Yes, large userbases can attract developers, but only to an extent; consider how many large projects there are out there that lack sufficient developer attention. If we focus on gaining developers and making them feel welcome, as we have, then gaining a large userbase will occur automatically, which is exactly what has happened. :-)
In any case, if our goal is to gain users, there are other approaches which would be much more effective. If this is the only reason for removing "gtkmm" and "C++" from the top of the main page, I don't think it is a strong enough reason. Unless and until someone puts together a dedicated developer.inkscape.org as Alan suggested, I think these things should be restored to our main page, or at least be added near the top of the FAQ.
Bryce
On 8/25/05, Bryce Harrington <bryce@...260...> wrote:
If I _don't_ mention gtkmm on the front page, I don't think I'll discourage anyone from anything. But if I _do_, I will likely scare away some users.
I would assume the opposite to be honest. Besides, with the mention of XML, SVG, CSS, W3C, PNG, etc. whether gtkmm or C++ is listed there seems like it wouldn't make much difference.
There IS much difference. The acronyms of formats and standards are one thing. Everyone has at least heard them. The (much longer and scarier, with weird capitalization and punctuation) "C++/GTKmm" is quite another. Besides it talks about "conversion" which adds to the confusion, as I explained.
Honestly, though, I think from a marketing perspective this qualifies as microoptimization. ;-) If there desire is to maximize users, then there are things that can be done that would have a much bigger effect on userbase size. (In fact, there is a possible opportunity I've learned of which may increase our userbase quite dramatically.)
I'd be interested to hear.
Pretend that you *did* actually care about what widgetset, language, etc. the code was implemented in.
Why pretend? I do care about them.
For example, imagine you are a company considering contributing code to the project but need to find out if your code is going to be compatible with Inkscape. Now start from the current http://www.inkscape.org page and see how far you'd need to navigate to find this information.
That's a completely different question - how easy it is to find information on our site. We're not discussing that at the moment. If that interested company quits after reading the first two paragraphs on the front page, I'd say it wasn't really interested to start with.
Also, for the purposes of gaining developers, I think it is more important for an open source project to appear developer-friendly than for it to have a huge userbase. Yes, large userbases can attract developers, but only to an extent; consider how many large projects there are out there that lack sufficient developer attention. If we focus on gaining developers and making them feel welcome, as we have, then gaining a large userbase will occur automatically, which is exactly what has happened. :-)
OK, let's make a deal. I will try to never scare away developers (not that I ever did, really) and you try to never scare away users :)
In any case, if our goal is to gain users, there are other approaches which would be much more effective. If this is the only reason for removing "gtkmm" and "C++" from the top of the main page, I don't think it is a strong enough reason. Unless and until someone puts together a dedicated developer.inkscape.org as Alan suggested, I think these things should be restored to our main page, or at least be added near the top of the FAQ.
Sure, a FAQ along the lines of "What programming languages and toolkits are used by Inkscape" would be entirely appropriate. Feel free to add it. Just so long as it's not on top of the front page, for the reasons I explained.
On Thu, 2005-08-25 at 02:46 -0300, bulia byak wrote:
On 8/25/05, Bryce Harrington <bryce@...260...> wrote:
<snip />
Hi fellas,
I think that we should look at other projects that are successful and learn from them. I agree with both of you on your points, but dont' want to rehash and nitpick on your previous post-crossposts.
I do think that Inkscape is scaling to the point where a website redesign is in order. And, I have noticed how many projects are doing their sites in a more streamlined fashion.
Hula has a nice simple site which is attractive to users and developers: http://hula-project.org/Hula_Server
I've been thinking about this approach for sometime in basically converting our entire site to mediawiki and tweaking the stylesheets and making main pages require user/pass. Hula does a great job of this
Another great example is: http://www.gnome.org/projects/evolution/
However, my point is we are at a time when we need to think about the different tracks of users. As much as we needed the testers list and community, I think the website needs to be redesigned and rethought in terms of being the most general portal for people to the project.
From there, it should splinter into other groups. I would go so far as
to have a user, developer, tester tab even at the top to get ppl. into a more specific infrastructure about the site according to interest.
Right now we have way too many links on our menu and the main page is starting to become a mess.
Anyhow, Bulia, I think before more tweaks happen on the page, maybe you should pass them by people. Maybe changing all of these things would be the equivalent of me coming in and moving the toolbars around in inkscape without discussing with anyone -- I think a few ppl. would get miffed about this.
Anyhow, I think we really need to put much thought into the web redesign. I hope this contest goes well, but I must say that it is a bit ambitious for about 20 days of work and all from an outside group of designers.
Personally, I think we could just put up a mediawiki and shuttle our content into that and make a nice simple interface for ppl. to understand our site.
Jon
Jon Phillips wrote:
I think that we should look at other projects that are successful and learn from them. I agree with both of you on your points, but dont' want to rehash and nitpick on your previous post-crossposts.
Yeah, and I think we should hash all of it out ASAP to modify the contest guidelines accordingly. I can't really post-pone the contest at this point as it notified over 50+ Inkscapers directly on dA about it just with the journal entry. Plus there were a few other places I announced (couple other places on dA and the lists).
-Josh
On Thu, Aug 25, 2005 at 01:34:41PM -0700, Jon Phillips wrote:
I've been thinking about this approach for sometime in basically converting our entire site to mediawiki and tweaking the stylesheets and making main pages require user/pass. Hula does a great job of this
This is an approach I've done in a couple past projects. I also had the same idea that doing everything in wiki would make the site easily editable and simplify the maintenace.
However, in practice I found that this idea didn't alway pan out as well as I'd imagined. There were several problems. First, invariably I needed to do some sort of layout that wiki couldn't quite handle. Being able to lay out individual pages in PHP or HTML directly is quite advantageous. Second, a strength of wiki is how quickly it can grow, but for a main website this can also be a weakness; I found that the wiki-based sites quickly became quite challenging to navigate. Third, the assumption that a wiki would be easier to edit often does not pan out. People who have the motivation to actually write content for a website typically also either know HTML or have a will/desire to learn it. For true website geeks, who eat and breathe HTML, using a wiki for the website can actually be constraining, and can drive them from being willing to contribute.
Thus, when I set up the web stuff for inkscape, I was quite deliberate in setting up both a PHP-based "shell", as well as a wiki for more freeform editing. You could argue that a given page in the wiki belongs on the site, or vice versa, but note how the main inkscape site is straightforward to navigate through, remains fairly consistent from visit to visit, and tends to just have what you need. Meanwhile the wiki is a seething brew of ideas, comments, etc. and while it may be tough to browse through, there's a LOT of good stuff in it.
Anyway, all that said, Mediawiki is a very good wiki, and it solves a number of issues mentioned above. So possibly with mediawiki it can all be done in one system. However, it would surprise me to see this.
Right now we have way too many links on our menu and the main page is starting to become a mess.
Agreed
Anyhow, Bulia, I think before more tweaks happen on the page, maybe you should pass them by people. Maybe changing all of these things would be the equivalent of me coming in and moving the toolbars around in inkscape without discussing with anyone -- I think a few ppl. would get miffed about this.
Actually, I still think that making the changes directly is best; requiring that changes be discussed ahead of time can lead to a lot of inefficient debates and arguments. However, I would emphasize that one should take care to "Patch first, discuss later", not "Patch first, period." ;-)
Bryce
On 8/26/05, Bryce Harrington <bryce@...260...> wrote:
Actually, I still think that making the changes directly is best; requiring that changes be discussed ahead of time can lead to a lot of inefficient debates and arguments. However, I would emphasize that one should take care to "Patch first, discuss later", not "Patch first, period." ;-)
Yes, which is why I started this thread.
On Thu, Aug 25, 2005 at 02:46:17AM -0300, bulia byak wrote:
In any case, if our goal is to gain users, there are other approaches which would be much more effective. If this is the only reason for removing "gtkmm" and "C++" from the top of the main page, I don't think it is a strong enough reason. Unless and until someone puts together a dedicated developer.inkscape.org as Alan suggested, I think these things should be restored to our main page, or at least be added near the top of the FAQ.
Sure, a FAQ along the lines of "What programming languages and toolkits are used by Inkscape" would be entirely appropriate. Feel free to add it. Just so long as it's not on top of the front page, for the reasons I explained.
Since you feel so strongly that these things should not be on the home page, let me ask that you take the action of moving them to the faq, and I will accept having it removed from the home page even though I do not agree with your arguments. I think that is a fair compromise.
Also, please be careful not to use phrasings like "Just so long as it's not..." which could be interpreted to be dictatorial. Since I had written this page originally, your wording sounded a bit presumptuous and rude. As you've mentioned before, your writing is often misunderstood, so I assume this is not how you meant it to sound.
Bryce
On 8/26/05, Bryce Harrington <bryce@...260...> wrote:
Since you feel so strongly that these things should not be on the home page, let me ask that you take the action of moving them to the faq
Moving WHAT to the faq? The single phrase about "conversion"? I think you or someone else should just write a faq entry from scratch. I'm not qualified to do this.
Also, please be careful not to use phrasings like "Just so long as it's not..." which could be interpreted to be dictatorial. Since I had written this page originally, your wording sounded a bit presumptuous and rude. As you've mentioned before, your writing is often misunderstood, so I assume this is not how you meant it to sound.
Oh. I meant it to _mean_ that "I do not object to adding this anywhere on the site but I object to putting it on the top of the front page". I _think_ that I said exactly this and that what I said was not at all rude. If you think otherwise I apologize (again). I also don't understand why it should matter who wrote the page originally.
On Fri, Aug 26, 2005 at 05:04:39AM -0300, bulia byak wrote:
On 8/26/05, Bryce Harrington <bryce@...260...> wrote:
Since you feel so strongly that these things should not be on the home page, let me ask that you take the action of moving them to the faq
Moving WHAT to the faq? The single phrase about "conversion"?
Yes. Or, if it's up to me I would just restore that phrasing to the main page. If you move it to the faq, I would be okay with that.
Bryce
On 8/26/05, Bryce Harrington <bryce@...260...> wrote:
Yes. Or, if it's up to me I would just restore that phrasing to the main page. If you move it to the faq, I would be okay with that.
Bryce, please explain how I can turn this into a FAQ entry:
Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm
I honestly don't understand.
If you want to revert my changes to the front page instead, please feel free. Hopefully this will end the story for good. (This may have a side effect, in that I will be afraid to touch anything that you wrote or coded, but at least the peace will be restored.)
On 8/26/05, bulia byak <buliabyak@...400...> wrote:
Yes. Or, if it's up to me I would just restore that phrasing to the main page. If you move it to the faq, I would be okay with that.
Bryce, please explain how I can turn this into a FAQ entry:
Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm
I honestly don't understand.
Or maybe someone else, well versed in language/toolkits issues, could add a FAQ on it to
http://wiki.inkscape.org/cgi-bin/wiki.pl?FAQ
and thereby save my front page edits from reverting? I would deeply appreciate that.
Quoting bulia byak <buliabyak@...400...>:
On 8/26/05, Bryce Harrington <bryce@...260...> wrote:
Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm
I honestly don't understand.
Q: Does Inkscape plan to switch to Gtkmm?
A: etc...
It's a bit like Jeopardy, really. Just find a question that fits your answer.
-mental
On Fri, Aug 26, 2005 at 01:36:31PM -0300, bulia byak wrote:
On 8/26/05, Bryce Harrington <bryce@...260...> wrote:
Yes. Or, if it's up to me I would just restore that phrasing to the main page. If you move it to the faq, I would be okay with that.
Bryce, please explain how I can turn this into a FAQ entry:
Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm
I honestly don't understand.
The main concern I have is that there are some basic developer questions that I feel need to be answered somewhere that is really easy for people to find. The following are examples of questions that have come up:
- Does your product compile and run on Linux? (Win? OSX?)
- What widgetset does it depend on?
- How much code is there?
- Is it one single codebase or is it divided into multiple components?
- Is Inkscape C or C++. I vaguely recall reading something about it being C or only recently been moved to C++. If so how modular / OO clean is it?
- What rendering engine do you use. We have sort of assumed you'd be using Cairo anyway (but we are aware it has some limitations that you seem to have go around - can't remember specifically what, but I think it might have been related to transparency.)
Bryce
On 8/26/05, Bryce Harrington <bryce@...260...> wrote:
The main concern I have is that there are some basic developer questions that I feel need to be answered somewhere that is really easy for people to find. The following are examples of questions that have come up:
Excellent questions, and I fully agree that they should be prominent in the FAQ. So will you (or someone else who's qualified) please write them up? After they're ready, a news item can be added to the front page, to draw more visibility to them.
BTW, with our FAQ growing, I think it would benefit from a table of contents and some sectioning (Using Inkscape, Developing Inkscape, etc.)
On Fri, Aug 26, 2005 at 02:32:18PM -0300, bulia byak wrote:
Yes. Or, if it's up to me I would just restore that phrasing to the main page. If you move it to the faq, I would be okay with that.
Bryce, please explain how I can turn this into a FAQ entry:
Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm
I honestly don't understand.
The main concern I have is that there are some basic developer questions that I feel need to be answered somewhere that is really easy for people to find. The following are examples of questions that have come up:
Excellent questions, and I fully agree that they should be prominent in the FAQ. So will you (or someone else who's qualified) please write them up?
Since you said you would do it if I explained how to do it, why don't you take a first stab at it.
Bryce
I have rearranged and expanded our FAQ:
http://wiki.inkscape.org/cgi-bin/wiki.pl?FAQ
Edits are welcome.
Unfortunately there is no way to automate TOC this with our wiki engine, so it's manual for now. There are also bugs: many <a>...</a> links do not work (though some do), and some paragraphs annoyingly change style on mouseover. If someone can fix this it would be great.
On Fri, 2005-08-26 at 18:49 -0300, bulia byak wrote:
I have rearranged and expanded our FAQ:
http://wiki.inkscape.org/cgi-bin/wiki.pl?FAQ
Edits are welcome.
Unfortunately there is no way to automate TOC this with our wiki engine, so it's manual for now. There are also bugs: many <a>...</a> links do not work (though some do), and some paragraphs annoyingly change style on mouseover. If someone can fix this it would be great.
Cool, I have mediawiki ready to go to make the transition actually, so that will be good...but have held off on doing so that we could just get our wiki up...that has auto-toc, which rules.
I'm also seeking out how to do docbook export directly in mediawiki, so that would be so awesome for our documentation, etc.
Jon
On Fri, 2005-08-26 at 18:49 -0300, bulia byak wrote:
I have rearranged and expanded our FAQ:
http://wiki.inkscape.org/cgi-bin/wiki.pl?FAQ
Edits are welcome.
Unfortunately there is no way to automate TOC this with our wiki engine, so it's manual for now. There are also bugs: many <a>...</a> links do not work (though some do), and some paragraphs annoyingly change style on mouseover. If someone can fix this it would be great.
fixed :)
Jon
On Fri, Aug 26, 2005 at 06:49:02PM -0300, bulia byak wrote:
I have rearranged and expanded our FAQ:
http://wiki.inkscape.org/cgi-bin/wiki.pl?FAQ
Edits are welcome.
Unfortunately there is no way to automate TOC this with our wiki engine, so it's manual for now. There are also bugs: many <a>...</a> links do not work (though some do), and some paragraphs annoyingly change style on mouseover. If someone can fix this it would be great.
Thanks, looks great.
Bryce
participants (6)
-
unknown＠example.com -
Alan Horkan -
Bryce Harrington -
bulia byak -
Jon Phillips -
Joshua A. Andler