Board.KolibriOS.org

Well, which filesystems are actually popular? What is used in x86 Mac? As for Linux, I remember Reiserfs was popular.

http://www.cyberciti.biz/faq/howto-moun ... der-linux/
https://www.kernel.org/pub/linux/utils/fs/

Why we should support another filesystem? ReiserFS for me not so important, sorry.

Maybe we should take care about more important points, like nVidia video drivers, NTFS file system improvements (encryption, write support), window manages improvements (windows "always on top", child windows), cool and usable audio player, search program, usable image editing program, library to save image as png/jpg, component menu and list, ability to rename files and folders in kernel and so on...

Here is a more detailed listing for the music player idea. What do you guys think?

Main goal: music player written in flat assembler with support for:
- wav, mp3 and xm file formats (using available external libraries)
- playlists (m3u) with shuffle and repeat functions
- time display

Additional goals:
- use of system wide hotkeys to control player
- support for IDv3 tags
- more codecs (flac, ogg, ...)
- audio indication (oscillograph, bar graph, ...)
- show cover art from files or album folder
- fade in/out and/or crossover
- streaming radio (at least mp3 over http stream)
- skins
- media library
- plugins? (with what purpose?)

Leency,
I can be a mentor only for file systems and userspace programs which require no specific knowledge.
You can offer yourself as a mentor.

Btw, I don't see most of your list items here.

dunkaist wrote:I can be a mentor for "Filesystem support" task. I have some experience in fs programming and I'm familiar with related kernel structures. It is common to see me online as well.

I really appreciate that you offered to volunteer as a mentor. Please create a short profile of yourself on our Wiki similar to this one: http://wiki.kolibrios.org/wiki/User:Hidnplayr

dunkaist wrote:However I'd prefer to change "* Add XFS write support" task to "* Add UDF read/write support" because [...] Implementing writing without reading is much harder, I don't think such a task can attract students (anyway, there is NTFS).

The current page is just a copy of previous year's page (hidnplayr just copied it from KSoC2013, and then removed tasks that were already done). That's why XFS write support is written there - because it appeared on KSoC2013 page, and read support was already done by you in 2013. You are free to edit this page as you feel correct.

dunkaist wrote:I'll update wiki page if nobody objects.

Sure, go ahead.

Leency wrote:Why we should support another filesystem? ReiserFS for me not so important, sorry.

Maybe we should take care about more important points, like nVidia video drivers, NTFS file system improvements (encryption, write support), window manages improvements (windows "always on top", child windows), cool and usable audio player, search program, usable image editing program, library to save image as png/jpg, component menu and list, ability to rename files and folders in kernel and so on...

We are going back to the same discussion as last year: the tasks that appear on the list are not the tasks that are most important to do, but the tasks that we have available mentors for. If you are willing to volunteer as a mentor for "nVidia video drivers", we will certainly add it to the list.

hidnplayr wrote:Here is a more detailed listing for the music player idea. What do you guys think?

Sounds great if you can mentor that one. Go ahead and add it to the Wiki page

Many thanks to everyone who volunteered so far. If we can get just 1 more mentor, it would be perfect for the application.

For those who weren't updated: I have submitted the application on February 14th. We will get answer from Google on February 24th.

dunkaist wrote:I can be a mentor only for file systems and userspace programs which require no specific knowledge.

На Хабре мне предлагали ещё одну идею на GSoC 2014, связанную с обработкой изображений, но я совсем забыл тебя о ней спросить:

Идея генерировать QR-Code на загрузочном экране из текста, который сейчас выводится как debug-log. И если юзера просят выложить загрузочный лог KolibriOS, он сможет, вместо того, чтобы фотографировать сам лог, сосканировать QR-Code и выложить на форум сразу текст.

Как тебе идея вообще, считаешь ли ты её годной для GSoC 2014, и готов ли ты быть её ментором?

Такое сделано в HaikuOS
http://www.haiku-os.org/blog/mmlr/2012- ... kdl_output

У меня вопрос - ну, ладно сделаете это вы, а у меня предположим нет смартфона с Андроидом и программ распознающих эти коды, какова тогда для меня как разработчика практическая целесообразность? Такие вещи должны быть опциональными. Обычный лог они должны лишь дополнять, а не заменять.

Wildwest wrote:Такое сделано в HaikuOS
http://www.haiku-os.org/blog/mmlr/2012- ... kdl_output

Да, именно это и предлагали - "Сделайте QR Code, как в Haiku".

Mario_r4 wrote:У меня вопрос - ну, ладно сделаете это вы, а у меня предположим нет смартфона с Андроидом и программ распознающих эти коды, какова тогда для меня как разработчика практическая целесообразность? Такие вещи должны быть опциональными. Обычный лог они должны лишь дополнять, а не заменять.

Моя идея была дополнять обычный лог - показывать QR Code в левом нижнем углу монитора во время вывода дебаг-лога (этот угол сейчас как раз пустует).

yogev_ezra wrote:Моя идея была дополнять обычный лог - показывать QR Code в левом нижнем углу монитора во время вывода дебаг-лога (этот угол сейчас как раз пустует).

А Гугл что из этой информации "излекает" c телефонов? Что за хитрую статистику? Или не только гугл.

Kopa wrote:

yogev_ezra wrote:Моя идея была дополнять обычный лог - показывать QR Code в левом нижнем углу монитора во время вывода дебаг-лога (этот угол сейчас как раз пустует).

А Гугл что из этой информации "излекает" c телефонов? Что за хитрую статистику? Или не только гугл.

Не понял вопроса. Если ты про "Большого брата", то тщательно переписав лог на бумажечку и выложив текст на форуме, юзеры Колибри дают Гуглу столько же информации, сколько использовав QR-Code. В случае с QR-Code, смартфон просто сам за юзера "переписывает на бумажечку".

yogev_ezra Думаю это отличная затея с QR-Code , недавно приходилось много переписывать вручную с экрана отладочные логи .

Чего-то подобное у нас уже делали, но не на QR - viewtopic.php?f=46&t=1995