 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
