Re: Formal complaint concerning the use of the name "System Settings" by GNOME

2011-07-23 Thread Dodji Seketeli
Emmanuele Bassi  a écrit:

> On 2011-07-23 at 11:27, Dodji Seketeli wrote:
>> Why?  Do you have an example that would show where Shaun's proposal
>> falls short?
>
> it falls short in showing:
>
>   System Settings
>   KDE System Settings
>
> under Gnome, and:
>
>   System Settings
>   Gnome System Settings
>
> under KDE.

Oh, I see.

> the real solution is to make it unnecessary (or even conflicting) to
> install the KDE system settings shell under a Gnome environment, and the
> Gnome system settings under a KDE environment;

That would be a more elegant situation, IMO.


> these are configuring the system settings, and you can hardly have two
> systems running at the same time on the same machine.

Agreed.  

> applications should not be configured through the *system* settings;
> and both system settings shell should configure the same services.

This makes sense to me.

>> You don't say why these would better address the issue "here and now" in
>> comparison with what Shaun is proposing.
>
> there is no "here and now" — that would be a hack. I hardly think we
> have to solve this *quickly*, so we should solve it correctly.

My point was to have the options written down and have interested people
explicitly say why a particular point is valid or not, rather than just
bluntly dismissing someone's point as being a non-solution without
providing rationale.

As for the "here and now", I don't personally perceive this issue as
urgent as I use GNOME only.  But I could imagine that some people do.

-- 
Dodji


Re: Formal complaint concerning the use of the name "System Settings" by GNOME

2011-07-23 Thread Dodji Seketeli
Denis Washington  a écrit:

> Am 23.07.2011 11:54, schrieb Giovanni Campagna:
>> Il giorno sab, 23/07/2011 alle 11.27 +0200, Dodji Seketeli ha scritto:
>>> Matthias Clasen  a écrit:
>>>
>>>> I don't think Shauns proposal addresses the issue, really.
>>>
>>> Why?  Do you have an example that would show where Shaun's proposal
>>> falls short?
>>
>> You have two .desktop files, matching the same application, so it is
>> possible gnome-shell, unity or kde could pick the wrong one when
>> matching desktop files to windows (unless you tweak Exec to pass
>> --class, but that fails again with single-instance applications)
>
> But one of them is hidden via [Not]OnlyShowIn. There should be code in
> all desktop's .destkop file matchers to prefer the files tailored to
> the respective environment, and if not, it is easy enough to add.

Exactly.

> I think everyone here agrees that this more a less a temporary measure
> and that other long-term solutions such as better cross-desktop
> settings integration is in order.

I couldn't agree more.

Giovanni Campagna  a écrit:

[please don't CC me in your replies.  I am subscribed to at lease one of
 the lists in the To: field]

>> > If you want an app to be usable in different environments, then there
>> > are some good solutions:
>> > - make sure the app is self-contained and manages all of its settings 
>> > itself
>> > - make your app smart enough to pick up the relevant settings from the
>> > different environments you want to support
>> >
>> > And there are bad solutions, including:
>> > - making the app drag along half of its original environment, via 
>> > dependencies
>> 
>> You don't say why these would better address the issue "here and now" in
>> comparison with what Shaun is proposing.
>
> You get to configure your apps once for both Gtk and Qt apps, which is
> better for the user and makes the system more consistent
> In particular, I underline "Gtk and Qt": you don't write GNOME apps, and
> you don't write KDE apps, you write Gtk and Qt (or Qt+kdelibs) apps, and
> then the toolkits adapts themselves to the environment. If you can write
> a Qt+kdelibs app that work on windows or mac os x, you can make it work
> out of the box in GNOME, without dragging in the entire workspace.

You forgot the "here and now" part in my question.  You just can't do
what Mathias is proposing /quickly/ enough.  It would seem to me that we
need a stop gap measure now, while we carefully think about something
more streamlined and future proof to be crafted later.

-- 
Dodji