GTK2 Enhancement Request

[SamK]

Request shared-mime-info+deps be included (it is in the tcz version).  I suspect that on systems that use both gtk2.scm and gtk2.tcz the omission goes unnoticed.  It is readily apparent when only the SCM is used.


Edit: typos

[Jason W]

It seems to be already in there.  I may need to export XDG_DATA_DIRS in the wrappers of gtk2 apps.  Which gtk2 app is affected so I can test?

[SamK]

Which gtk2 app is affected so I can test?

Rox-Filer shows it up well.  Try opening a directory containing some graphic images.  Ensure Rox has thumbnails activated.  When useing shared-mime-info, each image file is displayed as a thumbnail of the original.  Without it, only a generic icon is displayed.

[AmatCoder]

Sorry for noise, but I have a question related to this issue...

Why scm extensions are mounted in read-only mode? This prevents commands as update-mime-database or gtk-update-icon-cache under /apps...

[Jason W]

I believe that squashfs is a read only filesystem once the image is made.

But symlinks can and are used in these cases to /opt/scm/pkgname to allow write access.  I will make one for the mime data and the icon cache.

[AmatCoder]

Ok, I see...thanks for that.

Another case could be gschemas.compiled under ../share/glib-2.0/schemas/
That is used by applications that saved settings using GConf or dconf (gsettings).
glib-compile-schemas is the command that generate it.

[Jason W]

Ok.  So far three commands and resulting data directories that are to be dynamic to accommodate various apps that will use gtk2.scm.  As well as some of that data residing in the directory of the app itself.  This is of course the down side to having a separate gtk2.scm extension.  And I will make adjustments for those commands to be used and the data to be generated.

A separate gtk2 means faster startup and less RAM used, but with the above complications.  Including gtk2 in an app directory means any needed data aside from fontconfig files can be static as it can be generated once and is not needed by any other programs.    Midori has apparently been broken by an update to gtk2.scm, breaking extensions is another risk with the separate gtk2.  I will fix and support gtk2.scm but I admit that I am beginning to lean toward a more fully self contained approach for stuff that I package.

[Rich]

Hi Jason W
I'm, probably just stating the obvious but, as I understand it, the point of SCMs was the ability to easily mount and
unmount extensions at will and eliminate extension breakage due to dependency updates. The price for this being
larger packages, longer downloads, and greater disk and RAM requirements by the user. The other price that comes
to mind is if one of the built in dependencies needs an update, say for a security fix, then all the SCMs using that
built in dependency may need to be rebuilt. For all practical purposes, a tcz is just the opposite.

While I understand your desire to create an SCM architecture that is the best it can be, this hybrid approach sounds
like you are fighting two conflicting goals in an attempt to get the best of both worlds. That only works if the package
styles share a common attribute you can leverage, which doesn't sound like the case.

Kind of reminds me of a car commercial I once saw that claimed "exhilarating acceleration" and "phenomenal gas
mileage". The two don't co-exist in reality.

In any case, just some thoughts on my part and thanks for all of your contributions.

[SamK]

...greater disk and RAM requirements by the user.

This sparked a recall of a comparison done shortly after the introduction of SCMs.
http://forum.tinycorelinux.net/index.php/topic,12457.msg67531.html#msg67531
When used from persistent TCE storage, greater RAM usage seems to be more of a theoretical than practical issue.  I have not studied the matter to a great extent, but where SCMs have been adopted here, there has not been a noticable increase in RAM usage or an observed deterioration in perfromance as a result.

A separate gtk2 means faster startup and less RAM used...
...breaking extensions is another risk with the separate gtk2.
...I am beginning to lean toward a more fully self contained approach for stuff that I package.

For me, the principal attraction of the SCM format is its resistance to breakage.  If that resistance can be improved, without a corresponding increase in the RAM required, it will be at least worth exploring. 

[Jason W]

At this point I agree that the middle of the road approach is making the SCM less valuable than going "whole hog" and leveraging the advantages of total self containment.  If we are dealing with one scm being broken by an update of another, like in the case of Midori, then we have lost the "just works every time" advantage of the SCM.  Also if commands are needed to be run inside the package of one SCM, like gtk2.scm, to make another one like rox-filer.scm work, we lost the advantage of less complexity. 

I have started experimenting with fully self contained SCMS in the last week or so, and to be honest I was expecting criticism of it based on the RAM and download/storage space angle.  Of course, optional large packages like python and perl can remain just that.  I am glad that the current seems to be to go ahead and just make SCMs outright and not try to stay in the middle of the road to please all.  Those that don't use SCMs are not going to use them whether they are factored and more efficient or if they are not, so why water down the concept. 

The totally self contained packages made of recent are a test of concept and are likely not the final road to be taken in terms of internal structure or source, and of course all input is welcome.

[Rich]

Hi SamK

This sparked a recall of a comparison done shortly after the introduction of SCMs.
http://forum.tinycorelinux.net/index.php/topic,12457.msg67531.html#msg67531

That does not invalidate my statement. I believe that test was not a straight SCM vs tcz comparison, rather a hybrid vs tcz
comparison. The 24Mbyte gtk2.scm was likely already in existence and being used. See several posts prior to your link:
http://forum.tinycorelinux.net/index.php/topic,12457.msg67488.html#msg67488
If that's the case, it would make the SCM numbers look better than they would if they were totally self contained.

[SamK]

Hi Rich

That does not invalidate my statement. I believe that test was not a straight SCM vs tcz comparison...

I'm not going to chase this particular wraith.  It will take the discussion even further away from the topic.  I'll simply make the following observations and then park it.

It should not be interpreted as an attempt to invalidate your statement or a challenge to your beliefs.  The accompanying description was an attempt to convey my (unmeasured) experience of using SCMs.  In real-world usage over a reasonable period of time, this has been that the demand for RAM has been broadly neutral.  In terms of RAM usage (when using persistent TCE), I have not encountered an empirical constraint on a range of otherwise redundant hardware.

The idea of moving further towards full self-containment is at the test of concept stage.  It is likely to undergo modification and refinement during the exploration. Pesently it is unclear what, if any, the end product (including RAM usage) will be.

[Rich]

Hi SamK
Sorry, in hind site, that "invalidate" statement came off as confrontational. That was not the intent.
My final observations:
Change-log in gtk2 SCM shows it existed at the time of the test.
Had the gtk2 apps been true SCMs
    They would have occupied more disk space
    The would have used more RAM due to multiple copies of the libraries being loaded