Enemy projects

Puppy related raves and general interest that doesn't fit anywhere else
Post Reply
Message
Author
akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

Enemy projects

#1 Post by akash_rawal »

I recently read about dbus' poor performance, while searching for an easy to use IPC library for my next projects. I hence decided against dbus and instead started an attempt to write an equivalent with minimum overheads aimimg for maximum achievable throughput.

Yet I see most of the software projects using dbus for their IPC needs!

Do you know other libraries that run slower than they should be? That way I can avoid using them in my next projects. I spend most of my time in studies so I don't have this knowledge.

About a month back I tried wayland in precise puppy, trying drm output locked up entire OS. I thought weston-launch will start it properly, but it required pam. After installing pam and building weston with weston-launch, starting weston-launch flatly says "Permission denied." even when I was root. And till the end I couldn't get it working.

Recently I tried to get upower working so that shutdown/reboot options may appear in lxde-logout (The first thing I do when setting up a new puppy is compile and install LXDE). But upower requires policykit which ultimately failed to build.

I also see some negative attitude towards pam, policykit, udisks and upower right in this forum. See http://www.murga-linux.com/puppy/viewto ... 599#621599, http://www.murga-linux.com/puppy/viewto ... 634#657634.

So is this because it is difficult to get policykit and pam working? Or is there some other issue I must know? I am keeping a multiuser but small and lightweight OS in mind.

Just a few moments before I searched "gtk3 criticism" in google. and ultimately found this: https://trac.transmissionbt.com/ticket/3685. Is there really anything like a war of breaking compatibility between gnome and lightweight desktop environments? Are gnome guys doing it purposefully or is it an unwanted side effect?

Admins, feel free to reposition the post as required, I am myself unsure whether this is the right place to post.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#2 Post by amigo »

udev, systemd, dbus, *Kit for starters... followed by gtk2, gtk3, qt*...

lmemsm
Posts: 51
Joined: Wed 27 Jun 2012, 15:01

#3 Post by lmemsm »

Do you know other libraries that run slower than they should be? That way I can avoid using them in my next projects.
Finding alternative libraries is a great topic. There was a very similar discussion on the musl mailing list about lightweight alternatives. You can check the list archives to see what was covered and what alternatives were suggested.

When trying to compile gettext, I noticed it pulled in several libraries used by gtk+ such as glib, libcroco and libxml2. That's fine if you're using gtk+ on your system, but it's a lot of unneeded dependencies for those who don't use it. I decided to find an alternative lighter implemention for gettext. There are several out there and I think I'll end up combining code from a couple of them to get a minimal working alternative. I'm testing something for this now.

Pkg-config is another program that pulls in a glib dependency and not only that, it's a circular dependency. I've switched to pkgconf instead and it has worked just fine for me as a replacement.

I'm attempting to use only lightweight GUI libraries on my system and intend to avoid gtk+ and other hefty libraries. I don't know anything about the breaking compatibility issue for Gnome/Gtk+3, but I did find the gtk+ developers rather hostile when I reported an issue and included a patch for it. I'd prefer to use Open Source software where the developers are at least polite about receiving patches. I hope to be able to stick with sdl, ncurses/pdcurses, fltk and command line based applications. Am currently looking into finding replacements for any applications I use that require other GUIs that don't fit the lightweight classifcation or don't work well on low resource machines.

Will be interested to see if anyone else has suggestions for avoiding slower libraries or for other useful alternatives and hope too see a post on how the dbus alternative worked out.

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#4 Post by akash_rawal »

amigo wrote:udev,
Thanks for mentioning it :)

Gentoo devs are forking off udev for a more stable device manager. Their efforts could be beneficial to puppy too.
amigo wrote:*Kit for starters...
Did you mean policykit? or more?

I don't seem to find any problems with policykit on the web, other than difficulty in setting up (and again I wonder if it is just me).

I am interested in technical details.
amigo wrote:followed by gtk2, gtk3, qt*...
If both GTK and QT are bloated what should we use?

GUI libraries are almost always very large library and it isn't feasible for a lightweight distro to have all libraries in hand.

Writing/using an alternative doesn't seem to solve all problems, especially when the library is large. :(
lmemsm wrote:... but I did find the gtk+ developers rather hostile when I reported an issue and included a patch for it. I'd prefer to use Open Source software where the developers are at least polite about receiving patches.
I was just going to ask whether someone tried to improve gtk.

That isn't open source in true spirit then.

And add to it the problem of large libraries.

That's really ... :cry:
lmemsm wrote:hope too see a post on how the dbus alternative worked out.
My work isn't compatible with dbus. I think that its API and object finding algorithms are the overheads most of the time.

The work is slow, because I am a slow person myself :lol: , it will probably take more than few months I think.

I aim for features, ease in learning, and most importantly near-socket performance.

lmemsm
Posts: 51
Joined: Wed 27 Jun 2012, 15:01

#5 Post by lmemsm »

If both GTK and QT are bloated what should we use?
I've been collecting a list of alternatives, but GTK and Qt are usually the two most popular and most well-known. WxWidgets is nice, but unfortunately, the POSIX ports typically use GTK+ underneath. There are versions that work straight with X11 or other options, but they don't seem to be fully supported. As mentioned, I've been looking at applications built with ncurses/pdcurses, SDL and FLTK. I just posted about Fox Toolkit in a related post to this forum. A few alternatives that got mentioned on the musl list when the topic of non-bloated libraries came up were AntTweakBar and Agar. There's an alternative to SDL called SFML. Some other options are Ultimate++, POCO, OWLNext, V GUI. Also, GUI libraries like SDL can work with DirectFB to run outside of X Windows (so can pdcurses). Some GUI libraries like FLTK will work with X alternatives like nano-x. Factors like internationalization and whether or not a GUI library can handle themes can also come into play when choosing a specific library. Fox Toolkit and FLTK had limited internationlization support, but newer versions are adding some features to help with that. There are also some patches to FLTK at their web site to add a few extra themes, but themes aren't as configurable as with alternatives like GTK+. Thought it might be interesting to see if programs using a Win32 API could be compiled directly on Linux using microwindows or Winelib. Haven't had much luck with it yet, but it would make a useful GUI alternative.
That isn't open source in true spirit then.

That's nice to hear. I've been hitting issues like this a lot lately and I know of at least two other projects that weren't very happy about and weren't too polite about receiving patches. I'm hoping to simplify my system down to the point where I can avoid projects like these.
My work isn't compatible with dbus. I think that its API and object finding algorithms are the overheads most of the time.

The work is slow, because I am a slow person myself , it will probably take more than few months I think.
Hope you'll keep us informed of the progress anyway. Something doesn't necessarily have to be compatible to make a useful replacement for the functionality. A few months or more is still pretty good. One of the projects I'm working on is taking years. Good luck with your project.

bark_bark_bark
Posts: 1885
Joined: Tue 05 Jun 2012, 12:17
Location: Wisconsin USA

#6 Post by bark_bark_bark »

i like both gtk and qt. Why a need for non-standard alternatives?
....

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#7 Post by Ted Dog »

Where is Sage, still compiling a list... Never met a project he could have liked. :shock:

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#8 Post by sunburnt »

Ted Dog; Yowsa.! Sage does have a critical eye, it usually means they`re aware...

GTK+ is for Gimp and nothing else. They don`t care about other uses ( no docs.).

QT is aligned with Gnome - Ubuntu now that they`ve dumped GTK+.
Ubuntu seems to be on the road to becoming a non Linux compatible O.S.

My hope is that a real GUI tool-kit will be made that runs on top of X.
And some serious rewriting of X is in order. It`s become a patchwork quilt.!

lmemsm
Posts: 51
Joined: Wed 27 Jun 2012, 15:01

#9 Post by lmemsm »

I like both gtk and qt. Why a need for non-standard alternatives?
If you like them both, by all means, use them. You'll probably never need alternatives. As to what one is calling standard, who's defining that standard? I don't recall anyone saying any particular GUI is a standard on a Linux system. For Windows, Win32 was the standard. There may be recommended GUIs for particular desktops (usually what the desktops are written in), but I don't recall there being one standard desktop for Linux either. The nice thing is that we have several choices available for these options.

I believe Gnome is written using GTK+ and KDE is done with Qt. There's also an interesting lighter desktop alternative using Qt called Razor.

The reason I'm personally interested in GUI alternatives to GTK+ and Qt are because both libraries are rather large and resource intensive. I want something more lightweight that works well on systems with low resources. Also, I've already tried reporting an issue to GTK+ and I feel they are not open to contributions or patches from me. I would prefer to work with a project that is open to me sending them contributions and improvements.
Ubuntu seems to be on the road to becoming a non Linux compatible O.S.

My hope is that a real GUI tool-kit will be made that runs on top of X.
And some serious rewriting of X is in order. It`s become a patchwork quilt.!
I got the impression Ubuntu doesn't think it will make much more of a dent in the desktop market and that they're going after the large and growing phone and tablet/touchscreen market. Moves like possible replacement of X with Wayland seem to make more sense for that market.

I certainly hope X development continues to improve and that there continues to be competition among GUI libraries so that people can have better choices as to which they prefer.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#10 Post by amigo »

Some of us are still holding on to GTK+1 which is not large and has few dependencies. It's the only lightweight toolkit for which there exist a broad range of programs. It does have it's disadvantage -especially vis-a-vis usage with non-english locales. It can use utf8 fonts, but bi-directional text is a no-go.

A couple of us have even managed to back-port a few favorite GTK+2 programs for use with GTK+1.

FLTK has lots of disadvantages -the chief one being that there are no more than a dozen programs existing for it.

GTK (all versions) and QT *do* 'run on top' of X.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#11 Post by sunburnt »

amigo; I know that... :wink:

I was mainly referring to Ubuntu`s Wayland as opposed to X.

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#12 Post by akash_rawal »

Using alternative libraries every time can mean bloatware for a distro that aims to be small as they have to bundle all of them.

For large libraries like GUI libraries I still think attempting to improve existing libraries can be more beneficial.

I have this plan in mind.

I could start an experiment to find what works fast and small, and what not. I would cover all aspects of a typical GUI library from rendering and event handling to low level event loops and object frameworks. I would publish my findings somewhere and at most I'd just send the gtk developers a link to follow.

Others could benchmark it and maybe post their inventions too. I hope that gtk and qt devs might incorporate some aspects into their libraries that would make it faster and smaller.

This could go on for years maybe. If the devs are still unresponsive then by that time I would have a good idea what a good GUI lib will look like. I will then write my own cross-platform GUI library which is much faster and smaller than gtk and qt.

There's nothing to hide, the entire idea will be public.

If gtk devs are only driven by popularity, they can think they might lose popularity if they didn't incorporate these ideas.

The idea behind this plan is that I don't want to see the open source community getting fragmented over issues that can be solved.

At least some sort of unity is a must.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#13 Post by sunburnt »

Hi akash_rawal; Don`t kid yourself about any interest in your suggestions.
Many many folks have suggested much to many others, with little response.

GTK+ folks aren`t into popularity, they`re into themselves ( Gimp ).
And QT is now under the wing of the Gnome project.

Looking at the GTK+ libraries they amount to little more than 10 MB in size.
It`s hard to say if that could be improved upon, and size doesn`t matter.

I`ve looked at lots of apps. made with different tool kits, some work better.
Even in Windows I noticed the behavior of controls from different tool kits.
Windows has the best controls in general, but there`s room to improve.
Look at the fltk folks to understand the difficulty of making it all from scratch.
And as amigo pointed out, GTK+ and QT are about the only common tool kits.

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#14 Post by akash_rawal »

sunburnt wrote: Many many folks have suggested much to many others, with little response.

GTK+ folks aren`t into popularity, they`re into themselves ( Gimp ).
So, it seems impossible to avoid fragmentation :(

I would rather test the alternatives mentioned by lmemsm.
sunburnt wrote: And QT is now under the wing of the Gnome project.
I don't find anything like that, except small ideas in ubuntu forums. Or I am entering wrong terms in google search.
sunburnt wrote: Looking at the GTK+ libraries they amount to little more than 10 MB in size.
It`s hard to say if that could be improved upon, and size doesn`t matter.
GTK+ outsources rendering to cairo and pango. I think you should include them too.

Distro builders must be knowing more about this.

If it is still small then why should we consider it a bloatware?

Does there exist any benchmark specifications to examine the performance of a GUI library? I don't see any slowness associated with GTK, or my computer is very fast.

I hate GTK+ only because I find it is very difficult to extend. Last time I tried to create a container widget from scratch. It was an ordeal, I finally ended up searching in GTK+ source code and lots of trial and error before I got it working. Hardly anything was documented regarding that.

User avatar
NeroVance
Posts: 201
Joined: Wed 10 Oct 2012, 23:00
Location: Halifax, Canada

#15 Post by NeroVance »

I'm gonna be a jerk and suggest Motif, since it's LGPL'd.

Hell, I'd totally run CDE on a multi-user Puplet, and if I can find stuff for development on Motif, and perhaps decent wrappers for modern programming.

It's old, but with a bit of elbow grease, it could get some functionality that could be good.

Post Reply