Talk:PC-BSD® 9.2 TODO
Further suggested additions
Acceptably complete items are struck.
- Wouldn't it be useful to add a priority field to this list?
- WPA/WEP passkey configuration in network setup during install - supposing secured wifi is the sole internet access but a proxy is not needed/wanted, yet a network install is desired.
- Live Mode - Add forensic tools Scalpel and Foremost or similar.
- PC-BSD® 'standard' control panel items (as a GUI front end to cli configurator where possible) for all common System needs. Possible items to include if they do not already exist. Brand these PC-BSD® developed items with the fireball logo or in some way so they can be clearly and easily identified. The additional idea aside from having more control of necessarily configurable OS features and availability of them to the system in general (regardless), is that possibly other DE/WM included versions which may be buggy or resource wasteful could be turned off or deinstalled.
- Audio - auto-sense headphone connection, dolby/surround, assign specific output/volume to program/device.
- Sound Configuration allows for basic control, by making it easier to change the default audio device.
- Display - including multi-head.
- KDE's display control panel is a good example of what this should become, but accessible regardless of de/wm. Why must we reboot for this change? How does KDE succeed without the reboot?
- Input - keyboard, mouse, touch, tablet/stylus
- The capabilities exist and may be configurable but a PC-BSD control panel for them does not.
- Printer - could include fax
- This may not be perfect but it is functional. The trouble seems to be where the printer is redefined or re-configured in other programs or control panels.
- Fax - whether this is a part of another control panel, it should be a consideration for those who need or desire it.
- Network - wifi, ethernet, pppoe, dialup/modem.
- This is getting closer to what it should be, but as of 9.1rc1, it still seems to need work: It is my understanding that WPA and WPA supplicant configuration is a wifi feature, yet with no discovered wifi devices, the option is available for the network device which happens to be ethernet (em).
- Scanner - Xsane via Scanner control panel which also checks for the device attached to the system.
- Search - A GUI to Locate would be great, though searching within a file could be added, I suppose.
- Audio - auto-sense headphone connection, dolby/surround, assign specific output/volume to program/device.
- Service Manager - add a description of each service that may be stopped/started or enabled/disabled.. perhaps either display or quote the manpage for the service. Of course, if there is anything dependent upon a service, it may also be prudent to include tailored warnings about what will be affected.
- add multiple selection capability for removal or install
- add a sets function - this would allow for a defined group of apps to be installed, possibly transferable to other systems.
- Qt Curve system-wide theme configurator - Qt Curve is one of the most configurable themes already available to KDE, but being Qt-based, it should be possible for it to be available to other de/wms. Many de/wms have their own theme capability but few allow for the entire range of configuration to be adjusted and/or saved and recalled/loaded. This is necessarily a difficult concept especially considering an intention for it to function for all desktops with a theme functionality.
Painting over the Underbelly?
Our focus should be on making things easier and more approachable or accessible. Therefore, in subtle ways, we ought to maintain some visibility of the technical side of BSD. We can GUI-fy the output of a manpage, dmesg, locate, or other cli "ugliness". This would appeal to the tech-inclined without necessarily scaring away neophytes. It would be wrong to go the more extreme route that Apple has chosen, thereby hiding all technical/challenging aspects behind a simplistic (even if powerful) interface.
Even though it may be clear to some what the intention of the above list and PC-BSD may be, it is not necessarily obvious nor their cup of tea. It seems that their wish is simply to use FreeBSD as it exists and any other alterations must be extremely limited because their skill level means they can dig into the code or are otherwise capable of far more than the average 'Joe User' that we aim to please.
[from the addressee of the above and author of the next section] The opposite is true :) It is my honest believe that it is an important goal to make BSD more user friendly, integrate an intuitive desktop better than the current status quo, and offer an easy graphical installation and update. Both for the average 'John Doe' non-nerd user and the experienced UNIX guru. Even better, offer a choice of two, three, four desktops. I'd very much like to replace Ubuntu on my sister's PC with PC-BSD. But I can not (yet, hopefully). Thus, I do not consider additions to XFCE or LXDE needless. The point is, the lack of such (portable) tools is LXDE's/XFCE's problem, not PC-BSD's. And I think the PC-BSD developers should concentrate on PC-BSD - which does not mean it's bad to help LXDE/XFCE.
And I totally agree to the section "Painting Over the Underbelly"
Neither I think other alterations must be extremely limited. I welcome your work like the AppCafé, the PBI format, Warden etc. pp. very much.
I wanted to point out that for KDE, probably for GNOME as well, tools to do the things you re-implement already exist. And they are functionally on BSD. People switching from Linux (thanks Ubuntu's politics ;) these will be quite numerous) are distracted when the tools they know do not work. Boosh, back to Linux for the next 10 years. The avarage non-nerd is distracted, when s/he reads in a book or the online help, "click this or that", and it does not do what is described, but on Linux it does. Then the conclusion is that BSD is broken and Linux is ok. The PC-BSD additions sometimes interfere, e.g. the auto-mounter.
My vision is that it is better for a project like PC-BSD to integrate their additions into the existing system-settings/control-panel, than the other way around. Thus, if you want to invest the time and write/maintain e.g. an auto-mounter for XFCE/LXDE@BSD, good - but I see no sense in installing it in a KDE desktop (probably GNOME, too).
Besides that, you were totally right that it is much better to put my critics in an own section, than to clutter the existing page. But see: that's IMHO what you do with an otherwise fully functioning DE like KDE or GNOME.
This discussion is good, now I more clearly understand. Earlier I was just a little bothered by the comments which I answered with that first short paragraph. That was my view of the critique and now there is some agreement and at least discussion.
- With regard to duplication of capability in KDE or GNOME2 by the PC-BSD additions (ie mount tray), perhaps it can be a configurable inclusion for desktops that have such a capability, rather than requiring its presence. The only thing I can say in defense of the current duplication within KDE or GNOME2, is that making it always present even when not needed, means it will get tested more or will be seen by more users.
- The suggestions for inclusion don't necessarily need to be PC-BSD branded and new, but ought to be present in a DE/WM that is considered complete- sane and cups are two that have been added to the control panel. I am not sure if this suggestions list was originally written after v8.2, or v9.0, (it has found itself moved with the name change of the todo list) but it continues since it has not all been satisfied or entirely shot down.
- I have used XFCE, LXDE, KDE, GNOME2, and currently use Enlightenment. A few of them have quirks that get annoying over time. The drive mounting feature in GNOME is just a bit odd, in KDE can be inconsistent or strange. KDE includes some things that I have no need for, like semantic search, "places", personal information manager, but its display manager (as I mention above) is quite nice.
- I disagree about whether all desktops shouldn't be configured to appear identically as a rule, including replacing the icon for a "start menu" mechanism with the PC-BSD fireball logo. I think it is quite understood that the fireball is a logo and not dangerous, the installer includes the image for its entire operation. The desktop background of the flask of 'solution' that happens to have an orange-like color would be speculation to be acid- is the FreeBSD Daemon mascot "Beastie"also objectionable? Function is far more important than some images that would not be permanent. We already default the desktop wallpaper from whatever it may have been to the isotope styled image. Further strong recommendations I have written in Common Human Interface Guideline.
- It would be polite you brand only your own additions and not replace e.g. the KDE-logo at all!
- The visual appearance of the logo (the burning ball) needs a friendlier replacement. Who wants to burn his system? Same holds true for the vial filled with acid. I'm serious with this. A logo shall prompt positive associations.
- Many of the KDE system-settings modules are just fine or can be adjusted for FreeBSD/PC-BSD more or less easily. Users who want just a WM and not a DE are fine with configuring their systems on the console. And if a DE does not have GUI for system tasks because they are not mature (LXDE,XFCE), well, you get what you pay for. Hint: Today I ran KDE+ZFS with hw.physmem="768M" with default settings for FreeBSD 9.1+ KDE 4.9.5. It was ok.
[This was meant to prove that I see little need for a "lite" desktop, and not to demonstrate my "superiour Unix skills"]
- Network - wifi, ethernet, pppoe, dialup/modem [This is one of the few exceptions, i.e. the KDE NetworkManager is very linuxish]
- AppCafe® - before hacking even more bugs into it, fix the existing ones first!
Considered needless (reinvent the wheel)
- Audio - auto-sense headphone connection, dolby/surround, assign specific output/volume to program/device [re-invent the wheel]
- Sound Configuration allows for basic control, by making it easier to change the default audio device. [re-invent the wheel]
- Display - including multi-head [re-invent the wheel]
- KDE's display control panel is a good example of what this should become, but accessible regardless of de/wm. Why must we reboot for this change? How does KDE succeed without the reboot? [Don't read the source code. Better re-invent the wheel]
- Input - keyboard, mouse, touch, tablet/stylus [re-invent the wheel]
- Scanner - Xsane via Scanner control panel which also checks for the device attached to the system. [re-invent the wheel]
- Search - A GUI to Locate would be great, though searching within a file could be added, I suppose. [re-invent the wheel - dare you use the (fully functioning) KDE search&replace!!!]
- Service Manager - add a description of each service that may be stopped/started or enabled/disabled.. perhaps either display or quote the manpage for the service. Of course, if there is anything dependent upon a service, it may also be prudent to include tailored warnings about what will be affected. [re-invent the wheel]