Solved KDE, Wayland and Systemd

Well, you have my blessing. And I'd donate you a cold one, if I could.
 
If you can rack up a usable demo, and give us something to test. I’d gladly contribute. :) My development chops aren’t yet there to make code contributions.
 
Well, you have my blessing. And I'd donate you a cold one, if I could.
Heh, to be honest, that is all the extra encouragement I needed. It has officially begun then! ;)

If you can rack up a usable demo, and give us something to test. I’d gladly contribute. :) My development chops aren’t yet there to make code contributions.

Great to hear! I imagine I will be spamming these forums with a project update once I have something substantial. My end goal is to try to make writing GUIs "fun" again. I notice these days they are all such a massive chore with so much boilerplate and I have a few ideas to fix that. Code should be easy and fun, like QuakeC!
 
I have made some fair progress on the UI library today. Mostly I explored a few layout systems (grid, row/col, anchor) but I didn't really like any of them so decided to try out a new custom idea. I call it "flow" but in practice it actually feels like a reverse Tetris.

The following is a complete program (screenshots of the resulting program attached). So long as a widget is called "MainWindow", that will create the entry point. Keeping pretty much all boilerplate to a minimum.

Code:
#include <iffe/iffe.h>

widget(MainWindow, Init)
{
  int dummy;
};

void OnInit(struct InitEvent *ev)
{
  ref(Widget) panel = WidgetAdd(ev->sender, Spacer);
  WidgetSetHeight(panel, 100);
  WidgetFlow(panel, "^=<");

  ref(Widget) w = WidgetAdd(panel, Button);
  WidgetFlow(w, "^<");

  w = WidgetAdd(panel, Button);
  WidgetFlow(w, ">");

  ref(Widget) sw = WidgetAdd(ev->sender, Spacer);
  WidgetFlow(sw, "=<^");

  w = WidgetAdd(ev->sender, Button);
  WidgetFlow(w, ">");

  WidgetFlow(sw, "v");
}

iffe_flow.png


This instructional approach works very well for resizing. As for how flow works. In the following example:

Code:
WidgetFlow(panel, "^=<");

It would mean move widget upwards until it hits something and expand left until it hits something. Movements and expansions keep going until they collide with an existing widget or the parent bounds. They always start from the lower right corner of the parent container.

Repo is here. Still very early days. Makefile is a little limited so far: https://github.com/osen/iffe

Anyway, that is enough spam from me. Once it is ready for some simple utilities or custom widgets I will let everyone know. Probably a few months in between other work. My ultimate goal for it is to be able to clone something a little more substantial like Microsoft Paint (Windows XP version obviously, none of that Windows 10 crap).
 
In any software development matter, you start with a requirements specification: what does the thing actually need to do. In this case, it seems this is lacking (or may be it only appears to me as lacking), because I never found a functional description of what a desktop environment should do, aside from being colourful.
This is my humble personal opinion, but there is one thing the desktop environment should do - allow copy and paste from one application to another. That is why I am using terminal under MATE or KDE, and many other use cases...
 
Maybe we can even resurrect the old datatypes.library concept for the clipboard. I would love that.
 
Maybe we can even resurrect the old datatypes.library concept for the clipboard. I would love that.
I believe that the GUI should add some extra value to the system, which is not the responsibility of OS. May be, that object-oriented look to the whole system is a way to go.
 
For me I think the underlying display system should really handle the clipboard. I.e the GUI library and even desktop environment will need to integrate with "foreign" software. So just sticking to what X11 supports is quite good here. Of course I am guessing "clipboard" is beyond the scope for toys like Wayland. But "real" display systems are where most users should focus.

Amiga-style datatypes.library is cool but I would even play it safe and suggest avoiding smarter or object based clipboards and just stick with plain text. Yes, they are more limited but plain text keeps the complexity down so much that we end up with more uses for it. Unless we could get *every* software to play ball. Unfortunately I don't think this will ever happen for FOSS.
 
  • Thanks
Reactions: a6h
I would even play it safe and suggest avoiding smarter or object based clipboards and just stick with plain text.
Regarding clipboard, anything beyond plain text is plain stupid. Handling more that than is subjective. You have to predict large number of subjective combinations. That why programs like Microsoft Office have multiple options for pasting modes. Although there're some use cases, I don't think such complexity is necessary. Therefore I completely agree!
 
Regarding clipboard, anything beyond plain text is plain stupid. Handling more that than is subjective. You have to predict large number of subjective combinations. That why programs like Microsoft Office have multiple options for pasting modes. Although there're some use cases, I don't think such complexity is necessary. Therefore I completely agree!
Depends. Personally I like that I can copy screenshot to the clipboard (on my FreeBSD machine):
1606162338444.png

:cool:
 
Argentum Sure, as I said there're subjective use cases. For example I'm fond of bindsym in i3:
bindsym Shift+Print exec scrot -z -o '%y%m%d%H%M%S.png' -e 'convert $f -crop 1366x768+1920+0 $f && mv $f someWhereInTime'
 
I am sure scrot can be piped into uuencode ready for pasting into an unsuspecting chat ;)

Or I guess the screen can be saved in a temp image on disk and just a path to it added to the clipboard. In many ways I would find more use for that (such as scp to a server, etc).
 
  • Thanks
Reactions: a6h
In any software development matter, you start with a requirements specification: what does the thing actually need to do. In this case, it seems this is lacking (or may be it only appears to me as lacking), because I never found a functional description of what a desktop environment should do, aside from being colourful.
I think it is obvious what a desktop environment does. In CLI you have to keep in mind every command and their parameter list (or read the manual each time you want to do something), in desktop environments they give you the list of available commands you can choose from and their parameter lists with sometimes long descriptions, so you don't have to remember on a lot of stuff, just use it. Most of the DEs implement this only partially and they give you only basic CRUD. Another thing they cover is editing config files through the GUI instead of a text editor. The concept is the same here, you include the relevant part of the manual to the GUI, so people don't have to look it up and they don't even have to know the config file format e.g. ini, json, etc. I think it is not that hard to write a better DE from this perspective than the current ones, because they have a poor toolset compared to the UNIX CLI.
 
I know that are many users of KDE and similars DE , but long life to WM!
the only thing I need to work is a terminal emulator and tmux and for home use I had all the
tools to build my VM enviroment
is a shame if KDE go for the dark side($$) I am include myself in the list of ex users of KDE
(long time ago)
 
… systemd … actually works remarkably well …

Dendros asked: Why is systemd so hated?

Just once, years ago, I stumbled across an explanation that was (to me) suitably eloquent. I might have bookmarked it, but it's impossible to find.

This is not to say that I hate systemd; I do not. I feel no reason to hate it. I was frustrated by the noise, the colossal, endless and often intrusive noise, much of which seemed to be irrational or ill-informed.

I wish I could rediscover that one good explanation, but it will be impossible. Too much noise.
 
What does Wayland even have to do with systemd??? As far as I can tell, FreeBSD has no systemd, and Wayland runs fine on it. I would know, I got it running on my rig :p
 
Back
Top