antiX-16 - Page 3

Dave · posted: 2016-01-18 19:59

So which would be better by the opinion of the community?
I personally use spacefm... so as with you d.o. I modify my udevil rules and let it go. Then in my opinion using devmon with a good default udevil.conf should be enough or am I wrong?
BTW. it seems devmon is part of udevil

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://igurublog.wordpress.com/downloads/script-devmon/"
linktext was:"https://igurublog.wordpress.com/downloa ... pt-devmon/"
====================================

The next things to consider then:
1. is it dependant / user as the above page shows it to be started by xinitrc/window manager startup (desktop-session startup for all?) Or could it be started via init.d?
2. if two users are running on the same system will it crash as they both try to mount/unmount the drive?

dolphin_oracle · posted: 2016-01-18 21:28

another way to do this would be to use the spacefm daemon mode (spacefm -d) and set spacefm preferences to

1. not open a tab (this is not the default)
2. automount inserted media (actually the default)
3. on automount, launch"desktop-defaults-run -fm %m" which will launch the default filemanager at the new mount point.

oddly though, using"desktop-defaults-run -fm /media" in the terminal results in two rox-filer windows.

the only problem is that spacefm -d conflicts with the spacefm desktop.

dolphin_oracle · posted: 2016-01-18 21:45

ok, trying devmon from rc.local. works pretty good so far.

devmon --exec-on-drive"desktop-defaults-run -fm %d"

opens the mount point in the default file browser. The only problem is 2 filebrowser windows open in rox, and 2 tabs open in spacefm.

anticapitalista · posted: 2016-01-18 22:29

I'm thinking of using the wheezy version od MX-packageinstaller since it brings in no dependencies that aren't already needed. I have modified it so it works like the version in MX-15 (but qt4 rather than qt5) ie a separate packages for the package list. I have also de-branded the app to be called package-installer. I'll take a look at other mx apps that we may wish to include. (debranded and using qt4)

eugen-b · posted: 2016-01-18 23:53

I think you are aware of it anyway, but I would remind that CD size requirement for a"full" version could be dropped if there will be a"base" version which is CD sized. Those who cannot boot from USB stick will still be able use the"base" version then. (Please, consider my post not a provocation.)

anticapitalista · posted: 2016-01-19 00:27

eugen-b - I don't see your post as provocative, but I disagree with what you say.

antiX full will ship with as many apps as we can fit on a cd, including biggies such as libreoffice. Why? Because that is one of our mission statements and secondly (on Jessie) we can actually do this without too much loss elsewhere.

Also, for users in the poorer parts of the world (2/3rds of humanity = 4 billion people) a cd download with a fully functional office app 99% compatible with MS with no download needed (many users at best may have a dial up connection - most may have no internet connection) - we aim to support them. Utopian dream? - Maybe, but that is what we are about as much as trying to make antiX appealing to users with new boxes.

SamK · posted: 2016-01-19 07:50

Re USB Handling

dolphin_oracle wrote:...auto-populating the /medidirectory with inserted usb sticks/drives. even if they aren't mounted, it would be nice if they showed up in rox by default.

Dave wrote:So which would be better by the opinion of the community?

It would be most helpful if auto-mounting usb devices was controlled via the antiX Control Centre (CC), thereby making it simple and straightforward to toggle its state.

There are times when it is convenient to have auto-mounting enabled and others for it to be disabled e.g. ocassionns when a device must be unmounted for a procedure to complete.

The CC has attracted favourable comment for the centralising of system-type tasks. This seem another obvious one.

Edit:
Typo

SamK · posted: 2016-01-19 08:09

Re Package Delivery and Installation

anticapitalista wrote:I'm thinking of using the wheezy version od MX-packageinstaller...
I have also de-branded the app to be called package-installer.

If the revised package-installer is successful, perhaps good candidates for inclusion are 1-to-1 Assistance and 1-to-1 Voice.

anticapitalista wrote:...since it brings in no dependencies that aren't already needed. I have modified it so it works like the version in MX-15 (but qt4 rather than qt5)..

Just musing here...

Thinking about maintaining it over a longer term, would going along this route eventually lead to being pushed into using qt5? If so will antiX face the ISO size issue again at that point, or is that currently both qt4+qt5 will be required and eventually qt5 alone will not present the problem? Might it be worth investigating whether it is possible to do it in some other way (gtk,yad,python,perl...whatever)?

eugen-b · posted: 2016-01-19 11:10

SamK wrote:Thinking about maintaining it over a longer term, would going along this route eventually lead to being pushed into using qt5? If so will antiX face the ISO size issue again at that point, or is that currently both qt4+qt5 will be required and eventually qt5 alone will not present the problem? Might it be worth investigating whether it is possible to do it in some other way (gtk,yad,python,perl...whatever)?

It might work a year or two avoiding qt5. It seems already almost impossible to avoid gtk3 (I guess because of roxterm)...

dolphin_oracle · posted: 2016-01-19 13:37

SamK wrote:Re USB Handling

dolphin_oracle wrote:...auto-populating the /medidirectory with inserted usb sticks/drives. even if they aren't mounted, it would be nice if they showed up in rox by default.
Dave wrote:So which would be better by the opinion of the community?
It would be most helpful if auto-mounting usb devices was controlled via the antiX Control Centre (CC), thereby making it simple and straightforward to toggle its state.

There are times when it is convenient to have auto-mounting enabled and others for it to be disabled e.g. ocassionns when a device must be unmounted for a procedure to complete.

The CC has attracted favourable comment for the centralising of system-type tasks. This seem another obvious one.

Edit:
Typo

I think this will be easy. And I think that while configuration could be present in the control center (makes sense on the Disks tab), a right click off of usb-tray could easily be accomplished as well.

I've been playing with devmon, and I'm really liking the concept. however, I've found a small bug in desktop-defaults-run that does not have anything to do with devmon.

when using"desktop-defaults-run -fm" when the default file manager"follows" the desktop (the de facto default), issueing

Code: Select all

desktop-defaults-run -fm /media

will open up two rox windows or two spacefm tabs each displaying /media, depending on window manager.

when setting the default filemanager to a single filemanager (say rox-filer), then only one file manager window will open per folder specified.

so there is a parameter pass-thru issue with desktop-defaults-run.

btw, this command run from a wm or desktop-session startup file works pretty well.

Code: Select all

devmon --exec-on-drive"desktop-defaults-run -fm %d" --exec-on-disc"desktop-defaults-run -fm %d" &

***edit***

samk, your thought about disabling automount is pretty good. the antix2usb app might benefit from such a feature. and automounting would need to be disabled during running of the installer for instance. a central point for that makes a lot of sense. so does having the feature attached to a new usb-tray app.

masinick · posted: 2016-01-19 20:13

bedna wrote:For me IceWM better choice as default WM. I have own dark theme foe IceWM
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://kernelultras.org/index.php?shell=feh+projects%2Flegacyice%2Fantix-netbook-fm.jpg"
linktext was:"http://kernelultras.org/index.php?shell ... ook-fm.jpg"
====================================
+ project is here
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/KERNELULTRAS/LegacyIce-antiX"
linktext was:"https://github.com/KERNELULTRAS/LegacyIce-antiX"
====================================

Make package IceWM from this active development fork
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/bbidulock/icewm"
linktext was:"https://github.com/bbidulock/icewm"
====================================

Developers are very friendly.

I agree that IceWM, if we are sticking with simple window managers, is simple to use, easy to configure, and rivals Fluxbox as one of the lightest window managers available, so it strikes an appealing balance as the default WM. Fluxbox, in a similar way, attracts experienced"tweakers", so it should always be included as a light window manager, but defer to the IceWM default WM.

I'm indifferent about Openbox. In terms of features and size, it is similar to both Fluxbox and IceWM. It's arguably a bit easier than Fluxbox to configure, but not quite as obvious as IceWM to update. IF there is sufficient interest, I have no objection to its inclusion.

BIOS, Boot Loader and Boot Manager support: We have a lot of people with old hardware, so I don't know that getting into UEFI makes any sense. I have a newer system as well as older systems; the newer system uses it and seems to require it. I wonder how many users fall into a similar category?

We have GRUB 2; maybe that's all we need. If we don't include UEFI, we may want to consider an article in our documentation about how users with a UEFI-based BIOS can interact with antiX 16. (IF I can learn enough TRUSTWORTHY information on this topic by then, I'd be glad to contribute)!

masinick · posted: 2016-01-19 20:15

dolphin_oracle wrote:
Dave wrote:
dolphin_oracle wrote:I'd desktop-session is staying around I would like to see less duplication of the startup files. Maybe a set of defaults .conf in / etc and then the startup files in the user diretories.

OK so... if I understand correctly:
1. get rid of the global configuration options in / etc and make /user the only option. (rather than per user override)
2. place a default configuration setup for the user in the / etc/skel/ folder. (normally what was in / etc/desktop-session)
that sounds better than what I was thinking. going through the threads, there were lot of startup file questions.

I like this alternative approach too.

dolphin_oracle · posted: 2016-01-19 20:21

masinick wrote:
BIOS, Boot Loader and Boot Manager support: We have a lot of people with old hardware, so I don't know that getting into UEFI makes any sense. I have a newer system as well as older systems; the newer system uses it and seems to require it. I wonder how many users fall into a similar category?

We have GRUB 2; maybe that's all we need. If we don't include UEFI, we may want to consider an article in our documentation about how users with a UEFI-based BIOS can interact with antiX 16. (IF I can learn enough TRUSTWORTHY information on this topic by then, I'd be glad to contribute)!

fortunately we have a head start thanks to the work done on uefi install for MX-15. its a lot further along than you might think. check out the MX wiki entry on it for info on how it currently works in the (mx) installer.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.mepiscommunity.org/wiki/system/uefi"
linktext was:"http://www.mepiscommunity.org/wiki/system/uefi"
====================================

That said, I know there has been further development...

masinick · posted: 2016-01-19 20:23

anticapitalista wrote:eugen-b - I don't see your post as provocative, but I disagree with what you say.

antiX full will ship with as many apps as we can fit on a cd, including biggies such as libreoffice. Why? Because that is one of our mission statements and secondly (on Jessie) we can actually do this without too much loss elsewhere.

Also, for users in the poorer parts of the world (2/3rds of humanity = 4 billion people) a cd download with a fully functional office app 99% compatible with MS with no download needed (many users at best may have a dial up connection - most may have no internet connection) - we aim to support them. Utopian dream? - Maybe, but that is what we are about as much as trying to make antiX appealing to users with new boxes.

I think this is an admirable goal, enough so that if we're up against the CD limit size, we may want to consider cutting out a few other things that we've always included in previous releases in order to include core office functionality - Email, Web browsing, document and spreadsheet editing at a minimum.

While we would also desire to include as much documentation and localization capability built-in as possible, these may also be things where at some point we may need to make a few trade offs that we've not had to make in the past (though they'd be among the last things to even think about pulling out completely).

If size becomes a big problem, the way in which siduction handles some things may be helpful - provide base documentation easily accessible on or from the main screen, linking to locally installed information as much as possible and Web-based information for large, detailed documentation.

SamK · posted: 2016-01-20 08:05

Re Window Managers

eugen-b wrote:#1: Ship with an Openbox session.

masinick wrote:I'm indifferent about Openbox. In terms of features and size, it is similar to both Fluxbox and IceWM. It's arguably a bit easier than Fluxbox to configure, but not quite as obvious as IceWM to update. IF there is sufficient interest, I have no objection to its inclusion.

Because of the scope which antiX covers, it is likely that there will always be requests to have additions such as this included in the ISO. The WMs shipped in antiX-Full meet the antiX goals very well and IceWM is a most suitable choice as the default.

The question becomes

Does the proposed WM offer anything significantly different in terms of usability?
Does the proposed WM offer any significant benefits in terms of system resource usage?
Will the proposed WM be integrated into or supported by existing antiX apps ?
e.g. Wingrid requires each WM have its own specific configuration
Is there spare space within the shipped ISO?
Are the devs and the community willing to acquire the skills to be able to support it in a public forum?
This point was raised earlier in this topic by rokytnji
Has the item on WMs in the opening post of this topic by anticapitalista been overlooked?

The possibility that offering a particular WM will attract a new users is a lesser, but relevant consideration. The question here is how does one quantify it? If the use of a particular WM within a distro is a deal breaker, it is likely that users making such a judgement will already be familiar with it and also be sufficiently skilled to set it up and configure it to their own preferences. One of the strengths of antiX is its flexibilty of set up. It is able to accept other WMs, it just requires the user to install and configure it. It is not a deal breaker with antiX.

There is also the possibilty that interested users might make their own respin and make that available to the community in the existing respin section of the antiX forum.