New host services


#21

and a new updated version where the big distributions logos (on the left set) have shadows for increased contrast with the package (specially needed for ubuntu and mac logos.

sorry for the spam :slight_smile:
Berteh.
packages_icons_v3.png
packages_icons_v3.svgz.txt (402 KB)


#22

Great work, berteh! I’m putting them on the website…

EDIT: Download pages updated: synfig.org/en/current-release
^___^


#23

Another testing snapshot for PDF manual: mediafire.com/?5240wymkkjz


#24

As always one of my most appreciated feature in the recent website developments, thanks.

a few suggestions, just keep the ones you like and drop the others :slight_smile:

  • title page: add a synfig logo on title page
  • table of contents: reduce drastically size of police, optionally get it in 2 columns, and make it clickable ([hyperlink] tag, if I remember correctly)

content:

  • reduce line width to less than 70 chars. recommended width is ‘officially’ ~66 for the eye gets lost if text is too wide. a classical way to do it is reduce font size and layout in 2 columns.
  • reduce font size anyway.
  • make page margins homogeneous (small at p.17, big at p.153)
  • make size of pictures more homogeneous, consider on pages:
    • too big (seems to be the default with current export): 15-17,20-27, 29-33, 44-58, 60, 63-68, 80-83, 90-100, 108-111, 113-124, 127-133, 136, 138-139, 141, 146-152, 156, 159-166, 169, 190
    • too small: 11, 34, 62, 126, 168
    • size ok: the icons, 142-145
  • provide proper legend/titles for images (in very small size, sticking to each picture)… maybe a general guideline for documentation, even in the wiki?
  • reduce size of code blocks (eg: p.35), they are generally meant for copy-paste… so small size is ok… light greyish background would look nice (eg p.182)
  • make internal link (on wiki words) work in pdf, or drop them completely
  • rotate render options table… or make these pages landscape: 153-155
  • fix p176
  • make hotkeys visual guide link work (p.198)
  • layout keyboard shortcuts on (only) 2 consecutive pages, for an easy printing. (p.196-198)
  • drop “of 200” from page numbering, it’s no interesting info.

hope this helps… and whether you find time & means to make some of these work thanks in advance!
Berteh.


#25

Hi people!
This morning Zelgadis and I have been talking in google chat about something that is related to this thread. We both want to show you the whole conversation:
(“Yo” is me - Genete)

We would be very interested on listen your opinion about if it is worth to continue with Joomla website or move to a wikimedia site with its templates, DLP macros and extensions.
Also I want to publicly admit the amount of errros that we are commiting lately, but sincerely, we are doing our best ^_^’’. Keep alive a project like synfig is not a one or two man task. We are open to any suggestion and any help.
Meanwhile, as I said, I’ll focus on the release.
Cheers
-G


Wiki seems to be slow
#26

Thanks, Genete! :slight_smile:

@berteh:
Thank you for the notes. The manual definitely is not in “ready for read” state yet. There’s a lot of work on the content to do. But I’m happy that pdf export is working. If you are interested, discussions about manual re-writing is here - synfig.org/forums/viewforum.php?f=25 .


#27

hmmm, sorry, have a different view on this.

I think people expect a website of a project like Synfig to look kind of professional.
I cannot imagine to have a wiki website currently, might be that I don’t know what is possible, but the typical wiki lokk&feel would be much worse compared to what we have currently.
E.g.: and comment, edit, login tabs would be confusing.

The website (as it is) worked fine for me so far.

… and it is much faster than the wiki. As it seems like both are on the same server I guess that Joomla is just faster in delivering pages than mediawiki, at least with limited resources.

I do Joomla quite a while now for several projects and organizations, it is correct that a lot of people around joomla think that it is a great idea to earn money, but you can do a lot without those… What I like is that I can define times when things should appear and disappear on the website.

Don’t misunderstand me: if we have good reasons not to use Joomla, fine, but thenwe should use another CMS like drupal, … (please not Typo3, tried this one and got totally lost, kills a programmers mind :frowning: ), but not wikimedia.

My view… but, hey, you are around much longer, so up to you :slight_smile:


#28

Example of mediawiki-based website: amarok.kde.org/wiki/Main_Page

The main points against Joomla are:

  • File storage scheme is hard to adapt for our hosting
  • Website changes are not transparent, which is bad I think. Considering the limited human resources we have to attract more people from the community for maintaining of the website.
  • No revision control for pages

It’s still early to decide now, but I think that Mediawiki is good choice. Anyway, the joomla is not a way to go. Talking about cms solutions, concrete5.org/ looks interesting.


#29

Honestly, I do not see to have a big community working on the website as such.
It might be interesting to have some helping hands for translations. But the major messages about the project shouldn’t be left to frequent community changes, but should be well defined and agreed.

Also: Still I do not see how to make time scheduled changes to mediawiki pages. E.g. predefined content for special announcements actions, … appearing at the right time, but entered into the CMS ahead of time. That is a major feature for a CMS and very helpful for projects with limited ressources.


#30

Agree, that’s the feature mediawiki can’t provide.

EDIT: But it’s possible to store drafts and publish them manually.