themes in xffm

[Jasper Huijsmans]

Hey Edscott,

edscott wilson garcia wrote:
> El lun, 24-02-2003 a las 03:00, Jasper Huijsmans escribió:
> 
>>On 23 Feb 2003 19:31:15 -0600
>>edscott wilson garcia <edscott at imp.mx> wrote:
>>[Good stuff about icon themes]
>>
>>The xfce icons have a white background, instead of being transparent.
> 
> Some icons don't. It doesn't bug me in the least so this detail will  be
> fixed over a looooong period of time, unless volunteers step in (fat
> chance).  
> 

hmm, ok ... Jens, can you fix this for me :)))

Seriously, I may have a look at it tonight. It just looks silly, and 
that's too bad, because it should be rather easy to fix.

> 
>>Secondly, in the settings dialog you use option menus for 'View' and
>>'Preferences' (which has to be renamed, because all settings are
>>preferences :), 
> 
> 
> That's a moot point, if it were to apply. But it doesn't: all
> preferences are settings too ;-) 
> BTW, 'Preferences' and 'view' are the elements which correspond in xffm.
> They use the same source code for definition so changes in one reflect
> in the other. So I don't see any changes here.
> 

Ok, it's not entirely moot (they are synonymous, so it's a bit strange 
to use one as a subclass of the other), but I do see your point about it 
being the same as in xffm.

> but you use it as a normal menu with checkbox items.
> 
>>This is confusing and certainly not the way that widget was intended to
>>be used (a list of mutually exclusive options). If you need that many
>>options, they should be in a separate tab on the dialog.
> 
> 
> Nope. It should be a menu, just like in xffm (because there will be no
> settings dialong in xffm). Otherwise it would be confusing to me and I
> prefer that others be confused than me.  The only problem I see in the
> dialog is that the item shown when the menu is not expanded is not shown
> checked when it is checked. This will be fixed with a addition of either
> a checkbox or radio button, when I have the time. The dialog is work in
> progress.
> 

I don't agree, but that's only a matter of opinion I guess.

Maintainability is very important and I can't judge that so that may be 
reason enough to not change anything.

> 
>>Finally, it seems you save options both from xffm and from the mcs
>>dialog. This to me doesn't seem right. IMO, settings should be changed
>>with the plugin only. At least I think that's the way the settings
>>system is suposed to work ...
> 
> Maybe for the panel. But not for xffm. In this case the mcs-manager will
> be a way to change settings of all open xffm windows, while within xffm
> it will only change the current window. When you want to promote the
> local xffm setting to all windows, it will tell mcs-manager and save
> changes. Yes, I know mcs can save after it is told, but I don't want to
> do it that way. Why? Because xffm is meant to be run on both local
> machine and remote machines (where the settings xml is not available to
> the mcs-manager). 
> 

Does this mean the settings plugin never saves its options and xffm 
relies on the xml file rather than the mcs channel to read its 
configuration?

The local / remote instance settings is difficult and I don't feel 
qualified to say much on that subject. I've never run anything remotely.

But ...

I think there may be a problem here with the way the XSETTINGS protocol 
works. The settings manager handles the setttings on a screen. I think 
our manager handles all screens on a display. A remote app displaying on 
my xserver, should then use my local xsettings, if I'm correct.

The panel relies on this and that is why only 'preferences' like icon 
theme, etc. should be in the dialog and not panel 'data' like the actual 
items on the panel (this shows that the 'centering' stuff should not be 
in the dialog and I should just make the panel snap to corners and 
centers). This way I should be able to run remote panels, am I right? 
There may be difficulties with the orientation setting ... hmm, I don't 
know.

> In fact, if the panel relies only on mcs to save configuration, this is
> a *panel* *bug* because then you cannot save configuration for remote
> machines. (Yes, I do run multiple panels, although at the moment the
> remote machines are still on xfce3).
> 

The panel relying on the settings manager is a good thing IMO and if 
there is a problem with running remote instances, there may be a problem 
with the settings manager protocol, not necessarily with the panel.

I really would like to hear Olivier's opinion on this as well. All I can 
say is that I don't like to have different locations to set the same 
settings, although I do see the value of a 'Use as default' option.

/me is very much out of his depth with this remote stuff.

	Jasper