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.
Tigersharke 2:50, 6 March 2013 (PST)
[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.
Tigersharke 12:37, 6 March 2013 (PST)
Concerning printers & scanners (CUPS & SANE), KDE has fully functional cfg modules in the KDE system-settings that hide the complexity of CUPS and SANE and correct the "programmer's view" in an intuitive manner. Maybe that's true for GNOME, too.
- not to ship the KDE scanner module with PC-BSD and
- to re-invent the wheel and write such modules again although very mature, fine (master-) pieces of software already exist just because XFCE and LXDE are not mature yet and do not provide or integrate those (gnome's in gtk, if there is one). That's XFCE's and LXDE's problem, not PC-BSD's. If a user wants XFCE or LXDE and not KDE or GNOME, voilà, show them the links where they can join those projects to make those DEs better.
It gets worse in some cases:
- The apps that use the DE's toolkit will use the toolkit's setting and that might be different from the PC-BSD's module.
- Or you have to restart the toolkit's module/daemon to reload the cfg. An average user does not know that.
- The settings might even interfere. E.g. the auto-mounter, and iBus. KDE already has very good and intuitive modules to handle that. I can't see it's inconsistent or strange. Just reset to the default settings, and it works out of the box! In FreeBSD... But not in PC-BSD!
- When PC-BSD duplicates a functionality of a DE, the user has to adjust a setting twice if s/he wants to change s/th. E.g. sound: I have my laptop on the desk in a (what's the name of those boxes to plug in the laptop?). Thus I have two outgoing sound channels: external monitor, and external stereo. To switch between them, I have to configure that twice. For a non-nerd, the conclusion would be that BSD or KDE is broken, unless s/he knows/remembers to do it twice. A minor thing, but it shows that IMHO it would be better to advance PC-BSD's policy.
Last not least, there is FreeDesktop.org, to make the DEs and their apps co-operative, let their developers agree on common interfaces, even common backends, prevent duplicate work etc. pp. It's a HUGE project. Do you think PC-BSD's two or three developers can reach the same goal? I doubt so.
On your problems with KDE, I agree that it's blown up feature-wise, and therefore has more crashes than GNOME. Doesn't mean KDE is buggier than GNOME. Many of the bugs in GNOME just do not show up because the CLI to the full settings is rarely used! I'm not happy with the release politics of KDE, too, it could be strengthened. Nevertheless it's obviously (yes, I mean it, several tests say so - with default settings!) the most intuitive free DE, even better than Mac in some aspects. If you don't need desktop search, PIM/Kontakt/Akonadi, do not install or disable it, disable all or most animations (or just trust the automagic adjustment), and with the -- default (!!!) -- oxygen look you have a very stable, slim and fast modern desktop, but still superior to XFCE or LXDE. Even on an old machine with 256-512M RAM. It's true, try it. I ran KDE+ZFS with 786M (and again: default settings(!!!), no tweaks). Performance was not rocket-like, but ok. KDE4.10 is faster and uses less memory than 3.9.85 (I think that was the "golden" version that many people sticked to for a long time). That's why I don't understand people crying for a "light" DE -- and then run Firefox in it :).
On your "Common GUI Guidelines" I can say the following: The double click is (again: obviously) bogus, that's why the KDE default is single click. This is -- I'm sorry to say so -- no point of discussion. Give a native amazonian who's never seen a computer, a modern laptop. S/He will for shure use a single click! Besides that, single click is healthier wrt RSI.
One last question: Do the PC-BSD additions to LXDE & XFCE go back to them so they can integrate that or port it to Linux?
mjollnir 17:00, 8 March 2013 (MET)
- 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]