Tiling Managers in FatDog?

[Neo_78]

Has anyone tested to use a window tiling manager in FatDog?

https://www.tecmint.com/best-tiling-win ... for-linux/

Do you know which packages are available in the oficial repository?

[dr__Dan]

Hi neo_78.

From Gslapt I found:
fvwm 2.6.8 (Fast Virtual Window Manager)
icewm 1.4.2 (Window Manager)
jwm 2.3.7.s1685 (X11 Window manager)
twm 1.0.10 (TWM Window Manager)
xfwm4 4.12.5 (Windows Manager)

jwm is preinstalled along with Openbox, and can be switched to in the desktop right-click menu.

I haven't tried them, other than a little experimenting with jwm, so I don't know what the benefits might be. Most of the programs listed in the article aren't there.

Dan

[Neo_78]

Thanks @dr__Dan. Tmux is also available in Gslapt and straight forward to use:

https://github.com/tmux/tmux/wiki

i3wm seems to be a really popular choice, however not available it seems:

https://i3wm.org/

[je55eah]

I have been testing fatdog and antix. I don't know if it will work, but I wonder if wingrid can be installed on fatdog.

Windows tile easily on antix with ctrl+alt+(1-9)

[je55eah]

I tried this wingrid thing but jwm doesn't seem to recognize the key bindings.

So far, I copied all the wingrid shell script files to /usr/local/bin/

After I installed wmctrl with gslapt those scripts work from the terminal or by clicking them.

I copied wingrid.conf to ~/.config/wingrid/wingrid.conf

Then I paste the following tags into ~/.jwmrc

Code: Select all

<!--Wingrid-->
<Key mask="C" key="1">exec:wingrid-left.sh</Key>
<Key mask="C" key="2">exec:wingrid-right.sh</Key>
<!--
<Key mask="C" key="3">exec:wingrid-top.sh</Key>
-->
<Key mask="C" key="3">maxtop</Key>
<Key mask="C" key="4">exec:wingrid-bottom.sh</Key>
<Key mask="C" key="5">exec:wingrid-topleft.sh</Key>
<Key mask="C" key="6">exec:wingrid-topright.sh</Key>
<Key mask="C" key="7">exec:wingrid-bottomleft.sh</Key>
<Key mask="C" key="8">exec:wingrid-bottomright.sh</Key>
<Key mask="C" key="9">exec:wingrid-maximize.sh</Key>
<Key mask="C" key="0">exec:wingrid-close.sh</Key>

I also saved my ram layer and rebooted.

You can see I also tried to use the jwm built in maxtop, but it didn't work either. I also tried mask=SC and mask=CA

fn-alt-f4 seems to work and fn-alt-f1 causes the openbox menu to appear, so I guess that means some of the keybindings are working.

Here are some useful references:
https://joewing.net/projects/jwm/config-2.3.html#keys
https://bbs.archlinux.org/viewtopic.php?id=195189
http://download.tuxfamily.org/antix/doc ... ngrid.html

Does someone know how to make this work?

[je55eah]

I have tried to add the keybindings with openbox, but that also didn't work.

I created ~/.config/openbox/rc.xml and aded the following strings.

Code: Select all

<keyboard>
  <keybind key="C-1">
    <action name="Execute">
      <command>wingrid-left.sh</command>
    </action>
  </keybind>
  <keybind key="C-2">
    <action name="ToggleShowDesktop"/>
  </keybind>
</keyboard>

Then I restarted X, but those keys do nothing.

references:
http://openbox.org/wiki/Help:Bindings
http://openbox.org/wiki/Help:Actions

[step]

Copy /etc/xdg/openbox/rc.xml to ~/.config/openbox/rc.xml and add your key bindings to the latter file. You don't need to restart X, just run openbox --reconfigure when your want to test your changes.

[je55eah]

Thank you @step That worked. How do you fearn about the location of all of these obscure files?

Here are the bindings I added to rc.xml

Code: Select all

    <keybind key="C-1">
      <action name="Execute">
        <command>wingrid-left.sh</command>
      </action>
    </keybind>
    <keybind key="C-2">
      <action name="Execute">
        <command>wingrid-right.sh</command>
      </action>
    </keybind>
    <keybind key="C-3">
      <action name="Execute">
        <command>wingrid-top.sh</command>
      </action>
    </keybind>
    <keybind key="C-4">
      <action name="Execute">
        <command>wingrid-bottom.sh</command>
      </action>
    </keybind>
    <keybind key="C-5">
      <action name="Execute">
        <command>wingrid-topleft.sh</command>
      </action>
    </keybind>
    <keybind key="C-6">
      <action name="Execute">
        <command>wingrid-topright.sh</command>
      </action>
    </keybind>
    <keybind key="C-7">
      <action name="Execute">
        <command>wingrid-bottomleft.sh</command>
      </action>
    </keybind>
    <keybind key="C-8">
      <action name="Execute">
        <command>wingrid-bottomright.sh</command>
      </action>
    </keybind>
    <keybind key="C-9">
      <action name="Execute">
        <command>wingrid-maximize.sh</command>
      </action>
    </keybind>
    <keybind key="C-0">
      <action name="Execute">
        <command>wingrid-close.sh</command>
      </action>
    </keybind>

Can these changes be packaged for other users and for an easier re-implementation?

[step]

Thank you @step That worked. How do you fearn about the location of all of these obscure files?

A combination of bumping my head in the same walls before and the power of grep when I know what I'm looking for but can't remember the exact location.

Here are the bindings I added to rc.xml [...]

Can these changes be packaged for other users and for an easier re-implementation?

Thank you, I will play with your settings as I'm also interested in tiling windows. I like stacking window managers - openbox is just about right for me - but once in a while I prefer to tile windows. I do have my own openbox-based way to do it but I'm always searching for better ways.

Redistributing wingrid from Void Linux might carry licensing issues, I don't know. I'm not familiar with their licensing terms.

[jamesbond]

Redistributing wingrid from Void Linux might carry licensing issues, I don't know. I'm not familiar with their licensing terms.

I'm not into tiling, but if this is what you're talking about, feel free to package it - it's LGPLv3.

[step]

Redistributing wingrid from Void Linux might carry licensing issues, I don't know. I'm not familiar with their licensing terms.

I'm not into tiling, but if this is what you're talking about, feel free to package it - it's LGPLv3.

Not quite. That repo is the precursor to the wingrid that is shipped with Void Linux 21 with significant differences. We were talking about extracting wingrid from the Void Linux distribution.

[jamesbond]

Redistributing wingrid from Void Linux might carry licensing issues, I don't know. I'm not familiar with their licensing terms.

I'm not into tiling, but if this is what you're talking about, feel free to package it - it's LGPLv3.

Not quite. That repo is the precursor to the wingrid that is shipped with Void Linux 21 with significant differences. We were talking about extracting wingrid from the Void Linux distribution.

If the one in Void Linux is based/derived from the antiX one (that is, it is a derivative code, not just a software which happens to have the same name but comes from a completely different heritage or if they completely re-write it), then the license will still be LGPLv3. Derivatives of (L)GPLv(2,3)-ed code cannot willy-nilly change their license.

[je55eah]

Nice. I pulled the files right out of antix because my google foo wasn't as good as yours.

edit: It also worked when I put the keybinding into /etc/xdg/openbox/rc.xml directly.

[step]

Nice. I pulled the files right out of antix because my google foo wasn't as good as yours.

Well, yeah right, but I didn't remember correctly, it was actually Antix 21.5 not Void Linux.

edit: It also worked when I put the keybinding into /etc/xdg/openbox/rc.xml directly.

Yes, /etc/xdg applies to all users who don't override it with their own rc.xml in ~/.config/openbox.

[je55eah]

I am rebuilding everything with a multisession save and I discovered that this solution isn't working when I multi-session. It could be user error, but I am quite certain that I repeated everything accurately. What could prevent openbox from sending the keybinding commands under a multisession save environment?

[je55eah]

I found the problem. In the multisession mode ~/.config/openbox.rc.xml exists and supercedes /etc/xdg/openbox/rc.xml. I didn't find a tool to diff the files yet, but after I added the bindings to that file and reconfigured openbox they began to work.

[step]

Yes, the user's configuration, if present, almost always overrides system files. As regards comparing files, you could use diff (for command-line hounds) or install meld from package manager for a more comfortable graphical experience. If you don't want to install stuff, meld and its dependencies are included with the development sfs (fd64-devx.sfs). You could download devx with the SFS Manager, then temporarily load devx sfs, use meld, unload devx and be done with it. If you get stuck loading/unloading remember load_sfs.sh.

[wiak]

Here are the bindings I added to rc.xml

I just do it using simple rc.xml keybindings in my recent FirstRib Arch64-based openbox/tint2 distro (under development right now). It is simplistic - doesn't leave any gaps between the tiles, but that's fine for me. Windows super key + cursor right gives half screen right side tile and the rest of the key bindings allow for left, top, bottom as well as quarter sized tiles to any corner:

Code: Select all

<!-- Keybindings for tiling --> 
  <keybind key="W-Left"> 
    <action name="Unmaximize" /> 
    <action name="MoveResizeTo"> 
      <x>0</x> 
      <y>0</y> 
      <width>50%</width> 
      <height>100%</height> 
    </action> 
  </keybind> 
  <keybind key="W-Right"> 
    <action name="Unmaximize" /> 
    <action name="MoveResizeTo"> 
      <x>-0</x> 
      <y>0</y> 
      <width>50%</width> 
      <height>100%</height> 
    </action> 
  </keybind> 
  <keybind key="W-Up"> 
    <action name="Unmaximize" /> 
    <action name="MoveResizeTo"> 
      <x>0</x> 
      <y>0</y> 
      <width>100%</width> 
      <height>50%</height> 
    </action> 
  </keybind> 
  <keybind key="W-Down"> 
    <action name="Unmaximize" /> 
    <action name="MoveResizeTo"> 
      <x>0</x> 
      <y>-0</y> 
      <width>100%</width> 
      <height>50%</height> 
    </action> 
  </keybind> 
    <keybind key="W-Home"> 
      <action name="Unmaximize"/> 
      <action name="MoveResizeTo"> 
        <x>0</x> 
        <y>0</y> 
        <width>50%</width> 
        <height>50%</height> 
      </action> 
    </keybind> 
    <keybind key="W-Prior"> 
      <action name="Unmaximize"/> 
      <action name="MoveResizeTo"> 
        <x>-0</x> 
        <y>0</y> 
        <width>50%</width> 
        <height>50%</height> 
      </action> 
    </keybind> 
    <keybind key="W-Next"> 
      <action name="Unmaximize"/> 
      <action name="MoveResizeTo"> 
        <x>0</x> 
        <y>-0</y> 
        <width>50%</width> 
        <height>50%</height> 
      </action> 
    </keybind> 
    <keybind key="W-End"> 
      <action name="Unmaximize"/> 
      <action name="MoveResizeTo"> 
        <x>-0</x> 
        <y>-0</y> 
        <width>50%</width> 
        <height>50%</height> 
      </action> 
    </keybind> 
    <keybind key="W-M"> 
      <action name="ToggleMaximize"/> 
    </keybind> 
    <keybind key="W-I"> 
      <action name="Iconify"/> 
    </keybind>
</keyboard>

[je55eah]

@wiak
It looks like those would be a fine alternative to wingrid on openbox systems. Thanks.

The wingrid solution should work with jwm on puppy and easyos.

@step
I didn't know about meld or its place in devx. Thank you.

I didn't find diff because I didn't look for it. My problem was solved and I didn't feel that I had time to dig into the mystery.

The strange part, is that ~/.config/openbox/rc.xml file is generated for multisession but it doesn't exist on savefiles unless the user creates it.

[je55eah]

Will wingrid or the wiak alternative be added to future fatdog releases?

[step]

Probably not. There's nothing wrong with either one but we tend to leave desktop add-ons and themes to the free will of Fatdog64 users. The Fatdog software sub-forum could be used to share them.

[je55eah]

I wish there was a computer operating system that actually worked. Fatdog and puppy are the best in the world, but they still require weeks of manual reconfiguration and studying just to get basic features and new problems crop up daily that prevent me from ever doing the things I actually want to do.

I've been writing my reports on the forum because I thought we were working together to improve the situation. Are users each expected to maintain their own fork of fatdog or is there something I have done that has made the community unwilling to work with me specifically? There aren't a lot of people actively posting on the forum so I thought we would be better off if we collaborated.

[step]

Fatdog team members develop and support Fatdog in their free time. We all have different real jobs to earn our living, families to love, errands to attend, and so on. So we must prioritize and do what we can for Fatdog and this forum, sometimes disappointing some people but it usually turns out good - good enough, some people will say.

You didn't do or say anything wrong for what I've seen. You are beginning to give back to the forum in the form of new information and solutions you're finding as you go. That's the spirit: thank you for that.

So, Fatdog is a free (as in beer and as in open source) project developed and supported by OSS enthusiasts in their free time, who welcome all users, their questions and requests but can't guarantee a response to every one.

The same goes for the wonderful Puppy Linux forum, their forum owner and steward, moderators and members. I never said this before, so this is a good time to do it.

I wish there was a computer operating system that actually worked.

I totally agree. Some work better than others but it's all subjective anyway. Someone will find some OS perfect for what they need to do when someone else will find the same OS awful for what they need to do.

Fatdog and puppy are the best in the world, but they still require weeks of manual reconfiguration and studying just to get basic features and new problems crop up daily that prevent me from ever doing the things I actually want to do.

I've been writing my reports on the forum because I thought we were working together to improve the situation. Are users each expected to maintain their own fork of fatdog or is there something I have done that has made the community unwilling to work with me specifically? There aren't a lot of people actively posting on the forum so I thought we would be better off if we collaborated.

[je55eah]

I'm grateful for the work you and the others have done, but I am baffled by the fact that the two modifications I presented in a working state were both rejected by you and jamesbond. They were both features which were requested by another user as well.

I'm going to try to learn more about packaging for fatdog, puppy, easyos, DebianDog, and firstrib. It looks like it might be possible to deconstruct the entire system and rebuild it with modules. In that case, there may still be issues with configuration file conflicts. To address that problem I am thinking that every configuration file should be replaced with a script which reads and executes all of the scripts in a subdirectory of the same name. Each of those scripts could be numbered for priority and labeled to ensure uniqueness. The format may be something like :
20-applicationname-authorororganizationname.config

so the existing config file contents could be moved from
./applicationconfig.sh to ./applicationconfig/10-application-fatdog.config

By this mechanism all of the modules could add lines to the config scripts without mangling anything.

I am still looking for similar mechanisms for config files which are not scripts such as xml, json, ini, and others.