Yes I use bluetooth. I currently have a Dualshock 4 controller that can sync over bluetooth, and I used to use a bluetooth mouse.

There are a number of Slackware/FVWM users floating around, but according to this LQ poll perhaps not enough to warrant keeping FVWM in the distro, if it poses too much of a maintenance burden on the dev team.

If it disappears, I'd just build my own. The existing source/xap/fvwm/fvwm.SlackBuild could be rehomed to slackbuilds.org, for easy sbopkg'ing.

Agreed that VLC would be a welcome addition.

I offer no opinion on the other programs mentioned, as I've never used them.

This goes to prove that KDE 3.x was more 'feature complete' in 2005 than KDE 4.x is today.

... which leads me to ask for Trinity Desktop Environment to be included in Slackware... Even if only under /extra on the installation disc.

1 members found this post helpful.

To be fair I haven't looked into this in a great deal of detail, but one thing you can say is that FVWM, like a lot of the stuff in XAP, is pretty mature. Changes are few and far between, so I'd assume maintenance is relatively straightforward, compared to, say, a massive project like KDE which is still evolving.

1 members found this post helpful.

Not that many users of it and it would put too much maintainance strain on Pat for no real gain. Trinity might have a place in SBo but certainly not in mainline Slackware.

I really would like to see a Trinity SlackBuilds project, similar to the excellent MATE SlackBuilds...

i'd like to see gstreamer1 and firefox built against it
with vaapi/vdpau would be nice, although it might be buggy for some

fasm would also be nice, since, in my opinion, it is better then nasm/yasm

also i don't understand why there is blackbox and fluxbox but not openbox
as i found openbox to be the lightest and fastest of the boxen


there was something else, that i forgot..

You can't say that with any certainty.

People still use things like FVWM, twm, mwm, FluxBox, BlackBox and WindowMaker... And only a couple of those are desktops which I'd consider to be actually usable in a productive manner in their default configurations. I'll reiterate my comment that KDE3 made a more functional desktop in 2005 than KDE4 does today.

Not sure if you remember much about KDE3 or the build process for it at the time, but it was fairly simple. Compiling Trinity would not be much extra work at all.
Well, I did say I'd be happy to see it in the /extra directory... but, yes, I'd even be happy with a SlackBuild for it. If you wanted to further separate it, the packages could install it under /opt/tde and I'd be happy.

I do remember i was a rather avid user of it back in the 3.5.x series. (til; Slack 11? i think)

It would be a burden because not only we might soon have to consider how stuff between Qt4 and Qt5 might need to play out, but also have Qt3 in Tree.

All of the above boxen and WM can be used relatively reasonably in a productive manner even in their default configuration actually.

Plus the upside with the SBo would be easier testing and faster iterations / versions / updates etc without having it tied with mainline Slackware. Don't confuse this with the "no don't put it, me no like, me no wan't oh god muh bloat" types of arguments you see around.
I never thought about how i would like it, just state a few facts (i am most certain it would/could get a place in /extra or /trinity dir anyway which would just mean one more dir to exclude from my slack. end of story for me, but then again i just mirror and make MY isos do not maintain and cater the whole distro for the full target spectrum Slackware currently looks at.)

ecryptfs-utils

https://github.com/conraid/SlackBuil...ils.SlackBuild

gtk engines, if only for the clearlooks engine, which looks so nice with my XFCE themes.

I thought about this too, but I find most of the gnome2 parts in Salix directory.
To be specific, I wanted Industrial engine and gtk2 gtksourceview, I had found both of them there.

Otherwise, kdm3 without qt3, hal, or kde deps, that builds on qt4/qt5 and works with consolekit2
Not sure if possible though, may be a lot of work.

ffmpeg
yes we have gst already and vlc is proposed
but future firefox will use ffmpeg and gst(1)-libav makes gst actually useful

PS ffmpeg is pretty big, so would understand not including it

13M isn't that big.

Problem with including ffmpeg is that Pat would need to leave many of the commonly wanted codecs disabled to avoid legal/patent issues. Most folks would end up having to rebuild it using different config options anyway, so I'm not sure how much value a minimally configured ffmpeg would add, and it could even make life more difficult for those of us that add it to our systems should other parts of slackware start linking with it's libraries as a matter of course.

3 members found this post helpful.

idk 12MB is a bit big for binaries if you ask me

but yes, i forgot the patent thing for a moment
looks like h264 will remain so for a long while