There's a fork (SpaceFM-NG), and a new bugfix 1.0.6 release from ~March, though it hasn't been touched since ( let's hope the guy picks it up eventualy ).

https://github.com/Teklad/spacefm-ng
https://github.com/Teklad/spacefm-ng/releases/tag/1.0.6

Status update from IG: https://github.com/IgnorantGuru/spacefm/issues/687

If anybody tries to build a .deb package from NG repo, keep in mind that changelog is still at v1.0.5, so you should apply some "dch -i" magic on it to avoid apt "downgrading" it.

I've been running GTK2 build since it was released without any issues ( on Stretch though ).

Quote from: misko_2083 on May 07, 2017, 11:10:31 AM
@Filip
Thanks. 
mpv - That's a great idea! mpv has a remote (somewhere ), I will dig into documentation.

Between the couch cushions perhaps!? 

Joke aside, I did take a quick look @docs/google, but didn't find anything. The "bad" here is that MPV has support for real remote controlers ( the hardware ones ), which is the main hit on Google, making the shell "remote" we need here hard to find... And the docs are longer then the Bible... 

Quote from: misko_2083 on May 07, 2017, 11:10:31 AM
Close to tray - It's easy to close it, bringing it back is another story     
                          Will see about that. It's a good option to have a radio that stays out of the way.

"Kill to tray"

Maybe if there is an easy way to keep information about current station/log etc somewhere it might be doable with something like ( untested, just a thought ):


function main() {

if [[ "$LOG_AND_CURRENT_STATION_AND_OTHER_DATA" = true ]]
# main dialog stuff in here with the "--button=Close!close:1" & "DATA" appended somehow
else
# main dialog stuff in here with the "--button=Close!close:1"
fi

RET=$?
if [[ "$RET" == 1 ]]; then
WIN_VISIBLE=false
else
WIN_VISIBLE=true
fi
}
export main
main

function window_toggle() {
# called on tray left click
if [[ "$WIN_VISIBLE" = true ]]; then
main
fi
}


The bad side with the above is that you cannot click the tray icon to toggle the window. In other words, window needs to be closed the usual ways, and can only be brought back from tray with the "on tray" click.
Hope it helps some.
Cheers!

Quote from: VastOne on May 06, 2017, 12:38:46 AM
What I may end up doing is keeping the x32 build platform up to date in the even anyone should ever need it but would only be by request.. it is a simple process that is pretty much scripted

I would then only maintain an ISO for standard x64 and uEFI x64...

As far as I'm concerned, go for it!

Though you could also reduce the release frequency for 32bit to say, 3-4 releases per year or whenever some nasty breakages occur in Sid.
That way you'd provide a smoother transition for users, and eventually if nobody complains, ditch it all together or switch to "per request" builds only.

Quote from: VastOne on May 05, 2017, 11:52:08 PM
Great info and explanation Filip... Thanks mate

I do not mind the extra half hour of build and test time to have a uEFI option.. IMO a better question is why on earth is there a need for a 32 bit version at all

Lets debate that one

Anytime!

@32bit:
Well, personally I don't care about it anymore, nor see any real use-case in the desktop arena for it.
I have a great attachment to my Athlon-XP machine ( that was my first ever CPU ), however the growing pains coming from the lack of SSE2 instructions and the abysmal performance ( browsers, gtk3 etc ) simply killed all the joy in using & playing with it, so I just gave it up post Deb Jessie.

IMO, 32bit has become, or is slowly but surely becoming a niche/legacy arch, and should perhaps still be supported by the big players only ( Debian et al ).
Of course, I'm not trying to be provocative or something, there are still legitimate use cases, and users that really need the 32bit, however those numbers are low and getting lower by the day to justify the effort required by the distro maintainers ( excluding major players who can afford it ).

And not to mention that using a 32bit distro on a 64bit capable machine is just a pure waste of resources and performance. Further exaggerated by the fact how cheap RAM is these days ( so "higher RAM usage for 64 bit" doesn't really hold any more ).

@Misko

Nice work! 

Couple of notes/ideas:

1. I don't know for sure whether "mpv" has a remote control, however if it does it might be much better then "mpg123" ( atleast there woudn't be a "Quit lag" )
2. "Close to tray" would be awesome, though AFAIK it's not (yet) possible with YAD?? 

Quote from: VastOne on May 02, 2017, 12:45:07 AM
^ Good question... I can install to normal hw with the uEFI ISO but something goes amuck with grub.. I get the grub rescue screen...
...

That's the GRUB EFI vs GRUB BIOS issue.
See, having any GRUB variant preinstalled on the Live squash.fs image essentially locks you to that variant ( BIOS or UEFI ).
Installer, on the other hand is designed with the single ISO supporting both in mind, and works in the following way:

1. You don't have any GRUB installed @squash.fs
2. You do have all grub packages, "efibootmgr" and "os-prober" in the "support" dir on the ISO image root.

Then, during installation installer sets up a temporary Apt repository from the ^"/support" and installs apropriate GRUB for the machine from there.

Btw, installer-wise, there's nothing wrong with the separate ISO's aproach, except for that "issue" of being usable only for the targeted machines/BIOS types.

I think the issue here is that Conky waits for the command to return, which YAD doesn't since it's sitting active in the tray.
You should be able to confirm this by clicking the tray icon ( default is to quit on click ) after which Conky should redraw/show.
If so, then I don't think you can easily work around it.

On the other hand, going the regular bash route, something like this should do the job:

#!/bin/bash

PIPE=$(mktemp -u --tmpdir ${0##*/}.XXXXXXXX)
mkfifo $PIPE

exec 3<> $PIPE

function exit() {
    echo "quit" >&3
    rm -f $PIPE
}
trap exit EXIT

# "--command" is left empty with the purpose of
# disabling "Quit on left click".
# You can still middle click to quit.
yad --notification                  \
    --kill-parent                   \
    --listen                        \
    --image="gtk-help"              \
    --visible=false                 \
    --text="Tooltip text goes here" \
    --command="" <&3 &

function battery_check() {

# BATTERY=$(command to get battery percentage)

}
battery_check

while true; do
    if [[ "$BATTERY" -le 10 ]]; then
        echo "icon:battery_empty" >&3
        echo "visible:blink" >&3
    else
        echo "visible:false" >&3
    fi
    sleep 10s
    battery_check
done


I'm not using a laptop and don't know the command to get battery percentage, so you'll need to fill that in @"battery_check" function.
Also, it won't get anywhere close to hogging the RAM or the CPU, as long as you don't go wild with the "sleep" inside the "while" loop ( low intervals like "sleep 0.1s" ).

Quote from: ozitraveller on April 19, 2017, 03:42:30 AM
Awesome filip!

Like it!

Looks better than connman-ui

Thanks!

Indeed, it's awesome really. Looks good, stays out of the way and it's usable when needed. 

Btw, I haven't mentioned it here, I'm not the actual author.
I just packaged and patched it to enable window toggling from tray icon.

Quote from: PackRat on April 19, 2017, 12:19:47 PM
Looks good.

One item though, don't mean to nit-pick but on your git page you have:

QuoteDependencies

  intltool
  GLib
GTK >= 3.10

Shouldn't connman be on the list, this isn't a stand alone application is it?

Well, it should be, though it implies itself since it's a front-end for it ( not a stand alone )...
Anyhow, it's fixed now. 

Quote from: PackRat on April 19, 2017, 12:59:16 PM
Successfully compiled it on Void Linux.

Nice work.

I'll have to run connman for a while; much smaller memory footprint than NetworkManager or wicd.

Also seems to require root privleges to connect/roam with wireless. Will that be the case on Debian as well?

I'm using it for atleast 6 months and honestly have no idea it's even there. The damn thing JustWorks™. 

As to WiFI & root, I wouldn't know since I don't have a WiFi to test ( desktops on LAN all around ).
Though ( on Debian atleast ) I am finding it odd that the "connmanctl" command is installed in /usr/sbin ( thus requiring root privileges )... 
For example, on Arch it goes to /usr/bin...

With that said, you may try to symlink it to /usr/bin:
sudo ln -s /usr/sbin/connmanctl /usr/bin/connmanctl
I'm not sure that the front-end will even look for it there ( both connman and GUI might need rebuilding for this to work ).

And, after symlinking do verify that it actually works without root:
connmanctl scan wifi; connmanctl services

and then try to connect to one of WiFi's listed with:
connmanctl connect wifi_xxxxxxxxxx

Also, see: https://forum.voidlinux.eu/t/connman-needs-root/231/6

As promised in the installer topic, I've pushed the connman-gtk to git, including debian packaging and a small patch allowing main window to be toggled by clicking the tray icon.



For details and more screenshots see: https://gitlab.com/Cofi/connman-gtk

Build instructions:

1. Clone & cd:
git clone https://gitlab.com/Cofi/connman-gtk.git && cd connman-gtk

2. Install build deps:
mk-build-deps --install ./debian/control      # if "mk-build-deps" is missing install "devscripts" package first

3. Build and install:
dpkg-buildpackage -j$(nproc)
cd ../ && sudo apt install ./connman-gtk_1.1.1-2_amd64.deb

Enjoy & god-forbid there be any issues, let me know! 

Quote from: hakerdefo on April 14, 2017, 09:03:35 PM
@filip Great work on the installer 
Keep it up 

Cheers!!!

Thank you! 

---

@VastOne:

The "resume device" hang propagated to Stretch as well. And for once it actually has nothing to do with systemd.
You were right, issue was introduced in "initramfs-tools", v128 in order to fix the bug where some NVMe drives were slow to enumerate partitions causing the system to fail to resume from hibernation...

See changelog and a bug report.

The weird part is the wait time they've set ( ~20sec ). I mean what for, seriously!? Even the guy who reported the bug said that adding a 1sec delay fixed the issue for him... 

Anyway, until they sort it out, the quick fix is to add the "resume=/dev/sdXY" to the "GRUB_CMDLINE_LINUX_DEFAULT" in "/etc/default/grub" file, where "/dev/sdXY" is your swap partition ( worked for me atleast @Stretch ). 
You might even get away with any partition ( not just swap ), as long as you don't have any data on it ( untested!!! ).

---

EDIT:

I've also looked at the actuall shell scripts used, however I'm having a bit of a hard time reading them ( I've never really understood why Debianers always write shell scripts in such obfuscated and "hard to read" way  ).
I'll let you know If I get anywhere with that...

Quote from: VastOne on April 10, 2017, 12:01:34 AM
I do not have that on any line, I do not use swap and never ever have used hibernation even when I do use a laptop

This has also started to happen on this my build machine that is also completely up to SID levels..

This is nothing new in SID, just a hiccup that is only a concern if someone boots VSIDO on a new install and does not wait the 20 seconds on the boot and gets frustrated..

Cheers

Yeah, it's some update ( possibly systemd ) related then.

Quote from: VastOne on April 11, 2017, 02:03:36 AM
... I do not always cover that anymore.. Simply, I have been selfless forever and it has gotten me nowhere

No problem!
I know that feeling... 

Quote from: VastOne on April 11, 2017, 02:03:36 AM
To answer your question I did solve the network issue on V-Box with a tweak to a refracta file used in building the ISO

Great, thanks! 

Quote from: VastOne on April 09, 2017, 07:37:36 PM
Be aware that on the latest SID updates (and on VSIDO installs with the new ISO) there is a delay of about 20 seconds and then a message

Code Select Expand

gave up waiting on suspend/resume device

and then it boots normally

Not sure where the message even comes from as it is immediate .. possibly initramfs update but I am not sure

It is not causing any issues other than a blank 20 second delay.. strange one I have never seen before

Does NOT happen boot of ISO to LiveCD, only after installed..

It could also be an SSD issue since that is what I am running on

Try this:

1. Reboot
2. Remove "resume=/dev/sdxy" from kernel cmdline ( press "e" when grub shows, then find it on the "linux" line and remove ) & hit F10 to boot.

If the error goes away, and you haven't formated/deleted/moved the swap partition, then it's likely some systemd bustage ( though changelog doesn't indicate anything related ).

When you hibernate your machine, RAM content is dumped onto the swap partition for a persistent storage. Then, when you turn back on, "resume=/dev/sdxy" line is used to point the kernel to that partition as the resume device containing the previous state.

So, if you're not using hibernation, it's safe to remove the same line from "GRUB_CMDLINE_LINUX_DEFAULT" in "/etc/default/grub" file, and then run "update-grub", however do keep in mind that if you ever hibernate the machine, it will NOT resume into previous state, but boot normaly instead!
Otherwise if you moved your swap, correct the "/dev/sdxy" in the same file & update-grub.

Quote from: VastOne on April 09, 2017, 12:06:44 AM
^ You say you do not see this on the Trios side right?  What distro level are they?

My thinking is this could be a SID issue ..

Jessie.

@SID:

Possibly...
I have a feeling it's one of those dumbest ass things that on the "outside" appear perfectly normal and fine, yet silently casue issues and a major pain to detect. 
And when you finally find it, you go like "I don't wanna live on this planet anymore"... 

Anyhow, as they say, it's just a matter of time....
Will post progress updates as they come. 

Update @mkfs:

I'm perplexed and out of ideas really.   

Been sifting trough the installer for most of the evening --> found nothing obviously wrong. 
Heck, "partprobe" is being executed before every call to "mkfs", for the very reason of avoiding the issue we're seeing, which btw shouldn't be even needed, since we're just formating existing partitions, no changes were made to them or the partition table, warranting a need for "partprobe"...

Quote from: VastOne on April 08, 2017, 10:29:10 PM
HAHA  ... the garage at Jedi's is a definite place for the mind to relax and chill.. to the point of grand illusions          

Well, that explains it then... 

Quote from: VastOne on April 08, 2017, 10:29:10 PM
A perfect install .. no delays, a perfect boot

And STILL less than three minutes even with new procedures during the installation


 


I also attached is the installation log of the install if you wanted to check it out

Awesome! 

Though you might wanna recreate the partition table on that hdd ( via Gparted or installer ), to avoid potential issues in future testing. 
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645