New host services

General Synfig news discussion
11

Zelgadis: go for it! :wink:
-G

12

I would be glad to help for these icons, but need SVG import to be fixed if you want them in synfig format.

13

As it’s for the website, if you provide them in SVG format it’s OK! ^___^

14

a set of icons. feel free to comment. They are meant for big sizes (~150x150) otherwise the logo on the box is too small.

rename svg.txt to svg to get the sources: Synfig_package_icons__on-the-box.svg.txt (1.26 MB)
win.png
deb.png
rpm.png
linux.png
mac.png
source.png

15

and a variant that works better in small sizes for the OS logo is bigger… but you got only 1 distro for deb & rpm… so I prefer the former serie if you got place enough.

again, any comment/suggestion is welcome.
Synfig_package_icons__floating.svg.txt (1.25 MB)
floating.png

16

They look cool!
I wanted to ask to put logos near the packages, but you already catched my idea! Maybe make synfig logo a little bigger in the second version? And I suggest to remove blue square near the penguin. That’s all my thoughts. Good work!

(BTW, I have enabled uploading of svg on the forum)

17

Cool icons berteh!
I like them much!
Thanks!
-G

18

Great icons!
I would have to disagree with Zelgadis about the blue square. It is an icon for an executable, which suggests that the download is not a package. However, I don’t know if it’s universally recognizable, or used only by Ubuntu.

When switching hosts, I think we scrapped the doxygen pages and the review board. I would like to eventually see the doxygen pages restored because they can be useful in development.

19

Then leave only one icon. (But I still like Tux icon better ^___^ )

Doxygen pages are here: download.tuxfamily.org/synfig/api/index.html
Reviewboard is lost, because we can’t afford hosting that monster.

20

Thanks for all the comments. here’s an updated version of the 2 sets of icons. (with a lonely penguin in both sets and increased synfig logo size in the “floating” version.)

enjoy.
B.
packages_icons_v2.png
packages_icons_v2.svg

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

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.