Heh, heh, rarsa, as you already have pvolume and mixer using Gnocl,
I guess I'll put it into my own next Puppy! I don't know about the 2.15CE
core developers' plans for Gnocl though.

This is something we urgently need to discuss - a strategy for application development that offers essential freedom for developers without costing us bloat in the package.

I included Gnocl in 2.15CE Alpha to support what rarsa was doing with things like pvolume. Then again, rarsa hasn't decided between Gnocl and GINS and I don't think it would help to use both, if they require different support libraries.

OTOH, dvw86 has begun a really fantastic Control Panel using murgaLUA that only requires a 312kb runtime for applications to work. That's not unreasonable, IMHO. We can support applications based on something that size without impacting too much on Puppy's size.

We also have a number of requests for GUI front ends to applications that already exist or are in development - Icewm theme management is one such area, a GROSS (GRand Overall Startup Script) to front-end the essential setup wizards on first boot to walk users through system configuration, etc.

It would really help if we could arrive at some desirable consistency of development environment so all of the separate efforts would all be inter-operable. Am I asking too much here?

Rarsa, yes, but I have only included Gnocl because you are writing applets for it, and are keen on it, but I personally know nothing about Gnocl. I presume the Gnocl project is active?
Regarding murgaLua, I have asked a question about the runtime size on another thread (I haven't got back to that thread yet), but at this stage it would seem to be dispersing our
development environment too much.

Regarding murgaLua, I have asked a question about the runtime size on another thread (I haven't got back to that thread yet), but at this stage it would seem to be dispersing our
development environment too much.

Ok, that settles it then. It's Gtkdialog, GINS and Gnocl for Puppy 2.15CE. Thanks for the clarification guys.

Regarding murgaLua, I have asked a question about the runtime size on another thread (I haven't got back to that thread yet), but at this stage it would seem to be dispersing our development environment too much.

murgaLua development is very different to bash/tcl/c and will attrack a different set of people who otherwise may not contribute ...

I'm all for having guidelines, put some people's attitudes towards trying to force people into one specific language/platform or another seem a little missguided.

I'm all for having guidelines, put some people's attitudes towards trying to force people into one specific language/platform or another seem a little missguided.

It's all about choice

I understand your point. For that reason I have proposed that the murgaLUA runtime executable should be in the Puppy 2.15CE Office edition.

That said, I also understand the need to adopt some standards for development of the core OS and it's attendant applications, in order to keep to a reasonable size. So, as much as I regret doing so, I can't find space for murgaLUA and dvw86's excellent Control Panel app in the Standard edition of 2.15CE.

What I believe the Community Edition should do is offer choice where appropriate, and restrict options where appropriate. That may sound like having an each way bet on the ponies, but I think it makes perfect sense. Wouldn't you agree

That said, I also understand the need to adopt some standards for development of the core OS and it's attendant applications, in order to keep to a reasonable size. So, as much as I regret doing so, I can't find space for murgaLUA and dvw86's excellent Control Panel app in the Standard edition of 2.15CE.

What I believe the Community Edition should do is offer choice where appropriate, and restrict options where appropriate. That may sound like having an each way bet on the ponies, but I think it makes perfect sense. Wouldn't you agree

Heh ... It all depends what is deemed as appropriate and why.

My previous statement stands ...

I have no desire to labour this point as murgaLua has a home, and it's not Puppy ...
So I do not consider this an important point, although it is a bit sad.

i will say this. you know my stand on bloat. when a long time member of the community has developed a useful framework that is very small, within puppy, and has already been in puppy for sometime, i would sooner remove a tool that is not in current widespread use that is by someone else. that may not fit the description of anything in puppy right now.

on the other hand, with the work john did on murgalua, and mu did to get puppybasic in, i would be VERY unlikely to ever remove them. they *do* cater to a host of contributors, they *are* small, and they are not a single tool per se but the framework for many. on these criteria i would always lean towards their inclusion, i've registered my disappointment in removing murgalua from ce already... it's mild disappointment, but it's firm. i still appreciate that you are trying to remove bloat whodo- very much so, and i know some people are going to look for things they wish were included. and if it's really the best you can do, i am glad that it's at least in the office version... not that i personally think that's the best solution, but yeah better than nothing.

if you remove puppybasic too, it will simply be too hard to make small apps for puppy ce. i already tried to learn tcl/tk- EW. puppybasic is one of the best things that ever happened to puppy, it's even in mu's 12mb version.

although it would be a task (a task i wouldn't know how to do) it would be useful to have a list of what takes up how much, rather than have it come up in isolated debates about what to include. we could prioritize classes of what to keep and remove, and we could put "existing frameworks by community members" above "frameworks less in use that are not by members" i'm not saying we should all switch from gnocl to murgalua, that's not the point._________________sadly, it is not possible to separate politics from free software. free software - politics = unfree software.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum