On Sat, Feb 24, 2001 at 04:10:50PM +0000, Nick Lamb <njl98r@xxxxxxxxxxxxxxx> wrote:
> Thanks for demonstrating what you meant about people criticising something
> without knowing anything much about it, Marc.
I don't get it.
> is running Gnome ICU please go over and start up a conversation (anyone
> running a toy solely designed to let strangers send them silly colored
> messages won't be annoyed if you come over and talk to them) and while
Oh, I regularly annoy him by telling him how childish icq is.
> you are discussing the shortcomings of Gnome, check out the icon in the
> panel which was created and used by Gnome ICU.
I know very well what's causing this.
> Now, when an application calls a Gnome API function which has the sole
> purpose of creating a panel icon, and there is no panel, what should
> it do Marc?
No need to get personal. It should fail, since there is no
panel. Obviously the user thought something when she didn't start it in
the first place.
> I mean, this isn't some hacker Perl script, so probably
It's not perls fault that you didn't understand it ;)
> isn't an acceptable response for a desktop user. Gnome ICU calls such
> a function, and so GNOME creates a panel for it. Stop the FUD.
Which FUD? I think it is much less acceptable for a desktop user when some
program starts a lot of other programs the user expcliticly didn't ask for.
Otherwise they would be running already. This is of course not the only
example of unhealthy automatisms in gnome.
Nick, please, all personal grieves aside, my point was not that this is
clearly undesried behaviour, there is no point arguing it. BUT: the AUTHOR
of gnome-icu simply couldn't know this. He/she just called some of the
hundreds of api functions, completely oblivious of the fatc that this
function does a lot more than he/she ever expected.
"registering an icon" by no means should result in clobbering the desktop
screen. the unix philosophy is KISS, thus programemrs always go after the
principle of least surprise: "no panel, no icon, i can ignore the error or
not". gnome-icu does NOT depend on that icon in any way.
And this is what I meant by bewilderung API: functions that no longer do
what users expect them. Big, complex functions with a lot of automatisms
that often surprises their users. Also, look at windows: most of the
problems there have their origin in these "big" functions that result in
very complex behaviour the user neither wants nor the porgrammer could
expect. It's just too difficult to be safe.
And this is what I meant: be critical vs. "let's all be flashy" since this
often results in "doh, yet another little, annoying bug".
> ObVaguelyOnTopicAside: Maybe we should be able to provide something
> that you can use Gimp properly without X (not at build time, but..)
> during the 1.3.x GUI/ core separation process. Such a process could
> speak CORBA and thereby eliminate our existing gimp-wire i18n bug
The dependence on X has nothing to do with the wire protocol or CORBA. In
fact, CORBA would only be a difefernt API to the API(s) we currently have
to do this job. CORBA also wouldn't solve this problem: getting rid of the
X dependency would do it.
AFAIK gimp only requires x for fonts at the moment. Since there is
freetype, it should be possible (I'm not gtk+ expert) to get rid of this
last dependency. Making gimp a proper library would help much more than
using CORBA (CORAB is by no means more reliable as a transport protocol
than, say, the perl-server).
This reminds me of some other discussion: I was told that the OSD (open
softwrae description format, a package description format in xml in wide
use) would be much less suited for the job than some standard format
(namely RDF). This is just another misconception: OSD _uses_ XML as
underlying language. XML is *not* a software package format in itself. The
same is true for RDF: the (non-existing) RDF-based OSD-format _uses_ RDF
as underlying language. Saying that RDF is better suited than OSD is just
like saying that CORBA is better suited for transferring webpages than
HTTP: A domain viaolation (i.e. apples vs. oranges).
Now, RDF sounds like a cool "standard" (it is neither astonishingly cool,
given what researchers came up to represent complex relationships, but it
is certainly the best that ever escaped the research labs, NOR is it a
standard in any way), which made this guy think it mst be the solution for
everything. Yes, A formulation of OSD in RDF would probably _be_ the best
solution, such a thing doesn't currently exist, nor is it used. Cooking
up something new (based on a "standard" like RDF) just "looked right" for
him. That, in fact, this would be even less standard than the xml-based
OSD did never occur to him.
So again, I just plea for critical thinking before a decision is made
without actually deciding.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
