Премини към съдържанието
  • Добре дошли!

    Добре дошли в нашите форуми, пълни с полезна информация. Имате проблем с компютъра или телефона си? Публикувайте нова тема и ще намерите решение на всичките си проблеми. Общувайте свободно и открийте безброй нови приятели.

    Моля, регистрирайте се за да публикувате тема и да получите пълен достъп до всички функции.

     

Снимки на Вашия Linux - част 2


Препоръчан отговор

Можеш да си изрежеш, каквито искаш и да ги конвертираш в svg. Аз имам няколко типа, но само за един пълен комплект ми стигнаха нервите да преформатирам. 

http://xfce-look.org/content/show.php/Flags+from+Linux+Mint+Cinnamon+for+Xfce?content=163474

Другите са само us.svg и bg.svg.

Това е местоположението на знамената http://s19.postimg.org/khxcovx9v/flags.png

Може ли да ги ползвам за stotinkaOS във един пакет който съм направил за тази цел?

Линк към коментара
Сподели в други сайтове

  • Отговори 3,9k
  • Създадено
  • Последен отговор

Потребители с най-много отговори

Разбира се. Стига да стоят добре в панела на Gnome 2, защото са направени само за панела на Xfce. Възможно е в панела на Gnome 2, който е по- опростен и не се спазват пропорциите да има деформация на картинката. Първо тествай изображенията да не стане недоразумение. 

Редактирано от cybercop (преглед на промените)
Линк към коментара
Сподели в други сайтове

Екстра са:

 

h_1430034766_2821883_4606ffd355.png

 

h_1430034823_4607147_54a76edab2.png

 

И актуализацията на пакета, информацията тук => http://www.stotinkaos.net/stotinkaOS/repo/6/i386/repoview/gnome-flags.html след малко ще пусна мухата и във форума ни :D

 

edit: Направено - http://www.stotinkaos.net/forums/thread-47-post-919.html#pid919

 

Мерси!

Редактирано от ivoarch (преглед на промените)
Линк към коментара
Сподели в други сайтове

Ти си решаваш. Аз съм очарован от Xfce 4.12. Дори да се поддържаше Gnome 2, пак щях да мигрирам към Xfce.

 

Мен ме дразнят някои дефекти които и тук присъстват.

xfce ходдържа функция за изключване на ефектите при цял екран но не работи, и отделно така и не разбрах защо xfce-power-manager изобщо не вижда когато vlc работи на цял екран.

Линк към коментара
Сподели в други сайтове

Защото VLC има опция да блокира само предпазителя на екрана. А, xfce4-power-manager контролира режимите вместо него. Изключи опцията от xfce4-power-manager, остави само xscreensaver и опитай отново.

http://s19.postimg.org/hccqyoenn/xfce4_PM.png

Редактирано от cybercop (преглед на промените)
Линк към коментара
Сподели в други сайтове

Защото VLC има опция да блокира само предпазителя на екрана. А, xfce4-power-manager контролира режимите вместо него. Изключи опцията от xfce4-power-manager, остави само xscreensaver и опитай отново.

http://s19.postimg.org/hccqyoenn/xfce4_PM.png

 

Пробвал съм какво ли не просто екрана си гасне без никакво значение.

Линк към коментара
Сподели в други сайтове

Пробвал съм какво ли не просто екрана си гасне без никакво значение.

Пробвал ли си Caffeine? https://code.launchpad.net/~caffeine-developers/caffeine/trunk

Следи за приложения и директно подава инфо на X-a.

На Python e и не мисля, че ще е сложно да го подкараш.

 

p.s. Точно заради такива бози от 2 год не ползвам Linux за десктоп (освен на виртуалка).

2016 се надявам като пооправят нещата с Wayland и Mir всичко да е ОК. Стига и hardware vendor-ите да решат да направят читави KMS драйвери, щото имам лошото чувство, че да им ползваш драйверите ще се вика X сесия (поне в началото).

Редактирано от borovaka (преглед на промените)
Линк към коментара
Сподели в други сайтове

Те за тва ли тия нови знамена ми дойдоха като ъпдейт ,че се наложи да свалям нови и да си правя 2 за бг и английска клавиатура :).Тия ич не ми харесаха

Линк към коментара
Сподели в други сайтове

На KDE подобен проблем няма, та чак да се откаже човек от Линукс заради нещо такова е несериозно... Иначе да, всички чакаме Wayland :)

Проблема не е само в screensaver-а има страшно много неща, които не са изгладени при десктопа. Евала на Lennart Poettering и няколко други, че в последните години правят нещо радикално и то към добро според мене.

Другото, което е дистрибутирането на декстоп софт е отврателно към момента. Евала, че мислят и нещо в тая насока със Snappy пакетите и Atomic на RedHat и силно се надявам да вкарат някакъв стандарт ( и двете са контейнери ама не се знае дали ще са съвместими в крайна сметка). Щото в момента, ако искам да пиша софт за Linux десктоп някой може ли да ми каже от къде да започна?

Хващам QT или GTK и ако хвана GTK примерно върви търси документация на gobject/mutter/clutter/gstramer и ала бала ... до сега не съм намерил един добър guide спецално за десктоп.

Не хейтя Линукс ползвам от бая години и ми е кеф, ама пичовете за вече 10-12 години не можаха да стандартизират нещо.

Щото примерно, ако ще пиша за Android отварям си http://developer.android.com/и имам документация с примерни и практики, при MS е същото. Айде за QT донякъде съм съгласен, че документацията е на ниво, ама там е generic в смисъл не е насочено към Linux deleopment. 

Та така, мисля си, че нещата напоследък са добре в смисъл примерно стандартизацията на systemd, минаването към контейнери и други такива неща и се надявам, че скоро ще се получи нещо usable.

 

p.s. Тук говоря за дектоп иначе, що се отнася до работа за сървър там нещата си се случват.

Редактирано от borovaka (преглед на промените)
Линк към коментара
Сподели в други сайтове

Развитие при десктопите има от  2-3 години. И понеже Убунту и Минт взеха да правят техни си разработки всичко живо се юрна и то да прави  форкове на тая и оная графична среда. При големите  проекти има над 1000 бъгове на година а за малките сигурно цифрата е поне 10 000. Има супер дребни  бъгове които висят с години и на никой не му дреме. Инфото  е разпиляно в хиляди сайтове и форуми и ходи го търси във милионите теми  после.

Редактирано от AlkatrazBG (преглед на промените)
Линк към коментара
Сподели в други сайтове

Първо за видеото, https://wiki.archlinux.org/index.php/Mpvновият плеър няма такъв проблем - тествано на plasma 5. Що се отнася за документация - генерално не съм съгласен. Андроид е безумна простотия, която ако не напишеш точно примера и не работи - що за стандарт е тва? М$ дори няма да ги коментирам, дори и малкото пъти, в които ми се е налагало да ползвам MSDN, ми се искаше да си пръсна черепа от глупости. Qt има идеална документация, която може да се интегрира в IDE-то, KDevelop, QtCreator. GTK не мога да коментирам, не съм ѝ фен и не съм опитвал нищо да пиша. 

Линк към коментара
Сподели в други сайтове

Те за тва ли тия нови знамена ми дойдоха като ъпдейт ,че се наложи да свалям нови и да си правя 2 за бг и английска клавиатура :).Тия ич не ми харесаха

Е какво да се прави, за вкусове цветовете, както казват хората :). На мене лично тези ми харесват повече, онези бяха дяволски големи и ми вадиха очите. 

Линк към коментара
Сподели в други сайтове

Проблема не е само в screensaver-а има страшно много неща, които не са изгладени при десктопа. Евала на Lennart Poettering и няколко други, че в последните години правят нещо радикално и то към добро според мене.

Другото, което е дистрибутирането на декстоп софт е отврателно към момента. Евала, че мислят и нещо в тая насока със Snappy пакетите и Atomic на RedHat и силно се надявам да вкарат някакъв стандарт ( и двете са контейнери ама не се знае дали ще са съвместими в крайна сметка). Щото в момента, ако искам да пиша софт за Linux десктоп някой може ли да ми каже от къде да започна?

Хващам QT или GTK и ако хвана GTK примерно върви търси документация на gobject/mutter/clutter/gstramer и ала бала ... до сега не съм намерил един добър guide спецално за десктоп.

Не хейтя Линукс ползвам от бая години и ми е кеф, ама пичовете за вече 10-12 години не можаха да стандартизират нещо.

Щото примерно, ако ще пиша за Android отварям си http://developer.android.com/и имам документация с примерни и практики, при MS е същото. Айде за QT донякъде съм съгласен, че документацията е на ниво, ама там е generic в смисъл не е насочено към Linux deleopment. 

Та така, мисля си, че нещата напоследък са добре в смисъл примерно стандартизацията на systemd, минаването към контейнери и други такива неща и се надявам, че скоро ще се получи нещо usable.

 

p.s. Тук говоря за дектоп иначе, що се отнася до работа за сървър там нещата си се случват.

Аз не мисля, че липсва документация, било то за GTK, Qt или Linux. В интернет има доста четива в тази насока. Друг е въпроса, че не всички са на добро ниво.

 

 

 Qt има идеална документация, която може да се интегрира в IDE-то, KDevelop, QtCreator. GTK не мога да коментирам, не съм ѝ фен и не съм опитвал нищо да пиша. 

За GTK => http://www.gtk.org/documentation.php

 

 

Развитие при десктопите има от  2-3 години. И понеже Убунту и Минт взеха да правят техни си разработки всичко живо се юрна и то да прави  форкове на тая и оная графична среда. При големите  проекти има над 1000 бъгове на година а за малките сигурно цифрата е поне 10 000. Има супер дребни  бъгове които висят с години и на никой не му дреме. Инфото  е разпиляно в хиляди сайтове и форуми и ходи го търси във милионите теми  после.

Докато се пише код и се прави софтуер, бъгове винаги ще има, това е ясно като деня и нощта :).

Във windows не седят по различно нещата, или някой ще ми каже сега, че там няма бъгове?

Относно решаване то им, и това че стояли от сума ти време,  мисля че този проблем е по скоро срещан във сървърните дистрибуции като Debian, RHEL etc. . и то говорим за грешки от типа за X приложения, графични среди, които приложения не са им приоритет.  Макар, че до сега във RHEL,Centos не съм срещал подобни грешки (не казвам че няма), докато за Debian според това което пишат някои тука, се намират доста такива. За информацията че била разпиляна, какво очаквате, да се направи една wikipedia за информация, и  в нея да се тъпчи всичко за линукс, и да забранят на другите да пишат ли? Всеки иска да сподели, какво е научил, това е хубаво, защото така потребителя научава различни техники, и различни решения за всичко, няма такова нещо като универсален метод.

 

Има какво да се желае доста, но за потребител като мене, който никога почти не е ползвал Windows, тези неща не се забелязват :P.

Линк към коментара
Сподели в други сайтове

Е нали е отворен код  и никой не ги е натоварил със срокове и глоби ако ги не спазят. Ми да хванат една версия на графична среда  и да я направят  на 99%  готова и изпипана за ползване. Сменят тапета и 5 икони и айде нова версия :)  То е просто супер смешно и елементарно да му се не види и  работата . След  1 година като изчистят бъговете на оределена версия пък  да пуснат някакви нови фйчъри  и екстри да се тестват как работят от определен кръг от хора .  Да пускаш   полу-готови неща и да се надяваш на потребителителите  да ти фиксват  бъговете не е сериозно някак си. Ей го  тука има 200 000 потребителя  във форума  и съм сигурен ,че не повече от 30  имат хабер от програмиране  и писане на код над средното ниво.

Редактирано от AlkatrazBG (преглед на промените)
Линк към коментара
Сподели в други сайтове

Е нали е отворен код  и никой не ги е натоварил със срокове и глоби ако ги не спазят. Ми да хванат една версия на графична среда  и да я направят  на 99%  готова и изпипана за ползване. Сменят тапета и 5 икони и айде нова версия :)  То е просто супер смешно и елементарно да му се не види и  работата . След  1 година като изчистят бъговете на оределена версия пък  да пуснат някакви нови фйчъри  и екстри да се тестват как работят от определен кръг от хора .  Да пускаш   полу-готови неща и да се надяваш на потребителителите  да ти фиксват  бъговете не е сериозно някак си.

 

Че то дори след тестване и пускане, може да бъде открита грешка, вземи пример BASH, колко пъти трябваше да фиксват грешки, една след една. Потребителите не фиксват грешки, те по скоро ги докладват, и евентуално се взимат мерки.   По лошо от грешката, е само не оправената такава :D. Относно бързите версии, за това има LTS или както са RHEL,CentOS 10 години съпорт.

Линк към коментара
Сподели в други сайтове

@ivoarch Казвам, че няма синтезирана документация как е предвидено да се правят нещата, не някакви форум постове и wiki-та. Просо трябва примерно пичовете от Gnome да направят документация това трябва да се прави така и така и да се ползва това и това, + guide line за стиловете. То има наченки на нещо подобно в момента ама нивото е зле.
Другото което страшно куца са шернатите библиотеки и, че всяко дистро слага библиотеки и други неща където намери. Ето ти сега пресен пример при Ubuntu 15.04 решили да махнат libgcrypt 11 от репото и да го сменят с libgcrypt 20 и Spotify се усира, защото депендва на 11. Сега в случая софта ли е виновен или нещо друго?
Този въпрос ще се реши малко или много със Snappy пакетите и всякаквите други имплементации на контейнери, което си е ОК, ама защо трябваше да минат 6-7 години да стигнат до това велико заключение, при условие, че тези технологии ги има отдавна?
Другото което е, за 14-15 год откакто ползвам Линукс, не можаха да седнат да се разберат GTK и QT пичовете и да вкарат интерфейси за UI-то, поне за базовите widget-и. И сега си пускаш KDE-то и GTK-a приложенията са пълна боза, (айде да кажем обратното по не е така, поне QT са го докарали до GTK2).

Та има много неща, които мен, ако питаш всеки вижда, че са боза и не виждам защо не ги правят с приоритет, а гледат да бухат всевъзможни нови фийчъри.

Просто за да има някакъв стандарт мен, ако питате трябват някакви пичове като Poettering, Shuttleworth дето не им дреме, че другите реват и си вкарват нещата и тогава ще се оправи Dekstop-a. При кърнала нещата са си така в момента, Линус много често ги псува на майка и ги реже, без да му дреме, че има хора дето реват ( не е само той де, mailing листите там са интересни ).

Мен ми е кеф, че поне в последните няколко години започнаха да се случват неща.

п.с. Май доста избягахме от темата. Не смятам да спамя още. Ако някой има мерак да си отворим темичка и да си чешем езиците :)

 

п.с.2 В реда ми на мисли, developer-ите може да се force-нат да пишат софутер по стандарти, като се направи общо репо на приложения за всички дистрота. Там сяда community-то и разписва gideline за приложения и ако не си го спазил не можеш да си публикуваш app-a в официалните репота на всички дристрота. (пак ще има начин да се добави външно). Щото сега, както е никой не може да ме задължи, да напиша мега хакерията за декстоп, която не се връзва с нищо стандартно и да си я публикувам. Та аз като човек дето съм скаран страшно с UI-то ще го направя и от това ще страдат потребителите, пък, ако има кой да ме force-не може и да се замисля. Поне от моя гледна точка стоят така нещата.

Редактирано от borovaka (преглед на промените)
Линк към коментара
Сподели в други сайтове

Контейнерите не ми харесват, като идея. Както и не съм убеден, че с това което правят в момента ще оправят нещата. Но няма лошо да мислят в това направление.

 

И преди е изглеждало сякаш са постигали "остров на стабилност", които се разпадна с вкарването на нови функции и идеология. За мен основният проблем е в генералните промени по софтуера, без да се пазят предишните възможности и интеграция в системата. Нещата не се случват постепенно, особено при Linux.

 

Колкото до пакетите - да могат да преминат в един нов стандарт, логично е да се случи и може би и трябва. Но като цяло пакетите и управлението на софтуер-а работят почти идеално във всички Linux дистрибуции. Там не се случват проблемите, така че не е важно да се работи в тази посока.

Линк към коментара
Сподели в други сайтове

Другото което страшно куца са шернатите библиотеки и, че всяко дистро слага библиотеки и други неща където намери. Ето ти сега пресен пример при Ubuntu 15.04 решили да махнат libgcrypt 11 от репото и да го сменят с libgcrypt 20 и Spotify се усира, защото депендва на 11. Сега в случая софта ли е виновен или нещо друго?

Не, това е най-добрият вариант, в случая виновно е приложението - типично за програмисти на Windows. Зависимостта трябва да бъде към библиотека, а не към версия - т.е. когато излезе по-нова версия на библиотеката, приложението трябва да продължи да работи. Ако с новата версия се внасят основни промени и споделената библиотека не поддържа обратна съвместимост - трябва да се пренапише кода на приложението в по-нова версия. Не случайно KDE пренаписват или напасват приложенията с по-новите версии, защото примерно Qt5 премахна Qt3support. Йерархията в Линукс е супериорна, т.е. точно такава би трябвало да бъде.

Този въпрос ще се реши малко или много със Snappy пакетите и всякаквите други имплементации на контейнери, което си е ОК, ама защо трябваше да минат 6-7 години да стигнат до това велико заключение, при условие, че тези технологии ги има отдавна?

Тези пакети са голям недостатък и това ще се разбере много скоро, апропо в Андроид нещата са точно така - резултат Гугъл приложенията от по 9М станаха по 90, защото всички добавят едни и същи зависимости, но те не се решават глобално за системата, а локално за приложението. Много лош подход.

Другото което е, за 14-15 год откакто ползвам Линукс, не можаха да седнат да се разберат GTK и QT пичовете и да вкарат интерфейси за UI-то, поне за базовите widget-и. И сега си пускаш KDE-то и GTK-a приложенията са пълна боза, (айде да кажем обратното по не е така, поне QT са го докарали до GTK2).

Това може да стане само, ако ползваш софтуер като QtCurve - която зарежда теми за GTK приложения и има имплеmeнтиран layer (ниво) за комуникация с KDE базираните. Различието идва от това, че GTK описва стила на компонентите си във файлове, т.е темите им са xml със структурата и картинки с елементите, докато KDE темите, Oxygen/Breeze са споделени библиотеки, защото има само такъв интерфейс за темите. Такъв се предлага и от QtCurve. 

Редактирано от bvbfan (преглед на промените)
Линк към коментара
Сподели в други сайтове

Не, това е най-добрият вариант, в случая виновно е приложението - типично за програмисти на Windows. Зависимостта трябва да бъде към библиотека, а не към версия - т.е. когато излезе по-нова версия на библиотеката, приложението трябва да продължи да работи. Ако с новата версия се внасят основни промени и споделената библиотека не поддържа обратна съвместимост - трябва да се пренапише кода на приложението в по-нова версия. Не случайно KDE пренаписват или напасват приложенията с по-новите версии, защото примерно Qt5 премахна Qt3support. Йерархията в Линукс е супериорна, т.е. точно такава би трябвало да бъде.

Тези пакети са голям недостатък и това ще се разбере много скоро, апропо в Андроид нещата са точно така - резултат Гугъл приложенията от по 9М станаха по 90, защото всички добавят едни и същи зависимости, но те не се решават глобално за системата, а локално за приложението. Много лош подход.

Това може да стане само, ако ползваш софтуер като QtCurve - която зарежда теми за GTK приложения и има имплеmeнтиран layer (ниво) за комуникация с KDE базираните. Различието идва от това, че GTK описва стила на компонентите си във файлове, т.е темите им са xml със структурата и картинки с елементите, докато KDE темите, Oxygen/Breeze са споделени библиотеки, защото има само такъв интерфейс за темите. Такъв се предлага и от QtCurve. 

Направих нова тема във форума, за да продължим да си чешем езиците по темата, без да спамим текущата.

https://www.kaldata.com/forums/topic/241473-why-linux-sucks-for-desktop/

Линк към коментара
Сподели в други сайтове

За това обичам тази дистрибуция. 

http://s19.postimg.org/6pnj6zvw1/ubuntu14042.png

Във всяка поддържана версия, ползваш ядрото и драйвърите за видеото на всяка следваща.

Линк към коментара
Сподели в други сайтове

Добавете отговор

Можете да публикувате отговор сега и да се регистрирате по-късно. Ако имате регистрация, влезте в профила си за да публикувате от него.

Гост
Напишете отговор в тази тема...

×   Вмъкнахте текст, който съдържа форматиране.   Премахни форматирането на текста

  Разрешени са само 75 емотикони.

×   Съдържанието от линка беше вградено автоматично.   Премахни съдържанието и покажи само линк

×   Съдържанието, което сте написали преди беше възстановено..   Изтрий всичко

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Добави ново...

Информация

Поставихме бисквитки на устройството ви за най-добро потребителско изживяване. Можете да промените настройките си за бисквитки, или в противен случай приемаме, че сте съгласни с нашите Условия за ползване