Woof at Github

[mavrothal]

I have done some initial testing of gui enhancements in woof.
My guidelines

• Only touch gtkdialog code
• Take advantages of the recent gtkdialog features
• Allow scaling of window
• Clean up gui
• Make gui code more human readable
• Change gtkdialog3/4 to gtkdialog

• Make it touch friendly ?

[BarryK]

This is a great initiative!

I kept very quiet for sometime, wondering if something like this would spontaneously emerge, and it has!

Created and supported by long-time rock-solid guys too!

Yes, there are many who will now get a more direct input to the evolution of Woof and Puppy, than before, when everything channeled through me.

I have announced woof-CE in my new blog:

http://bkhome.org/news/?viewDetailed=00002

I wish you guys great success.

Let me know when a pup distro gets to release status and I'll announce it on my blog and at Distrowatch.

[puppyluvr]

Hello,
Great project to provide Woof with a future.
Great to see the Puppy Master on board!

[shinobar]

Great!

[01micko]

Slacko -testing, woof-CE (testing branch).

Reports here please.

[sunburnt]

I`ve had a long time Q that`s never been answered. And these are the folks that would know.
What part of a Woof build is uniquely Puppy.? I`d think: guis, scripts, Rox, JWM, GtkDialog.
But are all the os core files the parent distro`s.? /bin, /lib, /sbin, usr/......., X, xorg, gtk+.
I don`t want to pollute this thread, so if someone wants to pm me with an answer, great.!

[mavrothal]

What part of a Woof build is uniquely Puppy.?

Assuming you are referring to the produced ISO, whatever is in woof/woof-code/ but the scripts and the support folder, and all the pets that are used in a build (check DISTRO_PKGS_SPECS)

[amigo]

What part of a Woof build is uniquely Puppy.? Exactly the right question -because all that needs to be separated out, conceptually. Since that's where most development takes place and where there are most likely to be bugs, it should be treated as separate entities so it gets the needed attention.

[mavrothal]

What part of a Woof build is uniquely Puppy.? Exactly the right question -because all that needs to be separated out, conceptually. Since that's where most development takes place and where there are most likely to be bugs, it should be treated as separate entities so it gets the needed attention.

Technically as I said is what ever is in the woof-code folder. Conceptually, though I'm certainly not the best qualified to tell you, I would think the boot sequence, ie init script and rc.d scripts, the (ever argued upon) puppy package manager, the plethora of (mostly) gtkdilog-based customization apps (wizards) and to a lesser extend the ROX-JWM desktop, the (ever controversial) menu system and the hardware detection scripts (though lately udev and Xorg are mostly used for that).
The underlining theme in all these I believe is try to do some things in a simpler yet effective way without the bloat and the cascading dependencies of mainstream GNU/Linux.
Regarding separating them, I'm not sure I would agree. This exact separation I think is responsible to a great extend for the escalating size and dependencies of linux builds.

[sunburnt]

So most of the OS is uniquely Puppy. What then makes a variant Ubuntu or Slacko.?

Has anyone tried Woof on the Slackware or Ubuntu OSs including their X, xorg, gtk+ ?
And then use it to compile rox, jwm, gtkdialog, etc. And boot with Puppy`s boot, guis, etc.?
Another words, a Puppified "other distro". But maybe this is what Precise and Slacko are.
.

[Ibidem]

So most of the OS is uniquely Puppy. What then makes a variant Ubuntu or Slacko.?

Has anyone tried Woof on the Slackware or Ubuntu OSs including their X, xorg, gtk+ ?
And then use it to compile rox, jwm, gtkdialog, etc. And boot with Puppy`s boot, guis, etc.?
Another words, a Puppified "other distro". But maybe this is what Precise and Slacko are.
.

Yes; here's a short key:
Upup/Lucid/Precise = Puppified Ubuntu (Lucid = Ubuntu 10.xx based; Precise = Ubuntu 12.xx based)
Dpup = Debian-based Puppy
Spup/Slacko = Slackware-based Puppy
Apup = Arch-based Puppy
And I think there's a couple RPM-derived systems.

It would be interesting to use an OWL or PLD based Puppy...

[sunburnt]

So I think Ibidem`s saying that the "other" Puppies are all the other distro except Puppy scripts & etc.

So the Puppy parts are already separate ( not in woof/woof-code/ )?
And what goes in the support folder.?
.

[mavrothal]

So I think Ibidem`s saying that the "other" Puppies are all the other distro except Puppy scripts & etc.

So the Puppy parts are already separate ( not in woof/woof-code/ )?
And what goes in the support folder.?
.

The rest of the files in /woof (including support folder) are for building the puppies thought few make it to the iso too.

[nilsonmorales]

vicmz wrote

Is it possible to have an initrd that includes a basic set of popular languages to choose from at first, so that users are able to read boot messages in their language (practical for live-CDs) and then install the langpack when they get the desktop?

if you start the translate work for initrd i would like to help you my friend.

[vicmz]

Is it possible to have an initrd that includes a basic set of popular languages to choose from at first, so that users are able to read boot messages in their language (practical for live-CDs) and then install the langpack when they get the desktop?

"Gettexting" the init script is not a good idea as it would require a number of additional libraries in the initrd. However BK's init accepts the "plang" boot parameter (example: de_DE.UTF-8 ) and looks for the corresponding init in /locale/${PLANG%.*}/init (ie /locale/es/init or /locale/es-ES/init )
It also looks for a /PUPPYLANG file that contains the plang argument, in case you want to build a puppy with a different default language. The init script has 60 text messages so is not too much work to do. The only ¨problem¨ is that the language changes must be provided as a series of sed commands in the /locale/${PLANG%.*}/init file
You may want to add as an "enhancement" in the woof-CE/issues and then start working on the translation of the init script!

This is a job for Super L18L!

I wish I was that experienced but currently I'm doing what I actually can, otherwise you guys would have a lot more to fix.

The langpacks already have translations for the initrd through sss domains, but these are applied manually after booting to the desktop. I see Woof will require a different method in order to have new Puppies display a choose-language boot menu. For now it's just an idea, time will tell if this is viable/practical/etc.

[L18L]

... I see Woof will require a different method in order to have new Puppies display a choose-language boot menu. For now it's just an idea, time will tell if this is viable/practical/etc.

Look at other OSes:
-Android (I do know the x86 emulation running on my box): all languages included
-OpenSuSE and others had firstly choice of language
not choose from de es it pt ru.....
but choose from Deutsch Espanol Portugues pу

[mavrothal]

I have already realized this choice in Cutting edge section, see
internationalization of initrd messages at bootup
I did not make its way into woof.

But if it will be done in Woof-CE

Will be done in woof-CE if you can provide a patch for it against the current
woof-CE /woof-code/boot/initrd-tree0/

[L18L]

Will be done in woof-CE if you can provide a patch for it against the current
woof-CE /woof-code/boot/initrd-tree0/

Does it already boot directly into X

[mavrothal]

Will be done in woof-CE if you can provide a patch for it against the current
woof-CE /woof-code/boot/initrd-tree0/

Does it already boot directly into X

If you are asking about woof-CE builds then yes,
Slacko 5.6.3 is the latest woof-CE build and it does boot directly to X.
If you are asking if the initrd.gz has a mini Xserver (Xfbdev, tinyX etc) included, No.

[L18L]

If you are asking if the initrd.gz has a mini Xserver (Xfbdev, tinyX etc) included, No.

Yes, that was what I wanted to ask.
Will initrd.gz ever have a mini Xserver?