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