>> Well, maybe they shouldn't actively dissuade people from filing bugs by
>> making it so sodding hard to file a bug? :-P
>
> It *isn't* hard.  I've filed many bugs over the years, and it isn't the
> oh-so-difficult process you seem to think it is -

The account setup process seemed tortuously difficult to me. I spent a 
full two weeks trying to work around the problem before I finally gave 
up and tried to file a ticket.

> based on exactly ZERO experience doing so.

Zero experience?

Perhaps you're missing the part where I actually *did* all this to file 
a bug (which, last I checked, is still open). Basically Zypper gives you 
an incorrect error message - but apparently Zypper just tells you what 
Curl tells it. So until Curl gets fixed...

>> You know what's *really* annoying? Seeing an open bug for THE EXACT
>> PROBLEM that our production application has, seeing that upstream has
>> fixed it, and yet OpenSUSE refuses to release an RPM for it. *That* is
>> annoying! (We're talking about a different bug now. The ticket has been
>> open for many months. The fix is literally to build a new RPM. Yet it
>> isn't happening...)
>
> Example?  Because for that bug, I'd like to nudge someone, or at least
> find out why.

In OpenSUSE 13.1, systemd hangs for 60 seconds on shutdown. It's waiting 
for... I forget what it is now, but after 60 seconds it gives up and 
shuts down anyway. It just means every time you want to shut your PC 
down, you have to needlessly wait 60 seconds before it does it.

The bug is fixed in systemd 209 (?), but the latest official RPM from 
OpenSUSE is 208, which doesn't contain the fix. (There was some talk 
about the upstream "fix" being a bit of a kludge... I'm not sure exactly 
how true that is. I just want the bug to go away.)

Somebody filed a ticket. Somebody else said "here, try this RPM and let 
me know if that fixes it". The original poster never let anybody know if 
it worked. Ticket is currently set to "waiting for information" or similar.

>>> Not sure what you mean by "show task list option".  What was the
>>> specific thing you were trying to do?
>>
>> The option to have an icon for each window that's open, so you can
>> instantly switch between windows (or just tell when a hidden window
>> closes itself). You know, like the Windows taskbar.
>
> Oh, like the dash-to-dock extension gives you.  Yeah, that extension is
> one that I use, and it works great.

I, too, eventually found an extension that could be configured to behave 
in a suitable manner. It just annoyed me that this is some unsupported 
3rd-party hack, rather than part of the basic functionality of the shell.

>> Well, I don't know man. Version 2 of a product has a heap of features
>> which are gone in version 3. To be, that means that version 3
>> *objectively* has fewer features. I didn't think there's much to argue
>> about that...
>
> I used GNOME2, and I use GNOME3.  Both did the job I needed, so I don't
> really care if there are "fewer features", because features I don't use
> are unimportant to me.  Hence, personal preference.

I would have thought "seeing what windows are open and moving windows 
around" is a pretty core functionality to a window manager. But 
apparently your mileage is different...

> So no, you didn't ask for help, yet you complain about not being able to
> get help.  That's telling.
>
>> In seriousness: I asked on Stack Overflow. The question was upvoted
>> several times, and many other people lamented the utter lack of any
>> documentation. But nobody actually answered the question. Which is what
>> happens when nobody knows the answer!
>
> One venue, where GNOME development isn't a primary discussion topic, does
> not mean "nobody knows the answer".  Except in your world, it would seem.

Stack Overflow is only the single largest place to get help about any 
programming problem you might have. If not one single person who 
happened upon a GNOME question explicitly flagged with the GNOME tag 
knows how to do a thing, it can't be that well-known. (And if it *was* 
well-known, surely there wouldn't be so many people up-voting the 
question. Rather, they'd be saying "dude, read the manual, it's right 
here!")

>>> And "deleting code from the running system" isn't the same as extending
>>> it.
>>
>>    From what I've seen, you write extensions by deleting existing objects
>> and replacing them with new ones. (Or maybe just replacing a method or
>> two.) You'd think it works by creating a new object that exposes a
>> defined set of operations, and passing that to the framework. But no, it
>> seems you just put your hands in the framework, rip out the bits you
>> don't want, and then replace them.
>
> Overriding is not the same as "ripping out the bits you don't want and
> replacing them".  You should know that from your study of OOP methods.

Thing is, when you override a method, you're not destroying the old 
implementation. You're creating a new class that works differently. 
Anybody using the old class still gets the old behaviour. This is 
different; you're dynamically deleting the code from the system while 
it's still running - potentially even while somebody is trying to *call* 
that code!

I mean, it *works* and all... It just seems like a pretty scary design.

>> And then watch it all break horrifyingly in the next minor-release of
>> the shell.>_<
>
> If you refuse to find the right venue to ask for help, then you kinda get
> what you deserve there.

I'm talking about all the extensions that *other* people wrote which 
break on later versions of the shell. (My own extension actually 
survived - mostly because it barely does anything.)

>> Still, IMHO, I think most of this brokenness goes back to "we decided to
>> build a huge, complex application in a scripting language". All problems
>> flow from there.
>
> Now there's something I might be able to get behind.

Somehow I doubt the GNOME foundation are going to change it tho. ;-)

Post a reply to this message