I’ve seen it stated that scrollbar buttons depend on the theme used but I use jwm which has no themes. Can someone point me to where LO gets the image for the scroll bar buttons?
Thanks,
Mike
On this system under Debian bookworm and LO 7.2 I had scroll bar button. After upgrading to trixie and LO 25.2 still had scroll bar buttons but window resizing was broken and windows for cell format and Tools/Options went off screen. That was blamed on X11 and 1024x768 resolution. Using xrandr I could change the screen to 1920x1080 which kept the Tools/Options, etc. on screen but really slowed screen repaints down.Hoping to get buttons from trixie-backports I upgraded to LO 25.8.3, this fixed the window resizing problem but still don’t have buttons.
On fpy’s recommendation, ( see: https://ask.libreoffice.org/t/calc-window-not-resizing-properly/128607/9 I grabbed a aarch64 Deb for 25.8.2.3 from documentfoundation.org. This installed in /opt/ rather than /usr/lib/This one has VCL: gtk3 rather than X11 and works fine at 1024x768 so I don’t need the resolution switch but still doesn’t have buttons on the scroll bar.
Since all the LO versions using X11 had buttons I thought perhaps the fact that it wasn’t under /usr/lib/ was the problem so moved /usr/lib/libreoffice to libreoffice.orig and made /usr/lib/libreofice a link to /opt/libreoffice25.8 where the version from the documentation installed. It seems to run fine but still lacks scroll bar buttons.
I know they are in the system.
How do I tell LO where to find them.
Thanks,
Mike
please please, dont mess up your system! There should be distinct Menu-entrys for each LO, for Example: one executes: /usr/bin/soffice --calc and the other: /opt/libreoffice25.8/program/soffice --calc
Ps. you cannot run both at the same time because they use the same user-config-path !!
To run both at the same time you may change the menu-entry-command from libreoffice25.8 --calc %U to libreoffice25.8 -env:UserInstallation=file:///home/mike/tdf_lo/ --calc %U
(slightly) off topic:
-
the good news: since october_25 there are tdf-builds for linux-arm64 available
-
the not so bad news: their python-version is only 2 minor steps behind the conservative Debian:
Python 3.11.14 versus Python 3.13.5 -
the bad news: The python packages are still incomplete. (eg: no venv no pip …)
I thank you for your concern but you seem a little confused, switching what’s under /usr/lib/libreoffice would in no way break the system. At worst all it would have broken was libreoffice which could always be removed then reinstalled.
In fact all it did was to show that having the /opt version DL’d from the document foundation under /usr/lib/ did not clear up the missing scroll bar buttons and that is why the switch was made.
Happy ThanksGiving,
Mike
1 Like
I had looked with strace already and spotted nothing that I could lay the blame on but at your suggestion I tried again.
I straced both localc versions like so:
mike@RPI2:~> strace -f -o strace.lo25.8X11 /usr/lib/libreoffice/program/soffice --calc
mike@RPI2:~> strace -f -o strace.lo25.8gtk3 /opt/libreoffice25.8/program/soffice --calcThe former being DLd from trixie-backports, the latter from documentfoundation.org.
To pull out the files I used these:
mike@RPI2:~> open.strace() { grep open $1 | grep -v 'tmp\|ENOENT\|resumed' | cut -d\" -f2 | sort | uniq; }
mike@RPI2:~> open.strace.base() { for f in $(grep open $1 | grep -v 'tmp\|ENOENT\|resumed' | cut -d\" -f2 ); do
basename $f; done | sort | uniq; }A diff of the outputs of open.strace on the two files showed that there were lots of files with the same names in both directory trees so I just ran open.strace.base to get this list of names, so:
mike@RPI2:~> diff <( open.strace.base strace.lo25.8X11 ) <( open.strace.base strace.lo25.8gtk3 ) | grep '<' | column< 153570 < libicuuc.so.76
< 158c65c810c0d352a587f5be66058e87-le64.cache-9 < libjbig.so.0
< 807752c9e168308eb5108dacded5237a-le64.cache-9 < liblangtag.so.1
< Compose < liblber.so.2
< M8SdCd < libldap.so.2
< VL-PGothic-Regular.ttf < libltdl.so.7
< b9Uouk < libmhash.so.2
< compose.dir < libmythes-1.2.so.0
< fonts-japanese-gothic.ttf < libnghttp2.so.14
< g4J1gD < libnghttp3.so.9
< libLerc.so.4 < libnumbertext-1.0.so.0
< libabsl_bad_optional_access.so.20240722 < libopenjp2.so.7
< libabsl_bad_variant_access.so.20240722 < libpsl.so.5
< libabsl_log_severity.so.20240722 < libraptor2.so.0
< libabsl_raw_logging_internal.so.20240722 < librasqal.so.3
< libabsl_throw_delegate.so.20240722 < librdf.so.0
< libargon2.so.1 < libsasl2.so.2
< libboost_iostreams.so.1.83.0 < libsharpyuv.so.0
< libboost_locale.so.1.83.0 < libssh2.so.1
< libboost_thread.so.1.83.0 < libssl.so.3
< libclucene-contribs-lib.so.1 < libtiff.so.6
< libclucene-core.so.1 < libvclplug_genlo.so
< libclucene-shared.so.1 < libwebp.so.7
< libcrypto.so.3 < libxmlsec1-nss.so.1
< libdb-5.3.so < libxmlsec1.so.1
< libdconf.so.1 < libyajl.so.2
< libdeflate.so.0 < libzstd.so.1
< libeot.so.0 < libzxcvbn.so.0
< libexttextcat-2.0.so.0 < local
< libharfbuzz-icu.so.0 < m
< libhunspell-1.7.so.0 < m3g3On
< libhyphen.so.0 < oor:path=\
< libicudata.so.76 < opens___.ttf
< libicui18n.so.76 < user
The strace man page also suggested ‘-e trace=%files’ so I did this:
mike@RPI2:~> strace -e trace=%file -o strace.lo25.8X11.files /usr/lib/libreoffice/program/soffice --calc
mike@RPI2:~> strace -e trace=%file -o strace.lo25.8gtk3.files /opt/libreoffice25.8/program/soffice --calcUsing these :
mike@RPI2:~> files.strace() { grep -v 'ENOENT\|EINVAL\|CLD_EXITED\|tmp\|+++' $1 | cut -d '"' -f 2 | sort | uniq; }
mike@RPI2:~> files.strace.base() { for f in $( grep -v 'ENOENT\|EINVAL\|CLD_EXITED\|tmp\|+++' $1 | cut -d '"' -f 2 ); do
basename $f; done | sort | uniq; }
mike@RPI2:~> diff <( files.strace.base strace.lo25.8X11.files ) <( files.strace.base strace.lo25.8gtk3.files ) | grep '<'
< libpng16.so.16
mike@RPI2:~> grep libpng16.so.16 strace.lo25.8X11.files
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/libpng16.so.16", O_RDONLY|O_CLOEXEC) = 3strace.lo25.8gtk3.files shows that many files in /lib/aarch64-linux-gnu/ are opened by the /opt/ version of localc but not this one.
I was quite surprised that while ‘strace -f’ showed 433 & 517 files opened, ‘strace -e trace=%file’ only listed 37 & 35 files opened by the two localc versions.
Thoughts or suggestions?
After chasing this for many hours over many days I must admit I’m stumped.
Be well,
Mike
wow ! 
well, since you’re counting in (many) hours, it would be probably more interesting for you (and for LO) to try a top down approach → Development/BuildingOnLinux - The Document Foundation Wiki
will give you a better idea of the components involved → Development/VCL - The Document Foundation Wiki
→ https://opengrok.libreoffice.org/xref/core/vcl/unx/
with luck, you may also get more detailled suggestions from the various channels listed under Development - The Document Foundation Wiki
1 Like
Bless you Sir, you pointed me to a solution to my problem.
On this page https://wiki.documentfoundation.org/Development/Environment_variables#VCL I found the suggestion to add
--env:SAL_USE_VCLPLUGIN=gen
to my localc execution statement, like so:
/opt/libreoffice25.8/program/soffice --env:SAL_USE_VCLPLUGIN=gen --calc /mc/docs/finance/stocks.ods;The gen equates to X11 and now I have scrollbar buttons.
I failed to find a way to get those buttons with gtk3 but having the buttons was what I was after anyway so I’ve a grin on my face and you helped put it there.
Many Thanks,
Mike
soffice --help | grep env
-env:<VAR>[=<VALUE>] Set a bootstrap variable. For example: to set
-env:UserInstallation=file:///tmp/test
I see no double -- in front of env!