Welcome!
Forum users
  • Please read this before asking for help, and don't forget to add Quick System Info to help requests!
  • Please follow the Forum Rules

Current releases
--MX-19.4 release info here
--Migration information to MX-19.4 here
--antiX-19.4 (Grup Yorum) release info here

Important information
-- Spectre and Meltdown vulnerabilities

News
-- MX Linux on social media: here
-- New Forum Features, Marking Solved and Referencing a User: here

Taskbar program HDD LED/indicator for MX?

Message
Author
jonny70
Posts: 7
Joined: Sat May 22, 2021 9:38 am

Re: Taskbar program HDD LED/indicator for MX?

#21 Post by jonny70 »

JayM wrote: Wed May 26, 2021 9:51 pm Are you using MX-19.4 or MX-KDE? All of the advice given so far assumes you have the standard MX-19.4 with Xfce. KDE Plasma has a Hard Disk I/O Monitor widget that can be added to KDE's panel.
MX19.4-XFCE.

I was suggested this Disk Performance Monitor!
So I searched it.
https://docs.xfce.org/panel-plugins/xfc ... st_release

Installation Instructions
*************************

Copyright (C) 1994-1996, 1999-2002, 2004-2016 Free Software
Foundation, Inc.

Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. This file is offered as-is,
without warranty of any kind.

Basic Installation
==================

Briefly, the shell command './configure && make && make install'
should configure, build, and install this package. The following
more-detailed instructions are generic; see the 'README' file for
instructions specific to this package. Some packages provide this
'INSTALL' file but do not implement all of the features documented
below. The lack of an optional feature in a given package is not
necessarily a bug. More recommendations for GNU packages can be found
in *note Makefile Conventions: (standards)Makefile Conventions.

The 'configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a 'Makefile' in each directory of the package.
It may also create one or more '.h' files containing system-dependent
definitions. Finally, it creates a shell script 'config.status' that
you can run in the future to recreate the current configuration, and a
file 'config.log' containing compiler output (useful mainly for
debugging 'configure').

It can also use an optional file (typically called 'config.cache' and
enabled with '--cache-file=config.cache' or simply '-C') that saves the
results of its tests to speed up reconfiguring. Caching is disabled by
default to prevent problems with accidental use of stale cache files.

If you need to do unusual things to compile the package, please try
to figure out how 'configure' could check whether to do them, and mail
diffs or instructions to the address given in the 'README' so they can
be considered for the next release. If you are using the cache, and at
some point 'config.cache' contains results you don't want to keep, you
may remove or edit it.

The file 'configure.ac' (or 'configure.in') is used to create
'configure' by a program called 'autoconf'. You need 'configure.ac' if
you want to change it or regenerate 'configure' using a newer version of
'autoconf'.

The simplest way to compile this package is:

1. 'cd' to the directory containing the package's source code and type
'./configure' to configure the package for your system.

Running 'configure' might take a while. While running, it prints
some messages telling which features it is checking for.

2. Type 'make' to compile the package.

3. Optionally, type 'make check' to run any self-tests that come with
the package, generally using the just-built uninstalled binaries.

4. Type 'make install' to install the programs and any data files and
documentation. When installing into a prefix owned by root, it is
recommended that the package be configured and built as a regular
user, and only the 'make install' phase executed with root
privileges.

5. Optionally, type 'make installcheck' to repeat any self-tests, but
this time using the binaries in their final installed location.
This target does not install anything. Running this target as a
regular user, particularly if the prior 'make install' required
root privileges, verifies that the installation completed
correctly.

6. You can remove the program binaries and object files from the
source code directory by typing 'make clean'. To also remove the
files that 'configure' created (so you can compile the package for
a different kind of computer), type 'make distclean'. There is
also a 'make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.

7. Often, you can also type 'make uninstall' to remove the installed
files again. In practice, not all packages have tested that
uninstallation works correctly, even though it is required by the
GNU Coding Standards.

8. Some packages, particularly those that use Automake, provide 'make
distcheck', which can by used by developers to test that all other
targets like 'make install' and 'make uninstall' work correctly.
This target is generally not run by end users.

Compilers and Options
=====================

Some systems require unusual options for compilation or linking that
the 'configure' script does not know about. Run './configure --help'
for details on some of the pertinent environment variables.

You can give 'configure' initial values for configuration parameters
by setting variables in the command line or in the environment. Here is
an example:

./configure CC=c99 CFLAGS=-g LIBS=-lposix

*Note Defining Variables::, for more details.

Compiling For Multiple Architectures
====================================

You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you can use GNU 'make'. 'cd' to the
directory where you want the object files and executables to go and run
the 'configure' script. 'configure' automatically checks for the source
code in the directory that 'configure' is in and in '..'. This is known
as a "VPATH" build.

With a non-GNU 'make', it is safer to compile the package for one
architecture at a time in the source code directory. After you have
installed the package for one architecture, use 'make distclean' before
reconfiguring for another architecture.

On MacOS X 10.5 and later systems, you can create libraries and
executables that work on multiple system types--known as "fat" or
"universal" binaries--by specifying multiple '-arch' options to the
compiler but only a single '-arch' option to the preprocessor. Like
this:

./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
CPP="gcc -E" CXXCPP="g++ -E"

This is not guaranteed to produce working output in all cases, you
may have to build one architecture at a time and combine the results
using the 'lipo' tool if you have problems.

Installation Names
==================

By default, 'make install' installs the package's commands under
'/usr/local/bin', include files under '/usr/local/include', etc. You
can specify an installation prefix other than '/usr/local' by giving
'configure' the option '--prefix=PREFIX', where PREFIX must be an
absolute file name.

You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
pass the option '--exec-prefix=PREFIX' to 'configure', the package uses
PREFIX as the prefix for installing programs and libraries.
Documentation and other data files still use the regular prefix.

In addition, if you use an unusual directory layout you can give
options like '--bindir=DIR' to specify different values for particular
kinds of files. Run 'configure --help' for a list of the directories
you can set and what kinds of files go in them. In general, the default
for these options is expressed in terms of '${prefix}', so that
specifying just '--prefix' will affect all of the other directory
specifications that were not explicitly provided.

The most portable way to affect installation locations is to pass the
correct locations to 'configure'; however, many packages provide one or
both of the following shortcuts of passing variable assignments to the
'make install' command line to change installation locations without
having to reconfigure or recompile.

The first method involves providing an override variable for each
affected directory. For example, 'make install
prefix=/alternate/directory' will choose an alternate location for all
directory configuration variables that were expressed in terms of
'${prefix}'. Any directories that were specified during 'configure',
but not in terms of '${prefix}', must each be overridden at install time
for the entire installation to be relocated. The approach of makefile
variable overrides for each directory variable is required by the GNU
Coding Standards, and ideally causes no recompilation. However, some
platforms have known limitations with the semantics of shared libraries
that end up requiring recompilation when using this method, particularly
noticeable in packages that use GNU Libtool.

The second method involves providing the 'DESTDIR' variable. For
example, 'make install DESTDIR=/alternate/directory' will prepend
'/alternate/directory' before all installation names. The approach of
'DESTDIR' overrides is not required by the GNU Coding Standards, and
does not work on platforms that have drive letters. On the other hand,
it does better at avoiding recompilation issues, and works well even
when some directory options were not specified in terms of '${prefix}'
at 'configure' time.

:frustrated: :frustrated: :frustrated: :frustrated:

BTW "panel" is the Linux term for its equivalent of the Windows taskbar.
The best way to make poeple switch, is to introduce new nomenclature 90% of the world has no idea, what it means.
In MX-19.4 it defaults to a vertical panel along the left of the screen (which can easily be moved to the bottom in MX Tweak) while in KDE it's already along the bottom.
Ofcourse I have switched the taskbar from vertical :frustrated: to horizontal. And it took unnecessary time, to get the clock and layout where it should be.
I suggest you take some time to learn your way around in your new operating system, and if you're coming from Windows set your expectations properly as there's going to be a learning curve since you've changed to a very un-Windows OS with a different philosophy behind it. Otherwise, if you require an operating system that's just like Windows, there is one: Windows.
Blaming the customer is always the best way to succeed in a market. Nothing has changed in the last 20 years in the Linux community.

Technical superiority is useless, if the customer needs to relearn everything!

Complaining and calling Linux "awful" because it's not 100% the same as what you're already used to (and because you don't know what you're doing yet, but you will if you're just patient enough) is a waste of everyone's time including yours
100% the same?
No, I am talking about the problem, to get a tiny program running.
This problem is a FACT of a user. A fact. Ok?

It does not go away, if Linux people demand that I need to learn how to use a OS.
A OS should be transparent to the user anyway.

The success of Android is based on good understanding, how a OS must support the user - and not vice versa.
, time that could be spent more productively by exploring and learning your new system.
Have you ever worked under time pressure? This is totally false. Because if a tiny program already makes such a trmenedous hassle, I would be crazy, to try to make the switch.
Everyday tasks have to run very smoothly. Which Windows is capable of.
You had to learn Windows the first time you used it, didn't you? So now you have to learn MX Linux.
If there is a paradigma established to 95% of all users in the world, and I want to conquer this market, then it would be not very clever clever, to force users to relearn everything and make everything different.
Christian holidays were put on summer and winter solstice not by accident.

If you changed from a PC to a Mac you'd have to learn Apple's OS. If you buy a Chromebook you'll have to learn ChromeOS. Because those operating systems are different than Windows doesn't mean they're "awful", it just means they're different than Windows (because they're not Windows.)
There's nothing to learn with these OSs. All administrative tasks for users are self explanatory. No need to compile programs or check, which archive is needed for which OS build or CPU. The user is guided by the OS.
As you're just testing MX in a virtual machine you have plenty of time to explore it and learn about it so there's no need to get impatient and frustrated and take out your frustration on the people in the forum who are trying to help you. If you're too impatient to do that then perhaps Linux in general isn't for you.
I am sorry for having been rude.
Since I see, where MS and Google are aiming with a totalitarian control grid, and I already shook my head 20 years ago, what the Linux community was doing, instead of focusing on user friendlyness, I find even more frustrating these days, that the Linux community is still not understanding what it takes to gain market share and win with a technically far superior OS. But the best kernel is useless, if the frontend is not user friendly accordng to modern standards.

User avatar
Eadwine Rose
Administrator
Posts: 12954
Joined: Wed Jul 12, 2006 2:10 am

Re: Taskbar program HDD LED/indicator for MX?

#22 Post by Eadwine Rose »

One important thing: we are not here to cater to the market. We are here to provide something else to the individual who is willing to take the time to learn something new.
MX-19.4_x64 Oct 21 2019 * 4.19.0-6-amd64 ext4 Xfce 4.14.2 * 8-core AMD Ryzen 7 2700
Asus TUF B450-Plus Gaming UEFI * Asus GTX 1050 Ti Nvidia 418.197.02 * 2x16Gb DDR4 2666 Kingston HyperX Predator
Samsung 860EVO * Samsung S24D330 & P2250 * HP Envy 5030

jonny70
Posts: 7
Joined: Sat May 22, 2021 9:38 am

Re: Taskbar program HDD LED/indicator for MX?

#23 Post by jonny70 »

SwampRabbit wrote: Wed May 26, 2021 8:11 pm You can get what you want WITHOUT OPENING A TERMINAL OR DOING ANYTHING CODE RELATED. 90% of anything Linux can be done through a GUI.

Please reread my post #14. We're trying to help you.

1) Right click the panel
2) Hover over the "Panel" popout
3) select "Add New Items..."
4) select "Disk Performance Monitor"
5) click "Add"

You should see it added to the Panel at the bottom if you're using the default MX-19 panel.

If you Right Click it you can select move to move it anywhere in the Panel. Right Clicking also lets you change some of the properties.

Look at all the junk I just added in like 10 seconds without opening the terminal or even touching my keyboard
ksnip_20210526-201054.png
https://imgur.com/PmjUoqo

The time, money, business, and what not stuff.... I'm pretty sure that's just your frustration coming through. Because those really are just opinions and not facts.
:number1:
Thank you.

What is the best way to turn new users away? Nerds suggesting complicated solutions that lead newbies to dead ends... :mad:

User avatar
JayM
Qualified MX Guide
Posts: 10082
Joined: Tue Jan 08, 2019 4:47 am

Re: Taskbar program HDD LED/indicator for MX?

#24 Post by JayM »

The panel plugin that was recommended to you is already installed in the operating system and available. All you have to do is add it to your panel and configure it. You've been given step-by-step instructions by several people in this thread, such as post #18 by SwampRabbit, one of the developers. Nobody told you to search for instructions on compiling and installing a test version of it, for Pete's sake. If you're having problems with Linux being user-unfriendly those problems are entirely on you. We already told you exactly what to do.

Also, if you want to install things use MX Package Installer. First check the Popular Applications tab, then the Stable Repo tab. You should stay away from the Test Repo, Debian Backports and Flatpaks tabs for now until you know what you're doing. If a package or application is greyed out that means it's already installed.
Last edited by JayM on Thu May 27, 2021 6:19 am, edited 2 times in total.
Please read the Forum Rules, How To Ask For Help, How to Break Your System and Don't Break Debian. Always include your full Quick System Info (QSI) with each and every new help request.

User avatar
Eadwine Rose
Administrator
Posts: 12954
Joined: Wed Jul 12, 2006 2:10 am

Re: Taskbar program HDD LED/indicator for MX?

#25 Post by Eadwine Rose »

jonny70 wrote: Thu May 27, 2021 4:12 am :number1:
Thank you.

What is the best way to turn new users away? Nerds suggesting complicated solutions that lead newbies to dead ends... :mad:
We're not forcing this down your throat, and those who like it enough will stay and obviously do.
MX-19.4_x64 Oct 21 2019 * 4.19.0-6-amd64 ext4 Xfce 4.14.2 * 8-core AMD Ryzen 7 2700
Asus TUF B450-Plus Gaming UEFI * Asus GTX 1050 Ti Nvidia 418.197.02 * 2x16Gb DDR4 2666 Kingston HyperX Predator
Samsung 860EVO * Samsung S24D330 & P2250 * HP Envy 5030

User avatar
Jerry3904
Administrator
Posts: 29808
Joined: Wed Jul 19, 2006 6:13 am

Re: Taskbar program HDD LED/indicator for MX?

#26 Post by Jerry3904 »

This thread is going nowhere--time to move on.
Production: 5.6, MX-19, AMD FX-4130 Quad-Core, GeForce GT 630/PCIe/SSE2, 16 GB, SSD 120 GB, Data 1TB
Testing: XPS 13, 4.19, Intel Dual core,Intel HD Graphics 5500, 4 GB
Personal: Lenovo X1 Carbon

Locked

Return to “MX Repositories”