Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
GUI libraries
09-19-2013, 06:54 PM
Post: #1
GUI libraries
Ran across this page at the Connochaetos wiki:
http://www.connochaetos.org/wiki/deli:archive:devel:ltk
It discusses lightweight toolkits and tries to come up with the best to use for low resource computers. The conclusion of the article was to create a small gtk library replacement that would be gtk 2.x compatible but lighter.

I've been investigating the issue for a while now as well. Considering my own personal design decisions, I did not come to the same conclusions as the article.

First, the article is a bit dated now, so building a gtk 2.x compatible library would not be as useful since most gtk applications are moving to gtk+ 3. There was a reference in the cinepaint project to creating a library compatible to gtk+ 2 using fltk. Don't know how far this project got and haven't been able to find the source code for it. Would have made a good starting point if the goal was gtk+ 2 compliance though.

Second, the article mentions drawbacks with lighter toolkits and names FLTK and Fox. I agree with the issue mentioned that there are far more options for heavier libraries like gtk and qt. However, one doesn't always need large quantities of programs. What I personally prefer is the quality of the programs. So, to me, a few very useful lightweight applications that do a particular job well would be preferable to having access to lots of programs many of which I'd probably never use. The second objection was that there are multiple incompatible versions of these libraries. However, you have the same issues with gtk moving from 2 to 3 and qt moving from 4.8 to 5.1. If one knows which versions of a library the majority of applications work with, one can narrow down the selections by choosing it. If some applications don't work with a particular version, they can usually be ported to work with a specific library version. The last comment was that using several lightweight libraries takes up more "memory" than using one heavyweight one. I can see where this might consume more hard drive space. However, looking at speed at which the application responds and RAM, I don't see any statistics to support the theory that running several applications built from one heavyweight toolkit is more efficient than running several applications built with multiple lightweight toolkits. I've done some timing tests and found that running several applications based on efficient lightweight toolkits is more responsive on a low resource system than running several applications built with the same heavier toolkit. I think one might get a memory advantage if running something as a daemon (which some terminal programs do). However, this is typically not the way many applications run.

From the existence of the article, I think there's evidence that there's a need for something better than what's currently out there. I'd be very interested in finding alternative GUI projects that can fill the gap or possibly working to create one. Finding the right combination of existing lightweight GUI libraries and useful applications built with them could also be a viable solution. Would be curious to hear what others think about the topic in general.
Find all posts by this user
Quote this message in a reply
09-20-2013, 11:47 AM
Post: #2
RE: GUI libraries
Hi.
Instead of creating a new toolkit, I would see a contribution to the currently available toolkits as the right way.
Maybe it would be nice to create a library that would act as an unified interface to the well known toolkits. That means it would be switchable between the GTK, Fltk, Qt and their different versions. It would support only the most common features which are available in all of them. But it's hard to guess if this is esily doable.
Visit this user's website Find all posts by this user
Quote this message in a reply
09-20-2013, 12:51 PM
Post: #3
RE: GUI libraries
Speaking as a programmer, creating a GUI library that lets you switch back end toolkits would be more difficult than creating a new GUI library from scratch or trying to create a library with an API compatible with another library. If you use wxWidgets, it does make use of GTK as the back-end. However, other wxWidgets ports are available to X, nano-x, directfb, etc. I've tried them and they don't appear to be very stable. Was unable to build the key wxWidget based applications I needed with them. SDL gives a choice of X or directfb, but I often find the directfb version crashes with specific applications. So, just based on looking at the success of current GUI libraries in switching their back ends, it isn't an easy task. You will see more of this type of thing going on in the near future with the advent of Wayland. Some of the more widely used GUI libraries are going to try to support that as well as an X environment. However, if one becomes more popular (such as if Wayland or something similar ever becomes more common than X at some point), I wouldn't be surprised to see some X support going away.

If you want common user interface features and want to be able to switch between ncurses or X or GTK+ or FLTK or other libraries, the easiest way to do that is with tools like dialog. It does mean the interface is a separate application from the program you want to run. These types of tools also typically vary in their API, so one would have to use code to deal with that. I believe I've mentioned before, I've been using patched browsers in place of programs like dialog. They provide a common way to draw controls on a screen (using HTML as the standard). One could use any modified browser or web engine. I currently have the technique working in console mode and in X.

As to contributing to current GUI libraries, I believe I've contacted just about every one out there (except possibly qt). I've submitted patches to GTK+, Enlightenment, FLTK, SDL and others. Many of them are very negative about that sort of thing and don't want the outside help. So, I've had no luck with that route. One either uses the libraries out there as is or forks them if they won't work as is. If one is forking, then one has to take into account whether to upgrade all the changes to the next version that comes out or stay with the current version. Many of the GUI libraries keep upgrading in ways that aren't backward compatible, so either the applications need to update to work with the latest version or again, one needs to stay with a frozen version of the library. Some very good applications may not be currently in development, so one would have to port them to a newer GUI library version to get them to continue to work after an upgrade. Unless you use a technique like only working with applications that are actively developed (which many Linux distributions do), the whole situation can get very tricky. With distributions that are useful for low resource systems, always using actively developed applications may not necessarily be the best solution.

To me, the easiest route is to go with efficient, well written GUI libraries rather than large bloated ones. That way, if one needs to fork or modify something, it's easier to build and maintain. The trick is finding which libraries out there are the most efficient and easy to maintain if they need to be forked. With the lighter GUI libaries, I don't see one library doing it all. However, even if I was running a heavyweight library, I'd still be using command line and console applications.

I really don't see a best case solution as this point. I've examined the pros and cons extensively and, as I mentioned, am interested in how others perceive and deal with the situation. I'd certainly be interested in adding my efforts in working toward a good solution if a project with those goals was under development and welcomed contributions.
Find all posts by this user
Quote this message in a reply
09-22-2013, 10:44 AM (This post was last modified: 09-22-2013 10:47 AM by tavvva.)
Post: #4
RE: GUI libraries
(09-20-2013 12:51 PM)lmemsm Wrote:  creating a GUI library that lets you switch back end toolkits would be more difficult than creating a new GUI library from scratch or trying to create a library with an API compatible with another library.

I never said it's easy :] However, there's a good chance, that such toolkit switcher could have pretty low memory consumption. But even of that, I don't believe it would get popular enough to make upstream maintainers write a support for that.

(09-20-2013 12:51 PM)lmemsm Wrote:  If you use wxWidgets, it does make use of GTK as the back-end. However, other wxWidgets ports are available to X, nano-x, directfb, etc. I've tried them and they don't appear to be very stable. Was unable to build the key wxWidget based applications I needed with them.

Last time (=pretty long ago) I tried to write some wxWidgets based installer, it was a bit challenge to make a usable result. Those days I decided to create my own toolkit (called tavvvax) just for fun.

tavvvax screenshot:
   

But as I'm looking at the wxWidgets homepage right now, it seems the project is in much better condition these days.

(09-20-2013 12:51 PM)lmemsm Wrote:  SDL gives a choice of X or directfb, but I often find the directfb version crashes with specific applications.

... this is very probably caused by bugs in the applications.

(09-20-2013 12:51 PM)lmemsm Wrote:  So, just based on looking at the success of current GUI libraries in switching their back ends, it isn't an easy task. You will see more of this type of thing going on in the near future with the advent of Wayland. Some of the more widely used GUI libraries are going to try to support that as well as an X environment. However, if one becomes more popular (such as if Wayland or something similar ever becomes more common than X at some point), I wouldn't be surprised to see some X support going away.

If you want common user interface features and want to be able to switch between ncurses or X or GTK+ or FLTK or other libraries, the easiest way to do that is with tools like dialog. It does mean the interface is a separate application from the program you want to run. These types of tools also typically vary in their API, so one would have to use code to deal with that. I believe I've mentioned before, I've been using patched browsers in place of programs like dialog. They provide a common way to draw controls on a screen (using HTML as the standard). One could use any modified browser or web engine. I currently have the technique working in console mode and in X.

Unfortunately tools like 'dialog' have a limited set of usecases if you don't want to hack your app too much. And that would probably lead to usability penalties.

(09-20-2013 12:51 PM)lmemsm Wrote:  As to contributing to current GUI libraries, I believe I've contacted just about every one out there (except possibly qt). I've submitted patches to GTK+, Enlightenment, FLTK, SDL and others. Many of them are very negative about that sort of thing and don't want the outside help. So, I've had no luck with that route.

It always depends on the upstream members and their mood. Vanity and ego plays a major role here and I must admit it's sometimes pretty difficult to convince them. If you make someone angry, it usually leads to his unwillingness to cooperate in the future, so ... one must be very cautious when communicating.

(09-20-2013 12:51 PM)lmemsm Wrote:  One either uses the libraries out there as is or forks them if they won't work as is. If one is forking, then one has to take into account whether to upgrade all the changes to the next version that comes out or stay with the current version. Many of the GUI libraries keep upgrading in ways that aren't backward compatible, so either the applications need to update to work with the latest version or again, one needs to stay with a frozen version of the library.

Flexible projects use autotools to stay compatible with different versions of the libraries even if they change the interface.

(09-20-2013 12:51 PM)lmemsm Wrote:  Some very good applications may not be currently in development, so one would have to port them to a newer GUI library version to get them to continue to work after an upgrade. Unless you use a technique like only working with applications that are actively developed (which many Linux distributions do), the whole situation can get very tricky. With distributions that are useful for low resource systems, always using actively developed applications may not necessarily be the best solution.

If the application/library works like expected, then there's no reason for changes. Some maintainers are unable to realize, that it has no sense to tweak a simple 'hello world' application forever. Even if the application is more complicated, than just the 'hello world' one, some point where the application doesn't need any changes always exists. The need for changes is usually only triggered when any of the dependencies changes the API or if you want to add new features.

(09-20-2013 12:51 PM)lmemsm Wrote:  To me, the easiest route is to go with efficient, well written GUI libraries rather than large bloated ones. That way, if one needs to fork or modify something, it's easier to build and maintain. The trick is finding which libraries out there are the most efficient and easy to maintain if they need to be forked. With the lighter GUI libaries, I don't see one library doing it all. However, even if I was running a heavyweight library, I'd still be using command line and console applications.

I really don't see a best case solution as this point. I've examined the pros and cons extensively and, as I mentioned, am interested in how others perceive and deal with the situation. I'd certainly be interested in adding my efforts in working toward a good solution if a project with those goals was under development and welcomed contributions.

I personally like GTK+2 (with Cairo) and FLTK 2 ... I was able to build a high quality and art flavoured presentation software for galleries in GTK and small footprint applications in FLTK. Both toolkits are pretty usable. We'll see what happens in the future.
Visit this user's website Find all posts by this user
Quote this message in a reply
09-23-2013, 12:53 PM
Post: #5
RE: GUI libraries
(09-22-2013 10:44 AM)tavvva Wrote:  ... this is very probably caused by bugs in the applications.

In the cases I mentioned the bugs were in the GUI toolkits. wxWidgets even says that it doesn't provide complete support for certain platforms like X (without Gtk).

(09-22-2013 10:44 AM)tavvva Wrote:  It always depends on the upstream members and their mood. Vanity and ego plays a major role here and I must admit it's sometimes pretty difficult to convince them. If you make someone angry, it usually leads to his unwillingness to cooperate in the future, so ... one must be very cautious when communicating.

Something similar could be said for projects that are asking for volunteers. If they ask for help but aren't nice about it, people won't feel like freely giving their efforts to the project. This becomes a detriment to Open Source efforts.

(09-22-2013 10:44 AM)tavvva Wrote:  Flexible projects use autotools to stay compatible with different versions of the libraries even if they change the interface.

There are other techniques besides autotools. Also, a tool is usually only as good as the person using it. I've tried several projects that use autotools and they just fail to work properly for certain platforms.

(09-22-2013 10:44 AM)tavvva Wrote:  If the application/library works like expected, then there's no reason for changes.

If you need an application to perform a certain function, you can write it from scratch or start with an Open Source code base and modify it to meet your needs. Supposedly, code reuse is encouraged in the Open Source community. Plus, the original project might be able to make use of some of those modifications. I find myself making patches and changes to the majority of applications I use in order to use them effectively to get specific job dones. Working as expected and doing the job you need done in an efficient manner are typically two completely different things.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)

Contact Us | DeLi(cate) Linux | Return to Top | Return to Content | Lite (Archive) Mode | RSS Syndication