WindowMaker продолжает трудиться

WindowMaker как всегда прекрасен. Единственный лучик света в царстве низкопробных васянских полурабочих иксовых менеджеров окон.

В похожем на WindowMaker легендарном окружении легендарные программисты сделали легендарные Doom и Quake.

О, супер. Несколько лет сидел в нём в Gentoo, но он внезапно прекратил развиваться и обновляться. Слышал что недавно он снова ожил. Благодарю за скриншот, наверное снова поставлю, посмотрю как там сейчас.

Мне аж прям интересно стало: чему развиваться и обновляться в WindowMaker? Он же выглядит почти неизменно с тех времён, как у меня первый компьютер появился.

Я сейчас уже не помню, кажется когда hal выпиливали он продолжал от него зависить, или ещё что то там было такое. Короче возникло ощущение заброшенности. Часть dockapps не работала... А пару лет назад в сам проект какие то освежающие патчи были приняты, я новость про это помню. Дело то не в том как он выглядит, а от чего он зависит и от чего зависят его dockapps.

Обновление компонентов GNUstep

Вот, нашёл. Это про GNUStep, но dockapps windowmaker это dockapps GNUStep.

Ужасно

Мне в своё время показался удобным. Тогда как раз мониторы начались 16:9 и 16:10 и dockapps, и свёрнутые программы рационально для такого соотношения слева-справа укладывались. Да, в любом DE можно туда панели вынуть, но тут ещё NextStep эстетика + непохожесть на всеми любимые два основных DE. В тайлы я так и не въехал, а вот WidowMaker внезапно прижился аж на несколько лет. Но это было очень давно и сейчас я снова на KDE.

За WindowMaker зачёт.

Я скорее про UI. Про UX судить не могу, ибо не сталкивался с сабжем. Но чисто визуал это не.

windowmaker прекрасен, но у него есть баг, когда подключено несколько мониторов - приложения из «трея» по щелчку по ним - пропадают, из-за этого не смог им пользоваться.

Автору скриншота почет и уважение, с удовольствием всегда смотрю ваши скрины.

ну как. Когда-то подобный интерфейс некстепа развился в макось, так-что развиваться есть куда. Вопрос в другом - надо ли?

Дак как раз нет. У классической МакОС совершенно другой интерфейс, с другой философией. Интерфейс NextStep загнулся вместе с компьютерами Next и был возрождён энтузиастами в виде WindowMaker. Других потомков у него нет.

У классической - да, но я про Mac OS X. В ранних версиях прям местами видны схожие с виндоумейкером элементы. Да и док похожий, чоуж там. Ну и GNUStep - это вроде как свободная реализация cocoa, бывшая openstep.

Про GNUstep да, это именно что бывшая Openstep. А вот ранние MacOS X я только на картинках видел и сходства не замечал. А вот на классику нагляделся в своё время.

Для 4К мониторов один чувак перепиливает масштабируемые докаппы https://gitlab.com/xander1988/dockapps

работает, коэффициент кратный двум только.

У разработчиков wmaker'а есть планы на вейланд? Или кто-нибудь с нуля запилит клон?

Обновление компонентов GNUstep

GNUstep GUI Backend 0.29.0 - набор бэкендов для GNUstep GUI Library, в котором реализована поддержка X11 и графики Windows. В ней реализована поддержка Wayland, а также улучшена поддержка менеджера окон WindowMaker и API Win64

В wmaker'e нет ничего от гнустепа, там же свой тулкит wings.

Докаппы я от гнустепа там использовал помнится. Ну и по зависимостям он тянулся. Возможно ты прав, давно пользовался, плохо помню.

готовы принять если кто-то напогромирует https://groups.google.com/g/wmaker-dev/c/D88eczn-3Aw/m/Wi9sCzrKAgAJ

хз как ссылку на этот гугл вставить

зы, а вообще, вайланд виндовмэйкеру не нужен ;)

Очень интересный оконный менеджер. Правда, возникли трудности с его настройкой. Ещё не нашёл на него тем с современным дизайном. Нет, я не против ламповых тем из 90-ых-начала нулевых, но этот дизайн плохо сочетается с дизайном современных приложений. А так бы пользовался

Мой первый оконный менеджер в Linux (Red Hat 5.2) и самый необычный, как мне тогда показалось.

Сам факт того, что ТС десятилетия юзает то, что я не смог бы юзать и 10 минут уже вызывает уважение… Респект.

зы, а вообще, вайланд виндовмэйкеру не нужен ;)

Иксы в идеале WindowMaker’у тоже должны были быть не нужны. Оригинальный проект абсолютно никак с этими иксами не связан, он отрисовывал окошки через мощный Display PostScript. На момент конца 80-ых годов подобный способ отрисовки был прорывным и революционным, он уже тогда оставлял устаревший X11 со всеми его реализациями далеко позади:

https://baat.z-lab.me/~exl_lab/screens/NeXTSTEP_Display_PostScript_Rocks.png
https://baat.z-lab.me/~exl_lab/screens/NeXTSTEP_Display_PostScript_Rocks1.png

https://raw.githubusercontent.com/EXL/2048/master/image/ProjectBuilder-NeXTSTEP-Screenshot.png
https://raw.githubusercontent.com/EXL/2048/master/image/InterfaceBuilder-NeXTSTEP-Screenshot.png
https://raw.githubusercontent.com/EXL/2048/master/image/2048-NeXTSTEP-Screenshot.png

Именно благодаря Display PostScript в NeXTSTEP OS современные macOS и iOS не используют какую-либо ущербную реализацию X11 сегодня, а используют Quartz/PDF. Перед разработчиками Apple в далёком начале нулевых стоял вопрос, выбрать ли X11 или пилить сразу нормальный графический стек. На слешдоте было где-то интервью с главным разработчиком Quartz в Apple и он там отвечает почему они не выбрали X11, если кому интересно – найду ссылку.

Увы, что иксовая или если в будущем появятся Wayland’овая версии WindowMaker без Display PostScript будут лишь блёклыми клонами оригинального проекта.

Навеяло прекрасные времена Кр. Ш. 7.2

Надо поставить на фрю.

На слешдоте было где-то интервью с главным разработчиком Quartz в Apple и он там отвечает почему они не выбрали X11, если кому интересно – найду ссылку.

Интересно.

AeroSnap так и не появился?

За WM зачет. А я, правда, так себя и не смог заставить сидеть на нем больше 1-2 дней. Слишком много информации вокруг. Люблю когда все минимально.

На момент конца 80-ых годов подобный способ отрисовки был прорывным и революционным, он уже тогда оставлял устаревший X11 со всеми его реализациями далеко позади:

DPS с иксами таки поставлялся когда-то.

https://www.x.org/releases/X11R7.5/doc/graphics/dps.html

Во-первых, DPS не предоставлял оконной системы. То есть противопоставлять X11 и DPS вообще как-то странно. DPS не была оконной системой и в NeXT, там была своя оконная система, в которой DPS работал.

The main underlying concept of Display PostScript is to isolate the display operation from not only the host computer's operating system but also from its windowing system. The core of Display PostScript fits inside the host windowing system, which in this case is the NeXT windowing system, although it could be anything from Microsoft Windows to X-Windows to QuickDraw.

По сути своей это просто рисовательное API, состоящее из серверной части и клиентской библиотеки. Adobe все это и для иксов делало [1].

Во-вторых, для DPS надо с X-сервером довольно сложную реализацию таскать (ее и таскали). А потом пришли [2] к тому, чтобы функциональность аналогичную DPS перетащить на сторону X-клиентов, а на стороне X-сервера оставить некий простой базис. Таким базисом стало расширение X Render Extension. А клиентам предоставили возможность использовать, например, cairo в качестве высокоуровневой библиотеки. Можно и свои писать высокоуровневые библиотеки.

[1] https://www.adobe.com/content/dam/acom/en/devnet/postscript/pdfs/DPS.refmanua...

[2] At the time when I started this project, there was no decent rendering interface for X11 other than DPS. Since then, there has been a large amount of work on a simple and clean X server extension, Xrender, which provides the basis for just such an interface. http://dps.sourceforge.net/

зы, а вообще, вайланд виндовмэйкеру не нужен ;)

Как бы нам не хотелось, но за вейландом будущее, поэтому в перспективе они нужны друг другу.

DPS надо противопоставлять с Xlib вкупе с Xt => Xaw, Xt => Xm.

Годы шли, но в реализациях X11 так не родилось нормального графического тулкита, что кстати и стало причиной возникновения Qt вкупе с GTK+ и постепенного полного забвения и забрасывания Xlib/Xaw/Xt. Тот базис, который мог бы объединять графические тулкиты, почему-то перестал развиваться. К чему в итоге всё пришло? Настоящая сетевая прозрачность мертва, гоняем битмапы. Отрисовка через примитивы Xlib мертва, рисуем битмапы и т. д.

DPS с иксами таки поставлялся когда-то.

Да, и свободные реализации были тоже. Вот если бы WINGs из WindowMaker их использовал, это было бы интересно. Но похоже что их загубило вот это: http://dps.sourceforge.net/index-old.html#LICENSING

Интересно.

https://developers.slashdot.org/comments.pl?sid=75257&cid=6734612

Хороший скрин. Пользовался WM и AfterStep когда-то.

Выглядит все отлично. Как всегда.

Ужасно

Почему?

У разработчиков wmaker’а есть планы на вейланд?

Нет.

Или кто-нибудь с нуля запилит клон?

Начни.

DPS надо противопоставлять с Xlib

DPS does not offer the following:

- the ability to manipulate windows or handle events in PostScript code (sorry to all you NeWS fans);

- support for games (animations in DPS tend to run smoothly for a while, then halt for a fraction of a second as the server collects garbage);

- support for 3D graphics (use GLX for that);

- a complete alternative to X11.

Нет, Xlib - это далеко не только рисовательное API, но и API оконной системы, чего не было в DPS. В разрезе DPS можно рассматривать только запросы рисования в X11 Core Protocol. DPS пересылало код на аля-PostScript, который исполнялся на стороне X-сервера. Потом было предложено сделать векторную отрисовку на стороне X-клиента, а на стороне сервера оставить минималистический X Render (Keith Packard запилил). Cairo как раз имеет модель типа PostScript, но только на стороне X-клиента.

Qt вкупе с GTK+ и постепенного полного забвения и забрасывания Xlib.

До сих пор бэкенд xcb у всех них есть. Они без него не смогут в X Window System работать, хотя бы окно создать. Рисование же примитивами X11 Сore Protocol они не используют. Однако GTK3 даже до сих пор рендерит в X Render Extension (Qt5 уже нет):

$ xtrace inkscape | grep "RENDER"
[...]
000:<:1451: 20: RENDER-Request(139,30): SetPictureFilter picture=0x02600499 name='nearest' values=;
000:<:1452: 36: RENDER-Request(139,8): Composite op=Over(0x03) src=0x02600499 mask=None(0x00000000) dst=0x0260048c xSrc=0 ySrc=0 xMask=10 yMask=9 xDst=10 yDst=9 width=16 height=16
000:<:1453:  8: RENDER-Request(139,7): FreePicture picture=0x02600499
000:<:1457:  8: RENDER-Request(139,7): FreePicture picture=0x0260048c
000:<:145c: 24: RENDER-Request(139,4): CreatePicture pid=0x0260049b drawable=0x0260049a format=0x0000002a values={poly-mode=Imprecise(0x01)}
000:<:145d: 28: RENDER-Request(139,26): FillRectangles op=Minimum/Clear(0x00) dst=0x0260049b color={red=0x0000 green=0x0000 blue=0x0000 alpha=0x0000}; rects={x=0 y=0 w=36 h=34};
000:<:145e: 28: RENDER-Request(139,26): FillRectangles op=Src(0x01) dst=0x0260049b color={red=0xf6f6 green=0xf5f5 blue=0xf4f4 alpha=0xffff}; rects={x=0 y=0 w=36 h=34};
000:<:1460: 24: RENDER-Request(139,4): CreatePicture pid=0x0260049d drawable=0x0260049c format=0x00000026 values={poly-mode=Imprecise(0x01)}
000:<:1461: 28: RENDER-Request(139,26): FillRectangles op=Minimum/Clear(0x00) dst=0x0260049d color={red=0x0000 green=0x0000 blue=0x0000 alpha=0x0000}; rects={x=0 y=0 w=1 h=1};
000:<:1462: 28: RENDER-Request(139,26): FillRectangles op=Src(0x01) dst=0x0260049d color={red=0xcdcd green=0xc7c7 blue=0xc2c2 alpha=0xffff}; rects={x=0 y=0 w=1 h=1};
000:<:1463:  8: RENDER-Request(139,7): FreePicture picture=0x0260049d
000:<:1466: 24: RENDER-Request(139,4): CreatePicture pid=0x0260049f drawable=0x0260049e format=0x00000026 values={poly-mode=Imprecise(0x01)}
000:<:1467: 28: RENDER-Request(139,26): FillRectangles op=Minimum/Clear(0x00) dst=0x0260049f color={red=0x0000 green=0x0000 blue=0x0000 alpha=0x0000}; rects={x=0 y=0 w=1 h=1};
000:<:1468: 28: RENDER-Request(139,26): FillRectangles op=Src(0x01) dst=0x0260049f color={red=0xcdcd green=0xc7c7 blue=0xc2c2 alpha=0xffff}; rects={x=0 y=0 w=1 h=1};
000:<:1469:  8: RENDER-Request(139,7): FreePicture picture=0x0260049f
000:<:146b: 28: RENDER-Request(139,26): FillRectangles op=Src(0x01) dst=0x0260049b color={red=0xf6f6 green=0xf5f5 blue=0xf4f4 alpha=0xffff}; rects={x=0 y=0 w=36 h=34};
000:<:146c:304: RENDER-Request(139,10): Trapezoids op=Over(0x03) src=0x02600313 xSrc=2 ySrc=0 dst=0x0260049b maskFormat=0x00000024 trapezoids={top=1.000000 bottom=1.464844 left={x1=2.203125 y1=0.851562 x2=1.464844 y2=1.464844}; right={x1=33.789062 y1=0.851562 x2=34.531250 y2=1.464844};},{top=1.464844 bottom=2.023438 left={x1=1.464844 y1=1.464844 x2=0.851562 y2=2.203125}; right={x1=34.531250 y1=1.464844 x2=35.140625 y2=2.203125};},{top=2.023438 bottom=2.031250 left={x1=1.000000 y1=1.000000 x2=1.000000 y2=33.000000}; right={x1=34.531250 y1=1.464844 x2=35.140625 y2=2.203125};},{top=2.031250 bottom=31.960938 left={x1=1.000000 y1=1.000000 x2=1.000000 y2=33.000000}; right={x1=35.000000 y1=1.000000 x2=35.000000 y2=33.000000};},{top=31.960938 bottom=31.968750 left={x1=1.000000 y1=1.000000 x2=1.000000 y2=33.000000}; right={x1=35.140625 y1=31.789062 x2=34.531250 y2=32.531250};},{top=31.968750 bottom=32.531250 left={x1=0.851562 y1=31.789062 x2=1.464844 y2=32.531250}; right={x1=35.140625 y1=31.789062 x2=34.531250 y2=32.531250};},{top=32.531250 bottom=33.000000 left={x1=1.464844 y1=32.531250 x2=2.203125 y2=33.140625}; right={x1=34.531250 y1=32.531250 x2=33.789062 y2=33.140625};};
000:<:146d:2184: RENDER-Request(139,10): Trapezoids op=Over(0x03) src=0x026000ec xSrc=5 ySrc=0 dst=0x0260049b maskFormat=0x00000024 trapezoids={top=0.000000 bottom=0.097656 left={x1=5.000000 y1=0.000000 x2=3.988281 y2=0.097656}; right={x1=31.000000 y1=0.000000 x2=32.003906 y2=0.097656};},{top=0.097656 bottom=0.390625 left={x1=3.988281 y1=0.097656 x2=3.054688 y2=0.390625}; right={x1=32.003906 y1=0.097656 x2=32.941406 y2=0.390625};},{top=0.390625 bottom=0.851562 left={x1=3.054688 y1=0.390625 x2=2.203125 y2=0.851562}; right={x1=32.941406 y1=0.390625 x2=33.789062 y2=0.851562};},{top=0.851562 bottom=1.000000 left={x1=2.203125 y1=0.851562 x2=1.464844 y2=1.464844}; right={x1=33.789062 y1=0.851562 x2=34.531250 y2=1.464844};},{top=1.000000 bottom=1.078125 left={x1=31.000000 y1=1.000000 x2=31.800781 y2=1.078125}; right={x1=33.789062 y1=0.851

[...]

Красиво, свежо и оригинально, но совсем не то, чем я мог бы пользоваться.

Нет, Xlib - это далеко не только рисовательное API, но и API оконной системы, чего не было в DPS.

Стоп, так это ты перечислил всё то, чего нет в реализации Display PostScript для иксов от Adobe (или её свободной реализации), которая была сделана по остаточному принципу, там действительно только рисовательное API. Но в тех доработанных разработчиками из SUN и NeXT реализациях DPS, которые были в NeXTSTEP и NeWS, API оконной системы имелось и работало.

The developers of NeXT wrote a completely new windowing engine to take full advantage of NeXT’s object-oriented operating system. A number of commands were added to DPS to actually create the windows and to react to events, similar to but simpler than NeWS.

https://en.wikipedia.org/wiki/Display_PostScript#History

Так что сравнивать NeXTSTEP’овский DPS с Xlib и даже со всем X11 вполне себе справедливо и очень даже оправдано.

Например, см. описание операторов реализации Display PostScript из официальной документации NeXTSTEP:

https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/GeneralRef/05_DisplayPS/Operators/PSOperators.htmld/index.html

Там имеются как операторы создания окна, так и операторы получения списков окон, получения списков screen, управления курсором, отправки event’ов и есть всё остальное, чем обычно занимается оконная система и тулкит поверх неё.

window: Creates a window that has a lower left corner of (x, y) and the indicated width and height. x, y, width, and height are given in the screen coordinate system…

windowlist: Fills the array with the window numbers of all windows that are owned by the PostScript context specified by context…

seteventmask: Sets the Server-level event mask for the specified window to mask. For windows created by the window packages, this mask may allow additional event types beyond those requested by the application. The following operand names are defined for mask: Lmousedownmask Mouse-down, left or only mouse button; Lmouseupmask Mouse-up, left or only mouse button; Keydownmask Key-down; Keyupmask Key-up; Kitdefinedmask Kit-defined; Sysdefinedmask System-defined; Appdefinedmask Application-defined; Allevents All event types

posteventbycontext: Posts an event to the specified context. The nine parameters preceding the context parameter coincide with the NXEvent

adjustcursor: Moves the cursor location by (dx, dy) from its current location. dx and dy are given in the current coordinate system.

termwindow: Marks window for destruction

Вполне себе такой аналог Xlib на DPS, а не какое-то там «рисовательное API», не так ли?

А вот для 3D-графики в NeXTSTEP действительно был не OpenGL, а RenderMan того самого Pixar, владельцем которого был ещё Steve Jobs: https://en.wikipedia.org/wiki/Pixar_RenderMan, который кстати хотел чтобы он стал таким же стандартом в компьютерной графике, каким был PostScript в те годы в компьютерной типографике.

Our goal is to make Renderman and Iceman the system software of the 90s," Mr. Jobs said, likening these programs to PostScript, the software developed by Adobe Systems Inc. for high-quality typography.

Как же я люблю эти краны. А они уходят потихоньку. А на их место приходят бездушные монстры.

Что за скрепка и компас?

Ты о немецких грузовых дронах из соседней темы?

Не знаю что в какой соседней теме. Мне нравятся старые «советские» краны. Они художественные, ламповые, жирафики. Хотя маломощные.

Красивый скриншот. Всегда была слабость к WindowMaker’y, хоть пользоваться им мне как-то не очень удобно.

Как всегда прекрасно. Жаль, что сейчас у меня hidpi и этот прекрасный wm не выходит использовать удобно.

Спасибо

Но в тех доработанных разработчиками из SUN и NeXT реализациях DPS, которые были в NeXTSTEP и NeWS, API оконной системы имелось и работало.

Ну как бы конкретная дополненная реализация DPS. По идее DPS под это не затачивался. Ну, решили загнать туда и оконную систему. Тогда надо здесь сравнивать xlib+DPS vs NeXTSTEP. По ряду причин в итоге на DPS все забили. Quartz 2D никакой PS не шлет, преемственность Quartz2D и DPS такая себе. Disclamer: я очень плохо и мало знаю про Quartz и базируюсь на том, что написано.

Но похоже что их загубило вот это: http://dps.sourceforge.net/index-old.html#LICENSING

Так и в Quartz это тоже было причиной:

A graphics library called Quartz 2D provides PostScript-style imaging using the PDF rendering model (a subset, plus tweaks, of the PostScript model), but this is used by application frameworks—there is no PostScript present in the Mac OS X window server. Apple chose to use this model for a variety of reasons, including the avoidance of licensing fees for DPS and more efficient support of legacy Carbon and Classic code; QuickDraw-based applications use bitmapped drawing exclusively.

А для иксов Паккард и Ворт сделали тогда решение Cairo/X Render вместо DPS. Врочем X Render был первым бэкендом, а потом сделали кучу других. Cairo тоже такую модель имеет, но Cairo - клиентская библиотека, рисует на много на чем.

The cairo API provides operations similar to the drawing operators of PostScript and PDF. Operations in cairo including stroking and filling cubic Bézier splines, transforming and compositing translucent images, and antialiased text rendering. All drawing operations can be transformed by any affine transformation (scale, rotation, shear, etc.)

Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).

Ну как бы конкретная дополненная реализация DPS.

Естественно. Конкретные реализации что в NeWS, что в NeXTSTEP и нужно сравнивать с эталонной реализацией X11. Других распространённых реализаций DPS, которые ещё бы и предоставляли оконную систему, в те времена наверное и не было.

А то расширение DPS, которое Adobe запилила для X Window System по сути уже было сделано на закате самой технологии. NeXT тогда был уже куплен Apple и для своей новой UNIX-подобной OS они выбрали менее закопирайченный PDF, да и SUN тоже отказался от NeWS.

Тогда надо здесь сравнивать xlib+DPS vs NeXTSTEP.

Почему же? Вполне себе справедливо сравнивать просто любую реализацию X11 (ту же эталонную XFree86 или X386 в то время) и реализации Display PostScript, которые были в NeXTSTEP и NeWS. Обе технологии предоставляли пользователям оконный интерфейс, чего бы их собственно и не сравнивать? Это, собственно и делают:

Compared to X, NeWS was vastly more powerful, but also slower (especially for local connections).

https://en.wikipedia.org/wiki/NeWS#Competition_with_X_Window_System

Прям интересно стало, сколько тебе было лет, когда у тебя появился первый компьютер)

если речь про докаппы - то выше есть ссылка на масштабируемые