I had some time to spare and decided to tackle cleaning up a couple of tcl/tk applicaitions included in Puppy that had a rather old look.
I refrained from converting them to gnocl until it is included in the LiveCD so they still have the tk look, just a little bit cleaner.
Here is TkMines
Click the thumbnail to see the full size image
TkMines with a cleaned up UI
TkMines with a cleaned up UI
- Attachments
-
- tkmines-2.15-1.pet
- If you have a puppy 2.14 or newer use this one
- (5.86 KiB) Downloaded 1210 times
-
- tkmines-2.15-1.pup
- If you have a puppy older than 2.14 use this one
- (6.31 KiB) Downloaded 1139 times
[url]http://rarsa.blogspot.com[/url] Covering my eclectic thoughts
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to
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.BarryK wrote: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.
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?
Any thoughts, guys?
Barry,
If I understood correctly your comments in other threads, you are now settling for GTK compliant toolkits as follows:
- gtkdialog for simple bash interfaces
- GINS for complex bash interfaces
- gnocl for Tcl interfaces
I find it consistent with the current LiveCD toolkits and making it explicit again may help aligning efforts.
If I understood correctly your comments in other threads, you are now settling for GTK compliant toolkits as follows:
- gtkdialog for simple bash interfaces
- GINS for complex bash interfaces
- gnocl for Tcl interfaces
I find it consistent with the current LiveCD toolkits and making it explicit again may help aligning efforts.
[url]http://rarsa.blogspot.com[/url] Covering my eclectic thoughts
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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.BarryK wrote: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.
Cheers
murgaLua development is very different to bash/tcl/c and will attrack a different set of people who otherwise may not contribute ...BarryK wrote: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.
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
Cheers
JohnM
I understand your point. For that reason I have proposed that the murgaLUA runtime executable should be in the Puppy 2.15CE Office edition.JohnMurga wrote: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
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.WhoDo wrote: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
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.
Cheers
JohnM
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.
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.