pcbsd-developer

[Pcbsd-developer] Wow, There are people on here!

[Kris M. <pie...@gm...>]

Glad to hear from you guys! I haven't used lists much before, but I 
figure i had better get used to it now :)

Anyway, I figure we don't need to worry about being "rivials" for the 
moment, we can just work towards the goal of having the best, and 
easiest to use desktop OS around. Having the network manager will 
greatly improve that as well :) Aside from that, and the things I have 
listed on the roadmap, are there any other items that are "must-haves" 
for the 1.0 release?


-- 

Kristofer Moore

[Pcbsd-developer] what to add to roadmap

[Andrei K. <an...@bs...>]

Kris Moore wrote:

>   Aside from that, and the things I have listed on the roadmap, are 
> there any other items that are "must-haves" for the 1.0 release?
>
1. Let's add some good TrueType  fonts and remove ugliest ones like 
Type1- I totally disabled Adobe crappy fonts in my DVD version.
2. I already posted some information about animated cursors for X so I 
think eyecandy ain't hurt eithetr.
3. Linux compat layer- I don't like default fontset with linux programs- 
it seem's like software from third world...
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."

5. Hide soundcard module loading- it's distracting- users think that 
there is some problem.

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

[Kris M. <pie...@gm...>]

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.


> 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.

> 5. Hide soundcard module loading- it's distracting- users think that 
> there is some problem.
> 

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)


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 :)

Kris


> 
> 
> -------------------------------------------------------
> 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
> 

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

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

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? 

> > 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 :)

Federico

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

[Andrew Y. <yo...@de...>]

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.

>
>
>>> 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.

Andrew Youll

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