You are not logged in.

#1 2013-03-04 09:07:21

KCE
Member
From: SoCal
Registered: 2007-06-26
Posts: 41

Too many widget toolkits?

Do we have too many widget toolkits (GTK, Qt, etc.)?

In the context of the KISS principle (I like the pythonic interpretation - "There should be one[-- and preferably only one --]obvious way to do it" tongue), it might be violating the DRY rule and the abstraction principle. On the other hand, it's always good to have choice. Again, in the context of the KISS principle, another toolkit should not be created unless it is necessary. Sometimes too many choices leads to the choice paradox and information overload; we have too many choices for our own good, The answer, depends on what perspective you take...

From the Linux enduser's point of view, they all output the same widgets for the most part (and the dev's viewpoint). The problem for the enduser is they are somewhat forced to choose one if they desire a consistent look. To make matters worse, if they choose one, they may miss out on a program because there is no corresponding GUI.

From the developer's point of view is where the differences are more striking for reasons I'll mention. Qt is developed in C++ and GTK uses C (+GObjects). Qt is an entire application framework. GTK seems to be heading that way - tighter integration with the DE (or bloat...). This is where FLTK and FOX Toolkit come in. However, FLTK and Tk lack advanced widgets. wxWidgets focuses on native widgets. The cross-platform availabilty varies. Then there's freeglut, GNUstep, and so on. Finally, somewhat related, Ubuntu's Unity.

Using their similarities, is there some way we can form a common abstraction layer/interface/framework?

To kind of pull out the abstraction, leaving only the differences needing to be implemented. I think of the way we embrace Linux and the X Windowing System (Wayland is stirring things up) or are we not at that stage yet (no "obvious" solution)? There is the freedesktop organization but it seems limited to protocols. If not cross-platform, at least a common framework on Linux? Not one to rule them all, but one to lead them all.

The underlying issue seems to be that the developers' needs are outweighing the endusers' needs. It's no surprise as UNIX/Linux was developed by developers for developers. Fortunately, as the Linux userbase grows, the enduser is taken more into consideration, like with Ubuntu and VALVE's rejection of Windows 8. It's like two devs arguing in a room over xyz is better, when the enduser walks in and makes the answer obvious, before they can go fork it. This idea of balancing out the endusers and developers' needs, could easily apply to other Linux issues, such as the Linux Desktop, the ever growing number of distributions, package managers, WM/DEs, etc. especially the WM/DEs which from the enduser's POV varies in terms of their integration with other software and services. If Linux was able to unite, it would dominate! Currently, FOSS/Linux's greatest strength is being used as it's biggest weakness sad If only it could turn fragmentation into modularity.

I ask all of this because I may be potentially creating another toolkit, thereby altering the already crowded toolkit ecosystem, though it may be able to bring balance to the force...;)

Last edited by KCE (2013-03-04 10:23:25)

Offline

#2 2013-03-04 09:52:19

Awebb
Member
Registered: 2010-05-06
Posts: 4,331

Re: Too many widget toolkits?

standards.png

Offline

#3 2013-03-04 10:10:55

KCE
Member
From: SoCal
Registered: 2007-06-26
Posts: 41

Re: Too many widget toolkits?

standards.png

KCE wrote:

It's like two devs arguing in a room over xyz is better, when the enduser walks in and makes the answer obvious, before they can go fork it.

Close. It's only missing one thing tongue

Yeah, each dev thinks relative to themself, rather than the implications on the enduser...because who else is going to use Linux? jk lol

Though what really helps a standard become dominant is financial backing...

This blogger also made a good point about the related topic of usability and user-interface design:
http://www.mpt.net.nz/2012/06/why-free- … usability/

See also:
http://www.lambdassociates.org/blog/the … source.htm
http://daringfireball.net/2004/04/spray_on_usability

Last edited by KCE (2013-03-04 10:14:38)

Offline

#4 2013-03-04 10:51:25

Awebb
Member
Registered: 2010-05-06
Posts: 4,331

Re: Too many widget toolkits?

KCE wrote:

Using their similarities, is there some way we can form a common abstraction layer/interface/framework?

What is it to the end user, that makes working with different toolkits difficult? It is themes as well as component behavior. While I was never really troubled by the fact, that GTK and Qt do not respect each others settings (especially: "Text below/next to/instead of icons"), the most annoying thing about those toolkits is the lack of unified themes. I am aware of the fact, that the themes are not even a standardized thing inside one toolkit, as different themes use different engines.

I would not mind if the following happened:
1.1 One tool to configure them all. A script, that knows all about those toolkits, like position of config files and equivalent settings for the same phenotypes.
1.2 Since we're all about -kits these days, I had a look at packagekit and was surprised about the pacman (or libalpm?) support. How about a toolkitkit?
2. A common theme file type. Since most elements of such a theme package are descriptor files, it should not be too hard to interconnect the equivalent lines over the different toolkits. Qt, in fact, already does this, by being able to import the GTK settings. This could be another part of, err, toolkitkit.
3. People should abandon toolkits, that are tied too closely to desktop environments. The number of times I read "change in GTK broke XYZ" over the past two years, for example, is alarming.

Offline

#5 2013-03-04 12:11:23

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,834
Website

Re: Too many widget toolkits?

KCE wrote:

I like the pythonic interpretation - "There should be one[-- and preferably only one --]obvious way to do it"

It's even more simple to have zero.

Toolkits serve a purpose when one wants a fancy gui.  But I am driven mad by all the programs that use a toolkit just to say they did when they have no clear need for them.  They serve only as a banner of support for one of the "brands": the K brand, or the G brand.  All the while Xlib would have done everything they needed just fine.

The problem isn't reinventing the wheel, the problem is buying a shiny new sports car when all one really needs is a wheel.

Last edited by Trilby (2013-03-04 12:11:48)


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Online

#6 2013-03-04 14:37:17

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,476
Website

Re: Too many widget toolkits?

Here are some of my thoughts:

  • A couple years ago when I was ready to write my first GUI application, I was frustrated by all of the different and competing GUI toolkits. I decided I was going to use the native X GUI (I can't remember what it's called). Then I looked at the API, and decided to write a GUI application for the Haiku operating system instead. Also, the nice default Haiku API has pretty much been stable for, like, 15 years now.

  • Using a high level toolkit, such as wxWidgets, that interacts with many different other toolkits is nice, but comes at the cost of only having the option to use the lowst common denominator. Any type of special widgets are kind of hard to make.

  • I recently decided to stop worrying and love the different toolkits. I don't care about having more packages installed or that each application looks a little different, as long as it's well written and does what I want. Also, I think people used to complain that applications on Linux look less consistent than they do on Windows or Mac OS X. I think anyone who thinks that needs to take a step back and look again. All computers look like a mess!

KCE wrote:

I ask all of this because I may be potentially creating another toolkit, thereby altering the already crowded toolkit ecosystem

BURN HIM!

Last edited by drcouzelis (2013-03-04 14:39:12)

Online

#7 2013-03-04 23:07:16

KCE
Member
From: SoCal
Registered: 2007-06-26
Posts: 41

Re: Too many widget toolkits?

Awebb wrote:
KCE wrote:

Using their similarities, is there some way we can form a common abstraction layer/interface/framework?

What is it to the end user, that makes working with different toolkits difficult? It is themes as well as component behavior. While I was never really troubled by the fact, that GTK and Qt do not respect each others settings (especially: "Text below/next to/instead of icons"), the most annoying thing about those toolkits is the lack of unified themes. I am aware of the fact, that the themes are not even a standardized thing inside one toolkit, as different themes use different engines.

I would not mind if the following happened:
1.1 One tool to configure them all. A script, that knows all about those toolkits, like position of config files and equivalent settings for the same phenotypes.
1.2 Since we're all about -kits these days, I had a look at packagekit and was surprised about the pacman (or libalpm?) support. How about a toolkitkit?
2. A common theme file type. Since most elements of such a theme package are descriptor files, it should not be too hard to interconnect the equivalent lines over the different toolkits. Qt, in fact, already does this, by being able to import the GTK settings. This could be another part of, err, toolkitkit.
3. People should abandon toolkits, that are tied too closely to desktop environments. The number of times I read "change in GTK broke XYZ" over the past two years, for example, is alarming.

I thought I mentioned it in the OP, but mainly getting a consistent look besides Qt/GTK, and the availability of programs.

1. Packagekit, if only it supported the AUR, but I like the idea. That's another issue. It seems to me that the main differences among the package managers are 1) source vs binary 2) dependency handling 3) release cycle 4) configurability like make flags. And as a result, varying levels of repo size and program availability. I like pacman because you get the best of all features, although #2 for example, Slackware users would not agree with automatic dependency resolution.

2. Getting the devs of each toolkit to support the others would take some convincing.

3. I agree, although I see why they are tied to desktop environments - because endusers want that consistency. I think that's good but being implemented inefficiently, leading to bloat. Ofc, as you mention, the interdependency means when one thing breaks, everything breaks. What should be included, should be absolutely necessary, but needs are somewhat subjective. Like does the user need all those features? It's always a delicate balance. Linux's availability on so many platforms is a good example of this. Imagine if Xorg had been merged into the Kernel?

Redundancy can be beneficial but in this case it's detrimental. All the toolkit devs are reimplementing the same thing over and over; you could say this about distros - reconfigurations of the same software - such small differences yet an entire distro must be created each time. If there were a more convenient way, wouldn't the person have done it? The purpose of toolkits was so that the developer did not have to manually draw the widgets and event handling etc. We solved that issue but now we have another issue..redundancy at the toolkit level.

Trilby wrote:
KCE wrote:

I like the pythonic interpretation - "There should be one[-- and preferably only one --]obvious way to do it"

It's even more simple to have zero.

Toolkits serve a purpose when one wants a fancy gui.  But I am driven mad by all the programs that use a toolkit just to say they did when they have no clear need for them.  They serve only as a banner of support for one of the "brands": the K brand, or the G brand.  All the while Xlib would have done everything they needed just fine.

The problem isn't reinventing the wheel, the problem is buying a shiny new sports car when all one really needs is a wheel.

This reminds me of something I read, unfortunately I can't find it right now but it's like your ability to not use a GUI determines your hardcoreness lol. Geek culture...flex your intellectual muscle haha

Well, if you were only going a short distance a wheel might suffice...lol

drcouzelis wrote:

Here are some of my thoughts:

  • A couple years ago when I was ready to write my first GUI application, I was frustrated by all of the different and competing GUI toolkits. I decided I was going to use the native X GUI (I can't remember what it's called). Then I looked at the API, and decided to write a GUI application for the Haiku operating system instead. Also, the nice default Haiku API has pretty much been stable for, like, 15 years now.

  • Using a high level toolkit, such as wxWidgets, that interacts with many different other toolkits is nice, but comes at the cost of only having the option to use the lowst common denominator. Any type of special widgets are kind of hard to make.

  • I recently decided to stop worrying and love the different toolkits. I don't care about having more packages installed or that each application looks a little different, as long as it's well written and does what I want. Also, I think people used to complain that applications on Linux look less consistent than they do on Windows or Mac OS X. I think anyone who thinks that needs to take a step back and look again. All computers look like a mess!

KCE wrote:

I ask all of this because I may be potentially creating another toolkit, thereby altering the already crowded toolkit ecosystem

BURN HIM!

I agree about having all the different toolkits but there must be a more efficient way of implementing them - providing more consistency but allowing variation. Maybe I'm wrong...I think awebb had a good point about a common theme file, that'd be a small step in the right direction, but I guess GUIs are too independent.

Last edited by KCE (2013-03-04 23:43:51)

Offline

#8 2013-03-04 23:22:52

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,834
Website

Re: Too many widget toolkits?

KCE wrote:

it's like your ability to not use a GUI ...

This is the second time in the very recent past people have assumed I use/want no GUI simply because I'd like to avoid toolkits.  This is the very reason for my disdain for the toolkits: They've made people believe that gui=toolkit.  This is false.  I most certainly do use a GUI, and many of the programs I write have GUIs; I just don't use additional toolkits as Xlib by itself provides everything I'd want in a GUI.

It is a false dichotomy to claim one must either use a toolkit or be left with CLI only.


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Online

#9 2013-03-04 23:32:52

KCE
Member
From: SoCal
Registered: 2007-06-26
Posts: 41

Re: Too many widget toolkits?

Trilby wrote:
KCE wrote:

it's like your ability to not use a GUI ...

This is the second time in the very recent past people have assumed I use/want no GUI simply because I'd like to avoid toolkits.  This is the very reason for my disdain for the toolkits: They've made people believe that gui=toolkit.  This is false.  I most certainly do use a GUI, and many of the programs I write have GUIs; I just don't use additional toolkits as Xlib by itself provides everything I'd want in a GUI.

It is a false dichotomy to claim one must either use a toolkit or be left with CLI only.

Nah, I didn't assume that. Now, if you said you didn't like using wheels, maybe...lol. Just wondering, what are other types of GUIs besides widgets?

They say the majority of interpersonal communication is non-verbal, in other words humans are visual creatures, so I can see why we rely on GUIs. You could say, currently, communicating with a computer is not any different, until they somehow connect our nervous system to it - mind reading computers yikes

Last edited by KCE (2013-03-04 23:37:53)

Offline

#10 2013-03-04 23:43:35

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,834
Website

Re: Too many widget toolkits?

KCE wrote:

what are other types of GUIs besides widgets?

Xlib itself has many efficient drawing functions.

A couple XDrawRectangle() calls and a properly configured event loop (using XNextEvent()), can do everything a gtk_obnoxiously_complex_function_to_create_button() can do. wink

I've tried both gtk and qt toolkits and could never really get very far.  There are so many levels of abstraction I never felt like I was in control of the program I was writing.  With Xlib I feel like I have much more control.  My feelings on this very much parallel using archlinux over many other OSs: they can do most of the same things, but an arch user has both the control and the responsibility for what the system is doing.

This is my main gripe with using toolkits in coding my own programs.  But the major toolkits also generally drag in an odd assortment of dependencies.  Why do I need policykit to draw a rectangle on a window?  [That's a trick question ... I dont!]

I recently wrote a front end interface to a bit of harware I made for use in a research laboratory.  It had a window with several "checkbox" style toggles, text input and output boxes, progress-bar style meters, and various other components which would often be associated with toolkits, but it was written using only Xlib functions.  And it was shorter than the code needed to create a comparable interface using gtk.

EDIT: for clarity, I don't really have anything against the major toolkits.  What I have issue with is the delusion that they are necessary to have any decent gui.  Just like I have nothing against Microsoft*, but I do have a problem with someone claiming you have to be running the most recent version of Windows to use a computer efficiently.

*(ok, maybe I do, but for the sake of this discussion I wouldn't need to.)

Last edited by Trilby (2013-03-04 23:52:12)


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Online

#11 2013-03-05 00:48:38

Odaer
Member
Registered: 2010-08-14
Posts: 87

Re: Too many widget toolkits?

I thought the prospects for xlib ended with x11?

Offline

#12 2013-03-05 00:53:24

anonymous_user
Member
Registered: 2009-08-28
Posts: 3,058

Re: Too many widget toolkits?

@Trilby - I think the reason people (myself included)  tend to associate a GUI with toolkits, is that a majority of GUI programs rely on them. Also the last time I saw a xlib UI (xscreensaver dialog), it wasn't exactly pretty.

Offline

#13 2013-03-05 00:53:50

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,834
Website

Re: Too many widget toolkits?

@Odaer, Not sure what that means.  X11 was first released in 1987, and has been updated many times with an upcoming update scheduled for this year.  It is what the gui in every major linux and bsd system is based on, and it has found use in many other systems including Mac OSX.

You say its prospects ended with X11 as if that were some odd short lived blip in a history book.

@anonymous_user, the fact that some have made ugly programs without toolkits doesn't mean good ones can't be made without them - nor that ugly programs can't be made with toolkits ... xscreensaver uses gtk.

Last edited by Trilby (2013-03-05 01:05:51)


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Online

#14 2013-03-05 01:32:06

Odaer
Member
Registered: 2010-08-14
Posts: 87

Re: Too many widget toolkits?

@Trilby Okay, not ended but at least you are bound to X11.  In this day when every one  and his grandfather come up with new replacement to X11. I suppose something usable outside of X11 could be desirable.

Offline

#15 2013-03-05 01:37:13

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,476
Website

Re: Too many widget toolkits?

Trilby wrote:

Xlib...

Xlib interests me. Can you please give an example of an Xlib-only GUI application? (or two!) I totally want to experience one. (no sarcasm!)

Online

#16 2013-03-05 01:39:48

anonymous_user
Member
Registered: 2009-08-28
Posts: 3,058

Re: Too many widget toolkits?

Trilby wrote:

the fact that some have made ugly programs without toolkits doesn't mean good ones can't be made without them

I'd love to see some "good" examples, though, I think beauty might be in the eye of the beholder.

Trilby wrote:

nor that ugly programs can't be made with toolkits

Agreed.

Trilby wrote:

xscreensaver uses gtk.

Maybe for the config program. But I believe the unlock dialog does use xlib.

Offline

#17 2013-03-05 02:03:15

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,834
Website

Re: Too many widget toolkits?

There aren't many gui programs that use just Xlib, that's why I'm a bit of an advocate: there could be, but too often when one wants to make a gui, they just assume they need gtk or qt.  For basic examples see any of the programs on my github.

Many of thoes that have "real guis" however have not been posted there for distribution as they are specific to the harware they are meant to control.  I could probably strip one of those down as a demo that could be posted.

EDIT: dwm or just about any of the suckless tools can be used as examples of what it would take from the programmers perspective to do these.  But their tools are generally very minimal in terms of what the user sees for a gui.

Last edited by Trilby (2013-03-05 02:04:51)


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Online

#18 2013-03-05 02:11:20

Grinch
Member
Registered: 2010-11-07
Posts: 265

Re: Too many widget toolkits?

drcouzelis wrote:

Then I looked at the API, and decided to write a GUI application for the Haiku operating system instead. Also, the nice default Haiku API has pretty much been stable for, like, 15 years now.

Well the reason Haiku's API has been stable is because R1 aims for Beos R5 compability, and that API hasn't changed in 15 years. That does not mean that the Haiku devs thinks that the API is great, from pretty much everything I've read in the mailing lists they don't. Ingo Weinhold, one of the core devs wanted to deprecate the Beos api in favour of Qt (personally I hope they rewrite the Haiku API post R1 instead).

drcouzelis wrote:

Also, I think people used to complain that applications on Linux look less consistent than they do on Windows or Mac OS X. I think anyone who thinks that needs to take a step back and look again. All computers look like a mess!

Agreed, while just about every toolkit from Microsoft builds/wraps upon win32, it's a mess there aswell. OSX had the Carbon and Cocoa debacle as far as I know.

As for toolkits in general, I think the simple reason we have so many is because in an open ecosystem like (f)oss in particular, it's simply 'survival of the fittest', and as it stands neither gtk nor qt have emerged as the 'standard'. Again, (f)oss is about choice, and obviously developers exercise that option with regards to gui toolkits.

Now given that after all this time we have yet to see a toolkit emerge ubiquitous, I'd argue that none of the current front-runners (gtk and qt) ever will.

So if someone wants to create their own toolkit which they think is a better fit (to rule them all!) then go ahead, why not ? (good luck though, it's anything but a trivial matter from what I've read)

Offline

#19 2013-03-05 03:05:18

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,476
Website

Re: Too many widget toolkits?

Grinch wrote:

Ingo Weinhold, one of the core devs wanted to deprecate the Beos api in favour of Qt.

I've been following that thread too! I'm really curious what they will decide to do. smile

Even in Haiku there's this strange mix, as you know, where half of the applications use the native Haiku API and the other half use Qt. I'm not sure what to think of it. Maybe multiple GUI toolkits is just the natural way of things.

Oh, well. I, for one, really like the Haiku API, and how every application (used to) have the same look... hmm

Online

#20 2013-03-05 03:38:45

Grinch
Member
Registered: 2010-11-07
Posts: 265

Re: Too many widget toolkits?

Heh, well I do like Haiku. They will need to get alot of ports if they are ever going to be viable as a day to day OS for anything but people with extremely meagre demands, simply because there are practically no native applications being written for it as of now.

Sort of chicken and egg, without applications which make the OS useable people won't use it, and unless (devs in particular) use it they won't start writing native apps for it. So I say Qt ports, Gtk ports etc are very welcome, the important thing is to get people to use the OS at all, then if they like the OS they will likely (if they have the capacity) want to write software which makes direct use of the features that the OS directly offers (native).

I've seen people over at the forums who are against ports and I must say I find that to be incredibly stupid. Hopefully some of Haiku's software deficiencies can be solved with 'cloud' offerings like Google Docs and the likes, but that requires a featured Web Browser and again we are back at needing ports because Webpositive will not realistically suffice.

Offline

#21 2013-03-05 04:22:54

KCE
Member
From: SoCal
Registered: 2007-06-26
Posts: 41

Re: Too many widget toolkits?

Grinch wrote:
drcouzelis wrote:

Also, I think people used to complain that applications on Linux look less consistent than they do on Windows or Mac OS X. I think anyone who thinks that needs to take a step back and look again. All computers look like a mess!

Agreed, while just about every toolkit from Microsoft builds/wraps upon win32, it's a mess there aswell. OSX had the Carbon and Cocoa debacle as far as I know.

As for toolkits in general, I think the simple reason we have so many is because in an open ecosystem like (f)oss in particular, it's simply 'survival of the fittest', and as it stands neither gtk nor qt have emerged as the 'standard'. Again, (f)oss is about choice, and obviously developers exercise that option with regards to gui toolkits.

Now given that after all this time we have yet to see a toolkit emerge ubiquitous, I'd argue that none of the current front-runners (gtk and qt) ever will.

So if someone wants to create their own toolkit which they think is a better fit (to rule them all!) then go ahead, why not ? (good luck though, it's anything but a trivial matter from what I've read)

Well, I guess we keep on making toolkits until we find our winner...*shudders when thinking about the future*

On the other hand, this is what's nice about FOSS - we're not locked in, we can keep removing obsolete features and implement better ones - we can keep on improving, so we're more efficient in that regard.

I know xlib was supposed to be deprecated in favor of xcb. Maybe this will help with understanding xlib:
X-client-libraries.svg

Here's a xaw application:
570px-Screenshot_of_%22Xman%22_program.png

Here's a motif application:
Plan_Open_Motif_screenshot.png

Clearly, the other toolkits were created to overcome the limitations of Xt (I'm not sure what they are?). You might think - then why didn't they just improve Xt? I'm guessing the Xorg founders were staunch followers of the "provide mechanism rather than policy" philosophy, and did not feel this was their responsibility other than to *maybe* provide a very basic toolkit. And I do agree with them.

So the question is when will this happen, if ever? At some point, one should rise to prominence...happens with countries, happens in small groups when someone somehow becomes leader, etc. IMHO, Ubuntu should have stuck with GTK/GNOME but now they're off making Mir...I'll save this discussion for the other thread.

Last edited by KCE (2013-03-05 05:35:17)

Offline

#22 2013-03-05 08:16:47

jakobcreutzfeldt
Member
Registered: 2011-05-12
Posts: 1,033

Re: Too many widget toolkits?

Trilby wrote:
KCE wrote:

what are other types of GUIs besides widgets?

Xlib itself has many efficient drawing functions.

A couple XDrawRectangle() calls and a properly configured event loop (using XNextEvent()), can do everything a gtk_obnoxiously_complex_function_to_create_button() can do. wink

I think the biggest benefit of using a toolkit is the same as that of using any other 3rd party library: to avoid re-inventing the wheel every time you want to write an application. Sure, you can manually draw everything with Xlib, but you're basically recapitulating the same steps every time you do it. Well, you could make some functions like draw_button() and awesome_label(), but then look out, you've created a widget toolkit. The other point is that by using a toolkit, there's only one place to fix interactions with the underlying Xlib code; something in Xlib breaks/changes, Xlib gets deprecated, or you decide you want to change or improve how you handle, say, buttons, you only need to make the change in your toolkit library*. If you do everything manually every time, you have to go through your code from all of your projects and find all the places to make those changes.

* unfortunately, toolkits like GTK+ love to change their API, which means you can end up with the same problem anyway, but that's not a reason to argue against toolkits in general

Offline

#23 2013-03-05 11:42:06

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,834
Website

Re: Too many widget toolkits?

jakob, your second point is a good one, though your footnote is quite right: many toolkit apis change much faster than the xlib api.

The first point, however, doesn't really work for me.  I addressed it above as the contrast of reinventing a wheel versus buying a shiny new sports car ... when all you need is a single wheel.

Reimplementing code that someone else has already made is generally a bad idea because it tends to make the code longer and more confusing, and make the binaries bigger and slower.  In the case of (simple) guis, however, these general trends do not hold.  Reinventing a button can keep code shorter and clearer* than using gtk for example, and makes the binaries smaller and faster.

*Clearer is a bit subjective, so feel free to drop that one if you disagree.


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Online

#24 2013-03-05 11:56:51

jakobcreutzfeldt
Member
Registered: 2011-05-12
Posts: 1,033

Re: Too many widget toolkits?

Trilby wrote:

The first point, however, doesn't really work for me.  I addressed it above as the contrast of reinventing a wheel versus buying a shiny new sports car ... when all you need is a single wheel.

That analogy isn't quite accurate. Buying a shiny new sports car compared to building a wheel seems like a bad choice because it's ridiculously more expensive. When you consider that actually getting a car has the same price as having to build a wheel, and then you have to consider that the wheel needs an axel, and that axel needs some sort of fixtures to the chassis, etc, and then later on you find out you need three more wheels and a drive train (I'm reaching the extent of my automobile vocabulary here), it starts to make a lot of sense to just go with the free car, even if that means you get racing stripes and a spoiler too.

Reimplementing code that someone else has already made is generally a bad idea because it tends to make the code longer and more confusing, and make the binaries bigger and slower.  In the case of (simple) guis, however, these general trends do not hold.  Reinventing a button can keep code shorter and clearer* than using gtk for example, and makes the binaries smaller and faster.

It still seems like a waste of effort to me, though, especially if you do it for every new application that you make. It seems to me that it would at least be beneficial to you to create your own tiny library of bare-metal Xlib widgets so that you're not reproducing your work every time, possibly adding bugs that could be easily avoided and giving others the ability to use the same lightweight solution.

Out of genuine curiosity, how do you handle things like positioning widgets, modifying layout with window resizing, signal callbacks, etc? Because a button is more than just a rectangle drawn on the screen. It seems to me that there's a lot more to re-implementing a button every time than just copying some calls to Xlib drawing routines.

Offline

Board footer

Powered by FluxBB