GTK to remove X11 backend

Beastie7 said:
Here's the thing. It already exists; i'm using it on macOS. It's called Quartz. :) (which greatly inspired Wayland)

I'm just waiting for that brave soul to write an open source implementation for the BSDs.

To add; Wayland should've been API based, instead of protocol based. Canonical had the right idea with Mir (especially with native EGLStreams support), but they caved to Red Hat, zealots, and Co.

Hail IBM.
Click to expand...

Mir is also GPL 3 which caused controversy compared to MIT, used by Xorg and Wayland.
 
LibreQuest said:
Mir is also GPL 3 which caused controversy compared to MIT, used by Xorg and Wayland.
Click to expand...
Mir has been re-written as a Wayland compositor, BTW...
Beastie7 said:
I think it's impractical to expect a software project, conceived from an english-speaking country, to prioritize multi-lingual support. I mean, which is more economically feasible; multilingual support from a projects conception, or simply other foreign users learning the basics of english? I'm not trying to be contrarian, but most of what the world uses (from silicon to software) comes from America.
Click to expand...
Microsoft has pretty decent support for Japanese and other Asian languages. And Open Source is not that far behind, generally speaking. Microsoft grew rich at least partially because of that - Asia is a HUGE market. So it may be that for Microsoft, it was a pretty decent return on investment to do multi-lingual support. When it comes to Open Source, the ideas in play are the same all over the planet: compete with non-free options.

Also: Did you know that Blender is Dutch? as is misc/orange3 ? KDE is not an American project, either.
 
angry_vincent said:
Wayland protocol is simply better designed and has X.org issues sorted.
Click to expand...
Better designed? Perhaps. But it outright lacks 90% of what Xorg does (by design, it is beyond the scope). Wayland is more comparable to MS-DOS rather than an enterprise ready multi-user operating system.

However many will not know that because the reddit, twitter brigaders only really need to play their computer games and are able to overlook anything that the actual industry needs.

Red Hat is interested in it because they can simplify what they need to provide support for and still get paid. This is a feature in itself but I certainly can't say that "Wayland is better" vs Xorg.
 
Going back to the Japanese thing, I haven't given it an intense try out, but I suspect that RH's default Gnome, with ibus, does everything needed in a Japanese environment. My own, completely anecdotal eperience using labwc, does, (I realized after posting earlier, and not looking deeply into it) just allows Japanese in terminal, I wasn't able to input it in libreoffice or firefox, though I didn't try tweaking anything as I've had to in X.
The main place I use Wayland, though is when I connect my Thinkpad L420 to the TV. In both FreeBSD and Fedora, I find that Wayland gives me a much better and smoother picture. With X, it's pretty choppy.
 
The main place I use Wayland, though is when I connect my Thinkpad L420 to the TV. In both FreeBSD and Fedora, I find that Wayland gives me a much better and smoother picture.
Click to expand...

i have been running Wayland on Freebsd for the last 14 months using dwl
and i have found video playback is much smoother than on X

Also games play are a lot smoother as well
Duke Nukem runs like a dream
 
angry_vincent said:
If i plug my 2nd monitor, all my windows and applications are automatically adjusted with geometry and screen resolution, and fonts are scaled properly...
Try doing this with X.org...
Click to expand...
Well, that's exactly what I like about Xorg: I decide what to do with the second monitor, I don't want such kind of automagic.
 
aragats said:
Well, that's exactly what I like about Xorg: I decide what to do with the second monitor, I don't want such kind of automagic.
Click to expand...
Indeed -- this isn't unique to Xorg or Wayland --- but rather how the WM/DE or Compositor respectively decides to handle this.
 
I dont have X11 installed at all
only Wayland

wlroots + dwl

Freebsd 14.2-p1

Dell xps 15 2019 -16gb ram
Macbook air 2011- 4gb ram

one of the goals of wayland is that every frame should be perfect
which i found has knock on effect of smoother video and game play

wlroots wayland compositors support different parts of the wayland spec
so it also depends on what part of the wayland spec your compositor supports

for example both labwc and dwl support locking the cursor to the display you are playing a game on
so you dont accidentally move your mouse to another display and lose input focus in the game

i forget the name of the wayland protocol, its something like "cursor locking"

labwc has support for the "foreign top level" interface which list the applications running on a particular display
by default dwl doesnt but you can add a patch to enable it

so there may be some difference between the wlroots wayland compositor based on what part of the wayland spec they support
but i found video playback to be smoother on wayland on X

i have tried the follow wlroots compositors on freebsd

1- dwl - has independent workspaces for each monitor
2 - labwc - doesnt come with a panel and doesnt have independent workspaces for each monitor
3 - wayfire - comes with a panel but doesnt have independent workspaces for each monitor
4 - hikari - which is stuck using an old version of wlroots and looks to be abandoned

briefly tried river and ratposion wasnt impressed

after using wayland on freebsd for the past 14 months,
dwl is by far the best wayland wlroots compositor

dwl comes with panel, has independent workspaces for each monitor which is a must if you have more than one display
otherwise when you switch workspaces on one display the workspace on the other display switches as well,
which is a real pain if you are watching a video on the second display

all the other compositor require you to create rules to stick particular applications to the second display
which is a pain to have to set up and is also rather limiting

i hardly ever tile windows with dwl,
i just have the windows maximized which is the default on different workspaces
and then flip between them with super and the workspace number

What about using Gnome and KDE or XFCE with Wayland on Freebsd

Gnome

Gnome on Freebsd is version 42,
the current version of Gnome is 47

Gnome doesnt have independent workspaces per display

but if you put an application on the second display and switch workspace on the first display
then the application on the second display stays in place

Gnome takes a nanny knows best approach and is a bit like installing ios on your computer

KDE

KIDE doesnt have independent workspaces per display

you have to create window rules for application you want to stick on the second display when you change workspaces
or manually set the window to stick on the second display using a drop down menu in the window

at the moment KDE 6 inst in a working state on Freebsd
user seem to be reporting issues with kde 5 dependencies being pulled in and various parts of the desktop not working

the problem with kde is that its made up of multiple packages that all have to work together to create the desktop
all those widgets or spectacle to take screenshots

this is a problem on Freebsd because the port maintainers have to ensure that mutiple kde packages are kept up to date
and all work together to create the desktop

the issue is if one of the packages doesnt work then some of the desktops functionality is missing

kde does run multiple processes for things like file indexers which work with krunner
the kde file launcher which is one of the things i dont think you can remove

another issue with kde is that it creates dozens of config files in your home directory

because KDE is made up of multiple packages and at present doesnt have a release cylcle like other desktops
its a really bad fit for Freebsd

its really for people who like to customize a stacking desktop enviornment
and are more used to a Windows style desktop


XFCE

i used to use xfce but i only didnt have an external monitor then
from a quick search it looks like its xfce doesnt have independent workspaces per display

and you have to set a window to be "Always on visible workspace".

xfce does have some wayland support but at the moment you have to run a wlroots compositor like labwc
and then launch the xfce wayland session running on labwc

which means the window management is handled by labwc

so at present there is a working xfce "desktop"
just parts of xfce running inside anoter wlroots wayland session

Wayland application launcher and panels

most of the wayland addons for things like application launchers or panels are written for wlroots comositors
programs like tofi or wlr-which-key

wlroots applications wont run on Gnome or KDE
so you have to use either Gnome extension or KDE applets

which means you are in effect locking your self into their eco system
vendor lock in

Gnome doesnt offer many options to customize the desktop
and is very minimalist

KDE lets you customize most of the desktop
but i dont think you can remove the krunner application laucher

so you cant replace krunner with a wlroots application launcher like tofi
 
aragats said:
Well, that's exactly what I like about Xorg: I decide what to do with the second monitor, I don't want such kind of automagic.
Click to expand...
it runs in native resolution, if it was unclear. and all windows, fonts scaled based on that. For X.org yo uneed to have some external thing, like xrandr and doing the setting *magic* , write it config or else. And it is smooth, without any hiccups. Of course, with wayland I can also change that and set other resolution but it was never needed. So, i do not know whether it is good or bad? it works and I think it is good.
 
Wayland doesnt have a config file like X11's Xorg

so there is no need to specify the display settings
or things like font paths or other obscure command as you would on X11

you specify things like keyboard mapping in the compositors config file
if you follow the freebsd handbook its really to set up wayland

because there is no Xorg file to the user to configure and potentially mess up
it makes setting up a desktop much less error prone

and means the user can get straight to using the desktop
rather than messing with an xorg file before they can get the desktop working
 
NapoleonWils0n said:
Wayland doesnt have a config file like X11's Xorg

so there is no need to specify the display settings
or things like font paths or other obscure command as you would on X11

you specify things like keyboard mapping in the compositors config file
if you follow the freebsd handbook its really to set up wayland

because there is no Xorg file to the user to configure and potentially mess up
it makes setting up a desktop much less error prone

and means the user can get straight to using the desktop
rather than messing with an xorg file before they can get the desktop working
Click to expand...

I didn't know that. Now I hate wayland even more :)
 
So there is a config file?
Click to expand...

most wlroots dont have a gui to enable different settings

the exception is Wayfire which does have a gui to configure the desktop,
but it still stores the settings in a config file

most compositors use a config file which can be in different languages to customize the settings

dwl uses c,
labwc uses xml for some of its config

Gnome uses dconf for its settings
im sure KDE uses something similar

I used to use Xmonad on X11 which meant i had 2 config files,
my Xmonad config and a Xorg config

settings for things like the monitor, keyboard mapping with xkb_rules and trackpad
are specified in the wlroots compositors config file

instead of separately in an Xorg config file

dwl

config.h

C: 
/* monitors */
/* (x=-1, y=-1) is reserved as an "autoconfigure" monitor position indicator
 * WARNING: negative values other than (-1, -1) cause problems with Xwayland clients
 * https://gitlab.freedesktop.org/xorg/xserver/-/issues/899
*/
/* NOTE: ALWAYS add a fallback rule, even if you are completely sure it won't be used */
static const MonitorRule monrules[] = {
    /* name       mfact  nmaster scale layout       rotate/reflect                x    y */
    /* example of a HiDPI laptop monitor:
    { "eDP-1",    0.5f,  1,      2,    &layouts[0], WL_OUTPUT_TRANSFORM_NORMAL,   -1,  -1 },
    */
    /* defaults */
    { NULL,       0.55f, 1,      1,    &layouts[0], WL_OUTPUT_TRANSFORM_NORMAL,   -1,  -1 },
};

/* keyboard */
static const struct xkb_rule_names xkb_rules = {
    /* can specify fields: rules, model, layout, variant, options */
    /* example:
    .options = "ctrl:nocaps",
    */
    .layout = "gb",
    .model = "104",
    .options = "ctrl:swap_lalt_lctl,custom:swap_sterling_numbersign,caps:none",
    .rules = "evdev",
    .variant = "mac",
};

static const int repeat_rate = 25;
static const int repeat_delay = 600;

/* Trackpad */
static const int tap_to_click = 1;
static const int tap_and_drag = 1;
static const int drag_lock = 1;
static const int natural_scrolling = 0;
static const int disable_while_typing = 1;
static const int left_handed = 0;
static const int middle_button_emulation = 0;
 
There's no need to create an xorg.conf in most situations nowadays.
Click to expand...
i meant to mention that

sometimes you have to add settings for things like keyboard settings
and then you get users who create the Xorg file as root or something like that
 
kpedersen said:
But my recommendation is that we polish up Gtk+ 2.0. That one had vastly superior theme engines (Sun Microsystems did a really good job with Nimbus. Perhaps, less so with Blueprint) and was actually close to getting Linux on the mainstream desktop before the idiots broke it all. We should build off that.
Click to expand...

I've been meaning to find this post. I think this would be a fun project on its own. What would you suggest? Any features to add and/or remove? Ideally, a from scratch, portable, BSD licensed implementation would be nice. I'd be able to write stuff for my Mac and FreeBSD; since Cocoa/Objective-C/SwiftUI are locked down.
 
Beastie7 said:
I've been meaning to find this post. I think this would be a fun project on its own. What would you suggest? Any features to add and/or remove? Ideally, a from scratch, portable, BSD licensed implementation would be nice. I'd be able to write stuff for my Mac and FreeBSD; since Cocoa/Objective-C/SwiftUI are locked down.
Click to expand...
It would be nice if Gtk+ 2 has good Hi-DPI supports.
 
Beastie7 said:
I think this would be a fun project on its own. What would you suggest? Any features to add and/or remove?
Click to expand...
I think the first step is to track down specific versions of the Gtk dependency sprawl and combine it all into a single monolithic codebase / build system (similar to i.e Xenocara / CDE). this would make it more feasible to work on it as a small team. It would also help us start to chop away at some of the less needed dependencies.

Beastie7 said:
Ideally, a from scratch, portable, BSD licensed implementation would be nice. I'd be able to write stuff for my Mac and FreeBSD; since Cocoa/Objective-C/SwiftUI are locked down.
Click to expand...
Annoyingly most free GUI libraries are GPL (FLTK, OpenMotif, Gtk, Qt). And writing one from scratch is so time consuming. To reach parity with FLTK (the simplest) would take decades.

That said, nothing about a GUI library is intrinsically difficult to implement. So perhaps one day we could use one of those popular AI interpolation engines to generate most of the work for us.

Another approach is to get started now with writing a desktop ecosystem in FLTK (again because its the simplest) or a subset of Gtk 2.x, and slowly start re-implementing it at the same time. There is nothing in the GPL that says we can't "clone" an API.
 
kpedersen said:
I think the first step is to track down specific versions of the Gtk dependency sprawl and combine it all into a single monolithic codebase / build system (similar to i.e Xenocara / CDE). this would make it more feasible to work on it as a small team. It would also help us start to chop away at some of the less needed dependencies.


Annoyingly most free GUI libraries are GPL (FLTK, OpenMotif, Gtk, Qt). And writing one from scratch is so time consuming. To reach parity with FLTK (the simplest) would take decades.

That said, nothing about a GUI library is intrinsically difficult to implement. So perhaps one day we could use one of those popular AI interpolation engines to generate most of the work for us.

Another approach is to get started now with writing a desktop ecosystem in FLTK (again because its the simplest) or a subset of Gtk 2.x, and slowly start re-implementing it at the same time. There is nothing in the GPL that says we can't "clone" an API.
Click to expand...
I think that's very sound arguments against incredibly uninformed fantasies. I'm seeing LOTS of people fantasizing about writing their own OS, their own lib/toolkit, without realizing what that would even look like if they actually tried.

I'm pretty sure it was Linus himself who said, "Talk is cheap, show me the code!".
 
Jose said:
There's no need to create an xorg.conf in most situations nowadays. Things Just Work(tm) out of the box.
Click to expand...
I'm curious how to pull-off multiple custom resolutions on Linux with Wayland.

This xorg.conf works easy for 3 customs on 1 HDMI port:

Code: 
Section "Monitor"
    Identifier "HDMI-1"
    Modeline "1920x1080_74" 165.612 1920 1928 1960 2000 1080 1105 1113 1119 +HSync -VSync
    Modeline "1280x720_74" 75.077 1280 1288 1320 1360 720 732 740 746 +HSync -VSync
    Modeline "1024x768_74" 65.03 1024 1032 1064 1104 768 782 790 796 +HSync -VSync
    Option "PreferredMode" "1920x1080_74"
EndSection

video= kernel parameter works fine for 1 resolution Wayland and Xorg, but I haven't been able to figure out if it's possible to do multiple resolutions on a single port (commas or multiple video= didn't work):

Code: 
video='HDMI-A-1:1920x1080MR@74'

My screen is 60Hz, but can OC to 74Hz; desktop res 1080p, some games work better at 720p, and osu! works at 1024x768 for a drawing tablet's area :p

Iirc on Wayland some things keep the native res but scale the rendering output if a lower fullscreen res is selected, but I get better performance with the real lower-res used.
 
You must log in or register to reply here.
Back
Top