Nabble - Gnome - GnomeCC

Re: Automake Silent Rules

2009-11-24T14:41:15Z

On Tue, 2009-11-24 at 22:26 +0000, Thomas Wood wrote:
> On Nov 24, 2009, at 11:16 AM, Thomas Wood wrote:
> > Would anyone object to enabling automake silent rules by default?
>
> And while we're on the subject of build machinery, can I suggest
> moving configure.in to configure.ac?
>
as you like :)

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-24T14:33:39Z

On Mon, 2009-11-23 at 23:17 -0500, Matthias Clasen wrote:

> On Fri, Nov 20, 2009 at 7:05 AM, Sergey Udaltsov
> <sergey.udaltsov@...> wrote:
> > Hello Thomas
> >
> >> * a single window approach (no separate capplet windows)
> > Heh, I see you want to reinvent MacOS CC, don't you ?;)
> >
> >> * a common way to change 'system' properties (i.e. a way to become root
> >> when needed)
> > How do you plan to do it so that it would work in all distros???
>
> The fairly well-established answer to this question is to have a
> system bus service that provides an api for the capplet to use.
> Vendors can then provide their own implementation of the api. This
> setup also makes it very easy to use PolicyKit for controlling access
> to system settings.

maybe it's time to resurrect my (not sure if totally dead) AdminKit ->
http://git.opensuse.org/?p=projects/adminkit.git;a=summary and add
support for it to GNOME System Tools to provide the system-wide settings
UI?

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Automake Silent Rules

2009-11-24T14:26:08Z

On Nov 24, 2009, at 11:16 AM, Thomas Wood wrote:
> Would anyone object to enabling automake silent rules by default?

And while we're on the subject of build machinery, can I suggest
moving configure.in to configure.ac?

Regards,

Thomas
_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Categorisation in Control-Centre 3.0

2009-11-24T09:39:35Z

Hi there,

As may be becoming obvious we’re interested in improving Control Centre at Intel both to make it better for GNOME and so we can use the shell to manage settings in a future version of Moblin. As such I’ve been looking at the caplets and potential categorisation. We plan to do some more usability work on this sort in the new year so it’s in no way fixed.

This also includes all of the settings on the device. We’re interested in managing all the user’s settings within a single interface. We believe that two categories are useful, Your settings and Device settings with a third, application settings available but not necessarily shown by default.

Your settings

----------------

Accessibility

Fonts

Language

Preferred Apps

Security/passwords

Sharing (file, upnp etc.)

Update system

Wallpaper

Your contact details

Device/Hardware settings

-------------------------------

Bluetooth

Date & Time

Displays and projectors

External devices

Keyboard

Location and GPS

Network

Power

Printing

Sound

Trackpad and Mouse

This category would also contain the settings from:

Default Printer - merge with printing

Network Proxy - merge into network

Keyboard shortcuts - merge with keyboard

My Web Accounts

----------------------

Only available if we don't aggregate these into one magic setting within Your settings category. (i.e. the existence of this category is a fallback). Note: these functions are quite Moblin specific.

Calendar

Photos

Status updates

Sync

Application settings

------------------------

We’d like to expose an entry point to settings and preferences for every app on the device, although this would be deprioritised within the interface to avoid potential settings flood.

This sort and should work surprisingly well in the unified design that Thomas Wood and I have been playing around with. I’d certainly be interested in seeing people’s views on this. I’d certainly hope that we’re working in the spirit of stuff like this http://live.gnome.org/SystemSettings

Nick

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-24T09:25:20Z

On Mon, 2009-11-23 at 13:59 +0100, Rodrigo Moya wrote:
> if we plan for it to be in 3.0, I guess so, since dconf will probably
> replace gconf. But do we want the new control-center for 2.30 also?

Not sure, it's a fairly whole encompassing UI change, so I'm not sure it
could fall under the 2.x umbrella.

I've pushed my experiments with xembed into the single-window branch.
Screenshots for the impatient are here:
http://www.gnome.org/~thos/screenshots/

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Automake Silent Rules

2009-11-24T03:16:46Z

Would anyone object to enabling automake silent rules by default?

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Future of Default Applications

2009-11-24T02:55:53Z

On Sat, 2009-11-14 at 18:35 +0000, Thomas Wood wrote:

> Hi all,
>
>
> I've been going through the Default Applications capplet bugs in
> bugzilla and come across this:
>
> http://bugzilla-attachments.gnome.org/attachment.cgi?id=68324
>
> Which to me is just fairly horrible. If people want to add more and more
> handlers to Default Applications¹, it's going to get ugly very quickly.

This is crap, and obviously won't be integrated.

> If applications can provide an interface to set themselves as the
> default application (like many browsers already do), do we even need
> these options in the control center? If we do, then perhaps we could
> re-design this capplet so it's a bit more scalable so we can cover more
> ground.
>
> There is already a suggestion for a slightly simpler interface². Perhaps
> we could use this an collapse most of the options into a treeview or
> something?
>
> What do people think?

There are a number of things that the default applications is trying to
solve:
1) Supporting applications which don't use a mime-type at all:
- Terminals
2) Applications which handle only "schemes":
- SIP, Callto, mailto, etc.
- This would be needed because installing GConf schemas handling those
as Totem does (rtsp, pnm, etc.) doesn't scale when multiple applications
can handle them
3) Applications which handle both "schemes" and "mime-types":
- Web browser (default for HTML mime-type, http/https schemes)
- Multimedia apps (default for gnome-settings-daemon when pressing the
"media player" key, could make itself default for handling all the
mime-types and schemes it handles, not done now)

I believe that a system that would allow multiple applications to
register themselves as interested in handling a particular scheme would
solve most of our problems.

Cleaning up the differences between handling schemes and mime-types
might also do the code some good.

Cheers

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-23T20:17:34Z

On Fri, Nov 20, 2009 at 7:05 AM, Sergey Udaltsov
<sergey.udaltsov@...> wrote:
> Hello Thomas
>
>> * a single window approach (no separate capplet windows)
> Heh, I see you want to reinvent MacOS CC, don't you ?;)
>
>> * a common way to change 'system' properties (i.e. a way to become root
>> when needed)
> How do you plan to do it so that it would work in all distros???

The fairly well-established answer to this question is to have a
system bus service that provides an api for the capplet to use.
Vendors can then provide their own implementation of the api. This
setup also makes it very easy to use PolicyKit for controlling access
to system settings.
_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Future of Default Applications

2009-11-23T19:53:02Z

On Sat, Nov 14, 2009 at 1:35 PM, Thomas Wood <thos@...> wrote:

>
> What do people think?
>

In my opinion, 'default applications' and 'startup applications' (the
former session capplet) and maybe also part of the menu editor
functionality belong together in a single 'applications' capplet.
_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-23T09:53:15Z

On Mon, 2009-11-23 at 16:06 +0100, Rodrigo Moya wrote:

> On Mon, 2009-11-23 at 14:48 +0000, Thomas Wood wrote:
> > On Mon, 2009-11-23 at 14:01 +0100, Rodrigo Moya wrote:
> > > we could have the capplets provide a .so in some known directory, and
> > > them providing an entry point which returns a GtkWidget also, instead
> > > of
> > > GtkPlug/GtkSocket
> >
> >
> > This wouldn't allow the capplets to run out of process (while still
> > "inside" the shell) though, which might be an advantage.
> >
> you are right, if that's what we want, it makes sense to use
> GtkPlug/GtkSocket

I've written up a very quick shell and added a --socked-id option to two
of the capplets to get the to appear inside it. It seems to work pretty
well and with a bit of input from Nick, looks fairly decent now too.
Perhaps I'll push it to a branch in control-center tomorrow?

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-23T08:57:40Z

On 20 Nov 2009, at 18:07, Rodrigo Moya wrote:

>> right. So, would the .desktop file of each capplet have to include all
> the related tags to that capplet?

The way OSX seems to do it, FWIW, is just to match against all the GUI labels in each capplet. Which is nice in the sense that you don't have to worry about keeping some separate list of tags up to date, in every language you care about. On the downside, you miss out on some synonyms -- e.g. searching for "projector" in the OS X control center yields nothing, as projectors aren't mentioned in the Displays capplet.

(Presumably we'd need to have a policy that every capplet was implemented with a .ui file if we wanted to do it that way, though...?)

Cheeri,
Calum.

--
CALUM BENSON, Interaction Designer Sun Microsystems Ireland
mailto:calum.benson@... OpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

RE: Control Center 3.0

2009-11-23T08:56:48Z

>-----Original Message-----
>From: Bastien Nocera [mailto:hadess@...]
>Sent: Monday, November 23, 2009 12:45 PM
>To: Nick Richards
>Cc: 'Rodrigo Moya'; 'Thomas Wood'; gnomecc-list@...
>Subject: RE: Control Center 3.0
>
>On Mon, 2009-11-23 at 12:37 +0000, Nick Richards wrote:
>> >-----Original Message-----
>> >From: gnomecc-list-bounces@... [mailto:gnomecc-list-
>> >bounces@...] On Behalf Of Rodrigo Moya
>> >Sent: Friday, November 20, 2009 6:08 PM
>>
>>
>> >> * a single window approach (no separate capplet windows)
>> >>
>> >I agree on a single window approach, although I think it would be
>great
>> >to continue having the capplets as separate apps
>>
>> In particular this would be handy for us in Moblin as our current plan
>is to
>> put a lot of settings from a number of different sources into this
>> interface.
>
>If you intend on using the GNOME control-center shell for Moblin, we'd
>also need to make sure only relevant settings are shown, and
>"OnlyShownIn" keys are respected. For example, you wouldn't want to show
>GNOME's Bluetooth preferences when Moblin already has a native version
>of it.

This is a very good point and something we'd certainly want to have. It's
quite likely that we'd want a different categorisation as well as a
different selection - similar to our app launcher - which is I think
currently done by a heroically large rewriting of .desktop files.

Nick

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-23T07:06:51Z

On Mon, 2009-11-23 at 14:48 +0000, Thomas Wood wrote:

> On Mon, 2009-11-23 at 14:01 +0100, Rodrigo Moya wrote:
> > we could have the capplets provide a .so in some known directory, and
> > them providing an entry point which returns a GtkWidget also, instead
> > of
> > GtkPlug/GtkSocket
>
>
> This wouldn't allow the capplets to run out of process (while still
> "inside" the shell) though, which might be an advantage.
>

you are right, if that's what we want, it makes sense to use
GtkPlug/GtkSocket

> Otherwise, a simple plugin api using GModule might suffice.
>
I think it would make things easier for 3rd parties to write capplets,
but we'll have to risk crashing the whole control center if one of them
behaves badly, yeah

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-23T06:48:00Z

On Mon, 2009-11-23 at 14:01 +0100, Rodrigo Moya wrote:
> we could have the capplets provide a .so in some known directory, and
> them providing an entry point which returns a GtkWidget also, instead
> of
> GtkPlug/GtkSocket

This wouldn't allow the capplets to run out of process (while still
"inside" the shell) though, which might be an advantage.

Otherwise, a simple plugin api using GModule might suffice.

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-23T05:01:44Z

On Sun, 2009-11-22 at 13:19 +0000, Thomas Wood wrote:

> On Fri, 2009-11-20 at 19:07 +0100, Rodrigo Moya wrote:
> > I agree on a single window approach, although I think it would be great
> > to continue having the capplets as separate apps
>
> Sounds nice, especially as we wouldn't want third party capplets causing
> bugs to reported against the control center.
>
> What would be the best way to do this these days? GtkPlug/Socket, or
> some other way?
>

we could have the capplets provide a .so in some known directory, and
them providing an entry point which returns a GtkWidget also, instead of
GtkPlug/GtkSocket

Then, for having them as standalone, we can have a simple binary
("gnome-preferences display" for instance) that just loads that widget?

> >
> > > * a common way to change 'system' properties (i.e. a way to become root
> > > when needed)
> > >
> > that's a cool idea also, and using PolicyKit it should be easy, right?
>
> That's what I'd hope, although I don't know much about PolicyKit API.
>
I've only used it once, but it was quite easy to use. The harder stuff
is how to show the options in the UI :)

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-23T04:59:00Z

On Sat, 2009-11-21 at 11:52 +0000, Thomas Wood wrote:

> On Fri, 2009-11-20 at 19:34 -0500, David Zeuthen wrote:
> > > Essentially, you will write to '/system/whatever/path' in dconf and
> > that
> > > will only return after all the polkit stuff is done (possibly
> > failing,
> > > of course).
> >
> > Cool, this sounds perfect - let me know if you any questions about how
> > to make polkit do all this.
> >
> > Hopefully this feature will be useful in the new control center.
>
> I guess this raises another question, which is, should we be basing the
> new control center on DConf/GSettings?
>

if we plan for it to be in 3.0, I guess so, since dconf will probably
replace gconf. But do we want the new control-center for 2.30 also?

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

RE: Control Center 3.0

2009-11-23T04:45:09Z

On Mon, 2009-11-23 at 12:37 +0000, Nick Richards wrote:

> >-----Original Message-----
> >From: gnomecc-list-bounces@... [mailto:gnomecc-list-
> >bounces@...] On Behalf Of Rodrigo Moya
> >Sent: Friday, November 20, 2009 6:08 PM
>
>
> >> * a single window approach (no separate capplet windows)
> >>
> >I agree on a single window approach, although I think it would be great
> >to continue having the capplets as separate apps
>
> In particular this would be handy for us in Moblin as our current plan is to
> put a lot of settings from a number of different sources into this
> interface.

If you intend on using the GNOME control-center shell for Moblin, we'd
also need to make sure only relevant settings are shown, and
"OnlyShownIn" keys are respected. For example, you wouldn't want to show
GNOME's Bluetooth preferences when Moblin already has a native version
of it.

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

RE: Control Center 3.0

2009-11-23T04:37:39Z

>-----Original Message-----
>From: gnomecc-list-bounces@... [mailto:gnomecc-list-
>bounces@...] On Behalf Of Rodrigo Moya
>Sent: Friday, November 20, 2009 6:08 PM

>> * a single window approach (no separate capplet windows)
>>
>I agree on a single window approach, although I think it would be great
>to continue having the capplets as separate apps

In particular this would be handy for us in Moblin as our current plan is to
put a lot of settings from a number of different sources into this
interface.

Nick

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-22T05:19:49Z

On Fri, 2009-11-20 at 19:07 +0100, Rodrigo Moya wrote:
> I agree on a single window approach, although I think it would be great
> to continue having the capplets as separate apps

Sounds nice, especially as we wouldn't want third party capplets causing
bugs to reported against the control center.

What would be the best way to do this these days? GtkPlug/Socket, or
some other way?

>
> > * an 'intelligent' search bar in the shell window (e.g. 'projector'
> > matches display properties)
> >
> right. So, would the .desktop file of each capplet have to include all
> the related tags to that capplet?

Well, we'd have to think carefully about where to store the data (plus
localized versions), especially if it would be useful to applications
outside control center.

>
> > * a common way to change 'system' properties (i.e. a way to become root
> > when needed)
> >
> that's a cool idea also, and using PolicyKit it should be easy, right?

That's what I'd hope, although I don't know much about PolicyKit API.

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-22T04:18:22Z

That is a very good point! The search does not make sense at all if
keywords are not i18ned. That raises another small question - should
'search' be done on localized keywords only - or 'localized +
English'?

In relation to implementation - would it be compatible with existing
meta-data engine? So that people who search for клавиатура ("keyboard"
in Russian) would find, among other materials, the capplet?

Cheers,

Sergey
_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-21T03:52:22Z

On Fri, 2009-11-20 at 19:34 -0500, David Zeuthen wrote:

> > Essentially, you will write to '/system/whatever/path' in dconf and
> that
> > will only return after all the polkit stuff is done (possibly
> failing,
> > of course).
>
> Cool, this sounds perfect - let me know if you any questions about how
> to make polkit do all this.
>
> Hopefully this feature will be useful in the new control center.

I guess this raises another question, which is, should we be basing the
new control center on DConf/GSettings?

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-21T03:49:04Z

On Sat, 2009-11-21 at 11:01 +0100, Jens Granseuer wrote:
> >
> > and was written by Matthias Clasen (patch is sitting in bugzilla
> > somewhere - IIRC someone didn't like it).
>
> I guess that someone was me, and I still don't like it.

And me. Adding "Set Default" buttons on every dialog is just horrible,
which is why I raised the point again so that we can do it nicely.

My main problems with the "Make Default" buttons are that I would
imagine most people have no idea what "Make Default" would do and most
people wouldn't care about it even if they did know. I think a less
obtrusive solution would be much more desirable.

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-21T02:01:55Z

On Fri, 2009-11-20 at 17:51 -0500, David Zeuthen wrote:

> On Fri, 2009-11-20 at 12:52 +0000, Thomas Wood wrote:
> > > > * a common way to change 'system' properties (i.e. a way to become
> > > root
> > > > when needed)
> > > How do you plan to do it so that it would work in all distros???
> >
> > I don't know, what solutions do we have? This is mainly to set things
> > like 'default background' I guess.
>
> Today we do this in Fedora through a GConf patch (I think the GConf bit
> is upstream already) - it looks like this
>
> http://people.freedesktop.org/~david/gconf-polkit-default-background.png
> (note: the latest polkit version has features to make the auth dialog text
> look nicer - e.g. display "Authentication is required to change the
> background for all users" - we're just not using it yet)
>
> and was written by Matthias Clasen (patch is sitting in bugzilla
> somewhere - IIRC someone didn't like it).

I guess that someone was me, and I still don't like it. The approach is
broken and scales even worse than the list of capplets we currently have
in the menu. You start with adding a button for "set background
system-wide", then you add "set desktop font system-wide", "set theme
system-wide", and "set proxy system-wide", and then you blink and
realise you've cloned every single button in the preferences and added a
"system-wide" variety. (And no, I'm not making that stuff up (at least
not completely); some requests are already in bugzilla).

I don't remember where it was mentioned but I suppose it was either in a
mail from Calum Benson, or from Matthew Thomas, where it was talked
about adding a generic way of being able to make all settings apply
system-wide without adding tons of UI clutter. Now, that's something
that would make a lot of sense, but simply adding legions of duplicate
buttons doesn't.

Jens

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-20T16:34:08Z

On Fri, 2009-11-20 at 18:14 -0600, Ryan Lortie wrote:
> On Fri, 2009-11-20 at 17:51 -0500, David Zeuthen wrote:
> > Anyway, I think GSettings/DConf will have native polkit support for
> > things like this. I've added Ryan Lortie to the Cc to ask for this.
>
> Yes. It will. Thanks for reminding me that this is on my TODO list. :)
>
> Essentially, you will write to '/system/whatever/path' in dconf and that
> will only return after all the polkit stuff is done (possibly failing,
> of course).

Cool, this sounds perfect - let me know if you any questions about how
to make polkit do all this.

Hopefully this feature will be useful in the new control center.

Thanks,
David

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-20T16:14:40Z

On Fri, 2009-11-20 at 17:51 -0500, David Zeuthen wrote:
> Anyway, I think GSettings/DConf will have native polkit support for
> things like this. I've added Ryan Lortie to the Cc to ask for this.

Yes. It will. Thanks for reminding me that this is on my TODO list. :)

Essentially, you will write to '/system/whatever/path' in dconf and that
will only return after all the polkit stuff is done (possibly failing,
of course).

Cheers

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-20T14:51:26Z

On Fri, 2009-11-20 at 12:52 +0000, Thomas Wood wrote:
> > > * a common way to change 'system' properties (i.e. a way to become
> > root
> > > when needed)
> > How do you plan to do it so that it would work in all distros???
>
> I don't know, what solutions do we have? This is mainly to set things
> like 'default background' I guess.

Today we do this in Fedora through a GConf patch (I think the GConf bit
is upstream already) - it looks like this

http://people.freedesktop.org/~david/gconf-polkit-default-background.png
(note: the latest polkit version has features to make the auth dialog text
look nicer - e.g. display "Authentication is required to change the
background for all users" - we're just not using it yet)

and was written by Matthias Clasen (patch is sitting in bugzilla
somewhere - IIRC someone didn't like it).

Anyway, I think GSettings/DConf will have native polkit support for
things like this. I've added Ryan Lortie to the Cc to ask for this.

Thanks,
David

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-20T10:07:30Z

On Thu, 2009-11-19 at 23:59 +0000, Thomas Wood wrote:

> Hi,
>
> We've been discussing various things on IRC about what we'd all like to
> see in Control Center for GNOME 3.0. Quite a lot of people are
> interested in this, including folks from the gnome-shell team, the
> Moblin team, Sun and others.
>
> I think, for starters we all share the same vision. Here are a couple of
> goals I think we are aiming for:
>
> * a single window approach (no separate capplet windows)
>

I agree on a single window approach, although I think it would be great
to continue having the capplets as separate apps

> * an 'intelligent' search bar in the shell window (e.g. 'projector'
> matches display properties)
>
right. So, would the .desktop file of each capplet have to include all
the related tags to that capplet?

> * a common way to change 'system' properties (i.e. a way to become root
> when needed)
>
that's a cool idea also, and using PolicyKit it should be easy, right?

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-20T09:58:58Z

On Fri, 2009-11-20 at 18:54 +0100, Jens Granseuer wrote:

> On Fri, 2009-11-20 at 12:05 +0000, Sergey Udaltsov wrote:
> > > * scalability with third party 'capplets'
> > This one IMHO would be more realistic than supporting system editing
> > inside main gnome tree. Once we make capplets easy to create and
> > integrate (and, if we manage that, even plug extra functions to
> > existing capplets) - we could leave the rest to distromakers.
>
> I'd say capplets are pretty easy to write and integrate. After all, they
> are just regular (if usually smallish) apps. The problem with the
> current system is that it doesn't scale, though. Add 10 custom
> preferences panels, and you need Google maps to find the setting you
> need.
>
> I'm not sure that "better search" and "tagging" are sufficient answers
> to this problem but since I don't have any of my own they are probably
> better than nothing.

Multi-language keywords...

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-20T09:54:30Z

On Fri, 2009-11-20 at 12:05 +0000, Sergey Udaltsov wrote:
> > * scalability with third party 'capplets'
> This one IMHO would be more realistic than supporting system editing
> inside main gnome tree. Once we make capplets easy to create and
> integrate (and, if we manage that, even plug extra functions to
> existing capplets) - we could leave the rest to distromakers.

I'd say capplets are pretty easy to write and integrate. After all, they
are just regular (if usually smallish) apps. The problem with the
current system is that it doesn't scale, though. Add 10 custom
preferences panels, and you need Google maps to find the setting you
need.

I'm not sure that "better search" and "tagging" are sufficient answers
to this problem but since I don't have any of my own they are probably
better than nothing.

Jens

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-20T04:52:06Z

On Fri, 2009-11-20 at 12:05 +0000, Sergey Udaltsov wrote:
>
> > * a single window approach (no separate capplet windows)
> Heh, I see you want to reinvent MacOS CC, don't you ?;)
>

Well, I think there are certain improvements that we could make if we
were doing that ;-)

> > * a common way to change 'system' properties (i.e. a way to become
> root
> > when needed)
> How do you plan to do it so that it would work in all distros???

I don't know, what solutions do we have? This is mainly to set things
like 'default background' I guess.

>
> > * scalability with third party 'capplets'
> This one IMHO would be more realistic than supporting system editing
> inside main gnome tree. Once we make capplets easy to create and
> integrate (and, if we manage that, even plug extra functions to
> existing capplets) - we could leave the rest to distromakers.

It is true that the 'system settings' has been the area distro makers
have traditionally used to differentiate themselves. I'm all for
allowing this to continue and building a frame work that makes it easier
for distros to integrate 'system settings' into the control center
shell.

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Control Center 3.0

2009-11-20T04:05:22Z

Hello Thomas

> * a single window approach (no separate capplet windows)
Heh, I see you want to reinvent MacOS CC, don't you ?;)

> * a common way to change 'system' properties (i.e. a way to become root
> when needed)
How do you plan to do it so that it would work in all distros???

> * scalability with third party 'capplets'
This one IMHO would be more realistic than supporting system editing
inside main gnome tree. Once we make capplets easy to create and
integrate (and, if we manage that, even plug extra functions to
existing capplets) - we could leave the rest to distromakers.

Cheers,

Sergey
_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Control Center 3.0

2009-11-19T15:59:01Z

Hi,

We've been discussing various things on IRC about what we'd all like to
see in Control Center for GNOME 3.0. Quite a lot of people are
interested in this, including folks from the gnome-shell team, the
Moblin team, Sun and others.

I think, for starters we all share the same vision. Here are a couple of
goals I think we are aiming for:

* a single window approach (no separate capplet windows)

* an 'intelligent' search bar in the shell window (e.g. 'projector'
matches display properties)

* a common way to change 'system' properties (i.e. a way to become root
when needed)

* some way to set system defaults

* better categorisation of settings

* scalability with third party 'capplets'

* make sure we fit on (e.g.) 1024x600

* Is there anything people think I've missed out?

Further References:

mpt's ideas: http://live.gnome.org/SystemSettings

Sun's ideas:
http://live.gnome.org/UsabilityProject/Whiteboard/ControlCenter

Various bits of info: http://live.gnome.org/ControlCenter

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Future of Default Applications

2009-11-14T10:35:43Z

Hi all,

I've been going through the Default Applications capplet bugs in
bugzilla and come across this:

http://bugzilla-attachments.gnome.org/attachment.cgi?id=68324

Which to me is just fairly horrible. If people want to add more and more
handlers to Default Applications¹, it's going to get ugly very quickly.
If applications can provide an interface to set themselves as the
default application (like many browsers already do), do we even need
these options in the control center? If we do, then perhaps we could
re-design this capplet so it's a bit more scalable so we can cover more
ground.

There is already a suggestion for a slightly simpler interface². Perhaps
we could use this an collapse most of the options into a treeview or
something?

What do people think?

Regards,

Thomas

¹ which they do, see bug 171871, 345715, 536818, 557346

² https://bugzilla.gnome.org/show_bug.cgi?id=592509

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Auto-generating ChangeLog files?

2009-11-14T07:20:04Z

I've pushed the generation rulse to master. Be aware, the generation can
actually take some time (around 28 seconds on my system). However, this
is only run when you make dist, so it shouldn't be a big problem.

Regards,

Thomas

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list

Re: Auto-generating ChangeLog files?

2009-11-13T10:17:52Z

On Fri, 2009-11-13 at 17:31 +0000, Thomas Wood wrote:

> On Fri, 2009-11-13 at 17:41 +0100, Jens Granseuer wrote:
> > On Thu, 2009-11-12 at 23:02 +0000, Thomas Wood wrote:
> > > However, I haven't quite worked out how to create the top level
> > > ChangeLog and also ensure it doesn't duplicate any information from
> > the
> > > individual sub-ChangeLogs. Does anyone have any ideas?
> >
> > How about doing away with the separate ChangeLogs? They made things a
> > bit easier when it was tedious to get the info out of cvs/svn, but I'm
> > not sure they are still all that helpful.
>
> Works for me, I just assumed packages would preferred the separate ones.
>

sounds good to me also, specially if Thomas needs to spend lots of time
trying to auto-generating it.

So yeah, go ahead if you want

_______________________________________________
gnomecc-list mailing list
gnomecc-list@...
http://mail.gnome.org/mailman/listinfo/gnomecc-list