[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Gnome configuration (was: Re: Congrats! [gnome font rendering])



On Fri, Jan 17, 2003 at 11:54:54PM +0100, Emile van Bergen wrote:

> Ok, I'll drop it. But I wasn't trolling. I am truly, honestly
> disappointed with the direction in which the Free Software GUIs are
> going.

I wonder what would happen if someone build a toolkit which 
exported wrapper interfaces for all of the common ones in use: 
gtk, qt etc. I wonder whether or not that would be at all 
possible, too. The result of this would of course be a more 
consistent look and feel, and would give you one library to 
concentrate on optimising, not two or more.

> I never got much into writing GUIs for Unix stuff, even though I did
> lots of it on DOS, using my own toolkits. It's just too big, fat and
> ugly. Xt is, with that ugly X resources model. Motif is (was). XForms
> is. Qt is. Gtk is. And all of them take complete charge, leaving you a
> tiny corner of the framework to put your application into. You may ask
> the toolkit kindly to call some application routines if something
> happens, but the toolkit is what's in control. You figure out where you
> can keep your state yourself. And all of them try to reinvent parts the
> OS, badly, polluting Unix' elegant model of small APIs, of processes and
> IPC.

I haven't started working with Unix GUI tools, but I am 
interested in doing so. I am concerned about what you are saying.

> If Unix' IPC features are to primitive for GUI components, then let's
> work on that. But let's not drop the concept of standard, well thought
> out data messages between applications and switch to COM or Corba all
> the way, so that interfaces can be as wide as convenient. That's just
> not the Unix (or the internet) way, IMHO. That's the Windows (or telco
> standards ;-)) way. If we need a new kind of pipe for the 21st century,
> then let's build one. But please let's not toss Unix' model. It's not
> needed.
> 
> Even with what Unix currently offers, I think GUIs can be done
> differently. 
> 
> What if applications could use simple terminal I/O to build their GUIs,
> talking to a new, extensible type of graphics terminal? Why end that
> good, proven, concept at the VT520 and the Tektronics? 

Someone has mentioned SDL, and although I don't personally know 
if SDL fits this model, it is worth investigating. I think 
different GUI methods are an area worth exploring.

> At least the programming model for GUI applications could regain some
> sanity. It is patently absurd, and there is no /real/ excuse in my
> opinion other than the endless layers of abstractness to hide broken,
> complex programming models, that we need gigahertz machines simply for
> wordprocessing and webbrowsing these days, and hack upon hack (see
> prelinking) to keep the mess perform a little.

This annoys me a lot. Programs that I have been using without 
much trouble (e.g. pan) start using gtk2 with its lovely anti 
aliased fonts, but they crawl like a tortoise! I was thinking 
perhaps the libraries beneath need to be optimised for my machine 
(AMD K6-2) but thats quite a lot of work to just continue doing 
what I have been for a while.

Some apps that I use however seem to be well thought out, and I'm 
worried about library feature creep killing those too. At the 
moment, I am enjoying galeon immensly. gv isn't likely to be 
ruined by library changes, but I thought it deserved a mention as 
it is such a good piece of software to use!

> So sorry if this rant comes across as trolling, but it is an honest,
> heartfelt emotion here. I'll stop bothering you people with it now and
> will try to refrain from commenting on GUI topics here, until I've got
> some code to show.

I'd be interested to see what solutions you come up with :-) If 
you know of any groups who are doing some thinking in the area 
of GUI improvement, please drop me a line.

-- 
Jon Dowland



Reply to: