For over 10 years now I've been a satisfied Firefox user.

Today I finally got fed up with its extreme slowness, and tried to 
install another browser.

I think the thing that really drove it home was that the other day I 
happened to fire up an old VM that's running Firefox 5. It was *so much* 
faster! I could actually look at Google Maps in *realtime*! Not with a 
30-second pause every time I scroll or zoom.

Anyway, I tried Google Chrome, but it *insists* that you have to "log 
in" to allow them to track your movements - er, I mean, synchronise your 
devices. Yeah, that. But more to the point, Hotmail became 
*catastrophically slow*. (I presume this is perfectly intentional.)

So I installed Opera, and I've just spent about an hour trying to force 
it to work the way *I* want it to work, not how it tells me I should 
work. I still haven't found a way to get rid of the annoying Speed Dial 
feature, but at least I managed to force it to give me the Home button 
back. It was trivial to import my bookmarks, but obnoxiously hard to put 
them back on the bookmarks toolbar where they belong. (Assuming you can 
get that to display in the first place.)

I couldn't help noticing how the Opera settings pane looks almost 
pixel-for-pixel *identical* to the Chrome settings window. That seems 
highly suspicious. I also couldn't help noticing that, like Chrome, it's 
extremely anaemic in terms of options and settings. (Indeed, I tried 
Chrome several years ago, and promptly uninstalled it due to the 
complete lack of configurability and features.)

This seems to be a worrying trend. GNOME 2.x had a sea of configuration 
options. GNOME 3.x has almost *nothing*. In order to change anything, 
you have to install user-supplied "extensions". (Oh, did I mention? 
There's no documentation for how to write these extensions. You just 
have to read the source code. Because that's trivial...) It seems 
software producers have somehow got the idea that it's OK to produce a 
product with no configurability, and let a dozen different 3rd parties 
write a dozen mutually-incompatible "extensions" each of which solves a 
different 30% of the problem.

Seriously, you managed to implement a standards-compliant rendering 
engine! That's nearly impossible!! How hard can it be to add a trivial 
GUI for editing the frigging settings?!

(Indeed, judging my various Internet searches, it seems Opera used to 
have a magic URL that leads to a low-level settings dialog, similar to 
what Firefox has. So they removed it. Now the URL just redirects to 
their dumbed-down configuration GUI that won't let you configure 
anything. Good work, guys.)

Having said all that, browsing the Internet is now *drastically faster*! 
Like, I clicked the satellite view on Google Maps and *didn't* have to 
wait 5 minutes for all the bitmaps to load. You can literally scroll 
around the entire planet, zooming in and out, in actual *realtime*. Even 
in satellite view!! And don't get me started on how much faster 
scrolling is in Facebook...

The first time I logged into Hotmail, it was spectacularly broken. (As 
in, none of the CSS loaded, rendering [hah!] the page almost unusable.) 
I have no idea why. It seems to work fine now.

Not completely sure how I'm still logged in to Stack Exchange, even 
though I'm using a completely unrelated web browser...

Who knows? Maybe with another week or so of tinkering, I can force Opera 
to work *almost* the way I want it to...

Post a reply to this message

Am 16.03.2015 um 21:08 schrieb Orchid Win7 v1:

> This seems to be a worrying trend. GNOME 2.x had a sea of configuration
> options. GNOME 3.x has almost *nothing*. In order to change anything,
> you have to install user-supplied "extensions". (Oh, did I mention?
> There's no documentation for how to write these extensions. You just
> have to read the source code. Because that's trivial...) It seems
> software producers have somehow got the idea that it's OK to produce a
> product with no configurability, and let a dozen different 3rd parties
> write a dozen mutually-incompatible "extensions" each of which solves a
> different 30% of the problem.

Judging from some stuff you posted about Haskell libraries a while ago, 
shouldn't you be familiar with this? :P

Post a reply to this message

On 16/03/2015 08:18 PM, clipka wrote:
> Am 16.03.2015 um 21:08 schrieb Orchid Win7 v1:
>
>> This seems to be a worrying trend. GNOME 2.x had a sea of configuration
>> options. GNOME 3.x has almost *nothing*. In order to change anything,
>> you have to install user-supplied "extensions". (Oh, did I mention?
>> There's no documentation for how to write these extensions. You just
>> have to read the source code. Because that's trivial...) It seems
>> software producers have somehow got the idea that it's OK to produce a
>> product with no configurability, and let a dozen different 3rd parties
>> write a dozen mutually-incompatible "extensions" each of which solves a
>> different 30% of the problem.
>
> Judging from some stuff you posted about Haskell libraries a while ago,
> shouldn't you be familiar with this? :P

I'm not sure I follow...

Post a reply to this message

On Mon, 16 Mar 2015 20:08:35 +0000, Orchid Win7 v1 wrote:

> Anyway, I tried Google Chrome, but it *insists* that you have to "log
> in" to allow them to track your movements - er, I mean, synchronise your
> devices. Yeah, that. But more to the point, Hotmail became
> *catastrophically slow*. (I presume this is perfectly intentional.)

Chrome doesn't need you to login.  I know people who don't have gmail 
accounts even who use it, so obviously they don't have a password to even 
use.

> This seems to be a worrying trend. GNOME 2.x had a sea of configuration
> options. GNOME 3.x has almost *nothing*. In order to change anything,
> you have to install user-supplied "extensions". (Oh, did I mention?
> There's no documentation for how to write these extensions. You just
> have to read the source code. Because that's trivial...) It seems
> software producers have somehow got the idea that it's OK to produce a
> product with no configurability, and let a dozen different 3rd parties
> write a dozen mutually-incompatible "extensions" each of which solves a
> different 30% of the problem.

GNOME3 has plenty of configuration options, set using dconf-editor.

> Seriously, you managed to implement a standards-compliant rendering
> engine! That's nearly impossible!! How hard can it be to add a trivial
> GUI for editing the frigging settings?!

It isn't, because dconf-editor exists. ;)

Jim

-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On Mon, 16 Mar 2015 19:44:31 -0400, Jim Henderson wrote:

>> This seems to be a worrying trend. GNOME 2.x had a sea of configuration
>> options. GNOME 3.x has almost *nothing*. In order to change anything,
>> you have to install user-supplied "extensions". (Oh, did I mention?
>> There's no documentation for how to write these extensions. You just
>> have to read the source code. Because that's trivial...) It seems
>> software producers have somehow got the idea that it's OK to produce a
>> product with no configurability, and let a dozen different 3rd parties
>> write a dozen mutually-incompatible "extensions" each of which solves a
>> different 30% of the problem.
> 
> GNOME3 has plenty of configuration options, set using dconf-editor.

Oh, and for creating gnome-shell extensions?

https://wiki.gnome.org/Projects/GnomeShell/Extensions

Google with search terms "writing gnome 3 shell extensions".

First hit.

Jim
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On 3/16/2015 1:08 PM, Orchid Win7 v1 wrote:
> For over 10 years now I've been a satisfied Firefox user.
>
> Today I finally got fed up with its extreme slowness, and tried to
> install another browser.
>

Firefox's biggest problem seems to be how to threads things. It works 
nicely, if you have NoScript, and leave everything you don't absolutely 
need in the pages scripts "disabled". Its does vastly worse with a lot 
of active scripts, animated gifs, or anything that has to simultaneously 
load as the page does.

But, apparently... they know the problem, but fixing it... would require 
a complete rewrite of the engine it uses... :(

Hotmail... is broken in everything, imho, since they changed things 
there. lol

-- 
Commander Vimes: "You take a bunch of people who don't seem any 
different from you and me, but when you add them all together you get 
this sort of huge raving maniac with national borders and an anthem."

Post a reply to this message

On 16/03/2015 11:55 PM, Jim Henderson wrote:
>> GNOME3 has plenty of configuration options, set using dconf-editor.

GNOME 3 uses the gsettings system to hold its configuration settings. 
It's something like the Windows Registry, but harder to use. (E.g., it 
seems to be impossible to access when X11 isn't running. It's 
nightmarishly hard to configure settings for a user who isn't you. It's 
really hard to navigate without a GUI tool. And so on.)

Since OpenSUSE 13.1, gsettings likes to randomly revert certain settings 
every 103 reboots, for no defined reason. This is extremely unhelpful.

But the *most* unhelpful thing is that half the things you want to 
change DON'T HAVE SETTINGS! For example, there is no setting to bring 
back the minimise and maximise buttons; you have to install an extension.

But I guess that's a symptom of another worryingly common problem: GNOME 
3 is *clearly* designed to run on a tablet or a phone. Because nobody 
uses desktop PCs anymore, right? Right?? >_<

> Oh, and for creating gnome-shell extensions?
>
> https://wiki.gnome.org/Projects/GnomeShell/Extensions
>
> Google with search terms "writing gnome 3 shell extensions".
>
> First hit.

Riiiight. Because I haven't already read that page 65,536 times. :-P

Basically, you write a shell extension by writing a JavaScript file that 
contains [at least] three functions with specific names. These functions 
work by MONKEY-PATCHING THE LIVE RUNNING CODE to make it do something 
different. The extension itself is responsible for reverting these 
changes when you disable the extension. (In particular, there are 
extensions that cannot be disabled, or don't disable properly.) Leaving 
this critical detail up to people who don't really know what they're 
doing and have no documentation to go by is... not optimal.

This, then, is how you write a shell extension. And how do you work out 
which part of THE ENTIRE SHELL CODEBASE you need to monkey-patch to make 
the changes you want?

You read the source code.

For the entire shell.

Because there's no documentation. Indeed, one Stack Overflow commenter 
helpfully commented that "there SHOULD be no documentation, because the 
source code is the documentation". No, random Internet user, the source 
code is not and will never be the documentation. Because the source code 
gives you the *implementation* not the *interface*.

Then again, when your entire extensibility platform is fundamentally 
based on purposely breaking encapsulation to start with...

Post a reply to this message

On 17/03/2015 02:20 PM, Patrick Elliott wrote:
> Firefox's biggest problem seems to be how to threads things.

That would seem to be the case. Load any moderately complex page, and 
the CPU usage goes sky-high.

Does anybody else remember when everybody started switching to Firefox 
because it was so much faster than IE? People used Firefox even though 
dozens of high-profile web pages only worked with IE. (Like I said, 
running a dated version of Firefox was *so much faster*!) Now, it seems, 
the boot is on the other foot.

It's a shame, because Firefox seems to have some really lovely developer 
tools, if you want to build crazy web-stuff...

Post a reply to this message

Le 17/03/2015 20:00, Orchid Win7 v1 a écrit :

> But I guess that's a symptom of another worryingly common problem: GNOME
> 3 is *clearly* designed to run on a tablet or a phone. Because nobody
> uses desktop PCs anymore, right? Right?? >_<
> 

Well, I do not use gnome anymore on PC. xfce rules now.
I enjoyed gnome2 and its applets. They lost me with unity & gnome3.

>> Oh, and for creating gnome-shell extensions?
>>
>> https://wiki.gnome.org/Projects/GnomeShell/Extensions
>>
>> Google with search terms "writing gnome 3 shell extensions".
>>
>> First hit.
> 
> Riiiight. Because I haven't already read that page 65,536 times. :-P
> 
> Basically, you write a shell extension by writing a JavaScript file that
> contains [at least] three functions with specific names. These functions
> work by MONKEY-PATCHING THE LIVE RUNNING CODE to make it do something
> different. The extension itself is responsible for reverting these
> changes when you disable the extension. (In particular, there are
> extensions that cannot be disabled, or don't disable properly.) Leaving
> this critical detail up to people who don't really know what they're
> doing and have no documentation to go by is... not optimal.
> 
> This, then, is how you write a shell extension. And how do you work out
> which part of THE ENTIRE SHELL CODEBASE you need to monkey-patch to make
> the changes you want?
> 
> You read the source code.
> 
> For the entire shell.
> 

That's why I now prefer the xfce's run a shell widget (generic monitor):
the output for logo and text is not so fancy, but for periodical
scanning of a resource, it's easy enough to allow me to have want I
wanted (and easy testing), without problem. I could even have the shell
to launch a binary, if I dare to not be portable (and a bit slow for a
double fork)

> Because there's no documentation. Indeed, one Stack Overflow commenter
> helpfully commented that "there SHOULD be no documentation, because the
> source code is the documentation". No, random Internet user, the source
> code is not and will never be the documentation. Because the source code
> gives you the *implementation* not the *interface*.

Right. At best: the documentation is in the source code, for doxygen to
extract. But "Source is all you need" is just bad. Code never explains
the concepts.

Post a reply to this message

>> But I guess that's a symptom of another worryingly common problem: GNOME
>> 3 is *clearly* designed to run on a tablet or a phone. Because nobody
>> uses desktop PCs anymore, right? Right??>_<
>
> Well, I do not use gnome anymore on PC. xfce rules now.
> I enjoyed gnome2 and its applets. They lost me with unity&  gnome3.

Sadly, this seems to be the way of the world. At work I'm forced to use 
Windows 8, which keeps insisting that my desktop is actually a tablet. 
Complete with low-detail fonts, and an ugly, blocky colour scheme that a 
tablet can handle. Because why would you pay £1,000 for a developer 
workstation and then expect to use it like a developer workstation?

>> Because there's no documentation. Indeed, one Stack Overflow commenter
>> helpfully commented that "there SHOULD be no documentation, because the
>> source code is the documentation". No, random Internet user, the source
>> code is not and will never be the documentation. Because the source code
>> gives you the *implementation* not the *interface*.
>
> Right. At best: the documentation is in the source code, for doxygen to
> extract. But "Source is all you need" is just bad. Code never explains
> the concepts.

Indeed.

All the source code for the Linux kernel is freely available. Yet no 
sane person expects you to actually read the source code to figure out 
how you open a file!

(Then again, the Linux kernel obeys POSIX and similar, so...)

Post a reply to this message

Am 17.03.2015 um 20:00 schrieb Orchid Win7 v1:

> But I guess that's a symptom of another worryingly common problem: GNOME
> 3 is *clearly* designed to run on a tablet or a phone. Because nobody
> uses desktop PCs anymore, right? Right?? >_<

Why does that sound strangely familiar?

Post a reply to this message

On Tue, 17 Mar 2015 19:00:21 +0000, Orchid Win7 v1 wrote:

> On 16/03/2015 11:55 PM, Jim Henderson wrote:
>>> GNOME3 has plenty of configuration options, set using dconf-editor.
> 
> GNOME 3 uses the gsettings system to hold its configuration settings.
> It's something like the Windows Registry, but harder to use. (E.g., it
> seems to be impossible to access when X11 isn't running. It's
> nightmarishly hard to configure settings for a user who isn't you. It's
> really hard to navigate without a GUI tool. And so on.)
> 
> Since OpenSUSE 13.1, gsettings likes to randomly revert certain settings
> every 103 reboots, for no defined reason. This is extremely unhelpful.

Could be a bug.  Have you asked in the openSUSE forums for some help, and/
or reported a bug?

> But the *most* unhelpful thing is that half the things you want to
> change DON'T HAVE SETTINGS! For example, there is no setting to bring
> back the minimise and maximise buttons; you have to install an
> extension.

No, you don't. gnome-tweak-tool -> Windows.

> But I guess that's a symptom of another worryingly common problem: GNOME
> 3 is *clearly* designed to run on a tablet or a phone. Because nobody
> uses desktop PCs anymore, right? Right?? >_<

I use GNOME3 every day, and not on a tablet or touchscreen.  Works fine 
here.

>> Oh, and for creating gnome-shell extensions?
>>
>> https://wiki.gnome.org/Projects/GnomeShell/Extensions
>>
>> Google with search terms "writing gnome 3 shell extensions".
>>
>> First hit.
> 
> Riiiight. Because I haven't already read that page 65,536 times. :-P

You said it wasn't documented.  It is.

> Basically, you write a shell extension by writing a JavaScript file that
> contains [at least] three functions with specific names. These functions
> work by MONKEY-PATCHING THE LIVE RUNNING CODE to make it do something
> different. The extension itself is responsible for reverting these
> changes when you disable the extension. (In particular, there are
> extensions that cannot be disabled, or don't disable properly.) Leaving
> this critical detail up to people who don't really know what they're
> doing and have no documentation to go by is... not optimal.

Got a better idea about how to do it?

> This, then, is how you write a shell extension. And how do you work out
> which part of THE ENTIRE SHELL CODEBASE you need to monkey-patch to make
> the changes you want?
> 
> You read the source code.
> 
> For the entire shell.

No.  What you do is you identify what it is you want to do, and you find 
that part of the code, if that's the way it's actually done (I don't for 
a moment pretend to have written an extension, however given your track 
record in overstating things, you don't really think I'm going to take 
your word for it, do you? ;) )

> Because there's no documentation. Indeed, one Stack Overflow commenter
> helpfully commented that "there SHOULD be no documentation, because the
> source code is the documentation". No, random Internet user, the source
> code is not and will never be the documentation. Because the source code
> gives you the *implementation* not the *interface*.
> 
> Then again, when your entire extensibility platform is fundamentally
> based on purposely breaking encapsulation to start with...

Um, no, it's based on extending encapsulation in an OO way, as I 
understand it.  It's somewhat like using DITA specializations, or 
extending an object class in a directory service.

Jim
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> I think the thing that really drove it home was that the other day I 
> happened to fire up an old VM that's running Firefox 5. It was *so much* 
> faster! I could actually look at Google Maps in *realtime*! Not with a 
> 30-second pause every time I scroll or zoom.

Do you honestly think that if that were common, people wouldn't have
noticed? (I just tested google maps with firefox, and they worked just
fine in real-time, with no lagginess of to speak of.)

Or is this another one of your exaggerations, where you express
estimations with two orders of magnitude of exaggeration?

-- 
                                                          - Warp

Post a reply to this message

On 18/03/2015 05:41 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> I think the thing that really drove it home was that the other day I
>> happened to fire up an old VM that's running Firefox 5. It was *so much*
>> faster! I could actually look at Google Maps in *realtime*! Not with a
>> 30-second pause every time I scroll or zoom.
>
> Do you honestly think that if that were common, people wouldn't have
> noticed? (I just tested google maps with firefox, and they worked just
> fine in real-time, with no lagginess of to speak of.)
>
> Or is this another one of your exaggerations, where you express
> estimations with two orders of magnitude of exaggeration?

If it were just my home PC, I'd probably assume that something is wrong 
with my PC. Given that the PC at work does the exact same thing... and 
other people in the office have also mentioned it and switched 
browsers... I suspect it's not just me.

(Plus the fact that an older version of Firefox runs drastically faster. 
In a VM, which is typically slower...)

Maybe 30 seconds is an exaggeration. When you make a mouse gesture, and 
nothing visible happens for multiple seconds afterwards, it sure *feels* 
like several eternities.

Post a reply to this message

>> Since OpenSUSE 13.1, gsettings likes to randomly revert certain settings
>> every 103 reboots, for no defined reason. This is extremely unhelpful.
>
> Could be a bug.  Have you asked in the openSUSE forums for some help, and/
> or reported a bug?

Given how excruciatingly hard it is to get access to the OpenSUSE bug 
tracker... no, I haven't.

Besides, they'll just report it upstream and then go back to doing 
nothing. That's what they did with the Zypper bug I spent ages 
diagnosing and reporting.

>> But the *most* unhelpful thing is that half the things you want to
>> change DON'T HAVE SETTINGS! For example, there is no setting to bring
>> back the minimise and maximise buttons; you have to install an
>> extension.
>
> No, you don't. gnome-tweak-tool ->  Windows.

Perhaps it was the "show task list" option then. I remember spending 
weeks trying to configure the shell the way we want it, and in the end I 
couldn't do it.

>> But I guess that's a symptom of another worryingly common problem: GNOME
>> 3 is *clearly* designed to run on a tablet or a phone. Because nobody
>> uses desktop PCs anymore, right? Right??>_<
>
> I use GNOME3 every day, and not on a tablet or touchscreen.  Works fine
> here.

I'm not saying it doesn't *work*. I'm saying it's clearly not optimal. 
The way they try to stop you arranging multiple windows visible at once, 
the way they try to steer you away from multitasking. Heck, the latest 
revision even removed a scrollbar and replaced it with a sequence of 
buttons, so it'll work better with a touchscreen.

>> Riiiight. Because I haven't already read that page 65,536 times. :-P
>
> You said it wasn't documented.  It is.

How you write a minimal Hello World type thing is documented. The vast, 
sprawling mass of code you need to interact with to do anything 
nontrivial is utterly undocumented.

How do I respond to window open/close events? Not documented. How do I 
determine what tray icons are defined? Not documented. How do I resize 
an existing window? Not documented. Would you like me to continue?

>> Basically, you write a shell extension by writing a JavaScript file that
>> contains [at least] three functions with specific names. These functions
>> work by MONKEY-PATCHING THE LIVE RUNNING CODE to make it do something
>> different. The extension itself is responsible for reverting these
>> changes when you disable the extension. (In particular, there are
>> extensions that cannot be disabled, or don't disable properly.) Leaving
>> this critical detail up to people who don't really know what they're
>> doing and have no documentation to go by is... not optimal.
>
> Got a better idea about how to do it?

How about, I don't know, the system generating a reverse diff as you 
change stuff, and then applying that diff when you turn the extension 
off? It's more work for the framework, but then less work for the 
extension author. And I'd *hope* the framework is rather better tested 
than your typical extension...

>> This, then, is how you write a shell extension. And how do you work out
>> which part of THE ENTIRE SHELL CODEBASE you need to monkey-patch to make
>> the changes you want?
>>
>> You read the source code.
>>
>> For the entire shell.
>
> No.  What you do is you identify what it is you want to do, and you find
> that part of the code, if that's the way it's actually done (I don't for
> a moment pretend to have written an extension, however given your track
> record in overstating things, you don't really think I'm going to take
> your word for it, do you? ;) )

You realise I got *paid money* to write several shell extensions and 
modify some existing ones, right?

Indeed, it seems the only "documentation" for how to do anything is to 
read the source code for extensions that other people have already written.

(How THE HELL these other people wrote this stuff utterly baffles me... 
I guess one or two people might have too much free time, but given the 
vast number of extensions available [most of which add back 
functionality that GNOME 2 had built-in], it screams that somebody 
somewhere must have some real documentation...)

>> Because there's no documentation. Indeed, one Stack Overflow commenter
>> helpfully commented that "there SHOULD be no documentation, because the
>> source code is the documentation". No, random Internet user, the source
>> code is not and will never be the documentation. Because the source code
>> gives you the *implementation* not the *interface*.
>>
>> Then again, when your entire extensibility platform is fundamentally
>> based on purposely breaking encapsulation to start with...
>
> Um, no, it's based on extending encapsulation in an OO way, as I
> understand it.  It's somewhat like using DITA specializations, or
> extending an object class in a directory service.

In an OO language, you don't generally modify a huge, complex framework 
by deleting code from the running system and replacing it with your own.

Then again, JavaScript isn't completely OO, so...

Post a reply to this message

On 19/03/2015 08:03, Orchid Win7 v1 wrote:
> ... I suspect it's not just me.

I'm with you. When you find a better browser. Let us know.


-- 

Regards
     Stephen

Post a reply to this message

Patrick Elliott <kag### [at] gmailcom> wrote:

>
> Firefox's biggest problem seems to be how to threads things. It works
> nicely, if you have NoScript, and leave everything you don't absolutely
> need in the pages scripts "disabled". Its does vastly worse with a lot
> of active scripts, animated gifs, or anything that has to simultaneously
> load as the page does.
>
> But, apparently... they know the problem, but fixing it... would require
> a complete rewrite of the engine it uses... :(
>

I'm running the latest Firefox on Windows XP, along with the Flash plug-in
there.

The sluggishness of Firefox seems to be a known problem, having to do with its
"plug-in-container.exe" process. And without a solution, AFAIK-- except to add
the NoScript add-on. (Haven't done that yet.)

Flash + plug-in-container = big problem! Like, 100% takeover of the CPU. It
happens on my system about 50% of the time while I'm online. My only solution at
present is to kill the plug-in-container process in Task Manager, when things go
screwy. (Or to keep the Flash plug-in from firing up at all, choosing "ask to
activate" there.) I'm obviously missing a lot of Flash content on the web--but I
don't need to see most of it anyway.

Post a reply to this message

On Thu, 19 Mar 2015 08:14:37 +0000, Orchid Win7 v1 wrote:

>>> Since OpenSUSE 13.1, gsettings likes to randomly revert certain
>>> settings every 103 reboots, for no defined reason. This is extremely
>>> unhelpful.
>>
>> Could be a bug.  Have you asked in the openSUSE forums for some help,
>> and/
>> or reported a bug?
> 
> Given how excruciatingly hard it is to get access to the OpenSUSE bug
> tracker... no, I haven't.

1. Create user ID
2. Validate your e-mail address
3. Go to bugzilla.opensuse.org and enter a bug

Not terribly difficult, really.

> Besides, they'll just report it upstream and then go back to doing
> nothing. That's what they did with the Zypper bug I spent ages
> diagnosing and reporting.

You don't know that unless you file a bug.  File a bug, or don't 
complain.  Seriously, that is probably the most annoying thing you can do 
is bitch about something that's fixable and not report a bug.

>>> But the *most* unhelpful thing is that half the things you want to
>>> change DON'T HAVE SETTINGS! For example, there is no setting to bring
>>> back the minimise and maximise buttons; you have to install an
>>> extension.
>>
>> No, you don't. gnome-tweak-tool ->  Windows.
> 
> Perhaps it was the "show task list" option then. I remember spending
> weeks trying to configure the shell the way we want it, and in the end I
> couldn't do it.

Not sure what you mean by "show task list option".  What was the specific 
thing you were trying to do?

>>> But I guess that's a symptom of another worryingly common problem:
>>> GNOME 3 is *clearly* designed to run on a tablet or a phone. Because
>>> nobody uses desktop PCs anymore, right? Right??>_<
>>
>> I use GNOME3 every day, and not on a tablet or touchscreen.  Works fine
>> here.
> 
> I'm not saying it doesn't *work*. I'm saying it's clearly not optimal.

It's optimal for me, and I don't use a tablet.  "Optimal" is clearly a 
matter of personal taste, and I wish people would stop putting forth 
their personal opinion as cold hard fact - it's not.

> The way they try to stop you arranging multiple windows visible at once,
> the way they try to steer you away from multitasking. Heck, the latest
> revision even removed a scrollbar and replaced it with a sequence of
> buttons, so it'll work better with a touchscreen.

I don't see any of those issues.

> 
>>> Riiiight. Because I haven't already read that page 65,536 times. :-P
>>
>> You said it wasn't documented.  It is.
> 
> How you write a minimal Hello World type thing is documented. The vast,
> sprawling mass of code you need to interact with to do anything
> nontrivial is utterly undocumented.
> 
> How do I respond to window open/close events? Not documented. How do I
> determine what tray icons are defined? Not documented. How do I resize
> an existing window? Not documented. Would you like me to continue?

Since I don't write extensions, it's kinda pointless for you to 
continue.  However, again, given your track record, I'm not going to take 
it on faith that your assertion that these things aren't documented is 
true.  You'll have to forgive me my cynicism on that point.

>>> Basically, you write a shell extension by writing a JavaScript file
>>> that contains [at least] three functions with specific names. These
>>> functions work by MONKEY-PATCHING THE LIVE RUNNING CODE to make it do
>>> something different. The extension itself is responsible for reverting
>>> these changes when you disable the extension. (In particular, there
>>> are extensions that cannot be disabled, or don't disable properly.)
>>> Leaving this critical detail up to people who don't really know what
>>> they're doing and have no documentation to go by is... not optimal.
>>
>> Got a better idea about how to do it?
> 
> How about, I don't know, the system generating a reverse diff as you
> change stuff, and then applying that diff when you turn the extension
> off? It's more work for the framework, but then less work for the
> extension author. And I'd *hope* the framework is rather better tested
> than your typical extension...
> 
>>> This, then, is how you write a shell extension. And how do you work
>>> out which part of THE ENTIRE SHELL CODEBASE you need to monkey-patch
>>> to make the changes you want?
>>>
>>> You read the source code.
>>>
>>> For the entire shell.
>>
>> No.  What you do is you identify what it is you want to do, and you
>> find that part of the code, if that's the way it's actually done (I
>> don't for a moment pretend to have written an extension, however given
>> your track record in overstating things, you don't really think I'm
>> going to take your word for it, do you? ;) )
> 
> You realise I got *paid money* to write several shell extensions and
> modify some existing ones, right?

You realise that that's no guarantee that anyone's an expert at a task, 
right? I know lots of people who get paid to do things who don't take the 
optimal route to doing them.

How many questions did you ask on, oh, I don't know, the GNOME mailing 
lists?

> Indeed, it seems the only "documentation" for how to do anything is to
> read the source code for extensions that other people have already
> written.
> 
> (How THE HELL these other people wrote this stuff utterly baffles me...
> I guess one or two people might have too much free time, but given the
> vast number of extensions available [most of which add back
> functionality that GNOME 2 had built-in], it screams that somebody
> somewhere must have some real documentation...)

Bingo!  Just because you didn't happen to look in the right place doesn't 
mean that the documentation doesn't exist.

>>> Because there's no documentation. Indeed, one Stack Overflow commenter
>>> helpfully commented that "there SHOULD be no documentation, because
>>> the source code is the documentation". No, random Internet user, the
>>> source code is not and will never be the documentation. Because the
>>> source code gives you the *implementation* not the *interface*.
>>>
>>> Then again, when your entire extensibility platform is fundamentally
>>> based on purposely breaking encapsulation to start with...
>>
>> Um, no, it's based on extending encapsulation in an OO way, as I
>> understand it.  It's somewhat like using DITA specializations, or
>> extending an object class in a directory service.
> 
> In an OO language, you don't generally modify a huge, complex framework
> by deleting code from the running system and replacing it with your own.

Of course not.

> Then again, JavaScript isn't completely OO, so...

And "deleting code from the running system" isn't the same as extending 
it.

Jim

-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On 03/19/2015 10:24 AM, Kenneth wrote:
> I'm running the latest Firefox on Windows XP, along with the Flash plug-in
> there.
>
> The sluggishness of Firefox seems to be a known problem, having to do with its
> "plug-in-container.exe" process. And without a solution, AFAIK-- except to add
> the NoScript add-on. (Haven't done that yet.)
>
> Flash + plug-in-container = big problem! Like, 100% takeover of the CPU. It
> happens on my system about 50% of the time while I'm online. My only solution at
> present is to kill the plug-in-container process in Task Manager, when things go
> screwy. (Or to keep the Flash plug-in from firing up at all, choosing "ask to
> activate" there.) I'm obviously missing a lot of Flash content on the web--but I
> don't need to see most of it anyway.

Well there ya go ... not sure if it's totally the plug-in container 
processes fault /entirely/ my gut feeling says it's Flash. IHMO the most 
insecure process hog on the face of the planet ... JavaScript is a close 
second. On my linux system I /have/ also observed the plug-in container 
process consuming a lot of cpu cycles and have gone into the process 
table and killed it off when I've noticed it still running when Firefox 
isn't. I've also seen it delay my system going into stand-by as well, so 
/perhaps/ it's not completely blameless. Since a couple of versions ago 
I've not been running Firefox with Flash plug-in and have opted for 
Flash to HTML5 extension because I do frequent YouTube. If I run across 
something on other sites that I just /have/ to see I fire up Chrome 
because it comes bundled with the browser. In short ... I just gave up 
on Flash when I noticed an end of support notice for linux platforms.

Post a reply to this message

>> On 16/03/2015 11:55 PM, Jim Henderson wrote:
>>>> GNOME3 has plenty of configuration options, set using dconf-editor.

Yeah it's there you just got to dig a bit ... snipped most of what Jim 
said because I agree and I just wanted to add that Andrew kind of 
reminds me of Sheldon ;-)

Post a reply to this message

On Thu, 19 Mar 2015 13:00:42 -0400, James Holsenback wrote:

>>> On 16/03/2015 11:55 PM, Jim Henderson wrote:
>>>>> GNOME3 has plenty of configuration options, set using dconf-editor.
> 
> Yeah it's there you just got to dig a bit ... snipped most of what Jim
> said because I agree and I just wanted to add that Andrew kind of
> reminds me of Sheldon ;-)

LOL



-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On 19/03/2015 10:41 AM, Stephen wrote:
> On 19/03/2015 08:03, Orchid Win7 v1 wrote:
>> ... I suspect it's not just me.
>
> I'm with you. When you find a better browser. Let us know.

*shrugs* Opera seems minimally usable after you spend three days 
configuring it... It's not *great*, but it works.

Post a reply to this message

>> Given how excruciatingly hard it is to get access to the OpenSUSE bug
>> tracker... no, I haven't.
>
> 1. Create user ID
> 2. Validate your e-mail address
> 3. Go to bugzilla.opensuse.org and enter a bug
>
> Not terribly difficult, really.

Except that you have to give them your *real* name, who you work for, 
your annual income, your mother's maiden name, and your inside leg 
measurement. No, not hard at all.

>> Besides, they'll just report it upstream and then go back to doing
>> nothing. That's what they did with the Zypper bug I spent ages
>> diagnosing and reporting.
>
> You don't know that unless you file a bug.

Given that the bug is almost 100% certain to be a GNOME bug, they will 
just pass it to the GNOME team and then do nothing.

> File a bug, or don't
> complain.  Seriously, that is probably the most annoying thing you can do
> is bitch about something that's fixable and not report a bug.

Well, maybe they shouldn't actively dissuade people from filing bugs by 
making it so sodding hard to file a bug? :-P

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...)

>> Perhaps it was the "show task list" option then. I remember spending
>> weeks trying to configure the shell the way we want it, and in the end I
>> couldn't do it.
>
> 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.

GNOME 2 had it, and there's a dozen different mutually-incompatible 
extensions to add it back to GNOME 3. Because it's a basic feature that 
should have been in the shell to begin with. But hey, it's a tablet. Who 
runs multiple applications on a tablet?

>> I'm not saying it doesn't *work*. I'm saying it's clearly not optimal.
>
> It's optimal for me, and I don't use a tablet.  "Optimal" is clearly a
> matter of personal taste, and I wish people would stop putting forth
> their personal opinion as cold hard fact - it's not.

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...

>> How you write a minimal Hello World type thing is documented. The vast,
>> sprawling mass of code you need to interact with to do anything
>> nontrivial is utterly undocumented.
>
> Since I don't write extensions, it's kinda pointless for you to
> continue.  However, again, given your track record, I'm not going to take
> it on faith that your assertion that these things aren't documented is
> true.  You'll have to forgive me my cynicism on that point.

Sure, I can understand that.

>>> No.  What you do is you identify what it is you want to do, and you
>>> find that part of the code, if that's the way it's actually done (I
>>> don't for a moment pretend to have written an extension, however given
>>> your track record in overstating things, you don't really think I'm
>>> going to take your word for it, do you? ;) )
>>
>> You realise I got *paid money* to write several shell extensions and
>> modify some existing ones, right?
>
> You realise that that's no guarantee that anyone's an expert at a task,
> right? I know lots of people who get paid to do things who don't take the
> optimal route to doing them.

Your point is valid. My point is that I'm not talking about "oh hey, I 
tried to do this thing, but it was a bit hard so I gave up after five 
minutes". This is something I spent MULTIPLE MONTHS trying to solve.

> How many questions did you ask on, oh, I don't know, the GNOME mailing
> lists?

Yes, because I *want* to sign up to yet *another* mailing list just to 
get basic developer information that should already be written down 
somewhere. :-P

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!

>> (How THE HELL these other people wrote this stuff utterly baffles me...
>> I guess one or two people might have too much free time, but given the
>> vast number of extensions available [most of which add back
>> functionality that GNOME 2 had built-in], it screams that somebody
>> somewhere must have some real documentation...)
>
> Bingo!  Just because you didn't happen to look in the right place doesn't
> mean that the documentation doesn't exist.

As I said, I find it really baffling. The extensions I've looked at 
aren't exactly trivial or simple. And yet, I can't find any 
documentation, and nobody I asked about it can find any either. Not even 
so much as a blog entry or an auto-generated object list...

>> In an OO language, you don't generally modify a huge, complex framework
>> by deleting code from the running system and replacing it with your own.
>
> Of course not.
>
>> Then again, JavaScript isn't completely OO, so...
>
> 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.

And then watch it all break horrifyingly in the next minor-release of 
the shell. >_<

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.

Post a reply to this message

On Thu, 19 Mar 2015 18:38:59 +0000, Orchid Win7 v1 wrote:

>>> Given how excruciatingly hard it is to get access to the OpenSUSE bug
>>> tracker... no, I haven't.
>>
>> 1. Create user ID 2. Validate your e-mail address 3. Go to
>> bugzilla.opensuse.org and enter a bug
>>
>> Not terribly difficult, really.
> 
> Except that you have to give them your *real* name, who you work for,
> your annual income, your mother's maiden name, and your inside leg
> measurement. No, not hard at all.

No, you actually don't.  They ask, but (a) you don't need to fill in all 
the fields, and (b) even if you DO have to fill in all the fields, you 
don't need to provide real information.

So no, it actually *isn't* that difficult.  Remember that you're talking 
with one of the admins of the openSUSE forums, so I'm not just some yahoo 
out there who doesn't have a clue what he's talking about when it comes 
to this.

> Given that the bug is almost 100% certain to be a GNOME bug, they will
> just pass it to the GNOME team and then do nothing.

Well, fine, then Andy, screw it and report the bug upstream then, if 
you're so damned sure of yourself.  Again, that's not terribly difficult.

>> File a bug, or don't complain.  Seriously, that is probably the most
>> annoying thing you can do is bitch about something that's fixable and
>> not report a bug.
> 
> 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 - based on exactly ZERO 
experience doing so.

> 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.

>>> Perhaps it was the "show task list" option then. I remember spending
>>> weeks trying to configure the shell the way we want it, and in the end
>>> I couldn't do it.
>>
>> 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'm not saying it doesn't *work*. I'm saying it's clearly not optimal.
>>
>> It's optimal for me, and I don't use a tablet.  "Optimal" is clearly a
>> matter of personal taste, and I wish people would stop putting forth
>> their personal opinion as cold hard fact - it's not.
> 
> 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.

>>>> No.  What you do is you identify what it is you want to do, and you
>>>> find that part of the code, if that's the way it's actually done (I
>>>> don't for a moment pretend to have written an extension, however
>>>> given your track record in overstating things, you don't really think
>>>> I'm going to take your word for it, do you? ;) )
>>>
>>> You realise I got *paid money* to write several shell extensions and
>>> modify some existing ones, right?
>>
>> You realise that that's no guarantee that anyone's an expert at a task,
>> right? I know lots of people who get paid to do things who don't take
>> the optimal route to doing them.
> 
> Your point is valid. My point is that I'm not talking about "oh hey, I
> tried to do this thing, but it was a bit hard so I gave up after five
> minutes". This is something I spent MULTIPLE MONTHS trying to solve.

And did you ask for help?  Or did you spend months beating your head 
against the wall in solitude and then declare it impossible?  Again, past 
performance is my indicator here, so again, you'll have to forgive my 
cynicism about your approach to solving what you see as an "impossible" 
task.

>> How many questions did you ask on, oh, I don't know, the GNOME mailing
>> lists?
> 
> Yes, because I *want* to sign up to yet *another* mailing list just to
> get basic developer information that should already be written down
> somewhere. :-P

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.

>>> (How THE HELL these other people wrote this stuff utterly baffles
>>> me... I guess one or two people might have too much free time, but
>>> given the vast number of extensions available [most of which add back
>>> functionality that GNOME 2 had built-in], it screams that somebody
>>> somewhere must have some real documentation...)
>>
>> Bingo!  Just because you didn't happen to look in the right place
>> doesn't mean that the documentation doesn't exist.
> 
> As I said, I find it really baffling. The extensions I've looked at
> aren't exactly trivial or simple. And yet, I can't find any
> documentation, and nobody I asked about it can find any either. Not even
> so much as a blog entry or an auto-generated object list...
> 
>>> In an OO language, you don't generally modify a huge, complex
>>> framework by deleting code from the running system and replacing it
>>> with your own.
>>
>> Of course not.
>>
>>> Then again, JavaScript isn't completely OO, so...
>>
>> 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.

> 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 am not saying that it's a perfect environment 
to develop in, but jesus, Andy, if you aren't going to ask people who 
know what they're doing for help when you get stuck, what exactly do you 
think people are going to think or say?

> 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.

Jim

-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

>> 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

> GNOME 2 had it, and there's a dozen different mutually-incompatible
> extensions to add it back to GNOME 3. Because it's a basic feature that
> should have been in the shell to begin with. But hey, it's a tablet. Who
> runs multiple applications on a tablet?

You are aware that on one of the most popular tablet (and phone) OS's 
there's a dedicated button on every screen (one of only 3, the other two 
are home and back) that allows you switch between applications? I'm 
pretty sure they didn't decide to put it there just because it looked nice.

Post a reply to this message

Am 19.03.2015 um 21:45 schrieb Orchid Win7 v1:
>>> 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.

Maybe rather than calling it "tortuously difficult", a better 
terminology would be to say that it scares people off.

I'd totally agree with that, and maybe it might help Jim understand your 
point.

A signup process asking for more than absolutely necessary (i.e. a valid 
e-mail address, an alias and a password) /is/ scary for some people - 
and yes, dealing with scary things /is/ difficult for some people. 
Sometimes to the extent that they rather suffer two more weeks of trying 
alone.

Post a reply to this message

Le 2015-03-19 16:45, Orchid Win7 v1 a écrit :
> 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...
>

Have you contacted the curl maintainers?

>>> 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.
>

Maybe the proposed fix make his pc open a gate the to eight dimension, 
and the person was never seen again?  If I was in charge of QA, I'd be 
reluctant to release said RPM lest I be sure that it won't make dameons 
fly out of someone's nose.

(oh, and either switch newsreaders, or stop deleting the "XXX wrote:" 
lines at the top.  It makes it difficult to follow who said what)
-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On Thu, 19 Mar 2015 20:45:35 +0000, Orchid Win7 v1 wrote:

>>> 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.

*headdesk*

It seriously is not that difficult.  You go to the site.  You create an 
account, provide information (true or fake information, doesn't matter), 
validate e-mail address, authenticate to Bugzilla, and enter your bug.

It ain't rocket science.

>> 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...

Bug number?

>>> 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.

I didn't see that issue on my 13.1 systems, but now run 13.2, however, if 
the fix is a bit of a kludge, then I can see why the devs wanted to wait 
for a real fix from upstream.

>>>> 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.

Submit an enhancement request, then.  Unless you find logging into a 
website to be a bit too difficult to manage.  The proper place would be 
the GNOME3 bug tracking system (or enhancement request system).

> 
>>> 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...

I can see what windows are open, and I can move windows around.  I do 
that every day, so I don't know what you're on about here.

>> 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!")

I'll let you in on a little secret:  Not everyone with expertise has time 
to read a million different forums.  When a project has its own forums, 
use those rather than third party forums.  Choosing an appropriate venue 
is important.

See http://catb.org/~esr/faqs/smart-questions.html for why that's 
important.

>>>> 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.

I don't know for sure, but I think you'll find the underlying code is 
actually still there when an extension is installed - you're just hooking 
around it.

>>> 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.)

Well, here's a shock - when you upgrade a piece of software, stuff that 
depends on the software you upgraded might not work properly.  That's 
only the way things are with *every single piece of software used as a 
foundation for some other piece of software on the planet*.

>>> 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. ;-)

So then the alternative is to deal with it, if you have to, or don't, if 
you don't.
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On Fri, 20 Mar 2015 09:23:27 +0100, clipka wrote:

> Am 19.03.2015 um 21:45 schrieb Orchid Win7 v1:
>>>> 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.
> 
> Maybe rather than calling it "tortuously difficult", a better
> terminology would be to say that it scares people off.
> 
> I'd totally agree with that, and maybe it might help Jim understand your
> point.
> 
> A signup process asking for more than absolutely necessary (i.e. a valid
> e-mail address, an alias and a password) /is/ scary for some people -
> and yes, dealing with scary things /is/ difficult for some people.
> Sometimes to the extent that they rather suffer two more weeks of trying
> alone.

I understand his point completely.  His point just isn't valid - it's not 
tortuously difficult to create an account.  You fill in information, 
submit the form, get an account.  Nobody says the information has to be 
valid (other than the e-mail address, which is sensible).

Jim

-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> If it were just my home PC, I'd probably assume that something is wrong 
> with my PC. Given that the PC at work does the exact same thing... and 
> other people in the office have also mentioned it and switched 
> browsers... I suspect it's not just me.

So please explain why it works just fine with my PC.

-- 
                                                          - Warp

Post a reply to this message

On 11/04/2015 06:38 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> If it were just my home PC, I'd probably assume that something is wrong
>> with my PC. Given that the PC at work does the exact same thing... and
>> other people in the office have also mentioned it and switched
>> browsers... I suspect it's not just me.
>
> So please explain why it works just fine with my PC.

Absolutely no idea. What version are you running?

(As I said, I ran a much older version in a VM, and it was trippy-fast. 
It's only recent versions that seem slow...)

Post a reply to this message

On 16/03/2015 08:08 PM, Orchid Win7 v1 wrote:
> So I installed Opera, and I've just spent about an hour trying to force
> it to work the way *I* want it to work, not how it tells me I should
> work.

So today I learned a thing: Opera auto-updates itself. And it is 
impossible to disable this behaviour.

I don't find that very amusing.

(Well OK, it's but *impossible*, just damned hard. There's a 
command-line switch --- which won't work if you click a URL which 
auto-opens the default web browser. Or you can rename the updater 
executable. Which may accidentally get "repaired". Or you can try to 
firewall your web browser... good luck with that!)

Not only can you not tell it to stop this, you also cannot tell that 
it's doing this. There's no UI to tell you an update is happening, or 
how far it's got, or anything. That's very annoying.

Post a reply to this message

On 28/04/2015 07:17 PM, Orchid Win7 v1 wrote:
> So today I learned a thing: Opera auto-updates itself. And it is
> impossible to disable this behaviour.
>
> I don't find that very amusing.

Could be worse, I suppose; FileZilla auto-updates itself too. It has an 
option to turn off updates, WHICH IT BLATANTLY IGNORES!

As in, I've turned updates off, the settings dialog tells me it's off, 
and still every time I start the program it prompts me to install the 
update. And no matter how many times I delete the update file, it 
redownloads it again.

Maybe it's time to switch to WinSCP...

Post a reply to this message