Re: [Pcbsd-developer] what to add to roadmap

[Federico L. <flo...@gm...>]

On Sunday 16 October 2005 09:58 am, Andrew Youll wrote:
> On 16 Oct 2005, at 12:32, Federico Lorenzi wrote:
> > On Saturday 15 October 2005 06:10 pm, Kris Moore wrote:
> >> Andrei Kolu wrote:
> >>> 1. Let's add some good TrueType  fonts and remove ugliest ones like
> >>> Type1- I totally disabled Adobe crappy fonts in my DVD version.
> >>
> >> Ok, sounds good. Just send me the files / instructions that you used
> >> to do this on your DVD version, and I'll roll it into the next
> >> release
> >> and online update.
> >
> > Correct me if I'm wrong but isn't illegal to include windows fonts
> > due to
> > window's super friendly licences?
>
> Yes the Windows EULA prevents you from including windows fonts in any
> other application, withhout expressed permission, only way around
> this is to make a TTF.PBI which contains the MS Windows fonts.
>
Oh well... I still like my Bitstream-Vera. IMHO its the best font :) But I'm
sure that there are some free TTF fonts around that we could intergrate.

> >>> 2. I already posted some information about animated cursors for X
> >>> so I
> >>> think eyecandy ain't hurt eithetr.
> >>
> >> Ditto, send me instructions / files and i'll be more than happy to
> >> make
> >> it look nicer.
> >>
> >>> 3. Linux compat layer- I don't like default fontset with linux
> >>> programs-
> >>> it seem's like software from third world...
> >>
> >> Yep, fonts are totally a pain, but again, if you have a fix, i'm
> >> ready
> >> to implement :)
> >>
> >>> 4. Monitor detection- I found some useful information how it can
> >>> be done:
> >>>
> >>> "Graphics hardware configuration is handled by a combination of the
> >>> Debian anXious program (heavily hacked to work non-interactively),
> >>> Debian's xviddetect, the Corel Linux hardware detection and a
> >>> program
> >>> for querying the monitor's capabilities via VESA DDC. The Corel
> >>> software
> >>> is used to probe for the mouse, with USB, serial and PS/2 mice being
> >>> detected usefully. If the monitor does not support DDC, fairly
> >>> conservative defaults are used to reduce the liklihood of the
> >>> monitor
> >>> being pushed outside specs. xviddetect simply compares PCI ids to a
> >>> lookup table and spits out the X server that should be used. All
> >>> of this
> >>> information is then passed to anXious which writes an XF86Config and
> >>> then exits.
> >>>
> >>> In the case that the graphics card is not detected, the contents of
> >>> /proc/pci are sent to the sysadmins. The system then attempts to
> >>> carry
> >>> on, defaulting to using the SVGA X server. However, a file is
> >>> created in
> >>> /local. On the next boot, if this file exists, the system will
> >>> ask the
> >>> user if the previous attempt worked. If so, the file is deleted
> >>> and the
> >>> XF86Config is left as is. If not, configuration is attempted
> >>> again in
> >>> the hope that the PCI IDs will have been added to the lookup table."
> >>
> >> I don't know how easily we could hack this software to work on PC-
> >> BSD.
> >> What we have for the moment works fairly well, but again let me
> >> know if
> >> somebody has a better working method, I'll be glad to look at it.
> >
> > Again I say maybe we should just use the Xorg auto-detection, it seems
> > to be good enough and finds the max-resolutions quite well.
> >
> >> This would be nice, I don't like seeing so much scroll by before the
> >> splash comes up either. I haven't found any info on how or if this
> >> can
> >> be done with any flags or such. If some FBSD hacker out there
> >> knows how
> >> to do it, let me know :) (Aside from modifying kernel source, I
> >> want to
> >> stay away from that)
> >
> > Why don't we make it so the boot sequence is like this:
> > -> Load kernel
> > -> Splash screen comes up
> > -> In the begining of the rc file or the rc.local file just have
> > 'kldload snd_driver 2> /dev/null', that will load the driver and
> > hide all the
> > messages
> > Also, we can make the Splash Screen come up again simply by putting
> > vidcontrol -t 1 at the top of the /etc/rc file, and vidcontrol -t
> > off at the
> > end.
> >
> >> On another note, somebody mentioned on another post about making PBI
> >> stuff compatible with other WM's, Gnome, etc. That is a good goal,
> >> but I
> >> have no plans on doing it at the moment. Right now I just want to
> >> push
> >> towards getting 1.0 done and released with good KDE support. After
> >> that
> >> is all done, then we can go back and start adding in support for
> >> other
> >> WM's form of icons, start menus, etc. Frankly, its one extra
> >> headache I
> >> don't need at the moment :)
> >
> > This is quite a good idea, maybe we could have to parts two the PBI
> > system,
> > one is a config file with the icons needed and the other one is
> > part of the
> > DE, parsing the icon file and creating icons where nessacery.
> >
> > Finally to all the GTK+ PBI creators: Please try and include gtk-qt
> > in your
> > PBI as to give them a much nicer look and feel :)
>
> Another way would be to include gtk-qt engine in the base distro, not
> sure how that would work with PBI's mind.
Hmm, the problem with that, and why i haven't released a gtk+qt PBI is
due to the fact that the app's GTK+ must have PNG support, for everything
to work proply, otherwise the PNG icons of KDE won't display, an example of
this is the GIMP PBI.
>
> Andrew Youll
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> PCBSD-Developer mailing list
> PCB...@li...
> https://lists.sourceforge.net/lists/listinfo/pcbsd-developer