Re: editor settings list

[Dirk Vangestel <dirk_vangestel yahoo com>]

--- jeroen <jeroen xs4all nl> wrote:

[snip]

> The problem you talk about is inherant to component
> architectures. You can
> only demand so much from components in a component
> architecture such as
> Bonobo. What you want is to have a consistent UI. I
> really don't think
> this is possible. Not everybody cares as much about
> GUI development
> compared to actual functionality. And not everyone
> uses the same style.

I'm sure the usability group will not agree with you
:-) Since there are many different components (>10) it
would be very bad to have an equal amount of
preference dialogs, don't you think? Supporting
multiple editor widgets is nice, but you have to think
about the users too. If they see a totally different
settings dialog if they switch editors, it will likely
confuse them. It will also give a very sloppy
impression about gIDE even though everyone is trying
to do a good job. Also the documentation people will
kill us if we have an inconsistent interface.

> I agree however that you want some sort of grouping
> in the preferences
> dialog. I've tried to do that with the list i sent.
> Please comment
> directly on that list (which options do you consider
> "generic").

I'm only suggesting a different kind of grouping: one
that is common to all editors, and one that is
specific to scintilla. Which those are is not that
important right now, since we only have one editor
component anyway. It'll probably change once we have
more editors implemented (which is a bad thing, but
probably unavoidable). It also depends on what
settings are deemed essential for a gIDE editor. For
instance, if fonts or colors are put in the 'generic'
category, you're excluding a whole range of editors.

[snip gconf]

> I'll try reading that asap. I don't understand what
> you mean by
> "bonobo-conf is even worse". 

Well, you say there isn't even an 'apply' possibility.
So forget about 'cancel' and 'revert' then. PoNG has
'apply' 'ok' and 'cancel' but no 'revert' if I
remember correctly.

[snip system-wide settings]

> This "feature" is inherant to using the underlying
> GConf system. The only
> thing that is different in this case is that
> bonobo-conf actually listens
> to changes to the component's preferences in GConf.
> Most applications
> today would only notice the changes when they're
> restarted.

GConf already does that. It's not a feature of
bonobo-conf. Not that that makes a difference...

> How would you differentiate between the current tab
> size or the
> system-wide tab size? I think the behavior you want
> only comes from the
> fact that current applications only apply settings
> on startup (while
> bonobo-conf listens continuously for changes).

Not listening to changes is one extreme, but having
all instances react is the other extreme. The latter
is definitely an improvement, but more confusing for
end users. For lots of applications it's probably the
best way to solve the consistency issue, but not so
with something as generic as an editor.

> I agree that you want to be able to temporarily
> change the tab size for
> only that window, but i don't see how we can
> accomplish that with
> bonobo-conf.

Ah, that's the core of the problem, isn't it. Maybe
bonobo-conf is entirely incapable of supporting that
feature. If it is, I guess I'll have to live with
Nautilus changing while I edit my gIDE preferences (if
I happen to have a source file open in gIDE). And I'd
also set up a nice big server for bugzilla, because
it'll rain bug reports (but now I'm just being
pessimistic).

> Plans for language-specific settings have not been
> made (there has been
> some discussion between myself and jpr & campd and
> they think we should
> just have a single setting that would apply to all
> languages).

Why? Is that also something that's too hard to
implement, or just because it's thought to be
unnecessary?

[snip one dialog vs. multiple dialogs]

> Maybe i wasn't entirely clear about the other
> settings: the remaining
> settings (project, debug, plugins etc.) would all be
> contained in 1
> dialog.

So why make the editor special? Just curious.

> The idea is that each plugin has 1
> preference tab.

We discussed that at GUADEC. We concluded that was
going to be ugly, since some plugins have way more
settings than others. But it may be the only practical
solution.

> The only problem with the editor settings is that
> the scintilla
> component will probably have something like 3 or 4
> tabs (at the least). 
> So if these settings were to be displayed in the
> general preferences dialog,
> the dialog wouldn't be usable anymore (JBuilder uses
> the same principle btw).

I don't see why. If you add 3 more plugins, you'll
also have 3 more tabs in the dialog. The problem does
not go away by just removing the editor settings from
that dialog.

[snip editor idl]

> I only looked in /usr/share/idl. There doesn't seem
> to be a lot of editor
> idls there. I *think* gIDE just queries oaf for
> components that can
> display the specified MIME type.

That's for querying which components there are. But
then you still have to know how to talk to those
components, so you need to have an interface. Take a
look at the EditorBuffer interface.

> Then i hope this one does :)

It helps :) It still leaves me with a bad feeling.
Let's hope that's just me.

Dirk


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