themes in xffm

[edscott wilson garcia]

El lun, 24-02-2003 a las 09:21, Jasper Huijsmans escribió:

[snip] 
> 
> 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?

Although not entirely finished, the scheme is as follows: 
On changing any option with mcs-manager, the xml file is rewritten and
all xffm instances are notified of the change and apply it immediately
without rereading xml file (except instances on remote machines,
although this could be a configurable point).
On startup, xffm uses the xml file (which is in sync with the
mcs-manager data, except for remote instances). When options are changed
in xffm, the mcs-manager is informed *only* if the options are saved and
the xffm instance is local, so that the dialog-plugin will reflect the
correct settings.

> 
> 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 remote *could* use the local settings, maybe. This would be a great
strength. I have not gotten to the point to do any testing yet.
Otherwise, the remote instances would use remote configuration, like
xftree does. 

> 
> 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.

There are advantages to using different settings for remote instances.
For one, it's an easy way to tell which is which! ;-)

> 
> > 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.

It's really quite simple for an application to check if it's local or
remote. Configuration from there can proceed depending on user
preferences. But since it's not very common, the preference should be a
compile time option for configure.

> 
> 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.
> 

That's exactly what the save option is for in xffm. It's still bugged
though, because the "save view" should only save the view options and
the "save preferences" only the preferences options. At the moment they
are both saving the entire configuration. Theme and icon size are not
modifyable within xffm. Layer, home directory and smb_user are not
active yet and only smb_user would be modifyable from within xffm.


Edscott