Page 19 of 60

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 10:27 am
by fehlix
dolphin_oracle wrote: Tue Sep 10, 2019 10:01 am
fehlix wrote: Tue Sep 10, 2019 9:42 am
dolphin_oracle wrote: Mon Sep 09, 2019 9:00 pm

what do you think of something like this, if it even still works. got it out of the depths of stackoverflow.

Code: Select all

echo 'SUBSYSTEM=="block", ENV{UDISKS_AUTO}="0"' > /run/udev/rules.d/90-udisks-inhibit.rules
supposedly that disables automounting. it certainly leaves the list in place in thunar.

i tried with gparted in my test suite with some success, but I need more data points.

**never mind, didn't work in practice **
The closest to the mentioned requirement I can get with something like to "ignore" those which are going to be added or re-partitioned. E.g. for new or recreaterd sda4, sdas5 sda6 creating such rule

Code: Select all

echo 'KERNEL=="sda[456]", SUBSYSTEM=="block", ENV{UDISKS_IGNORE}="1", ENV{UDISKS_AUTO}="0"' > /run/udev/rules.d/00-udisk2-ignore-block.rules
udevadm control --reload; udevadm trigger --subsystem-match=block
seems to not trigger any automount. Perhaps also related to udev polling time. After removing later that rule devies are shown but automount is not triggered.

that's close. but the ones that I get asked to automount aren't the ones we are installing to anyway (there are already mounted), its other partitions and especially partitions on other devices.
On my system partprobe does not trigger automount, when nothing has changed. Only when kernel signals some changes,partpobe seems to triggers automount. The above example "hides" the changes hence at least on my system I get not automount triggered, even with having added partitions.

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 10:39 am
by dolphin_oracle
fehlix wrote: Tue Sep 10, 2019 10:27 am
dolphin_oracle wrote: Tue Sep 10, 2019 10:01 am
fehlix wrote: Tue Sep 10, 2019 9:42 am
The closest to the mentioned requirement I can get with something like to "ignore" those which are going to be added or re-partitioned. E.g. for new or recreaterd sda4, sdas5 sda6 creating such rule

Code: Select all

echo 'KERNEL=="sda[456]", SUBSYSTEM=="block", ENV{UDISKS_IGNORE}="1", ENV{UDISKS_AUTO}="0"' > /run/udev/rules.d/00-udisk2-ignore-block.rules
udevadm control --reload; udevadm trigger --subsystem-match=block
seems to not trigger any automount. Perhaps also related to udev polling time. After removing later that rule devies are shown but automount is not triggered.

that's close. but the ones that I get asked to automount aren't the ones we are installing to anyway (there are already mounted), its other partitions and especially partitions on other devices.
On my system partprobe does not trigger automount, when nothing has changed. Only when kernel signals some changes,partpobe seems to triggers automount. The above example "hides" the changes hence at least on my system I get not automount triggered, even with having added partitions.
I need to think about that one. I'm not sure where such a rule would be included, and how we deal with things before we know what devices are changed (in otherwords, when the user runs gparted from the installer).

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 10:56 am
by fehlix
dolphin_oracle wrote: Tue Sep 10, 2019 10:39 am
fehlix wrote: Tue Sep 10, 2019 10:27 am
dolphin_oracle wrote: Tue Sep 10, 2019 10:01 am


that's close. but the ones that I get asked to automount aren't the ones we are installing to anyway (there are already mounted), its other partitions and especially partitions on other devices.
On my system partprobe does not trigger automount, when nothing has changed. Only when kernel signals some changes,partpobe seems to triggers automount. The above example "hides" the changes hence at least on my system I get not automount triggered, even with having added partitions.
I need to think about that one. I'm not sure where such a rule would be included, and how we deal with things before we know what devices are changed (in otherwords, when the user runs gparted from the installer).
If the above could be proved is working ( means hiding partitions changes made by minstall), we could regard the gparted-call to be identical as when called from the menu. So the user would have identical "gparted" experiences.
The above "hide" rules would only need to be added as soon as we know what partitions are involved ( i.e. before re-creation/re-formatting), e.g. just before that action and only at the end to be removed (if at all).

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 11:27 am
by dolphin_oracle
fehlix wrote: Tue Sep 10, 2019 10:56 am
dolphin_oracle wrote: Tue Sep 10, 2019 10:39 am
fehlix wrote: Tue Sep 10, 2019 10:27 am
On my system partprobe does not trigger automount, when nothing has changed. Only when kernel signals some changes,partpobe seems to triggers automount. The above example "hides" the changes hence at least on my system I get not automount triggered, even with having added partitions.
I need to think about that one. I'm not sure where such a rule would be included, and how we deal with things before we know what devices are changed (in otherwords, when the user runs gparted from the installer).
If the above could be proved is working ( means hiding partitions changes made by minstall), we could regard the gparted-call to be identical as when called from the menu. So the user would have identical "gparted" experiences.
The above "hide" rules would only need to be added as soon as we know what partitions are involved ( i.e. before re-creation/re-formatting), e.g. just before that action and only at the end to be removed (if at all).
so maybe hide everything until the installer actually launches, then remove the rule that hides everything and then put in place the new rule above, reload the rules, partprobe, and see what happens.

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 12:04 pm
by phykris
The orage preferences that I set (from the whisker menu) seem to have no influence at all at the layout of the calendar that I see when I click on the clock in the panel.
Any idea how to fix this? I would like to remove the week numbers.

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 12:16 pm
by dolphin_oracle
phykris wrote: Tue Sep 10, 2019 12:04 pm The orage preferences that I set (from the whisker menu) seem to have no influence at all at the layout of the calendar that I see when I click on the clock in the panel.
Any idea how to fix this? I would like to remove the week numbers.
are you using the orage clock plugin? by default, we are not.

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 12:22 pm
by fehlix
phykris wrote: Tue Sep 10, 2019 12:04 pm The orage preferences that I set (from the whisker menu) seem to have no influence at all at the layout of the calendar that I see when I click on the clock in the panel.
Any idea how to fix this? I would like to remove the week numbers.
Yes, bc the default clock/calendar in the panel is not the orage calender/clock but the xfce4-datetime-plugin. :footinmouth:
clocks.png
Not sure how to hide week-numbers within xfce4-datetime calendar.

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 12:52 pm
by Jerry3904
The calendar is a gtk widget. Looking at the documentation here, I see there is a way to hide the week numbers, but the method would take some snooping around. You can use the Orage Panel Clock plugin instead.

I made a request on the Xfce Forum where you can keep track of responses.

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 1:41 pm
by Eadwine Rose
On a fresh install of beta 2.1 here, I decided to first test out the vsync thing in mx tweak - compositor because my second monitor is not displaying correctly (resolution is correct but it is smaller in size than the screen itself) and AK-47 told me to try that. Well, it doesn't help that bit, however as soon as I changed it a second volume icon popped up right above the other one (or below).

One on top has the slider all the way up, the other one has it all the way down.

I don't think that is supposed to happen?

Re: MX-19 Beta 2.1 Feedback

Posted: Tue Sep 10, 2019 2:04 pm
by Eadwine Rose
Another thingie is going on: gdebi isn't behaving like it should. Noticed this on the earlier install but went meh. Want to report it anyway.

I wanted to install the .deb for Slack-desktop (that thing is not in the repos), so I right click it to open with Gdebi and it just sits there doing nothing, so it seems, indefinitely. Screen empty and all:
Screenshot.png


Now, if I go to file - open and navigate to the .deb it WILL call in what I want to see:
Screenshot-1.png