pcbsd-developer — PC-BSD Developers List

Re: [Pcbsd-developer] Re: xorg auto detection

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

Renato Fl=F3rido wrote:

> Andrei Kolu wrote:
>
>> Federico Lorenzi wrote:
>>
>>> On Sunday 16 October 2005 09:51 am, Renato Pinto Fl=F3rido wrote:
>>> =20
>>>
>>>> Frederico wrote:
>>>> /Again I say maybe we should just use the Xorg auto-detection, it=20
>>>> seems
>>>> to be good enough and finds the max-resolutions quite well.
>>>>
>>>> /Frederico, does the Xorg auto-detection detect vertical and=20
>>>> horizontal
>>>> refresh rates?
>>>>
>>>> what they are trying to achieve here with DDC is a detection=20
>>>> feature that
>>>> can config V/H refresh rates as well. Afaik, Xorg auto-detection=20
>>>> didnt do
>>>> this.
>>>>  =20
>>>
>>>
>>> Well, I'm not really a moniter expert, but I used Xorg detection on
>>> my laptop, my dad's laptop and on my desktop, and it detected all=20
>>> the screens fine, on my laptop the res was 1024x768 (The max), on my=20
>>> dad's it was 1920x1280 (The max) and on my desktop 1280x1024(The max).
>>>
>>> =20
>>>
>> What about refresh rate? With LCD 60Hz is fine, but with CRT it's=20
>> headache.
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads,=20
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> PCBSD-Developer mailing list
>> PCB...@li...
>> https://lists.sourceforge.net/lists/listinfo/pcbsd-developer
>>
> we are talking about vertical/ horizontal refresh rates here... you=20
> know...
>
Yes I KNOW. I know all about modeline...

Re: [Pcbsd-developer] Re: xorg auto detection

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

On 16 Oct 2005, at 14:21, Renato Fl=F3rido wrote:

> Andrei Kolu wrote:
>
>
>> Federico Lorenzi wrote:
>>
>>
>>> On Sunday 16 October 2005 09:51 am, Renato Pinto Fl=F3rido wrote:
>>>
>>>
>>>> Frederico wrote:
>>>> /Again I say maybe we should just use the Xorg auto-detection, =20
>>>> it seems
>>>> to be good enough and finds the max-resolutions quite well.
>>>>
>>>> /Frederico, does the Xorg auto-detection detect vertical and =20
>>>> horizontal
>>>> refresh rates?
>>>>
>>>> what they are trying to achieve here with DDC is a detection =20
>>>> feature that
>>>> can config V/H refresh rates as well. Afaik, Xorg auto-detection =20=

>>>> didnt do
>>>> this.
>>>>
>>>>
>>>
>>> Well, I'm not really a moniter expert, but I used Xorg detection on
>>> my laptop, my dad's laptop and on my desktop, and it detected all =20=

>>> the screens fine, on my laptop the res was 1024x768 (The max), on =20=

>>> my dad's it was 1920x1280 (The max) and on my desktop 1280x1024=20
>>> (The max).
>>>
>>>
>>>
>> What about refresh rate? With LCD 60Hz is fine, but with CRT it's =20
>> headache.
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, =20
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> PCBSD-Developer mailing list
>> PCB...@li...
>> https://lists.sourceforge.net/lists/listinfo/pcbsd-developer
>>
>>
> we are talking about vertical/ horizontal refresh rates here... you =20=

> know...
>

Okay they are infact called V-Sync and H-Sync not V-Refresh rate, and =20=

H-Refresh Rate. if that helps clear up any confusion


>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, =20
> 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] Re: xorg auto detection

[<ren...@gm...>]

Andrei Kolu wrote:

> Federico Lorenzi wrote:
>
>> On Sunday 16 October 2005 09:51 am, Renato Pinto Flórido wrote:
>>  
>>
>>> Frederico wrote:
>>> /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.
>>>
>>> /Frederico, does the Xorg auto-detection detect vertical and horizontal
>>> refresh rates?
>>>
>>> what they are trying to achieve here with DDC is a detection feature 
>>> that
>>> can config V/H refresh rates as well. Afaik, Xorg auto-detection 
>>> didnt do
>>> this.
>>>   
>>
>> Well, I'm not really a moniter expert, but I used Xorg detection on
>> my laptop, my dad's laptop and on my desktop, and it detected all the 
>> screens fine, on my laptop the res was 1024x768 (The max), on my 
>> dad's it was 1920x1280 (The max) and on my desktop 1280x1024(The max).
>>
>>  
>>
> What about refresh rate? With LCD 60Hz is fine, but with CRT it's 
> headache.
>
>
> -------------------------------------------------------
> 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
>
we are talking about vertical/ horizontal refresh rates here... you know...

Re: [Pcbsd-developer] Re: xorg auto detection

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

Federico Lorenzi wrote:

>On Sunday 16 October 2005 09:51 am, Renato Pinto Fl=F3rido wrote:
> =20
>
>>Frederico wrote:
>>/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.
>>
>>/Frederico, does the Xorg auto-detection detect vertical and horizontal
>>refresh rates?
>>
>>what they are trying to achieve here with DDC is a detection feature th=
at
>>can config V/H refresh rates as well. Afaik, Xorg auto-detection didnt =
do
>>this.
>>   =20
>>
>Well, I'm not really a moniter expert, but I used Xorg detection on
>my laptop, my dad's laptop and on my desktop, and it detected all the sc=
reens=20
>fine, on my laptop the res was 1024x768 (The max), on my dad's it was=20
>1920x1280 (The max) and on my desktop 1280x1024(The max).
>
> =20
>
What about refresh rate? With LCD 60Hz is fine, but with CRT it's headach=
e.

[Pcbsd-developer] Re: xorg auto detection

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

On Sunday 16 October 2005 09:51 am, Renato Pinto Fl=F3rido wrote:
> Frederico wrote:
> /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.
>
> /Frederico, does the Xorg auto-detection detect vertical and horizontal
> refresh rates?
>
> what they are trying to achieve here with DDC is a detection feature that
> can config V/H refresh rates as well. Afaik, Xorg auto-detection didnt do
> this.
Well, I'm not really a moniter expert, but I used Xorg detection on
my laptop, my dad's laptop and on my desktop, and it detected all the scree=
ns=20
fine, on my laptop the res was 1024x768 (The max), on my dad's it was=20
1920x1280 (The max) and on my desktop 1280x1024(The max).

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

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

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

[Pcbsd-developer] Re: Asked for a Todo list?

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

Precicly, most Linux Distros ship with 1000 different editors, when
all the user wants is a simple notepad app.

On 10/15/05, Andrei Kolu <an...@bs...> wrote:
> Tim McCormick wrote:
>
> > Andrei Kolu wrote:
> >
> >> so why not use DesktopBSD Networking Manager- why write our own????
> >> Let's cooperate!
> >
> >
> > Ah, there are certain issues with this that we've looked at already.
> > The  only real problem in the way is that all the DesktopBSD tools
> > come with a rather large handful of dependencies. It is such that if
> > we wanted to use, for example, their Network manager we'd have to also
> > import a huge number of their specific libraries onto our base system.
> > I don't think we really want to do that.
>
> So you want to use your own huge number of libraries???
>
> I hoped that we don't fell in that trashcan like Linux distros by
> writing hundreds of tools for ONE task...
>
>
> -------------------------------------------------------
> 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: [Re: [Pcbsd-developer] Asked for a Todo list?]

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

Tim McCormick wrote:

> Andrei Kolu wrote:
>
>> so why not use DesktopBSD Networking Manager- why write our own???? 
>> Let's cooperate!
>
>
> Ah, there are certain issues with this that we've looked at already. 
> The  only real problem in the way is that all the DesktopBSD tools 
> come with a rather large handful of dependencies. It is such that if 
> we wanted to use, for example, their Network manager we'd have to also 
> import a huge number of their specific libraries onto our base system. 
> I don't think we really want to do that.

So you want to use your own huge number of libraries???

I hoped that we don't fell in that trashcan like Linux distros by 
writing hundreds of tools for ONE task...

Re: [Re: [Pcbsd-developer] Asked for a Todo list?]

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

Well I've been talking to Kris, and Kris acknowledges that I'm =20
working on a GNOME release of PC-BSD, I have successfully built GNOME =20=

and I'm working on refining the system.

PC-BSD tools do require a few components of the KDE3LIBS so are in =20
fact not DE independent, this is why the GNOME release I'm working on =20=

will also include:

- KDE3BASE
- KDE3LIBS
- QT3


On 15 Oct 2005, at 17:17, Andrei Kolu wrote:

> Renato Fl=F3rido wrote:
>
>
>> well, politic is about discussion. at lest it should be.
>>
>> you didn't understand my point. It's not about changing from one =20
>> DE to another, it's about not being tied to a DE.
>>
>> Linux distros are not even reinventing the wheel, they are =20
>> discussing only about each color the whell should have :-D
>>
>
> As I said earlier : let's stick with default KDE environment and =20
> make it work properly- only then we can change color and other =20
> unimportant things.
>
>
>> In this case, reinventing (or advancing) is tying the PC-BSD tools =20=

>> to PC-BSD, not doing it to the DE. If you look carefully, each =20
>> time a Linux OS chooses a DE and needs special tools (or different =20=

>> tools) they start making DE tools. That is different from having =20
>> the tools DE independent (can be used with what DE one wishes)=20
>> which and are developed for the OS and work no matter what color =20
>> you paint it.
>>
>
> There is no such thing like Linux OS! Linux even don't have =20
> userland like FreeBSD...
> Who want change DE? PC-BSD tools is separated from default KDE =20
> binaries- there is no need to write another version...
>
>
>> About The InterNetworking Manager, the permission manager and the =20
>> ports gui, it really makes no sense releasing a "desktop" which =20
>> hasn't got these basic features if there is a very similar project =20=

>> (DesktopBSD) which is supposed to aim at a more "educated" user =20
>> with a better knowlege of BSD and ships with them.
>>
>>
> so why not use DesktopBSD Networking Manager- why write our own???? =20=

> Let's cooperate!
>
>
>> If 1% of the politics were like us we would be in a better world :)))
>>
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, =20
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> PCBSD-Developer mailing list
> PCB...@li...
> https://lists.sourceforge.net/lists/listinfo/pcbsd-developer
>
>
>

Re: [Re: [Pcbsd-developer] Asked for a Todo list?]

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

Renato Fl=F3rido wrote:

> well, politic is about discussion. at lest it should be.
>
> you didn't understand my point. It's not about changing from one DE to=20
> another, it's about not being tied to a DE.
>
> Linux distros are not even reinventing the wheel, they are discussing=20
> only about each color the whell should have :-D

As I said earlier : let's stick with default KDE environment and make it=20
work properly- only then we can change color and other unimportant things.

> In this case, reinventing (or advancing) is tying the PC-BSD tools to=20
> PC-BSD, not doing it to the DE. If you look carefully, each time a=20
> Linux OS chooses a DE and needs special tools (or different tools)=20
> they start making DE tools. That is different from having the tools DE=20
> independent (can be used with what DE one wishes)which and are=20
> developed for the OS and work no matter what color you paint it.

There is no such thing like Linux OS! Linux even don't have userland=20
like FreeBSD...
Who want change DE? PC-BSD tools is separated from default KDE binaries-=20
there is no need to write another version...

> About The InterNetworking Manager, the permission manager and the=20
> ports gui, it really makes no sense releasing a "desktop" which hasn't=20
> got these basic features if there is a very similar project=20
> (DesktopBSD) which is supposed to aim at a more "educated" user with a=20
> better knowlege of BSD and ships with them.
>
so why not use DesktopBSD Networking Manager- why write our own????=20
Let's cooperate!

> If 1% of the politics were like us we would be in a better world :)))
>

Re: [Re: [Pcbsd-developer] Asked for a Todo list?]

[<ren...@gm...>]

Andrei Kolu wrote:

> Renato Pinto Flórido wrote:
>
>> _Andrei Kolu wrote:_
>> /
>> Why rewrite wheel? If we use KDE then all config must be from the 
>> same environment. //
>> If we have to maintain jet another DE then we lose so much time that 
>> never release fine desktop operating system.
>>
>> /I hear the "reinvention of the wheel" all the time and if you think 
>> about it, itsn't really a smart answer. It's a Linux kind of answer.
>>
>> Let me point you to a few facts:
>>
>> 1 - if man hadn't reinvented the wheel time after time, we would be 
>> still eating ants in the bush. Improving of existing technology is 
>> waht has been driving humanity forward.
>>
>> I myself build bycicle wheels and i can surely tell the difference 
>> between a properly made wheel and a piece of trash (assuming one is 
>> using the same hub/spokes/rim/nipples)
>>
>> Little details can diferentiate the good enough from the exellent.
>
>
> This is exactly the "Linux way" to answer. :) I know that "wheel" is 
> reinvented in linux about 125 times right now...maybe more...
>
> WHY REWRITE TOOL THAT JUST WORKS!!!???? dziis...
>
>>
>> 2- Making the system DE independent (i am sure this cant be done 
>> overnight) ensures several good things:
>>
>>  - Everything will still work 100% by default
>>  - DE PBI 's for PC-BSD will be easier to develop and no one will be 
>> asking for x,y or Z version of PC-BSD
>>  - PC-BSD will be future proof as it is not linked to the story of 
>> any particular DE. If KDE gets into trouble in the future, we will 
>> have the ability to steer away from problems and if anything better 
>> comes, we can make the shift faster and easier.
>> - We wont have to support any other DE as the pbi maker will have all 
>> the necessary things to build the DE PBI. If someone says: "Ah, but 
>> i'd like to have Gnome" we just say "sure, grab the pbi. It works 
>> just the same way. every tool is there"/
>>
>> /Have you compared a F1 car wheel with a regular wheel? It works 
>> better, faster, lighter.
>>
> If KDE == F1 then GNOME == Ford to me...
>
>> This is surely one of those things you do overnight but it has to be 
>> done before it is too late to turn back.
>>
>>
>> Second issue:
>> /
>> Please no crappy emulation...
>> /
>> I ment compatibility layer. In some places it is referred as 
>> compatibility layer, in some other it is emulation layer... Sorry for 
>> the confusion.
>>
> I'd like to have native FreeBSD programs not some RedHät 8.0 
> compatibility layered...piece of ...
>
>>
>> Third Issue:
>>
>>
>> /"PC-BSD default tools"/
>>
>> I think most of it is better leave for 2.0 version of PC-BSD.
>> /
>>
>> /The Internetworking Manager, the permission manager and the ports 
>> gui should be here before 1.0 The rest can be added after. as i said, 
>> some things are not to be applied immediately./
>> //
>> /
>
>
> Okei this is getting too political right now :))))
>
>
> -------------------------------------------------------
> 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
>

well, politic is about discussion. at lest it should be.

you didn't understand my point. It's not about changing from one DE to 
another, it's about not being tied to a DE.

Linux distros are not even reinventing the wheel, they are discussing 
only about each color the whell should have :-D

In this case, reinventing (or advancing) is tying the PC-BSD tools to 
PC-BSD, not doing it to the DE. If you look carefully, each time a Linux 
OS chooses a DE and needs special tools (or different tools) they start 
making DE tools. That is different from having the tools DE independent 
(can be used with what DE one wishes)which and are developed for the OS 
and work no matter what color you paint it.

About The InterNetworking Manager, the permission manager and the ports 
gui, it really makes no sense releasing a "desktop" which hasn't got 
these basic features if there is a very similar project (DesktopBSD) 
which is supposed to aim at a more "educated" user with a better 
knowlege of BSD and ships with them.

If 1% of the politics were like us we would be in a better world :)))

Re: [Re: [Pcbsd-developer] Asked for a Todo list?]

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

Renato Pinto Fl=F3rido wrote:

> _Andrei Kolu wrote:_
> /
> Why rewrite wheel? If we use KDE then all config must be from the same=20
> environment. //
> If we have to maintain jet another DE then we lose so much time that=20
> never release fine desktop operating system.
>
> /I hear the "reinvention of the wheel" all the time and if you think=20
> about it, itsn't really a smart answer. It's a Linux kind of answer.
>
> Let me point you to a few facts:
>
> 1 - if man hadn't reinvented the wheel time after time, we would be=20
> still eating ants in the bush. Improving of existing technology is=20
> waht has been driving humanity forward.
>
> I myself build bycicle wheels and i can surely tell the difference=20
> between a properly made wheel and a piece of trash (assuming one is=20
> using the same hub/spokes/rim/nipples)
>
> Little details can diferentiate the good enough from the exellent.

This is exactly the "Linux way" to answer. :) I know that "wheel" is=20
reinvented in linux about 125 times right now...maybe more...

WHY REWRITE TOOL THAT JUST WORKS!!!???? dziis...

>
> 2- Making the system DE independent (i am sure this cant be done=20
> overnight) ensures several good things:
>
>  - Everything will still work 100% by default
>  - DE PBI 's for PC-BSD will be easier to develop and no one will be=20
> asking for x,y or Z version of PC-BSD
>  - PC-BSD will be future proof as it is not linked to the story of any=20
> particular DE. If KDE gets into trouble in the future, we will have=20
> the ability to steer away from problems and if anything better comes,=20
> we can make the shift faster and easier.
> - We wont have to support any other DE as the pbi maker will have all=20
> the necessary things to build the DE PBI. If someone says: "Ah, but=20
> i'd like to have Gnome" we just say "sure, grab the pbi. It works just=20
> the same way. every tool is there"/
>
> /Have you compared a F1 car wheel with a regular wheel? It works=20
> better, faster, lighter.
>
If KDE =3D=3D F1 then GNOME =3D=3D Ford to me...

> This is surely one of those things you do overnight but it has to be=20
> done before it is too late to turn back.
>
>
> Second issue:
> /
> Please no crappy emulation...
> /
> I ment compatibility layer. In some places it is referred as=20
> compatibility layer, in some other it is emulation layer... Sorry for=20
> the confusion.
>
I'd like to have native FreeBSD programs not some RedH=E4t 8.0=20
compatibility layered...piece of ...

>
> Third Issue:
>
>
> /"PC-BSD default tools"/
>
> I think most of it is better leave for 2.0 version of PC-BSD.
> /
>
> /The Internetworking Manager, the permission manager and the ports gui=20
> should be here before 1.0 The rest can be added after. as i said, some=20
> things are not to be applied immediately./
> //
> /

Okei this is getting too political right now :))))

Re: [Pcbsd-developer] Setting monitor config properly

[<ren...@gm...>]

Charles A. Landemaine wrote:

>Guys, I have an idea, please tell me if it's a good one, or if it's
>not viable :)
>I think we definately need a monitor configuration that runs out of
>the box, so that the user doesn't need to edit any xorg.conf file to
>increase the refresh rate and the resolution.
>
>PC-BSD "works" out of the box, but still, most of the time, the
>refresh rate and screen resolution are not set the way the user wants.
>
>Here's what I suggest: We create a database of screens (could be
>extended to any piece of hardware actually), and for each screen, the
>PC-BSD community informs data such as screen resolution, refresh rate,
>etc... For instance I have 19' Sony SDM-S93 LCD monitor that has
>native 1280x1024 resolution, an horizontal refresh rate of 28-80 and a
>vertical refresh rate of 48-75, the maximum refresh rate of the screen
>being 75Hz.
>
>Now, we store this data in the PC-BSD install CD. During installation,
>PC-BSD detects the monitor, look at the hardware DB and sees if there
>is already an SDM-S93 monitor. If there is this monitor in the DB, it
>configures X.org accordingly using a configuration that works fine
>because it has already been tested by contributors, and that uses the
>maximum screen performance (1280x1024@75Hz in this case instead of
>1024x768@60Hz by default!)
>
>No hack for newbies, and faster for the rest of us. What do you think?
>
>Charles.
>
>
>-------------------------------------------------------
>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
>
>  
>
Actually charles, the DDC is supposed give the correct values but in 
kudzu, it also checks those values agaist a monitor database. The only 
problem is we need something which has BSD license and Kudzu uses GPL if 
i am not mistaken.

Combining DDC probing with a Database is the way to go.

[Pcbsd-developer] Setting monitor config properly

[Charles A. L. <lan...@gm...>]

Guys, I have an idea, please tell me if it's a good one, or if it's
not viable :)
I think we definately need a monitor configuration that runs out of
the box, so that the user doesn't need to edit any xorg.conf file to
increase the refresh rate and the resolution.

PC-BSD "works" out of the box, but still, most of the time, the
refresh rate and screen resolution are not set the way the user wants.

Here's what I suggest: We create a database of screens (could be
extended to any piece of hardware actually), and for each screen, the
PC-BSD community informs data such as screen resolution, refresh rate,
etc... For instance I have 19' Sony SDM-S93 LCD monitor that has
native 1280x1024 resolution, an horizontal refresh rate of 28-80 and a
vertical refresh rate of 48-75, the maximum refresh rate of the screen
being 75Hz.

Now, we store this data in the PC-BSD install CD. During installation,
PC-BSD detects the monitor, look at the hardware DB and sees if there
is already an SDM-S93 monitor. If there is this monitor in the DB, it
configures X.org accordingly using a configuration that works fine
because it has already been tested by contributors, and that uses the
maximum screen performance (1280x1024@75Hz in this case instead of
1024x768@60Hz by default!)

No hack for newbies, and faster for the rest of us. What do you think?

Charles.

Re: [Re: [Pcbsd-developer] Asked for a Todo list?]

[<ren...@ne...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<u>Andrei Kolu wrote:</u><br>
<i><br>
Why rewrite wheel? If we use KDE then all config must be from the same
environment.
</i><i><br>
If we have to maintain jet another DE then we lose so much time that
never release fine desktop operating system.<br>
<br>
</i>I hear the "reinvention of the wheel" all the time and if you think
about it, itsn't really a smart answer. It's a Linux kind of answer.<br>
<br>
Let me point you to a few facts:<br>
<br>
1 - if man hadn't reinvented the wheel time after time, we would be
still eating ants in the bush. Improving of existing technology is waht
has been driving humanity forward.<br>
<br>
I myself build bycicle wheels and i can surely tell the difference
between a properly made wheel and a piece of trash (assuming one is
using the same hub/spokes/rim/nipples)<br>
<br>
Little details can diferentiate the good enough from the exellent.<br>
<br>
2- Making the system DE independent (i am sure this cant be done
overnight) ensures several good things:<br>
<br>
&nbsp;- Everything will still work 100% by default<br>
&nbsp;- DE PBI 's for PC-BSD will be easier to develop and no one will be
asking for x,y or Z version of PC-BSD<br>
&nbsp;- PC-BSD will be future proof
as it is not linked to the story of any particular DE. If KDE gets into
trouble in the future, we will have the ability to steer away from
problems and if anything better comes, we can make the shift faster and
easier.<br>
- We wont have to support any other DE as the pbi maker will have all
the necessary things to build the DE PBI. If someone says: "Ah, but i'd
like to have Gnome" we just say "sure, grab the pbi. It works just the
same way. every tool is there"<i><br>
<br>
</i>Have you compared a F1 car wheel with a regular wheel? It works
better, faster, lighter.<br>
<br>
This is surely one of those things you do overnight but it has to be
done before it is too late to turn back.<br>
<br>
<br>
Second issue:<br>
<i><br>
Please no crappy emulation...
<br>
</i><br>
I ment compatibility layer. In some places it is referred as
compatibility layer, in some other it is emulation layer... Sorry for
the confusion.<br>
<br>
<br>
Third Issue:<br>
<br>
<br>
<i>"<span class="moz-txt-underscore">PC-BSD default tools<span
 class="moz-txt-tag">"</span></span></i><br>
<br>
I think most of it is better leave for 2.0 version of PC-BSD.
<br>
<i><br>
<br>
</i>The Internetworking Manager, the permission manager and the ports
gui should be here before 1.0 The rest can be added after. as i said,
some things are not to be applied immediately.<i><br>
</i><i><br>
</i>
</body>
</html>

Re: [Pcbsd-developer] Asked for a Todo list?

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

Renato Pinto Fl=F3rido wrote:

> Hi! I am by no means an expert, but i do want to help. I signed this=20
> mailing list mainly to be aware of how the work is going but hey, as i=20
> am here and i have something to say, it's not a problem if i write to=20
> the list.
>
> *This is a part of my PC-BSD todo list *
>
> *_PC-BSD Structure_*
>
> *. Make PC-BSD tools Desktop Environment independent *

Why rewrite wheel? If we use KDE then all config must be from the same=20
environment.

> - enabling users to run which DE they desire by installing DE PBI=20
> packages
> - making PC-BSD future proof
> - making PC-BSD more versatile_*

If we have to maintain jet another DE then we lose so much time that=20
never release fine desktop operating system.

> *_Development utilities_*
>
> *. PBI Opener*
> - PBI maker should be able to open PBI packages after they are already=20
> made (while containing an encryption feature or similar security featur=
e

I agree.

> *_Documentation_**__*
>
> *. Guide for certified PBI creation*
> - Installation layout
> - Dependencies
> - Menu layout
> *. Pre installation requirements*
> *. PC-BSD Installation guide*
> * . Getting Started*
> *. PC-BSD Manual*
> *. PC-BSD Handbook*
> *. PC-BSD Help_

Please no Handbook- we already got some from FreeBSD.

> *_Installation process_*
>
> *. Auto detection of processor model/type and installation of=20
> respective kernel for each system=92s needs*
> - Increases PC-BSD performance and possibly stability

Actually there is no need for different architecture support cos freebsd=20
kernel by default compiled without 3dnow and sse support. Only=20
difference is for SMP kernel.

> Boot_*
> _**_
> *. Hardware auto detection and configuration*
> - Steps: Hardware change check (checks current hardware against a=20
> hardware profile)> Configuration of new hardware (if new hardware is=20
> found)> saving of hardware profile.

Freebsd did not have "hardware profiles" like linux - all detections is=20
performed by kernel.

> - Monitor Auto detection and configuration using DDC and a monitor=20
> database (as Kudzu)
> - Ability to configure multiple monitor and multi mice (for laptops)=20
> setups
> - Ability to configure several mice types (3 button, 5 button, 7=20
> button, roller balls...)

must have....

> - Asks for PBI drivers which are listed on PC-BSD update service and=20
> installs them as soon as the pc is connected to the internet

I think we can provide "Project Evil" windows drivers like .PBI-s

> *. Better boot loader for multiple boot environments *
> *. Boot screen *
> - should cover all text until the OS login screen
> - should have a Status bar
>
I'd like that too.

>
> *_System_*
>
> *. Linux emulation layer integration within the main install*

Please no crappy emulation...

> *. Rar, zip, Tar, etc by default

must have. I already mentioned this in forums.

> . Hide file system by default*
> - Same procedure as the Mac OSX

I think this is not main priority right now.

> *. Auto detection and auto mount of floppies, USB storage devices,=20
> hard drives, CD=92s, DVD=92s, photographic cameras, mp3 players, memory=
=20
> cards, etc.

This is real challenge...

> *
> *_Things needing tuning (KDE stuff not working and little bugs)_*
>
> *. KDE=92s keyboard layout listed on KDE control centre should be the=20
> same as the one chosen by the user during the installation
> * - Configuration chosen by the user during the installation must be=20
> on kde control center.*
> . Get Noatun working by default*

Please remove this "plays nothing by default" player and bundle PC-BSD=20
with amaroK and Kmplayer.

> *. Remove unneeded KDE bits and making all remaining KDE apps fully wor=
k*

as I already said.

> *. Conqueror and all other PBI packages installed browsers should be=20
> tuned by default to use the PBI installed java, flash and other plug-in=
s*
> * . Only anti-aliased founts should be used
> . Only fonts which can be used with all supported languages (using=20
> only fonts which support for letters which are custom to some=20
> languages) supported on the installation CD should be used*

Just what I wanted long time ago.

> * _PC-BSD default tools_*
>
> *. Development of Graphical interfaces for all essential FreeBSD tools=20
> and mechanisms*
> * . GUI for FreeBSD boot loader management*
> * . Internetworking manager*
> * . System wide permission manager*
> - Gui for permission management
> - Stores permission profiles (PC-BSDOriginal,RegularUser,Custom=20
> profile, etc=85)
> - User can save custom profiles***
> . GUI for ports management* ****
> *. Backup utility for files and system configuration files*
> - Should create a setup file which could be used to reset a system=92s=20
> settings after a reinstall.
> - Certified PBI should be made with this feature in mind
> *. Expos=E9-alike software* **
> *. PC-BSD Control panel* **
> *. Inserting CD=92s, DVD=92s pen drives etc, should bring an icon to th=
e=20
> desktop* _*
>
I think most of it is better leave for 2.0 version of PC-BSD.

> *_Needed PBI packages_* *__*
> *. PBI plug-in packages*
> * *- Java (one which works with firefox)**
> - Flash (more recent)
> - Shockwave
>
Agree, but we need NATIVE java and flash.... :(

> *. Development **of** driver PBI packages*
> - Experimental ATI 3d driver

Someone must kick asses at ATI...

> - Intel gigabit network drivers

"Project evil"

> - Other widely used drivers
> *. Firewall and respective Graphical interface .PBI packages* **

version 2.0

> *. Codec pack or individual codec pbi=92s* **

> ( This is not the complete list. )
>
>
> Cheers!
> RF

Re: [Pcbsd-developer] Asked for a Todo list?

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

Hi
Concerning the flash, I've tried to get it up to 7, but it is highly
unstable so I decided not to release the PBI.
As for the X detection why not just use nothing? When i was using FreeBSD i
just typed in startx or kdm and Xorg auto-detected my configuration
perfectly (on my laptop, and on my computer).
For the support of USB disks etc. I would have to agree but they should be
implimented through AMD so that the user dosnt have to unmount them all the
time.
And as for the codecs, thats pointless as MPlayer and VLC include them buil=
t
in.
Now, with the PBIs: I'm working on a proposal PBI standard, which makes
things a hell of a lot eaiser for the packagers and for the users (Stuff
like a PBI Updator script, and Get Hot New PBIs).
Anyways thats just my ideas for now.\
 Federico

[Pcbsd-developer] Asked for a Todo list?

[<ren...@ne...>]

Hi! I am by no means an expert, but i do want to help. I signed this 
mailing list mainly to be aware of how the work is going but hey, as i 
am here and i have something to say, it's not a problem if i write to 
the list.

I believe Andrei is right, when he means rivaly, i am sure he is talking 
"sane rivalry" :-) . Being perfectionist to some extent is good.

Now, about the roadmap.


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

/I am all for this, we should only use good looking, TrueType fonts and 
remove all bad looking fonts from the default system. If the fonts are 
cannot be read right, why are they occupying space on the CD? I am sure 
we can have a great font collection without breaking the law.

/3. Linux compat layer- I don't like default fontset with linux 
programs- it seem's like software from third world...

/And now we will be moving languagesto the second CD (and hopefully lots 
of garbage right out of the system) we can ship the Linux emulation 
Layer installed by default. Everyone will be using linux programs anyway...

/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 am glad i hammered Andrew Youll's head about automatic XF86Config 
configuration.
What you guys will be doing is what Kudzu already does. I learned this 
when i was searching for info about DDC with Youlle. It may not be a bad 
idea to look at Kudzu's specs more carefully before you get your hands 
dirty. This should avoid wasting time with known problems.

/5. Hide soundcard module loading- it's distracting- users think that 
there is some problem.
/
Also agree. When i first installed PC-BSD, i was unsure if i had only my 
soundblaster working or both the pci card and the integrated sound 
syetem although i had it disabled in the bios.

Now i can add some things to this list. I have more but that should be 
probabily adressed after the first official release (it's a long list)

*This is a part of my PC-BSD todo list *

*_
_*

*_PC-BSD Structure_*

*. Make PC-BSD tools Desktop Environment independent *
- enabling users to run which DE they desire by installing DE PBI packages
- making PC-BSD future proof
- making PC-BSD more versatile_*
*_
_**_
*_Development utilities_*

*. PBI Opener*
- PBI maker should be able to open PBI packages after they are already 
made (while containing an encryption feature or similar security feature
* *
* *
*_Documentation_**__*

*. Guide for certified PBI creation*
- Installation layout
- Dependencies
- Menu layout
*. Pre installation requirements*
*. PC-BSD Installation guide*
* . Getting Started*
*. PC-BSD Manual*
*. PC-BSD Handbook*
*. PC-BSD Help_
_*
*__*
*_Installation process_*

*. Auto detection of processor model/type and installation of respective 
kernel for each system’s needs*
- Increases PC-BSD performance and possibly stability
*_

Boot_*
_**_
*. Hardware auto detection and configuration*
- Steps: Hardware change check (checks current hardware against a 
hardware profile)> Configuration of new hardware (if new hardware is 
found)> saving of hardware profile.
- Monitor Auto detection and configuration using DDC and a monitor 
database (as Kudzu)
- Ability to configure multiple monitor and multi mice (for laptops) setups
- Ability to configure several mice types (3 button, 5 button, 7 button, 
roller balls...)
- Asks for PBI drivers which are listed on PC-BSD update service and 
installs them as soon as the pc is connected to the internet
*. Better boot loader for multiple boot environments *
*. Boot screen *
- should cover all text until the OS login screen
- should have a Status bar


*_System_*

*. Linux emulation layer integration within the main install*
*. Rar, zip, Tar, etc by default
. Hide file system by default*
- Same procedure as the Mac OSX
*. Auto detection and auto mount of floppies, USB storage devices, hard 
drives, CD’s, DVD’s, photographic cameras, mp3 players, memory cards, etc.
. Enabling a way for the users to change permissions on storage devices 
through right click, properties menu of such device.*
- Of course, users are asked for root password for this
- The user should be asked whether he wants to use the new permission 
profile only for the current session or write it to his profile, save 
as… and make it permanent behavior
- The permissions manager under a properties menu of a storage device 
should only display that device’s permissions but there must also exist 
an “advanced” button pointing to the system wide permission manager.* 
(described under the PC-BSD default tools near the end of the list) **
*. Manager for customizable settings for each user in:*
- Sound, looks, installed apps, permissions, screen resolution, etc.
- Sub-profiles for each user allowed
*. Burning in user mode*
- The implementation should enable any burning app to use it (i.e. k3b).
- The user should be prompted with the usual root password request the 
first time he attempts to burn or use a burn app and the option to make 
it the default policy.
- Certified PBI packages of burning apps should be made with this 
feature in mind
*. Ability to install groups of PBI packages in one move*
* . Uninstall shortcut on each PBI program folder on K Menu which points 
to the package manager)*
* * *
*
*_Things needing tuning (KDE stuff not working and little bugs)_*

*. KDE’s keyboard layout listed on KDE control centre should be the same 
as the one chosen by the user during the installation
* - Configuration chosen by the user during the installation must be on 
kde control center.*
. Get Noatun working by default*
*. Remove unneeded KDE bits and making all remaining KDE apps fully work*
*. Conqueror and all other PBI packages installed browsers should be 
tuned by default to use the PBI installed java, flash and other plug-ins*
* . Only anti-aliased founts should be used
. Only fonts which can be used with all supported languages (using only 
fonts which support for letters which are custom to some languages) 
supported on the installation CD should be used*
* *

* _PC-BSD default tools_*

*. Development of Graphical interfaces for all essential FreeBSD tools 
and mechanisms*
* . GUI for FreeBSD boot loader management*
* . Internetworking manager*
* . System wide permission manager*
- Gui for permission management
- Stores permission profiles (PC-BSDOriginal,RegularUser,Custom profile, 
etc…)
- User can save custom profiles***
. GUI for ports management* ****
*. Backup utility for files and system configuration files*
- Should create a setup file which could be used to reset a system’s 
settings after a reinstall.
- Certified PBI should be made with this feature in mind
*. Exposé-alike software* **
*. PC-BSD Control panel* **
*. Inserting CD’s, DVD’s pen drives etc, should bring an icon to the 
desktop* _*

*_*********__**__*
*_Needed PBI packages_* *__*
*. PBI plug-in packages*
* *- Java (one which works with firefox)**
- Flash (more recent)
- Shockwave

*. Development **of** driver PBI packages*
- Experimental ATI 3d driver
- Intel gigabit network drivers
- Other widely used drivers
*. Firewall and respective Graphical interface .PBI packages* **
*. Codec pack or individual codec pbi’s* **

( This is not the complete list. )


Cheers!
RF

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

[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] Re: PCBSD-Developer digest, Vol 1 #1 - 1 msg

[Charles A. L. <lan...@gm...>]

Yes Antik, I think there's no point being a rival of Linux - At least
this is everything but my goal. We can greatly learn from Linux,
especially from the mistakes that have been done over the years. The
Linux relative fever can be a run way for PC-BSD because some people
at least know there are alternatives out there, and this is good.

As this is a dev mailing list, I can contribute in graphic design, but
I'm not a good C++ programmer, as I had only classes at the University
:(

Other than that, I hope the Network control panel project emerges soon :D

[Pcbsd-developer] Hi all! First post?

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

I was anctious to see some rapid development work here, but found so 
quiet place that I can hear needle dropping...
We have lots of work to do to become tough rival for Linux distros. But 
I think FreeBSD can provide us really stable ground to build some 
kickass desktop operating system!

Forgive me my bad english, but I think I can be useful for PC-BSD 
community with my FreeBSD know-how and with some unusual ideas:)