Puppy Linux Discussion Forum

rockedge wrote: ↑Thu Jun 06, 2024 2:29 pm

Note the part about common set of puppy-specific utilities. Not so sure that idea works nowadays either. How can that be enforced, and would you always want if to be?

That is becoming more or less out of date in ways and too limiting in scope.

As things stand it doesn't seem to be honoured anymore, but I feel many users really appreciated that no matter which Puppy they used, certain core utility/apps were always available (including less than perfect PPM tho that was always problematic so I'd vote for that being optional addon only).

I do think a common set of guaranteed utils/apps remains an attractive feature, so would recommend a discussion on finding an agreed set to always include and particularly for reasonably small util/apps.

A problem, for a long time, is that woof-CE included always certain P_apps by default, and there was no attempt to adopt other sometimes newer and maybe better alternatives that came along. For example, personally, despite its relatively small size, I have really never liked Pmusic (or Pfind for that matter, tho not so bad, but there are so many nicer reasoably small and fast search utility apps around). Pmusic seemed to forever cause problems for me, often leaving zombie processes hanging around and hard to kill. Maybe I am alone with that issue/ dislike. Nevertheless, I'd go with the forum agreed choice (but not just Puppy stewards unilaterally deciding to force their babies via woof-CE onto the rest of Puppy users world).

Similarly, as I've said before, I'd rather like to see KL distros agree a common set of expected core utils/apps (those of smallish size and none of them need to be mine! ). In fact I'd rather like KL to, as far as possible, usually include same agreed set of core util/apps as Puppy choosed to offer, though some differences likely in multi-user supporting KL world.

wiak wrote:

I do think a common set of guaranteed utils/apps remains an attractive feature, so would recommend a discussion on finding an agreed set to always include and particularly for reasonably small util/apps.

Yes.

A problem, for a long time, is that woof-CE included always certain P_apps by default, and there was no attempt to adopt other sometimes newer and maybe better alternatives that came along. For example, personally, despite its relatively small size, I have really never liked Pmusic (or Pfind for that matter, tho not so bad, but there are so many nicer reasoably small and fast search utility apps around). Pmusic seemed to forever cause problems for me, often leaving zombie processes hanging around and hard to kill.

Ok, always possible that there are issues with some custom made apps shared here, then should be fixed of course, but shouldn't be a reason to never support including those apps.

Puppy wouldn't be Puppy without the richness of the apps shared by the community IMO .

fredx181 wrote: ↑Fri Jun 07, 2024 2:59 pm

Ok, always possible that there are issues with some custom made apps shared here, then should be fixed of course, but shouldn't be a reason to never support including those apps.

Indeed, however the apps included were controlled by whatever was provided via woof-CE in latter years and that was mainly those of stewards. Other apps did get included in actual (considered official Puppy releases), but that was the results of remastering after main woof-CE build. Result was the common set of app/utils between different Pup creations was lost as a nice feature of Puppy releases.

In days gone by, pre woof-CE, BarryK decided what to include, but that allowed any forum project to be considered and included (in all official releases) whereas the woof-CE mechanism ended that incentive to produce P-based utilities. Yes, app creators could push to woof-CE, but doesn't happen in practice so Puppy lost out in terms of community participation IMO.

On KLV-Airedale and KLV-Spectr we brought in several very useful utilities from Puppy Linux which work really well in the Void Linux environment.

But a major factor to consider is both of those KLV's carry gtk2, gtk3 and gtk4 with two separate gtkdialog versions with one compiled against gtk2 libraries and the other against gtk3 lib's. To be able to select the correct version needed by these puppy app's the gtkdialog's need to be differentiated.

To do this we have symlinks (gtk2dialog) to target both versions of gtkdialog. This is a workaround to accommodate only having to make minor modifications to the different application's code that utilize the gtk2 to use the correct gtkdialog by replacing the call with the symlink gtk2dialog.

The question becomes is it worth updating the code's syntax to use a newer gtkdialog compiled against the gtk3 libraries and continue using apps designed to use gtkdialog? Some might be able to be converted into using yad or something along those lines.

Look for an alternative for each utility to keep the same types of tools and utilities as possible.

Converting is time consuming and sometimes from the design, not possible.

The dependency on GTK+ 2 in 2024 is really bad. Core projects Puppy and even the other distros here depend on, like gtkdialog, are unmaintained (and some rely on X.Org, which is also deprecated).

Without a gtkdialog port to GTK+ 4 I think it would be best to migrate away from it and anything that uses gtkdialog, instead of migrating all existing gtkdialog-based stuff to GTK+ 3.

Hello @wanderer. Forgive me for weighing in here, but I want to make plain something that I think is obvious. Your prior post, above, reflect completely different build systems used for distro generation (and you missed a couple more). Each build system is unique for good reasons they are used. Build systems in the OS world do not look alike as the objectives at the time of each are/were different. The likes of HP, IBM, MS, Apple... and the list goes on, ALL wrestle with varied build systems within their own walls and have often been either redesigned or combined or replaced depending on ...

Hello @fredx181, I kinda agree with your objection of veing lumped into a category with the animal nomenclature, BUT, as @wiak points to "it is a Brand" and in this world brand loyalty is important for identification and attractiveness. Seems Puppy was started to be attractive to x386/486 users with low ram and low communications facilities. Decade later Fatdog, even later DDog that got characterized as better/bigger Pups; namely mature "Dogs". And now, the community ALSO has KLs. ALL of these landing within the same FORUM walls of the PLDF. This is in addition to the EASYs being built after Barry's Pup departure and re-emergence.

The PLDF community is vast and is a micro-culture of the distros that bears a similarity to the larger Linux Culture reflected in Distrowatch, MajorGeeks and Sourceforge.

In my observation, this topic discussion is surfacing the varied views all of us have on it.

There is no magic bullet solution to either the larger culture or this micro one. We either accept its reality or start a new Brand...aka Linux distro called ??? with its own forum and following that will emerge.

AI is here and we are already late to the real future afoot! I have a multi-year understanding that I am reluctant to share when so many are entrenched in the past. But, as I have seen in my multi decades of life, a new BRAND will surface somewhere with a new understanding of what is useful and consistent with the times.

Hello @dimkr, I have been a proponent for GTK4 for years, but development poop-pooped that then. If started then, we would be years ahead now without development taking the stop-gap with the limited resources it has from year to year. Thus spending resources to go to GTK3 , then turn around to do GTK4, in hindsight...well you know. BTW, this is not seeking a justification which I assume is the same as it was back then, but well its just hindsight on my part when I was considerate of the resource-review needs, back then. This comment is NOT an indictment, rather merely an observation AND a concurrence that going to GTK4 at this time is logical and appropriate. GTK2 must be abandoned as PUPs move into the future. But, it now must also look to abandon GTK3, now, as well as trying to address or fix things in all 3 of these strains an already constrained set of developers and resources.

I'm another who has posted for some years now that we should re-write all useful gtkdialog frontends in a different, stable maintained language. I talked about wishing I had time to re-write my wex screen capture program with probably yad, but since X is basically replaced by Wayland decided long time ago not worth the effort. More generally dabbled in using Lua or Python gui frameworks that became and are available, but smallest, simplest, and the one most devs here have used and are very familiar with remains yad. Forget gtkdialog. Dead.

Most pup frontend utilities are pretty simple. Conversion to yad or similar not difficult at all and a worthy pursuit as part of this forum member hobby.

But yes, needs time, willingness, availability, and effort. Many hands make light work.

Whatever... choosing stable language/gui-framework that is readily available in all our distros would be best approach. Yad is sufficient for most pup utils. Something more capable may be required now and then... Pity PySimpleGUI gone partly commercial but yad ok more generally.

wiak wrote: ↑Sat Jun 08, 2024 12:51 am

Most pup frontend utilities are pretty simple. Conversion to yad or similar not difficult at all and a worthy pursuit as part of this forum member hobby.

But yes, needs time, willingness, availability, and effort. Many hands make light work.

Whatever... choosing stable language/gui-framework that is readily available in all our distros would be best approach. Yad is sufficient for most pup utils. Something more capable may be required now and then... Pity PySimpleGUI gone partly commercial but yad ok more generally.

Ah, typical opensource community... we now also have this: https://github.com/spyoungtech/FreeSimpleGui

we now also have this...FreeSimpleGUI..,,

Installed it and tried out small example python program to show it. Was okay to set up with pip3

@wiak AFAIK PySimpleGUI uses tk, which is X11-only, so it depends on Xwayland, doesn't support fractional scaling and doesn't look 'native'. It basically has all the disadvantages of sticking to GTK+ 2, and more. Python makes it easy to write some things, but maintenance is hard when packages don't support the Python version you have. Python has no compiler that ensures your code is still going to work once you update Python or dependencies.

Both GTK4 and QT-v6 are excellent in a Wayland environment. Each has the advantage of being ubiquitous going forward in the current and the future of this forum's kennel arena of distros. EVERY developer knows one or both of them. And many-many app designers build their apps for these.

wiak wrote: ↑Sat Jun 08, 2024 7:02 am

dimkr wrote: ↑Sat Jun 08, 2024 5:59 am

@wiak AFAIK PySimpleGUI uses tk, which is X11-only, so it depends on Xwayland, doesn't support fractional scaling and doesn't look 'native'. It basically has all the disadvantages of sticking to GTK+ 2, and more. Python makes it easy to write some things, but maintenance is hard when packages don't support the Python version you have. Python has no compiler that ensures your code is still going to work once you update Python or dependencies.

Could be and since you've checked I guess that's the situation. I haven't looked at it for a long time when I was using X. Hopefully it will be developed to use Wayland appropriate technologies, but until then best to use yad or whatever is sufficient for forum distro purposes.

Yes, pity Python is so unstable in terms of upgrade model. Kind of makes it relatively useless when it would otherwise be so useful. I suppose that's why web-based apps so popular or resign to using snaps, flatpaks, or AppImages or similar huge app encapsulating formats.

Edit: but re-checking, PySimpleGUI seems to also support QT tho I dont know the details

Clarity wrote: ↑Sat Jun 08, 2024 6:29 am

Both GTK4 and QT-v6 are excellent

But they're not drop-in replacements: somebody will need to port every application that uses GTK+ 3 to GTK+ 4. It's not easy, and sometimes it's impossible because GTK+ 4 removes some features. You can't just add them to a distro and everything magically starts to support Wayland, fractional scaling and all.

I really do think it would be a good idea to advise forum contributors to avoid further use of gtkdialog. Yad is fine.

@dimkr dont know why you directed your comment to me. I have never suggested what you are trying to tie me to in your post.
'
I am keenly aware that moving from version to version with product lines, does not mean a drop-in. I have never referenced, now or in the past, that as he is attempting to tie me to.

Please EVERYONE understand that I am NOT positioned as he has suggested. That comment is a back-handed disparage.

Clarity wrote: ↑Sat Jun 08, 2024 2:31 pm

@dimkr dont know why you directed your comment to me. I have never suggested what you are trying to tie me to in your post.
'
I am keenly aware that moving from version to version with product lines, does not mean a drop-in. I have never referenced, now or in the past, that as he is attempting to tie me to.

Please EVERYONE understand that I am NOT positioned as he has suggested. That comment is a back-handed disparage.

Hi Clarity, I think you are taking it too much personally, sometimes comments have the purpose just to give (additional) information, no more, so not intended to say that what anyone wrote is wrong.

Clarity wrote: ↑Sat Jun 08, 2024 2:31 pm

I am keenly aware that moving from version to version with product lines, does not mean a drop-in.

Nobody is working on this, but repeatedly mentioning GTK+ 4 and Qt 6 will not persuade anyone to migrate everything in Puppy to these newer libraries. We don't have enough developers even for general maintenance work.

I really have to agree with @wiak here. Where's the sense in going to all the tedious, time-consuming effort of porting gtkdialog when YAD is SO easy to use? Let's face it; if a complete idiot like me can get the hang of using it, there really can't be anything hard about its use......can there??

It's not so "sensitive" to themes, either. I use a range of different themes across the kennels; yes, it's a "given" that it will look different under different themes, but no functionality gets lost due to this. And I'm sorry to say this, but if various folks are THAT concerned about everything looking and behaving exactly the same, well......to me, that's just "nit-picking" in the highest degree!

(Mind you, I've always been a bit "rough & ready"..!! )

For utilities, etc, I see no issue with employing YAD. None at all.

(*shrug...*)

Mike.

YAD is the way to go. It does appear that it is easier to port the existing tools and utilities we all like to see in Puppy's to YAD then anything else.

Python is great but the large overhead and other problems already mentioned make using it to produce GUI's unattractive. Also the code for these utilities would need to be completely overhauled and retro-fitted for python.

Don't get too excited about yad, it doesn't have a GTK+ 4 port and its GTK+ 3 port has strong dependencies on X11 (search the codebase for xid) that need to be eliminated to make it future-proof. It's a much healthier and simpler project compared to gtkdialog, though, and that's the main advantage of yad IMO.

Clearly there is and has never been an ideal alternative to the now no-use-really gtkdialog, but yad will likely continually be developed (I hope); I just hope cherrytree developer keeps that going too - this near or completely sole developer issue continues always in opensource world. Worth keeping an eye on FreeSimpleGUI though - it is nice to use and easy enough. Problem Puppy seems to have had is that it doesn't manage to keep up with Python updates required every so often.

Does YAD require Xwayland to work with Wayland? See: https://github.com/v1cont/yad/issues/15 ... 1110836434

It appears EndeavourOS uses wofi for some small GUI dialogs: https://github.com/EndeavourOS-Communit ... er-menu.sh

rockedge wrote: ↑Sat Jun 08, 2024 5:26 pm

YAD is the way to go. It does appear that it is easier to port the existing tools and utilities we all like to see in Puppy's to YAD then anything else.

People keep saying this. I would like to see an example of a P-app conversion that was more than a few buttons and boxes.

YAD cannot make the likes of the more complex all in one gui windows. Nevertheless, it is enough for many and could use multiple yad windows to replace some complex gtkdialogs. But for more complex gui better to use the likes of freesimplegui, lua uip, or maybe straight gtk or fltk programming like other distros do. There are not many complex util app writers here anyway and they are capable of learning gtk programming; qt more of an issue since C++?

Maybe better is web frontend approaches though. Not meaning electron since thats like full chromium...

I agree also that YAD can never be a full replacement for gtkdialog (yad has many limitations, although some nice gui's were made with it, by myself and others).
Probably impossible to convert properly e.g. Pburn or Pmusic to a yad version, also goes for the Peasy* scripts, I think.

Not sure, but part of me feels glad that I appear to be out-living gtkdialog. I might even manage to out-live Puppy, but no chance any of us will out-live Linux more generally.

Let's be honest about what's happening here. Gtkdialog will never be gtk4. No one is going to rewrite those old gtk2/gtk3 apps in YAD. In a post-gtk3 world, those apps will disappear. Puppy builders should be thinking about how to completely replace their functionality with apps from mainstream Linux, not about dragging all that old home-made stuff along.

I suspect that that's the real agenda held by some Puppy developers. "I don't use any of those apps myself, so they can't be that important, so let's just get rid of them and move on." Fair enough. But when users come looking for those old apps, you should have an answer for them.

Here is my personal opinion. Mainstream Linuxes like Debian will continue to support gtk3 well past its expiration date, just like they did with gtk2. Its quite possible to update the really-old gtk2 stuff to gtk3 and keep it running. I've done it myself. Maintainers like Fred can keep gtk3 apps going by saving the base gtk3 lib packages in their own repo.

rcrsn51 wrote:

Mainstream Linuxes like Debian will continue to support gtk3 well past its expiration date, just like they did with gtk2.

Even up to now, gtk2 (basic) is still supported by Debian, testing and unstable still has it in the repos, but ok, that will change the upcoming years, I know.
So indeed, probably basic gtk3 will last for years and years, I expect that too.

The consensus about YAD's inability to handle "complex" GUIs is fair comment. My own forays into using YAD are all pretty simple affairs anyway; very basic GUIs, just the necessary controls/functions/buttons. Deffo no frills. But I can live with that, because it usually achieves what I want.

With the exception of my desktops - which ARE quite "busy"! - in many other ways I'm something of a minimalist when it comes to functionality & design. Don't see the point of incorporating "extraneous" controls that are only requested/wanted by a handful of users.

Although I hate to admit it, Bill's comment about the need to incorporate the sort of utilities, etc, that are used by everyone else hits the nail on the head. Puppy's been out on a limb for long enough, with our pride in doing things differently to everyone else meaning we've kept all those old home-grown utilities around for probably way too long.

Many of those were born in a time when hardware capabilities were far less than they are now.......and while there ARE still a few of those kinds of machines still around - for which Puppy was originally the "best fit" - many of us have naturally migrated to more powerful and capable hardware as it saturates the second-hand markets at affordable prices.

Mike.

Some of the Puppy in-house applications

mikewalsh wrote: ↑Sun Jun 09, 2024 2:06 pm

our pride in doing things differently to everyone else meaning we've kept all those old home-grown utilities around for probably way too long.

IMO some of them are really bad and optimize for the wrong thing. An audio player written as a shell script, with gtkdialog for UI, can be super small on disk and fast to start but slow to respond and much heavier than a "binary" one like deadbeef. The choice of shell script as the implementation language means most operations are handled by running a process or even multiple processes, making it a CPU and RAM hungry application that freezes often (it doesn't react to a second click while it waits for a command-line to finish). Rewriting such applications with yad won't solve problems like their single-threaded nature, but most of them have alternatives that are bigger on disk (because they're not shell scripts) but not huge, and consume fewer resources at runtime. A usable OS is so big these days, to the point a slow 100K music player is a very tough sell compared to a 5 MB one that doesn't have the same problems.

These applications made much more sense in <2010, in times where replacing coreutils with busybox reduced the size of distro by >1%. Replacing 'big' applications with a shell script made sense, too.