Salix Xfce 15.0beta1

User avatar
missTell
Posts: 111
Joined: 19. Apr 2018, 06:45

Re: Salix Xfce 15.0beta1

Post by missTell » 26. Jun 2022, 10:21

gaucho wrote:
26. Jun 2022, 03:57
I encountered almost the same problem on another Linux distro that I run. Although I've used GnuCash for years and am fairly familiar with the program's operations, its configuration and theming settings are over my head. :oops: I had looked before at some of those sources which you mention, and experimented with various changes. In the end, nothing I did made any difference. (It turned out that the issue was likely caused by some updates in GTK-related packages which interacted badly with some components of the MATE DE. A later update eventually solved the problem.)

Here on Salix Xfce today, I tried some additional workarounds -- including reinstalling GnuCash via Gslapt, deleting the ~/.config/gnucash directory, and even tinkering with some settings using the dconf-editor (based on an online tip I read). None of that worked.

I finally decided "What the heck!!\%# ... This is a beta and I have nothing to lose." So I removed GnuCash and tried installing the Flatpak of GNC 4.10 via Flathub.

Amazingly, the Flatpak is working fine. GNC starts up as I'm accustomed to and the register / ledger "looks like it's supposed to":

IMAGE

I'm a bit frustrated that I had to resort to the "nuclear option." But I felt like I'd already sunk enough time into looking for a solution.
Well, as I previously wrote, I do not know the program, but I also can't reproduce your issue.

Since Linux in general is a mess, the best way to check if something is an OS issue or the application failure, is to install the program under Windows.

This for two reasons...

Every Open Source application I ever tried, worked better (or same good) on Windows, and the looks of those applications is as the authors wrote them.

The window frame is controlled by the Windows, and what's inside, is controlled by GTK / Qt.

Here some screenshots of GnuCash on Windows 10:

Default view:
https://ibb.co/VxgTyG7

Education tab (default):
https://ibb.co/XCyXt9h

Sames as above, but with another window border:
https://ibb.co/3mmZj26

Note that under Windows, Adwaita / hicolor themes are used.

That's exactly the same, as I had on Salix Xfce 15.0beta1 upon fresh install.

Default view:
https://ibb.co/2cRYMCX

Education tab (default):
https://ibb.co/xSdBDL4

With horizontal lines enabled:
https://ibb.co/FxLdgN9

Dark theme:
https://ibb.co/6DjQGRB

Any color of your choice:
https://ibb.co/dJk6Z4j

The screenshots here are from GnuCash Flatpak on Springdale (RHEL):

Default view:
https://ibb.co/QMw0Q5V

Education tab (default):
https://ibb.co/f8LwHF3

With horizontal and vertical lines enabled:
https://ibb.co/WGGfmJm

With other words, the program behaves just as well (or bad?) in all three cases.

The only difference is in icons.

Under Windows, the hicolor is used -- for obvious reason.

Under Salix, there is a mixed bag mess -- mix of Qogir, hicolor and the own icons.

Under Springdale, there is a mix of Breeze (since Newaita-Breeze is set as default) and the own icons.

All in all, that's the expected behaviour in Linux, where every application looks and behaves more or less different.

Here one example of Inkscape window borders on Springdale -- both Adwaita, and both different! ;)

https://ibb.co/ZWBpRmw

One can also easily see why, and it could be easily fixed -- simply change the path.

That's probably the reason why it becomes better in your case.

However, what puzzles me is -- why do you get different defaults then me, if we use the same OS and the same theme.
“Never argue with stupid people, they will drag you down to their level and then beat you with experience.” (Mark Twain)

User avatar
missTell
Posts: 111
Joined: 19. Apr 2018, 06:45

Re: Salix Xfce 15.0beta1

Post by missTell » 26. Jun 2022, 10:47

miracleman wrote:
25. Jun 2022, 22:58
Gslapt crashes when updating.
Yes, it is, and it is directly connected to:
gapan wrote:
21. Jun 2022, 15:40
I have uploaded an updated qogir-icon-theme package to the repos. Careful that you need to upgrade the spkg package first before you install it.

Reminder that if you have a fresh beta installation, you will need to first remove the previous package and then install the new one:

Code: Select all

sudo spkg -d qogir-icon-theme
sudo slapt-get -i qogir-icon-theme
The default Qogir theme now includes dark panel icons, so you can actually tell what runs in the tray. There is also a -dark variant as well as a -dark-panel variant, which is meant to be used with light themes that otherwise have dark panels. There are also several other improvements with respect to individual icons.
mimosa wrote:
23. Jun 2022, 19:37
I tried doing this (including upgrading spkg) and got the following output (not all of it still available):

Code: Select all

WARNING: Can't remove directory usr/share/icons/Qogir-dark. (Directory not empty)
mimosa[~]$ sudo slapt-get -i qogir-icon-theme
Reading Package Lists...Done
The following NEW packages will be installed:
  qogir-icon-theme
0 upgraded, 0 reinstalled, 1 newly installed, 0 to remove, 0 not upgraded.
Need to get 0.0kB/2.9MB of archives.
After unpacking 11.5MB of additional disk space will be used.

Preparing to install qogir-icon-theme-20220112-noarch-2gv
Installing package qogir-icon-theme-20220112-noarch-2gv...
ERROR: Installation script is too big. (5394 kB)
ERROR: Package installation failed!
Failed to execute command: [/sbin/spkg -i /var/slapt-get/./salix/l/qogir-icon-theme-20220112-noarch-2gv.txz]
gapan wrote:
23. Jun 2022, 20:04
mimosa, did you upgrade spkg first?
Probably you also have that issue with the icon theme update.

Try upgrading (only) spkg first, then all the other packages except icon theme (deselect icon theme), and if everything went well (as it should), start fiddling with icon theme upgrade -- from the command line, as it will show you if there is some issue, and if, which.

In my case, I simply did 'rm - rf' to get rid of the old icon folder.
“Never argue with stupid people, they will drag you down to their level and then beat you with experience.” (Mark Twain)

User avatar
mimosa
Salix Warrior
Posts: 3236
Joined: 25. May 2010, 17:02
Contact:

Re: Salix Xfce 15.0beta1

Post by mimosa » 27. Jun 2022, 11:19

gaucho wrote:
26. Jun 2022, 04:08
mimosa wrote:
24. Jun 2022, 08:12
L3eapad still has the typo in the hover-over text
I also thought it was a typo, but it's not. :oops:

Some Google-fu revealed that L3afpad is a fork of Leafpad. L3afpad supports GTK3, whereas Leafpad uses GTK2.

https://github.com/stevenhoneyman/l3afpad
Thanks for unearthing that info, David!

tonb
Posts: 3
Joined: 27. Jun 2022, 14:43

Re: Salix Xfce 15.0beta1

Post by tonb » 27. Jun 2022, 20:45

Test Salix 15.0beta1, 32-bit, en_US.utf8, Europe/Amsterdam, 5-25 June 2022
Old PC (2006), Athlon 64, single core.

- Installation was straightforward. The Settings Manager window was
convenient to set some personal preferences.

- It was a pleasure to see that the terminal window has white characters
on a black background, no colors, no transparancy, no nonsense.

- vi and view come with colors and line numbers. That is not what I want.

- vim is not installed, but there is a .vimrc in every homedir. There is
also a reference to vim in .bashrc.

- neovim is used for vi and view. neovim is not in Slackware and that
makes me suspicious. Slackware 15 has nvi as a no-nonsense implementation
of vi. I installed that and changed the links for vi and view in /usr/bin.

- The man command displays manpages with colors. Fortunately, it also
displays the name of the culprit: most. I removed the following line
from .bashrc:
export PAGER=/usr/bin/most
and I got manpages displayed the way I am used to.

- First upgrade using Gslapt. Working fine.

- I installed the Epson escpr printer driver from slackbuilds.org, which
was a hassle, but doable and straightforward when you follow the Howto.
In the process I discovered how easy it is to set the root password on
a "root disabled" system:
$ sudo passwd root

- I installed emacs, gfortran, gnuplot and octave using Gslapt. No problem.
I am typing this in emacs and ran some test examples for Fortran, gnuplot
and octave. All fine.

- Strange behaviour of Gslapt. Sometimes, if the result of a search is only
1 package, it is impossible to select that package. Example: search for
"inxi", select the package (no problem), then search for "gucharmap".

- Additional partitions are visible in the Thunar file manager and mounted
when clicked upon, after you enter a password. If the user has sudo rights,
the password of the user is asked for. If the user has no sudo rights,
the root password is asked for. That is not really compatible with the
"root disabled" approach.

- I missed a "Character Map" utility in the desktop menu. Found package
gucharmap and installed it.

- Second upgrade with Gslapt.
"17 upgraded, ..." a.o epson-inkjet-printer-escpr, the SBo package will
be replaced with the one from the Salix repository. There goes my hard
work.

Gslapt crashed somewhere half way the upgrade. Repeating with
$ sudo slapt-get --upgrade
gave me a message:
ERROR: Installation script is too big ..."
This is the problem that several people encountered already. After some
experimentation, the following worked for me:
$ sudo slapt-get -i spkg
$ sudo slapt-get --remove qogir-icon-theme
$ sudo slapt-get -i qogir-icon-theme

It would be nice if the upgrade procedure had a possibility to give
priority to a package, such that all other upgrades are blocked until
the new version of that package is active (maybe after a reboot).
I think that is the way it works with Debian and friends.

User avatar
gapan
Salix Wizard
Posts: 5954
Joined: 6. Jun 2009, 17:40

Re: Salix Xfce 15.0beta1

Post by gapan » 28. Jun 2022, 17:41

tonb wrote:
27. Jun 2022, 20:45
- vim is not installed, but there is a .vimrc in every homedir. There is
also a reference to vim in .bashrc.
That reference to vim in .bashrc has been changed to vi now.
tonb wrote:
27. Jun 2022, 20:45
- neovim is used for vi and view. neovim is not in Slackware and that
makes me suspicious.
Suspicious of what exactly?
tonb wrote:
27. Jun 2022, 20:45
- Strange behaviour of Gslapt. Sometimes, if the result of a search is only
1 package, it is impossible to select that package. Example: search for
"inxi", select the package (no problem), then search for "gucharmap".
I just tried that. I don't see a problem. gucharmap is selected just fine.
tonb wrote:
27. Jun 2022, 20:45
- Additional partitions are visible in the Thunar file manager and mounted
when clicked upon, after you enter a password. If the user has sudo rights,
the password of the user is asked for. If the user has no sudo rights,
the root password is asked for. That is not really compatible with the
"root disabled" approach.
But you may have enabled the root user... In any case, the result is that you won't be able to launch that, which is what should happen in this case.
tonb wrote:
27. Jun 2022, 20:45
- Second upgrade with Gslapt.
"17 upgraded, ..." a.o epson-inkjet-printer-escpr, the SBo package will
be replaced with the one from the Salix repository. There goes my hard
work.
Yes, we now have a package for this, so the package manager will always prefer that over another that is not in the repos. You may use the EXCLUDE list in /etc/slapt-get/slapt-getrc (or configure through gslapt) to keep your custom packages from getting upgraded.
tonb wrote:
27. Jun 2022, 20:45
Gslapt crashed somewhere half way the upgrade. Repeating with
$ sudo slapt-get --upgrade
gave me a message:
ERROR: Installation script is too big ..."
This is the problem that several people encountered already. After some
experimentation, the following worked for me:
$ sudo slapt-get -i spkg
$ sudo slapt-get --remove qogir-icon-theme
$ sudo slapt-get -i qogir-icon-theme
Yes, spkg has been upgraded to support bigger installation scripts. This has been described in this thread before.

tonb wrote:
27. Jun 2022, 20:45
It would be nice if the upgrade procedure had a possibility to give
priority to a package, such that all other upgrades are blocked until
the new version of that package is active (maybe after a reboot).
I think that is the way it works with Debian and friends.
I'm not sure I understand what you mean here.
Image
Image

User avatar
gapan
Salix Wizard
Posts: 5954
Joined: 6. Jun 2009, 17:40

Re: Salix Xfce 15.0beta1

Post by gapan » 28. Jun 2022, 17:45

Papasot wrote:
22. Jun 2022, 13:34
gapan wrote:
21. Jun 2022, 15:40
I have uploaded an updated qogir-icon-theme package to the repos
On dark styles such as Salix-dark, NetworkManager applet icon is only visible with the Qogir-dark-panel icon theme (invisible with Qogir or even Qogir-dark icon themes). Conversely on light styles (such as Salix), NetworkManager applet icon is barely visible with the Qogir-dark-panel icon theme but clearly visible with Qogir and Qogir-dark icon themes.
I am guessing this is the intended behavior, but better make sure than assume.
Nope, that is not the intended behaviour. It should also be visible with the Qogir-dark theme. I'll fix that...
Image
Image

tonb
Posts: 3
Joined: 27. Jun 2022, 14:43

Re: Salix Xfce 15.0beta1

Post by tonb » 1. Jul 2022, 22:56

gapan wrote:
28. Jun 2022, 17:41
tonb wrote:
27. Jun 2022, 20:45
- neovim is used for vi and view. neovim is not in Slackware and that
makes me suspicious.
Suspicious of what exactly?
Suspicious of it being untested and unstable. Slackware has a reputation of being old-fashioned and stable. So, if something is not in Slackware, I suspect it is either not old-fashioned or not stable enough. For me, old-fashioned and stable are the keywords of what vi has to be. vi should simply work, without bells and whistles.
gapan wrote:
28. Jun 2022, 17:41
tonb wrote:
27. Jun 2022, 20:45
- Strange behaviour of Gslapt. Sometimes, if the result of a search is only
1 package, it is impossible to select that package. Example: search for
"inxi", select the package (no problem), then search for "gucharmap".
I just tried that. I don't see a problem. gucharmap is selected just fine.
I do the following:
- Search for inxi. The line for inxi (name and version) appears in the upper window.
- Click on inxi in the upper window. The line turns blue. Info of inxi appears in the lower window.
- Search for gucharmap. Name and version of gucharmap appear in the upper window, replacing inxi. The line stays blue. The info of inxi is still in the lower window.
- Click on gucharmap in the upper window. Nothing happens. The info of inxi stays in the lower window.
gapan wrote:
28. Jun 2022, 17:41
tonb wrote:
27. Jun 2022, 20:45
It would be nice if the upgrade procedure had a possibility to give
priority to a package, such that all other upgrades are blocked until
the new version of that package is active (maybe after a reboot).
I think that is the way it works with Debian and friends.
I'm not sure I understand what you mean here.
This is a suggestion for the next version of slapt-get and/or the underlying
software. The problem is that the latest spkg must be installed before
cogir-icon-theme, but the automated upgrade procedure is designed to upgrade
packages in random (alphabetic?) order. I will try to reason towards a solution
of this problem. With solution I mean an automated procedure that would not
get broken on this order dependency of spkg and qogir-icon-theme.

For ease of reference suppose package X must be upgraded before package A.
We can think in two directions: 1. treat A as special, 2. treat X as special.

1. We could think of holding back A until the new X is installed.
1.1. Holding back A on the developer side is not a good option, as the developer
should have to wait until all users (including future users) have upgraded
X. That could last for an indefinitely long time.
1.2. Holding back A at the user side would require the developer/maintainer to
add additional info to the new version of A in the package database. Then
slapt-get would have to read that info and check the currently installed
version of X. That would imply that there is place to store that additional
info, a kind of second dependency, in the database. That would require a
redesign (at least partially) of the database.

2. We could think of giving X priority. That is the same as holding back
everything else until the new X is installed.
2.1. Doing this at the developer side is not a good idea, for the same reason
as above.
2.2. In order to handle this at the user side, slapt-get should be made aware
that X needs special treatment. So the developer/maintainer should set a
flag for package X and slapt-get should read that flag. That would still
require some redesign of the package database, although simpler than in
case 1.2.
2.3. Case 2.2 can be simplified if we know that it is always X that needs
special treatment. In that case nothing has to be changed in the package
database. Only slapt-get has to be changed. The trigger for special action
is the appearing of X in the list of packages to be upgraded.

If we substitute spkg for X, case 2.3 covers the problem with spkg and
qogir-icon-theme. Perhaps a few more packages that are part of the upgrade
procedure (I actually don't know which packages, if any.) should be given the
same treatment. This way, unnecessary failure (i.e. failure while a fix is
already available) of the upgrade procedure can be prevented.

User avatar
Papasot
Donor
Posts: 157
Joined: 3. May 2015, 18:37
Location: Patras, Greece

Re: Salix Xfce 15.0beta1

Post by Papasot » 2. Jul 2022, 09:00

tonb wrote:
1. Jul 2022, 22:56
I do the following:
- Search for inxi. The line for inxi (name and version) appears in the upper window.
- Click on inxi in the upper window. The line turns blue. Info of inxi appears in the lower window.
- Search for gucharmap. Name and version of gucharmap appear in the upper window, replacing inxi. The line stays blue. The info of inxi is still in the lower window.
- Click on gucharmap in the upper window. Nothing happens. The info of inxi stays in the lower window.
I was able to reproduce @tonb's example above, but the bug is not always apparent. I believe the bug has to do with the first entry found in a search, and whether it is selected automaticaly (has a blue background before even clicking on it) or not. Try the examples below to verify this:

Search for "inxi", select it, then search for something that can be found more than once, say "neovim": several entries are found, but note that the first one is automatically selected: This is not normal, it wouldn't happen in 14.2 (no entry should be selected automatically). Now select any entry except the first one, say "oni": it works as expected, lower window is updated, giving information about oni. Now search for "gucharmap": only one entry is found and it is selected automatically (blue background in upper window - but click on it if you wish, or don't): either way, nothing happens in lower window, information is still given about oni.
Now try again, in another fresh Gslapt session: search for "inxi", select it, then search for "neovim": first entry, in this example eovim, is automatically selected; click on it: nothing happens in the lower window, information is still given about inxi.

Also try this, right after reproducing @tonb's example above: search for something that doesn't exist, say "fuf": nothing found, so nothing is selected; information in lower window is still about inxi. Now search for "gucharmap" again; one entry is found but note that this time it is not selected by default: click on it: it works, lower window is now updated, giving information about gucharmap.

Conclusion: the problem is probably related to the fact the first entry after a search is sometimes selected automatically (without clicking on it). This never happened in Gslapt on 14.2 where no entry is automatically selected, even if there is only one. Whenever first entry is automatically selected in 15.0beta1, clicking on it won't do anything: lower window will not be updated.

Now, I am only guessing here, but it seems the problem is related to GTK; new version is not completely compatible with Gslapt code?
A pleasant detail in this forum: several people pick a picture of their pet as their avatar. Who am I to do otherwise? ;-)

User avatar
gapan
Salix Wizard
Posts: 5954
Joined: 6. Jun 2009, 17:40

Re: Salix Xfce 15.0beta1

Post by gapan » 2. Jul 2022, 10:55

tonb wrote:
1. Jul 2022, 22:56
Suspicious of it being untested and unstable. Slackware has a reputation of being old-fashioned and stable. So, if something is not in Slackware, I suspect it is either not old-fashioned or not stable enough. For me, old-fashioned and stable are the keywords of what vi has to be. vi should simply work, without bells and whistles.
That is a logical fallacy.

And in any case, if you only want to run software that is included in slackware, then salix is not for you. There are more than 100 packages in a salix default installation that are not part of slackware (out of a total of about 900). And if we're talking about the repos, slackware includes almost 1600 packages. There are currently more than 9000 packages in the salix repos for 15.0. Salix is not about slapping a different wallpaper on slackware and calling it a distro as most Ubuntu derivatives do with Ubuntu.

And for what it's worth, neovim is probably more popular and tested way more than vim is right now. It is the most popular editor in the world according to https://insights.stackoverflow.com/surv ... chnologies

And to add to that, the main reason for moving to neovim is that the slackware vim packages apparently haven't been tested enough. The 32bit and 64bit packages should have been identical with respect to their dependencies, but they are not. The 32bit package requires ruby, while the 64bit one doesn't. This creates a problem for us, since ruby is not part of the default salix installation.

And you know what? You're free to do whatever you want with your installation, including replacing neovim with nvi.
tonb wrote:
1. Jul 2022, 22:56
I do the following:
- Search for inxi. The line for inxi (name and version) appears in the upper window.
- Click on inxi in the upper window. The line turns blue. Info of inxi appears in the lower window.
- Search for gucharmap. Name and version of gucharmap appear in the upper window, replacing inxi. The line stays blue. The info of inxi is still in the lower window.
- Click on gucharmap in the upper window. Nothing happens. The info of inxi stays in the lower window.
OK, I see it now.
tonb wrote:
1. Jul 2022, 22:56
This is a suggestion for the next version of slapt-get and/or the underlying
software. The problem is that the latest spkg must be installed before
cogir-icon-theme, but the automated upgrade procedure is designed to upgrade
packages in random (alphabetic?) order. I will try to reason towards a solution
of this problem. With solution I mean an automated procedure that would not
get broken on this order dependency of spkg and qogir-icon-theme.
A mechanism for this exists. If package A depends on package B and both receive updates, then B is always installed before A. However, I chose not to do this in this case because:

1. spkg is not really a dependency for qogir-icon-theme
2. we're still in beta, these kind of things are expected, although hopefully they don't appear often (and they really don't)
3. we're still in beta, if you test, you're kind of expected to read the comments in this testing thread to see if a problem has been resolved and how
Image
Image

User avatar
gapan
Salix Wizard
Posts: 5954
Joined: 6. Jun 2009, 17:40

Re: Salix Xfce 15.0beta1

Post by gapan » 2. Jul 2022, 10:56

Papasot wrote:
2. Jul 2022, 09:00
Now, I am only guessing here, but it seems the problem is related to GTK; new version is not completely compatible with Gslapt code?
Yes, this is definitely something to do with the move to GTK3. There's probably a way to fix it though.
Image
Image

Post Reply