Yes it is .. and it is already planned for v1.1

Dimitrij,

Disclaimer: I understand the need to keep retro simple but wanted to weigh in on attachments.

You mentioned in [#32] that you didn’t think it was a good idea to add attachments to the wiki. Could you expand on that?

We’ve transitioned from trac to retro (very, very happy with it btw) but miss this feature of trac.

In the course of working on a project it is quite common to receive files (perhaps in an email) that may not be available on a web site or approprate for adding to the project’s svn repository. These files may apply to a ticket but often times they’re most useful in the context of documentation – found in the wiki.

We can work around it when you add it to the blog section but it would be nice if the capability existed from the wiki.

Best, Eric

I’m sorry for the misunderstanding, I was talking about inline images in the Wiki in [#32]. Downloadable attachments are something different and definitely worth to think about. I’ll keept this one in mind, let’s see what I can do ;-).

Dimitrij

+1 for attachments on wiki and blog.

I used to upload zip files of project releases etc that clients could download off the trac wiki. It was a very nice feature.

+1 for attachments to the wiki at the very least!

+1 for attachments to the wiki pages.

I think, that it let’s upload an image and have an inplace ! http://... ! reference to it inside the same wiki page (or may be even from other pages)

+1 for attachments +1 for inline images, a blog really needs images in my opinion and how i use it. Can attachments be given some priority please, this is a great package otherwise

q ojala q me llegue

inline images would be really helpful. I’m trying to include screenshots of the software we’re developing. Obviously key for showing install instructions and the like on the wiki.

nevermind just found this code –

http://www.salewroughtiron.cn installing metal stair rails Interior stair handrail installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails http://www.china-made-door.com.cn door gate http://www.beijing-door.cn wrought CONTEMPORARY designs stairways installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails http://www.hebei-railings.cn aluminum modern log banister DECK outdoor price installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails posts vinyl curved rails

Many things are transparently clear for a dev but unclear for an end user. This is why I think it is a different community which should take care of the docs than which develops the code. Of course the app maintainer has to check for vandalism correctness and his cool hidden feature missing for releases, but the docs can be generally worked out by end users who would like to contribute and start to use docs to learn cool stuff about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, duns [http://www.about-china.net.cn/wrought-iron/cat_4.html china tour] [http://www.about-china.net.cn/wrought-iron/cat_3.html Apparel] [http://www.about-china.net.cn/wrought-iron/cat_5.html shoes] [http://www.about-china.net.cn/wrought-iron/cat_12.html bags] [http://www.about-china.net.cn/wrought-iron/cat_6.html Kitchen] [http://www.about-china.net.cn/wrought-iron/cat_7.html Food and Wine] [http://www.about-china.net.cn/wrought-iron/cat_8.html Furniture)] [http://www.about-china.net.cn/wrought-iron/cat_9.html Flowers and Gifts] [http://www.about-china.net.cn/wrought-iron/cat_10.html Wall Art] [http://www.about-china.net.cn/wrought-iron/cat_11.html Computer Components] I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are much better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs, that more help is needed as long as the devs prefer to code than to write nice docs. And it is their choice to some degree imo. Technically interested but non-dev end users, which are plenty out there, are the users of and the best contributers to the docs, since they know what to write about. And they are certainly more than devs

Many things are transparently clear for a dev but unclear for an end user. This is why I think it is a different community which should take care of the docs than which develops the code. Of course the app maintainer has to check for vandalism correctness and his cool hidden feature missing for releases, but the docs can be generally worked out by end users who would like to contribute and start to use docs to learn cool stuff about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, [http://www.nikeshoesshop.com shop][http://www.nikewholesaleshoes.com Wholesale][http://www.shoesnike.cn Trainers][http://www.nikechina.net Sneakers][http://www.nikeshoeswholesaler.com wholesaler][http://www.nikeshoessaler.com Sell][http://www.nikeshoes-sale.com Sale] I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are much better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs, that more help is needed as long as the devs prefer to code than to write nice docs. And it is their choice to some degree imo. Technically interested but non-dev end users, which are plenty out there, are the users of and the best contributers to the docs, since they know what to write about. And they are certainly more than devs