Давайте форкнем иксы

Вот, нашёл что я имел ввиду https://arcan-fe.com/

https://bbs.archlinux.org/viewtopic.php?id=87281

• MicroXWin:
  (from their website) «X Window Systems is a standard graphics framework for Unix/Linux desktops. There are large number of GUI toolkits and applications already written for X Windows Xlib API. X Windows is a network oriented and client-server design with the X server responsible for all graphics operations.
  MicroXwin is binary compatible to the Xlib API. However it is neither client server nor network oriented. Graphics operations are implemented in the linux kernel via a kernel module. An open source Xlib library sends graphics commands to the kernel. There is no network overhead and no context switch from X client to X server. This makes our solution smaller and faster than traditional X Windows.
  Benefits Of MicroXwin
  Why should you consider using MicroXwin.
  Snappy GUI - MicroXwin has 2X times faster graphics, faster event handling, low latency and low round-trip delays.
  Lower Memory Usage - MicroXwin's kernel based X server uses < 1/2MB versus 19MB used by Xorg server on Fedora 7 distribution.
  Compatibility - MicroXwin is binary compatible with standard X11 at the Xlib layer. So you can run all the standard applications and window managers.
  Open Source Libraries- MicroXwin's user space libraries are open sourced allowing easy integration into customers platform. The kernel module is however proprietary.»
  
  My experience: I have not been able to get this to install. It wanted me to install regular X.Org libraries first and then build theirs and simply overwrite the regular X.Org files. I found this incredibly stupid and decided against it. It also kept complaining for old X.Org things like a rgb.txt file in the share folder, which I supplied, it continued and eventually failed on some [dmpsstr] not found issue. I decided it wasn't worth it. Anyone use succeed with this and/or enjoy it?
  
  Links: 1) http://www.microxwin.com/ 2) http://en.wikipedia.org/wiki/MicroXwin 3) http://bbs.archlinux.org/viewtopic.php?id=75646
  
  
• Y Window System:
  (from their site) «Network Transparency
  Contrary to popular belief, supporting network transparency does not reduce the speed of the window system on local hosts. Further, with Y's in-server knowledge of widgets, applications run over a slow network can appear almost as responsive as local applications (especially when compared to an X application).
  Modularity (plug-in style: dynamically unloadable and reloadable)
  Unload an old video driver, load a new version. On the fly. No restart in sight.
  In-server implementation of widgets
  Y specifies a core set of widget classes. Objects of these classes are stored in the server, where they are closer to the user and thus more responsive from the user's point of view.
  Consistency and Themeability
  Y widgets use the currently loaded theme to render themselves. Since all server widgets are using the same theme, all widgets appear consistent throughout the desktop. Client applications can also use the theme's drawing operations, allowing specialised widgets to make themselves fit in with the look-and-feel.
  Support for hardware acceleration
  The Y design can make use of hardware acceleration to speed up rendering operations. This can even include the use of 3D-accelerators' textures to draw windows with (someone has already implemented a prototype of this which is very smooth).
  Better internationalisation, localisation, and accessiblity
  In-server widgets means there can be exactly one current language, one complex input method system for languages that require them, and one set of accessibility features.»
  
  My experience: I installed all their dependencies with the exception of iterm (--disable-yiterm). It would always complain about wanting ( >= ) libsigc++-1.0 and on their site it says 1.2 will not work. So... Arch has a way newer version of this and so I downgraded to 1.0 (then later 1.1). It would continue to compile and finish successfully. I try to «make» and it fails almost immediately. I'm not on my Arch machine right now so I can't supply the error but I doubt it's worth it. This project is very old and I think it's abandoned.
  
  Links: 1) http://www.y-windows.org/ 2) http://en.wikipedia.org/wiki/Y_Window_System
  
  
• DirectFB:
  (from Wikipedia) «DirectFB stands for Direct Frame Buffer. It is a software library for the GNU/Linux operating system that provides „hardware graphics acceleration, input device handling and abstraction, integrated windowing system with support for translucent windows and multiple display layers on top of the Linux Framebuffer Device.“
  The library allows developers an alternative to a full X Window System server used in Unix-like operating systems. DirectFB allows applications to talk directly to video hardware through a direct API, speeding up and simplifying graphic operations.»
  
  My experience: I haven't tried this yet nor I have I seriously researched it. Sorry. AFAIK, you can use it as a replacement for X. Anyone try this? Also, I couldn't get their official website to load. Maybe it's down right now. Also, it seems that DirectFB will not work in KMS with Intel, for those who need this.
  
  Links: 1) http://www.directfb.org/ 2) http://en.wikipedia.org/wiki/DirectFB 3) http://www.mail-archive.com/directfb-us … 06248.html 4) http://nanl.de/blog/2009/10/gtk2-runnin … n-openwrt/ 5) http://qt-directfb.sourceforge.net/story.html 6) http://www.daa.com.au/pipermail/pygtk/2 … 17214.html 7) http://bbs.archlinux.org/viewtopic.php?id=70324 (about KMS issue)

• Xynth Window System:
  (from their site) «Xynth is a portable embedded windowing system, client/server interface between display hardware (mouse, keyboard, video displays) and the desktop environment that works on many hardware, including embedded devices (handhelds, set-top boxes, etc.).
  Features
  * TCP/IP (allows client/server connection on different hosts)
  * UDS (Unix Domain Sockets)
  * pipe() based socket api implementation. usefull for embedded devices. (there is no dependency for TCP/IP stack, if clients and server linked in singled app.)
  * Memory based pipe(), read(), send(), poll() implementation. xynth is able to work even there is no file descriptor on system.
  * mutex and condition variables implementation using semaphores.
  * DMA (Direct Memory Access). allows clients to draw directly on graphics buffer.
  * Buffer streaming (allows client/server connection on different hosts)
  * Move, 8-way resize
  * Optional theme plugin support. (theme_*.so)
  .xpm to .so tool.
  * Anti-aliased fonts with Freetype Library.
  * Anti-alias enabled low-level graphics library.
  (rgbcolor, colorrgb, setpixel, getpixel, hline , vline, fillbox, putbox, putboxmask, getbox, putboxpart, putboxpartmask, copybox, scalebox, getsurface, setsurfacevirtual, setsurface)
  * Anti-alias enabled overlay drawing ability.
  (rgbcolor_o, colorrgb_o, setpixel_o, getpixel_o, hline_o, vline_o, fillbox_o, putbox_o, putboxmask_o, getbox_o, putboxpart_o, putboxpartmask_o, copybox_o, getsurface_o, setsurfacevirtual_o, setsurface_o)
  * Basic image library.
  (xpm, png, gif)
  * Basic widget library.
  (object, frame, button, checkbox, textbox, scrollbuffer, listbox, controllistbox, pushbutton, etc.)
  * Low Memory & CPU Usage;
  In 1024x768x32bits mode with 253 clients open mem. usage is ~2,5M
  * Static linked binary : ~125K
  ...... snipped ......
  My experience: I haven't tried this as of yet but I'm looking forward to trying. Now it says embedded systems but I'm guessing it will work on a regular desktop the same way as things like gtk2 are ported. I didn't get anything from the Forum Search so I'm curious if anyone else has tried this yet.
  
  Links: 1) http://alperakcan.org/?open=projects&project=xynth 2) http://en.wikipedia.org/wiki/Xynth
  
  
• Fresco:
  (from their site) » Fresco is a windowing system derived from a powerful structured graphics toolkit originally based on InterViews. Fresco extends earlier incarnations to the status of a full windowing system, in command of the video hardware (via GGI, SDL, DirectFB or GLUT) and processing user input directly rather than peering with a host windowing system.
  
  Additionally, Fresco's extensions include a rich drawing interface with multiple backends, an upgrade to modern CORBA standards, a new Unicode-capable text system, dynamic module loading, and many communication abstractions for connecting other processes to the server. It is developed entirely by volunteers on the internet, using free software, and released under the GNU Lesser General Public License. "
  
  My experience: I have not tried this but at least it's another alternative. I see the imagery isn't that pretty but that won't stop me from trying it. I didn't get any search results for this either, so has anyone else even tried it? Their website says this: «Fresco is not yet ready to replace X (or any other windowing system) for even the most adventurous of users. However, if you want to try it out for yourself or assist with development, then you'll need to get it running. We recommend that developers check out the latest version from CVS; those looking to experiment can try their luck with the latest development code, or use one of our occasional Releases. In either case, once you've gotten the source, you'll want to read the instructions on how to install. » So I'm guessing it's not really usable. I'll see about experimenting.
  
  Links: 1) http://www.fresco.org/ 2) http://en.wikipedia.org/wiki/Fresco_(windowing_system) 3) http://linux.softpedia.com/get/Desktop- … 7785.shtml
  
  
• Metisse:
  (from their site) «Metisse [1, 2, 3] is an X-based window system designed with two goals in mind. First, it should make it easy for HCI researchers to design and implement innovative window management techniques Second, it should conform to existing standards and be robust and efficient enough to be used on a daily basis, making it a suitable platform for the evaluation of the proposed techniques.
  
  Metisse is not focused on a particular kind of interaction (e.g. 3D) and should not be seen as a new desktop proposal. It is rather a tool for creating new types of desktop environments.
  
  Metisse was used, for example, to implement the User Interface Façades system, a system that allows to adapt, reconfigure, and re-combine existing graphical interfaces through direct manipulation techniques. It was used by Mekensleep to integrate GTK+ interfaces into the OpenGL-based Pok3D game. Distributed as a ``Live CD" by Mandriva in early 2007, Metisse is now available as one of the standard desktop configurations in the Mandriva Linux distribution.»
  
  My experience: Have not tried this only because I'm not sure I can. Mandriva's site say it's not for 64-bit (soon, it says) and some people report compile errors for 64-bit while other says it works flawlessly. This is sad to me as it seems really nice and I'm not sure I'll be able to use it but I'm sure someone has tried it at one point or time as it can be used in Mandriva and Gentoo and I'm sure many others.
  
  Links: 1) http://insitu.lri.fr/metisse/ 2) http://en.wikipedia.org/wiki/Metisse 3) http://www.mandriva.com/archives/en/pro … e/faq.html 4) http://www.youtube.com/watch?v=dxsUKX6xXyE
  
  
• KDrive (or TinyX):
  (from their site) «KDrive (Tiny X, TinyX) is an X server written by Keith Packard that was designed for low memory environments. On Linux/x86, a KDrive server with RENDER support but without support for scalable fonts compiles into less than 700 KB of text. KDrive tends to avoid large memory allocations at runtime, and tries to perform operations „on the fly“ whenever possible (but this is also true of recent versions of the stock XFree86 server). »
  
  My experience: Well, I haven't had any experience with this. It seems a nice alternative to the «big» version of X if you're going to be stuck with X.Org anyways. I guess if you really don't want to let go of your X applications. tongue I may actually end up doing this if I can't get any of the others to work. Anyone else here use a dedicated KDrive?
  
  Links: 1) http://www.pps.jussieu.fr/~jch/software/kdrive.html 2) http://en.wikipedia.org/wiki/KDrive

Твой переиначенный протокол ломает совместимость со старыми приложениями. Тебе придется пилить слой совместимости. Чем твой условный X12 лучше вайланда, если оба нарушают обратную совместимость?

А чего сразу не взять исходники Xsun из старого Solaris’а? Там вообще ничего «лишнего».

На самом деле X Window System всегда был набором отвратительных костылей.

Тут можно причаститься ненавистью из начала 90х

Твой переиначенный протокол ломает совместимость со старыми приложениями.

Не факт. Я сейчас имею ввиду всякие абсолютно безумные расширения, которые напилили 20 лет назад и которые сегодня никому не нужны.

Тебе придется пилить слой совместимости. Чем твой условный X12 лучше вайланда, если оба нарушают обратную совместимость?

Тем, что вялянд говно не столько из-за нарушения обратной совместимости. Он говно по огромной куче причин, и обратная совместимость – наименьшая из них.

Опять же, никто не мешает поддерживать две версии протокола. Старая идёт дефолтом, но клиент может попросить новую.

А чего сразу не взять исходники Xsun из старого Solaris’а? Там вообще ничего «лишнего».

На самом деле X Window System всегда был набором отвратительных костылей.

Тут можно причаститься ненавистью из начала 90х

Там нытьё в духе «ололоэ почему они не сунули иксы в ядро как это сделал microsoft в nt». Типа, да, на говножелезе из 80х это бы решило тормоза. Сегодня это ни разу не актуально.

ты полностью прочитай. Когда это писалось до выхода Windows NT (3.5) было еще 4 года

Не факт. Я сейчас имею ввиду всякие абсолютно безумные расширения, которые напилили 20 лет назад и которые сегодня никому не нужны

Выкинув старые расширения ты лишь немного расчистишь кодовую базу. Проблемы вроде тиринга, отсутствия элементарной безопасности и нормального протокола захвата экрана ты не решишь.

Тем, что вялянд говно не столько из-за нарушения обратной совместимости

Это не ответ. Почему вайланд говно и чем именно твой X12 будет лучше?

Не факт. Я сейчас имею ввиду всякие абсолютно безумные расширения, которые напилили 20 лет назад и которые сегодня никому не нужны

Выкинув старые расширения ты лишь немного расчистишь кодовую базу. Проблемы вроде тиринга, отсутствия элементарной безопасности и нормального протокола захвата экрана ты не решишь.

Проблема тиринга давно решена в иксах на уровне драйверов. Уже сегодня, вот прямо сейчас. Элементарную безопасность можно запилить без нарушения совместимости. Захват экрана в иксах куда лучше вялянда работает.

Тем, что вялянд говно не столько из-за нарушения обратной совместимости

Это не ответ. Почему вайланд говно и чем именно твой X12 будет лучше?

Я тебе – да, вот лично тебе! – минимум в трёх разных тредах уже писал, почему вялянд сосёт. Иди перечитай.

Проблема тиринга давно решена в иксах на уровне драйверов

Сами по себе 2d-драйверы — лютый костыль. А TearFree называют говном сами разработчики иксов. Что ты можешь сказать про безопасность и захват экрана?

Я тебе – да, вот лично тебе! – минимум в трёх разных тредах уже писал, почему вялянд сосёт

Ты не объяснил. Ты выдавал перлы в духе «говно у тебя в штанах» в ответ на предложение конструктивно раскритиковать вайланд и предложить правильное решение проблемы. Если я пропустил аргументы в потоке твоих рассуждений о говне в штанах – дай ссылки на конкретные сообщения

let array = [ 1 2 3 4 5 ]
echo @array[0]
echo @array[2..=4]

Это что как в пёрле помнить что означают @/#/$/% перед именами переменных?

Захват экрана в иксах куда лучше вялянда работает

Он работает отвратительно.

Элементарную безопасность можно запилить без нарушения совместимости

Как?

Think twice before abandoning Xorg. Wayland breaks everything!
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

Он работает отвратительно.

4.2 же. Захват всего экрана работает превосходно. Есть проблемы с захватом отдельных окон, если они находятся на разных виртуальных рабочих столах, но это зависит в основном от WM я так понимаю, а не от самих иксов.

Как?

Просто добавить в код Xorg функционал ограничений доступа к функциям получения фреймбуфера, а не отдавать его по первому требованию. Для программы управления доступом можно создать отдельный протокол в виде расширения.

Захват всего экрана работает превосходно

Он работает отвратительно. Любое окно может получить доступ ко всему вводу и выводу без спроса. Захват экрана не работает без композитора (с композитором, кстати, тоже не всегда; в picom не работает).

Как будет работать этот код, если все окна обрабатываются в одном потоке?

Это что как в пёрле помнить что означают @/#/$/% перед именами переменных?

Сравни с Bash для разнообразия.

Особенно синтаксис итераций, извлечения элемента массива и т.п.

сами разработчики иксов

Не разработчики иксов это, а вредители вялендовские! Враг в стенах нашей крепости! Покайтесь!!1

Есть проблемы с захватом отдельных окон, если они находятся на разных виртуальных рабочих столах, но это зависит в основном от WM я так понимаю, а не от самих иксов

Кто там критиковал вайланд за зоопарк несовместимых композиторов?

в picom не работает

Опять 4.2

Захват экрана не работает без композитора

В i3wm без композитора работают и скриншоты и obs. Или ты не то имел в виду?

Вы всё врётиии!

Почему он не работал у меня в i3? Когда я переключал фокус на другое окно или перемещал записываемое окно на другой воркспейс — запись ломалась

Глюки WM != несовместимые WM. Протокол общий, но конкретно в i3 нельзя транслировать окно, если оно не на текущем рабочем столе. Я так понимаю, он тупо не рендерит вне текущего рабочего стола.

Он не умеет захватывать окна. Без композитора перемещение окна на другой воркспейс или переключение фокуса приводит к «потере» окна на записи

Это баги i3, связанные скорее всего с неотрисовкой окон вне текущего воркспейса.

Это не глюки. Это отсутствие нормального, не зависящего от wm композитора, полностью реализующего стандарт.

Он не умеет захватывать окна.

Умеет.

Без композитора перемещение окна на другой воркспейс или переключение фокуса приводит к «потере» окна на записи

А вот тут да.

А вот тут да.

Если это называется «умеет захватывать окна», то Цой живее всех живых

Это баги i3, связанные скорее всего с неотрисовкой окон вне текущего воркспейса

В кедах наблюдался тот же эффект

А что это, если не захват окна?

Это недоделанная реализация некой функции, не работающая должным образом

Но тем не менее, она работает ;)

Она не работает. Она создает иллюзию работоспособности, пока записываемое окно и obs находятся в одном воркспейсе и записываемое окно активно.

bash ужасен - это не спорю

Этой иллюзии вполне достаточно, если я, например, хочу сделать запись работы в какой-нибудь программе.

Эту иллюзию нельзя назвать «работоспособностью»

DO IT FAGGOT!

Почему? Она же работает.

Причём у меня в i3wm захват продолжает работать даже при переключении фокуса на другое окно. Даже если я спрячу окно в tabbed. Единственное, когда окно пропадает из захвата - когда я перемещаю его в другой воркспейс. Так что работает захват и работает неплохо ИМХО.

Найдём и откатим все вредоносные коммиты от агентов вайланда

Откровенно вредоносных коммитов я не помню. Есть спорные моменты, но к вредоносному они не относятся. Я бы пока не трогал.

А вообще есть смысл, но только если добавлять фичи.

все проблемы которые выяснятся с иксами у лоровцев

Да проблем то особо и нет. Все проблемы на десктопе в 95% случаев как правило касается тулкитов, а именно GTK3. Нужно его в первую очередь форкнуть, а то вредители уже выбрасывают из DE те фичи, которые в GTK3/Wayland не работают.

Даже уже есть starter pack.

Я всячески слышу, что он рулез, но нет ни одного дистрибутива, который его бы юзал и как поюзать не понятно, кроме как красноглазить и компилять.

Это хреновая подача продукта.

Я знаю девелопера, который вдохнёт новую жизнь иксам, внеся в них php ;)

Во-первых, не оскорбляй меня девелопером, я всего лишь макака с пет-прожектом;

Во-вторых через пару лет поговорим, когда приползешь за багфиксом, а он будет начинаться с <?php

=))

Думаем что самая главная проблема Иксов - всратая архитектура с минимумом спецификаций и рабочих примеров, чтоб человек просто сел, прочитал, и начал под это программировать.

Решения - неоднозначные. Чего только системный трей стоит - с такой тривиальной задачей как просто прочитать приложения с определенным признаком - без бутылки и малой кровью не разберешься.

Форкнуть-то можно. Но незачем. В принципе все проблемы, с которыми встречается конечный пользователь - уже давно решены.

Остались проблемы для программистов, а их решать нужно последовательно и комплексно, не на тяп-ляп.

Взяли блок с кривой архитектурой->написали правильно блок с таким же функционалом + снабдили транслятором искаропки, чтобы новые программы могли использовать новые фичи, но старые при этом не превращались в тыкву->через 5 лет депрекейтнули->через 10 лет дропнули.

И тогда через 10 лет у нас будет изящное графическое решение.

А вот эти форки форков, патчи на патчи - всего лишь вносят хаос и мешают этим пользоваться даже тем, кто хочет.

Уже было: https://www.y-windows.org

Дамы и господа, а вот и он сам! :-)))

За 25 рублей в час?

Неет, ты чего. Гораздо-гораздо опытнее в графическом стеке!

Немного тёплого лампового ШГ нам в хату

Как-то пропустил я эту хтонь. Что ж, смело!

Так там PHP for Windows, это ведь уже почти C++.