Re: editor settings list

[Dirk Vangestel <dirk_vangestel yahoo com>]

--- jeroen <jeroen xs4all nl> wrote:
> 
> OK, so we delay creating generic & specific
> preferences groups until we
> have more than 1 editor component.

Which puts us back to your original proposal. Funny
how things work out that way :-)

> > [snip gconf]
> 
> What meant was that the bonobo-conf preferences
> dialog DOES have an Apply
> button but it's always disabled. I don't (yet) know
> how we can enable that
> button.

Ok, misunderstanding by me.

> I think the usability people have sufficiently
> argued that Apply, OK and
> Cancel are the correct buttons for preferences
> dialogs.

I vote for a 'revert' button too. See GConf
description (basically it's a Cancel without closing
the dialog). Not a really big deal, if the 'apply'
works.

> I've been thinking about this some more and all i
> can come up with is
> this: simply have 2 tab-width settings, one for
> local and one for
> system-wide settings. This is the only way that i
> can see that it would
> work.

I was more thinking along the way of a 'local apply'
and 'global apply' which would serve 2 purposes:
trying out settings locally, and changing settings
locally. How to implement that is an entirely
different matter though. The 'local apply' would then
be non-persistent (ie. not stored by bonobo-conf) and
the 'global apply' would per persistent. But there is
a (big) downside: if only gIDE would implement
something like this, it would be equally bad. Even
worse would be to have the 'apply' only work on the
current editor and the 'ok' work globally. That would
redefine standard buttons and thus be Evil.
Sigh. It's too hot to think.
Hmmm. Hang on. An 'apply' and 'revert' (or even
'cancel') could do the same thing: just change the
settings for a moment and then switch back to the old
ones. Not as good, and would still cause applications
to update while you were changing the settings, but as
a work around it would be ok I guess. At least until
people start complaining.

> IIRC jpr & campd argued that it would be
> confusing/unnecessary for normal
> users. This is still up for debate though.

The confusing part is a danger. It has to be well
thought-out. About the unnecessary part: I even have
different editors depending on the language in which I
program, so I certainly have different settings. gIDE
makes this editor switching transparent since it's
based on the MIME type, so it would be a shame if that
wouldn't be possible for editor settings.

> The problem is one of UI design/usability. Having
> lots of tabs in a
> notebook is considered bad practice (there's an
> Interface Hall of Shame
> (http://www.iarchitect.com/tabs.htm) that has some
> very good examples 
> of bad notebook/tab practices). This is the reason
> that i want to move the
> editor settings to a separate dialog. 

Yeah, I fully agree with that. So maybe a tabbed
dialog is not the best way to do the preferences (at
least not with a tab per plugin). Unfortunately, I
don't have an alternative.

> You probably won't be able to fix this for the
> general preferences
> dialog since you can't control how many plugins the
> user has loaded.

Yeah, that's a rather big problem. We did identify
that problem (I even think I put in the TODO) but I
still don't have a solution for that. Except for
trying to write some kind of layout algorithm which
would put several plugins on one page if they have few
options. But that's probably more trouble than it's
worth.

> It's
> up to him/her to organize those plugins (unload them
> maybe using your new
> plugin manager, which is very cool btw, but has 1
> very visible bug:
> initially, it thinks that there are no plugins
> loaded, while the opposite
> is true).

Ok, thanks, I'll have a look. Don't look at the code
though :) It's ugly.

> I'll do that when i get home.

Same problem here: only Windows crap at work :-(

Dirk


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/