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

2011-07-26 Thread Giovanni Campagna
Il giorno lun, 25/07/2011 alle 12.56 +0200, Markus Slopianka ha scritto:
  Which settings don't they follow? Apart from theme (as there is no gtk3
  engine written in Qt yet)
 
 Why do theme engines have to be written for Qt in order to let GTK apps at 
 least integrate 
 visually into a Qt environment. There should be a Qt theme loader in GTK just 
 as there is 
 a GTK theme loader in Qt.

Well, I think that an hypothetical KDE-looking GTK theme would use Qt
calls to paint widget, same as the GNOME-looking Qt theme paints using
gtk_paint_*.

 Well, other than that: GNOME/GTK apps don't integrate with the Notifications 
 panel, File 
 Type Associations, Icon theme, CDDB config (for media players or CD rippers), 
 ...

Gtk apps normally use either libnotify, libappindicator or GtkStatusIcon
(systray protocol). All of them are supported by KDE, AFAIK.
File type associations are from xdg-mime/shared-mime-info, and should be
shared by all freedesktop toolkits.
Icon theme is taken from XSettings, you just need to export it, like
Xfce and Lxde do.
As for CDDB config, I don't think GNOME as something shared across the
desktop for that.

Giovanni


signature.asc
Description: This is a digitally signed message part


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

2011-07-25 Thread Giovanni Campagna
Il giorno dom, 24/07/2011 alle 22.17 +0200, Aurélien Gâteau ha scritto:
 Le 24/07/2011 17:11, Emmanuele Bassi a écrit :
  GTK+ applications use the XSETTINGS keys:
  
  http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html
  
  so every key that is shared using that specification is picked up
  automatically by GTK+ applications.
  
  we can definitely talk about extending the set of shared keys: we
  routinely do that on xdg-list -- for instance when the sound theme
  spec was introduced.
 
 The spec does not provide a list of shared keys, does such a list exist?
 If there is no such list I don't see how we could share anything.

http://wiki.freedesktop.org/wiki/Specifications/XSettingsRegistry

 I don't know what is shared right now but it is definitely not enough: a
 GTK application running on a KDE workspace does not follow KDE
 keybindings, palette, fonts, icon theme, label alignment or dialog
 button order.

 Additionally I don't believe a shared keys system is enough to share a
 widget theme. Otherwise the Oxygen devs probably wouldn't have created
 the Oxygen GTK theme.

Of course, you would need to create a KDE theme. XSettings is just for
choosing which theme among many.

Giovanni



signature.asc
Description: This is a digitally signed message part


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

2011-07-24 Thread Giovanni Campagna
Il giorno dom, 24/07/2011 alle 21.00 +1200, Ben Cooksley ha scritto:
 2011/7/24 Emmanuele Bassi eba...@gmail.com:
  hi;
 
  2011/7/24 Aurélien Gâteau agat...@kde.org:
  Most distributions split KDE packages so if you get a pre-installed
  computer with Gnome and a few KDE applications installed, KDE System
  Settings would not be installed.
 
  You are only likely to get both System Settings pre-installed if your
  computer was shipped with both KDE and Gnome desktops. In this
  situation, I assume you would be provided with some explanation as to
  what KDE and Gnome are.
 
  installing both Gnome and KDE is not equivalent to running both at the
  same time.
 
  if you managed to get yourself into the scenario where KDE and Gnome
  have been installed at the same time then the KDE system settings
  shell should be marked as NotShowIn=Gnome, and the Gnome one should be
  NotShowIn=KDE. currently, gnome-control-center uses:
 
   OnlyShowIn=GNOME;Unity;
 
  so a menu rendered under KDE won't show it. now, googling a bit I found 
  this:
 
   https://git.reviewboard.kde.org/r/102038/
 
  which is, I guess, what really prompted this thread. so, if the KDE
  system settings shell appears alongside any other system settings
  shell it means that the users are not running KDE, but are running any
  other XDG-recognised desktop.
 
  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.
 
  Releases are conflicting right *now*, so yes, I think there is a need to
  solve it quickly, even if the first fix is a short-term one.
 
  the short-term fix is to make the KDE system settings OnlyShowIn=KDE,
  so that users running KDE will not have any issue, and every other
  desktop will correctly not show the KDE system settings shell.
 
 Wrong. Emmanuele, read my initial email to see why that is not an
 acceptable solution under any circumstances.
 It has to be shown in some form, regardless of the name, under all
 desktop environments.

Again, no. There is nothing you want to configure, running under GNOME,
in KDE system settings. Qt apps, running under GNOME, should use Gtk+
style (already done by Qt), GNOME preferred apps and mime-type
associations (already done by shared-mime-info), GNOME networking
preferences (already done by NetworkManager and libproxy), GNOME fonts
(already done by fontconfig). Everything else (desktop effects, hardware
settings, date and time, users...) should not be configurable by KDE
system settings, and will likely conflict if changed. 

Giovanni



signature.asc
Description: This is a digitally signed message part


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

2011-07-24 Thread Giovanni Campagna
Il giorno dom, 24/07/2011 alle 22.37 +1200, Ben Cooksley ha scritto:
 On Sun, Jul 24, 2011 at 10:25 PM, Giovanni Campagna
 scampa.giova...@gmail.com wrote:
  Il giorno dom, 24/07/2011 alle 21.00 +1200, Ben Cooksley ha scritto:
  2011/7/24 Emmanuele Bassi eba...@gmail.com:
   hi;
  
   2011/7/24 Aurélien Gâteau agat...@kde.org:
   Most distributions split KDE packages so if you get a pre-installed
   computer with Gnome and a few KDE applications installed, KDE System
   Settings would not be installed.
  
   You are only likely to get both System Settings pre-installed if your
   computer was shipped with both KDE and Gnome desktops. In this
   situation, I assume you would be provided with some explanation as to
   what KDE and Gnome are.
  
   installing both Gnome and KDE is not equivalent to running both at the
   same time.
  
   if you managed to get yourself into the scenario where KDE and Gnome
   have been installed at the same time then the KDE system settings
   shell should be marked as NotShowIn=Gnome, and the Gnome one should be
   NotShowIn=KDE. currently, gnome-control-center uses:
  
OnlyShowIn=GNOME;Unity;
  
   so a menu rendered under KDE won't show it. now, googling a bit I found 
   this:
  
https://git.reviewboard.kde.org/r/102038/
  
   which is, I guess, what really prompted this thread. so, if the KDE
   system settings shell appears alongside any other system settings
   shell it means that the users are not running KDE, but are running any
   other XDG-recognised desktop.
  
   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.
  
   Releases are conflicting right *now*, so yes, I think there is a need to
   solve it quickly, even if the first fix is a short-term one.
  
   the short-term fix is to make the KDE system settings OnlyShowIn=KDE,
   so that users running KDE will not have any issue, and every other
   desktop will correctly not show the KDE system settings shell.
 
  Wrong. Emmanuele, read my initial email to see why that is not an
  acceptable solution under any circumstances.
  It has to be shown in some form, regardless of the name, under all
  desktop environments.
 
  Again, no. There is nothing you want to configure, running under GNOME,
  in KDE system settings. Qt apps, running under GNOME, should use Gtk+
  style (already done by Qt), GNOME preferred apps and mime-type
  associations (already done by shared-mime-info), GNOME networking
  preferences (already done by NetworkManager and libproxy), GNOME fonts
  (already done by fontconfig). Everything else (desktop effects, hardware
  settings, date and time, users...) should not be configurable by KDE
  system settings, and will likely conflict if changed.
 
 Wrong, wrong and wrong.
 Phonon backend cannot be configured without System Settings.

And that's a feature, I suppose. As a GNOME user, I want GStreamer at
all times (and as a Fedora user, I can't even install xine).

 Standard keyboard shortcuts for KDE applications cannot be configured
 without System Settings.

Which is a KDE bug. You should use GNOME shortcuts when possible. I
mean, Gtk has emacs and Mac OS modes for keybindings, I doubt Qt hasn't
something similar.

 We don't share Date/Time/Localisation/etc - you need System Settings for that.

You don't have $LANG? or org.freedesktop.Accounts? Both are KDE bugs.

 Theme - we both have our own stores of it - you need System Settings
 again (in case you don't believe me, read ~/.gtk2rc)

It is true that you can change KDE theme without changing the GTK one,
but why would one want that? I want the look and feel of my system to be
consistent, even when different apps or toolkits are used, and I want
one place to configure the theme.
(or none, if I'm using GNOME3 /rant)

 KDE Wallet has some of it's configuration stored in System Settings
 too - and it is used by KDE applications even outside KDE for secure
 password storage.

KDE apps under GNOME should use gnome-keyring, not kwallet: that's what
org.freedesktop.Secrets is for.

Giovanni



signature.asc
Description: This is a digitally signed message part