[PC-BSD Dev] how many qt?

Ken Moore ken at pcbsd.org
Fri Jan 4 06:49:00 PST 2013


On 01/04/2013 04:24, Luca Ferrari wrote:
> Hi all,
> please, this is not meant to be a flame, but I'm curious to understand
> the rationale behind the strong usage of Qt within PCBSD. I mean, as a
> Qt (junior) developer I love the library and the facilities it
> provides, and as a Unix lover, I love PCBSD too. However I see that
> more and more gadgets are specifically developed using Qt instead of
> "patching" and porting existing software. As an example, consider the
> removable device manager and network connection manager that are in
> 9.1: why not using the network manager and pluggable device plasmoid
> already present in KDE? I also read somewhere about a Qt based desktop
> manager (login screen). It sounds to me that a lot of existing pieces
> are going to be reimplemented using Qt and while I understand how
> portability is important, I believe that this could also lead to a
> less attractive system since Linux users will not jump on board if
> they don't have their well known gadgets (either KDE's, Gnome's or
> whatever desktop's).
>
> Luca
> _______________________________________________
> Dev mailing list
> Dev at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/dev

Let me start by giving you a bit of the rationale behind what is going 
on with PC-BSD, then I think the way we are moving forward will start to 
make sense...

First: We are trying to make sure that PC-BSD is desktop-environment 
agnostic. In order to accomplish this we make sure that all of our 
utilities are either written in pure shell (for command-line utilities) 
or in Qt for graphical interfaces (since we are familiar with C++/Qt).

Second: We try to avoid using desktop-specific utilities due to the 
added "bloat" it brings to the base PC-BSD system, in addition to the 
difficulties in making that utility work properly for ANY desktop 
environment.

Third: Since PC-BSD is based on FreeBSD, but most applications are 
developed on Linux, we need to be careful to make sure that any utility 
we include works properly in a FreeBSD environment. In addition, it is 
easier to maintain/fix our own utilities rather than spending a lot of 
time trying to "fix" other applications to work properly on an OS they 
were not originally designed for. Plus, since FreeBSD is so stable, 
usually once we create a utility that works, it takes relatively little 
work to keep it current with any FreeBSD updates.


Now lets look at a couple examples in applying this rationale:

Example 1: The new login manager that we are working on.

We are currently using GDM as the login manager for PC-BSD 9.0/9.1, but 
it requires so many GNOME libraries and utilities to actually work that 
it is making the base PC-BSD system much larger than it needs to be, 
especially if the users do not want the GNOME desktop environment to 
begin with. This will also cause a problem in the near future once 
GNOME3 gets ported to FreeBSD, as we are not sure how well supported GDM 
will be any more. Our solution for this is to create our own login 
manager entirely in Qt that will provide no additional dependencies, and 
still gives us the features that we need from a login manager (such as 
XDMCP support, desktop/locale/keyboard switching, etc...).

Example 2: The new device mounting utility for 9.1 and the network 
configuration GUI's.

For the 8.x and older version of PC-BSD, KDE was the only desktop 
available in PC-BSD experience. The network and device managers in KDE 
worked some/most of the time, but they used a Linux-centric mindset in 
how they worked which caused a lot of headaches on FreeBSD. Now that 
PC-BSD is desktop-agnostic, these utilities also ran into the problem of 
only working for KDE and not in any of the other desktop environments. 
Our solution for this was to create our own network manager for 9.0, and 
the device mounting utility for 9.1. This allowed us to automate/use the 
standard FreeBSD methods of setting up networks and device that work 
much more reliably and are a lot easier to debug if something does go 
wrong, since we are just using the abilities already included with FreeBSD.


Sorry for the long reply, but I hope this helps to clear up any 
confusion about the approach(s) we are taking for additional PC-BSD 
utilities. If you have any further questions just let me know and I will 
try to help!

-- 
~~Ken Moore~~
PC-BSD/iXsystems



More information about the Dev mailing list