Moving to GTK+3 or elsewhere for Puppy!

Under development: PCMCIA, wireless, etc.
Post Reply
Message
Author
scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

Moving to GTK+3 or elsewhere for Puppy!

#1 Post by scsijon »

Moderators: Not sure if this is the correct spot to put this, but?... It will need monitoring!

THIS is a Discussion Topic, it's not for rants and raves! If you can't keep your temper and be 'nice' online don't add a comment. A monitor or Moderator WILL remove it!

--------------------------

Having 'listened in' on a online discussing group a couple of evenings ago, I consider that this has an outcome that may affect us so i'm writing about it. I don't attampt to hold punches on my thoughts about the whole subject, but don't expect me to name anyone, etc., it just won't happen!

It's just a basic set of comments from the meetings outcome on what I think we need to deal with in the near future (or sooner since we have time in 'lockdown' mode).

--------------------------------------------

With the end of gtk+ or gtk2 (it was EOL as of 2400hrs 31 December 2019 and extended by one year to allow 'conversions'), there are many still using it. However the group supposidly 'controlling its use' have started putting pressure on package builders/mantainers to move across to at least gtk+3 (gtk3 series) if not prepare to use the new gtk+4 due for first release later this year (about the same time as gtk3.8 appears). There has already been a few notices to a couple of gtk+ patch creators that they were neither approved or allowed to be added, that's how far they have taken it at this point. Packages that only have gtk+ versions and those creating new packages have apparently been asked to 'upgrade'. That is apparently how serious it is becoming.

Then the question for Easy, Quirky and Puppy builders and the various ofshoots is how much work will be needed to move across, or do we consider moving to another model, such as wayland/weston or musl/clang/llvm style systems, instead?

-------------------------------

And from here i'll leave it to you, i'll also monitor and when necessary or need requires comment if I can.

User avatar
666philb
Posts: 3615
Joined: Sun 07 Feb 2010, 12:27
Location: wales ... by the sea

#2 Post by 666philb »

bionicpup64 already has a mix of gtk2 & gtk3 apps and in fossapup gtk3 apps maybe outweigh (no pun intended) the gtk2 apps.

rox-filer would probably be the main casualty for us, but lots of small projects may disappear

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#3 Post by 01micko »

Lets look at the pros and cons of moving to gtk+-3

Pros
  • is necessary because (nearly) all up to date browsers depend on it (see cons)
  • gtkdialog supports it somewhat
  • removes the need to carry 2 gtk+ (2 and 3) toolkits
  • much up to date software depends on it (abiword, gnumeric, evince etc)
  • we do need to move forward
Cons
  • limited (read 'deprecated') support for tray status icons
  • major browsers depend on it
  • support for menu icons is deprecated (WTF?)
  • much more heavy on resources than gtk2
  • uses CSS (cascading style sheets) for themes instead of simple 'rc' files plus needs much more comprehensive icon themes.
  • ROX will likely never have gtk3 support. Probably the same can be said of mtpaint, gftp, leafpad, didiwiki, sylpheed(?) and many other staple gtk based apps in puppy.
My thoughts.

I tend to agree that we do need to move forward but at limited cost. The tray status icons are probably my biggest beef. While most will still compile in gtk3 (with appropriate modification) they do not look and function as well as built against gtk2. The replacement is appindicator which doesn't even support tooltips. For crying out loud! XP had 'balloons'! :!: (a 20 YO OS almost - yes 20 )

Gtk3 is more bloated with stuff we'll never use. Or will we? It does indeed have better touchscreen support builtin. I doubt that touchscreens as we know them even existed when gtk2 was drafted.

One day I intend (yes have lots of intentions but they are inversely proportionate to my time :roll: ) to build a gtk3 only pup to see how it goes. Don't hold your breath!
Puppy Linux Blog - contact me for access

ozsouth
Posts: 858
Joined: Fri 01 Jan 2010, 22:08
Location: S.E Australia

#4 Post by ozsouth »

There is some very interesting discussion on gtk from 2 of our guys at the link below (is after first 4 comments).
https://github.com/wjaguar/mtPaint/issues/23

enrique
Posts: 595
Joined: Sun 10 Nov 2019, 00:10
Location: Planet Earth

#5 Post by enrique »

Please just tell me, this is not a crisis or a mayor road block. It just same corporate thinking stupidity. Expecting that ALL will move to new and scrap all old programs just because a so called decision maker think so.

I understand is like everything else. We are force to have all installed, gtk, gtk2, gtk3, etc. Nothing new, Same as all other script. Take for example today most use I guess python. We have to have python 2 and python 3 installed there is no solution for this?

1 script language can become dangerous as it can be used to be hacked. So, then we are force in a situation to have multiple varieties of same script language, as is one was not bad enough.

This is like good vs evil. Instead rich vs poor. The rich say, give me the best to the garbage the rest. But the poor can not do that, so it try to survive by having a mixture. And as 90% of the people are not rich, there you have it. most old technology have a destiny to survive.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#6 Post by 01micko »

@ozsouth - yes interesting. No doubt @wjaguar is a skilled technician and will move appropriately in the future.

@enrique - don't worry too much. I doubt gtk2 is going anywhere soon, but there will come a point (hopefully in distant future) where bitrot sets in and it will be unlikely that many gtk2 programs will cooperate with underlying system - at which point I'll move to BSD :P
Puppy Linux Blog - contact me for access

enrique
Posts: 595
Joined: Sun 10 Nov 2019, 00:10
Location: Planet Earth

#7 Post by enrique »

But gtk3 survive with gtk2. Or I am missing something.
I am almost sure I have both at busterdog and Puppy bionic.

In any case current Puppy will survive. I do not want to move agan. I did this on October last year from Ubuntu to Debian. Well this was very easy.

Note:
OHH I see topic title read GTK+3! "+" meaning after 3 as we all know GTK=GTK+

I read a little and found no warning on gtk3 vs gtk4 problem with coexistence. As a Puppy user that is what is important. At most we use gtkdialog to improve our bash scripts.

* Puppy users do not normally write high intensive screen display programs like let say a game.

*A Master Puppy usually adapt current available programs to its derivative of Puppy.

** But as a Graphic Program Developer truly can encounter trouble learning how to do its busyness in a new way. Only if its app deal with graphics. But most programmers do not get affected, all is transparent as it will depend on the tools he use for programming. It is the tools the ones that may need updates. But this has nothing to do with Puppy. 99.9 of Puppians users will not see any issue. Just another application to add.

I see the duplicity on gtk, gtk2, gtk3 & gtk4 but not a reason to move from Puppy. As a Puppian why do I have to move to BSD or else? What is what I am missing?

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#8 Post by nic007 »

Who's using the latest Seamonkey on Puppy Linux? It requires GTK+3.

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#9 Post by peebee »

and then there is also Qt5 (>15MB as minimum)..............!!!!

My approach as recorded in my system Notes FWIW:
6. Dependencies
This Puppy Linux build does NOT include some large infrastructure components which may be dependencies of some extra add-on applications. For instance it does not include GTK+3, Qt5, Perl, Python, SystemD, PulseAudio or any SQL database. Some of these dependencies may be found in the devx (e.g. Perl, Python & SQL database). Some dependencies may be available as add-on .sfs files (e.g. Qt5) or may be included in application .sfs files (e.g. GTK+3 in webrowsers Chromium & Firefox). Some dependencies may be available to install via the PPM package manager.
In particular, the browsers I provide as .sfs include "enough" GTK+3 to function as is required (c. 8MB out of typically 50MB or greater).

Other Pup system builders take a different approach and include GTK+3 and Qt5 in their iso...... horses for courses..... but I guess users need to know what they're getting..... hence my System notes.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#10 Post by wiak »

Most small distros rely on upstream repos, so when, as happens, the upstream distro stops supporting something altogether then, for these upstream repo reliant distros, that is the end of it. PyGTK, for example, is long deprecated so the PyGTK-based cherrytree hierarchical notetaker is currently no longer available from official Arch repo (and I think maybe not in latest Ubuntu either). Two Pythons is certainly a bit of a pain.

Once upon a time we all mourned the loss of GTK+1, with similar comments about how much less of a resource hog it was, but hardly anyone uses that at all now, and 128MB RAM computers are pretty much redundant now too (I had a few Pentium 3 class machines, but one by one they broke down anyway).

Nowadays, I stick to my Intel Core 2 Duo machine, from 2008, which until recently had 2GB RAM, which I've upgraded to 4GB. It continues to perform admirably for me. Its original 128 hard disk failed and I've replaced that with a 128GB SSD I bought for US$20 from China

So I run WeeDogLinux Arch64, which is no Puppy in size, being 1.5GB by default - but it is very resource friendly in terms of RAM usage and CPU and 1.5GB is next to nothing compared to the 128GB SSD size. And of course many a Puppy user expands their system out of all proportion to the original download size via sfs or dotpet addons or huge save files/folders... Hard disk storage space is irrelevant unless you are really running whole system in RAM (which wastes a lot of valuable RAM in the process and hardly speeds anything up nowadays - old slow harddrives is also a thing of the past).

Whatever may be may be - I'll just adapt accordingly. Anything else eventually just becomes nostalgia.

I wouldn't mind jumping to GTK +4; that's not the problem as I see it - rather its some of my favourite apps not being prepared to make that jump, but there are always alternatives - best to look for them now.

Small distros who want to encourage easy programming/apps/utilities could do worse than adopt (GTK +2 or GTK +3): https://sourceforge.net/projects/iup/
It is just as easy to use as gtkdialog or yad (and has very similar easy widgets to both of these, but far more powerful if you need it) - I demonstrated it some years ago by making a quick fork of fredx181 gifenc-gui program (which fredx181 wrote using yad) - pretty similar number of code lines - just as simple in fact.

http://murga-linux.com/puppy/viewtopic. ... 877#988877

wiak
Last edited by wiak on Sun 28 Jun 2020, 12:05, edited 3 times in total.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#11 Post by wiak »

accidental double post cos using GTK +2 instead of GTK +1

ndujoe1
Posts: 851
Joined: Mon 05 Dec 2005, 01:06

#12 Post by ndujoe1 »

I understand about moving to GTK3. The software world has always been a moving target, and never stays in place. So like several others here have mentioned we must move along.

Although, I am sad that the transition to these new forms give rise the bloated size of software development. The original puppylinux was small, efficient and did what we needed beautifully. I will miss that going forward.

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#13 Post by wjaguar »

ndujoe1 wrote:I understand about moving to GTK3.
Once more, proof that ignorance is bliss. :)
Any such move, if started now, is destined to still be in progress, or in a sorry alpha stage, just as the upstream makes the happy jump to GTK4 and breaks everything every which way yet again.
If you believe that the 3-to-4 transition will be in any way less catastrophic than the 2-to-3 one, read this and weep: https://developer.gnome.org/gtk4/stable ... -to-4.html
If you expect the newer fashionabler GTK+4 to quickly reach an usable state, abandon all hope: GTK+3 had reached the feature parity with GTK+2 as required by mtPaint only in version 3.12, for crying out loud, and the more-newer-and-shinier-toy is now being made by the very same "let's release now, make it work a decade later, but break things every year" guys.

Actually, the only workable solution to the present churn is decoupling programs from GUI toolkits. My V-code is just one example, a compact solution for a compact binary; if you look at how Mozilla or Open/LibreOffice do things, you'll see a complete homegrown GUI toolkit built into either, and only painting itself into a surface lookalike of GTK+ (or Windows UI, or whatever) through plain old bitmap manipulation (and therefore, Seamonkey's "abandoning GTK+2" is about forcing users to be alpha testers, not any hard technical reason: none such can arise there in principle).

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#14 Post by wiak »

wjaguar wrote:Actually, the only workable solution to the present churn is decoupling programs from GUI toolkits.
Which is how it 'should' be (but perhaps easier said than done).

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#15 Post by wjaguar »

wiak wrote:Which is how it 'should' be (but perhaps easier said than done).
One person, half an year: most part of designing, implementing, and transitioning to V-code (while redesigning it on the fly). One person, one month: adding a GTK+3 backend to V-code, with all the investigating and working around the bugs, incompatibilities, and plain craziness that entailed.
As compared to GIMP transitioning to GTK+3... for how many years already? While GTK+ itself is transitioning away from it in the meantime.

Also, with the solution being in fact "a toolkit above toolkit", there already exist projects that fill the niche: the "native widget toolkits", such as wxWidgets and IUP:
https://wxwidgets.org/
http://webserver2.tecgraf.puc-rio.br/iup/
Using them or similar for new projects instead of using GTK+ directly, should protect programs from planned bitrot.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#16 Post by wiak »

Oh I see you like IUP too. Works on most platforms, and as easy to code as all the so-called 'simple' script GUI frontends we use here. I'm surprised IUP hasn't had more exposure - I'm a real fan - if I was doing much more app/utility programming I'd be using it, but I'm not really planning much more in that direction, but would love to see it being adopted rather than almost certainly obsolete bash/gtkdialog efforts.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

#17 Post by mikeslr »

Just lightly following the discussion.

For possible use with IUP I wanted to bring Cherrytree's Code Box and the many languages supported to your attention, Sections 7.5 and 8.3. https://giuspen.com/cherrytreemanual/#_ ... ghlighting 8.3 discussing the Code Box mechanism.

IUP appears interesting and flexible, http://webserver2.tecgraf.puc-rio.br/iup/:

"Availability
The library is available for several compilers:
GCC and CC, in the UNIX environment
Visual C++, Borland C++, Watcom C++ and GCC (Cygwin and MingW), in the Windows environment
The library is available for several operating systems:
UNIX (SunOS, IRIX, and AIX) using Motif 2.x
UNIX (FreeBSD and Linux) using GTK+ (since 3.0)
Microsoft Windows XP/2003/Vista/7 using the Win32 API"

Does the above line suggest only a Windows limitation? Or is the Linux version also stuck in 32-bit?

enrique
Posts: 595
Joined: Sun 10 Nov 2019, 00:10
Location: Planet Earth

#18 Post by enrique »

Win32 API => Win32 code that runs as 32 bit under the WoW64 emulator

Beware that tools have "Version" too and that from time to time your code will too have to deal with changes as well.

I do not have knowledge on IUP, Now I am a small user of wxWidgets. This is opensource, And the way I deal is be recompiling same old version. And we force to submit our old version share libraries with our programs.

As for QT you know story for now we have mostly to leave with QT4 + QT5 libraries.

I am please to count wjaguar I believe developer of mtPaint. And I hope to understand his position on dealing with the big task he face. But how many graphic developers Puppy have? This is not a Puppy Issue but of Linux and other OS. This is why they get Huge in size.

I can give you a sample in waist disk space. My brother just gave me a Temperature Data Logger. Its Windows support Installation software is 500MB. I bet you it uses 1 GB of space. WHATTT!! 1 GB of used disk space, to download data from a device. A device I may use once in my life. I bet you once I found out I can download the data in less that 10K script file. And our gnumeric can display its data with almost 0 space.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#19 Post by wiak »

I haven't compiled IUP for a long time, but these slightly older compiled for use with gtk+2 dotpets (32bit and 64bit) could at least get you started probably:

http://www.murga-linux.com/puppy/viewto ... 611#987611

Note that I'm no longer maintaining these though, so not sure whether they'd work with latest Lua or not.

Easiest to learn for some programmers on murga forum is probably from the comparison with yad and gtkdialog scripts I did here:

http://murga-linux.com/puppy/viewtopic. ... 818#988818

I included several posts above and below that with exemplars.

wiak

Post Reply