Xfce-mcs-manager is not going to be part of xfce 4.6, it will be replaced by xfconf. Xfwm4 should be using xfconf instead of xfce-mcs-manager to store it's settings.
Created attachment 1620 Migrates non-key-theme settings to xfconf. This patch stores all generic options inside a xfconf-channel. It also makes the settings-array store the values inside GValue structs, to make it easier to move the data to and from xfconf.
Set it as blocking 4.6, and set the target milestone on 4.6 ALPHA. (aka Pinky)
Created attachment 1687 Patch against revision 27054 It only crashes on 'unloadTheme' when a setting is changed. I probably missed something when loading the Theme (the top-side perhaps?) Could you please take a look at it?
Created attachment 1688 Sanitised patch (was missing a few key-shortcuts)
Created attachment 1695 Fixed unload crash (In reply to comment #3) > > It only crashes on 'unloadTheme' when a setting is changed. > > Could you please take a look at it? > I toke a look (long) at it. The property-changed signal callback had not enough arguments, it was missing the GValue, so the stack got corrupted. The patch included contains all the changed from Stephans last patch, and the callback fix.
Created attachment 1696 Fix with --enable-debug=full Patch fixes compile issues with --enable-debug=full It also adds a check for the color_props. (if they are strings or not)
Created attachment 1700 First dialog made ready for xfconf
A few remarks, the patch does not apply on trunk, you'll modified patch attached. I also experienced a hang of xfwm4 using that patch and the modification of settings seems very slow compared to the current implementation (Playing with the compositor settings that cause a repaint in real time).
Created attachment 1701 Modification to apply on trunk
I guess this might be caused by continuous updates while dragging the knob, whereas in the current version the values are updated only on button release.
This is correct, for composite it needs to be handled differently. It is caused by the default behaviour of xfconf_bind_property.
Perhaps this could be fixed in xfconf.
Yes, I noticed this myself while working on the xfdesktop dialog. Definitely needs a fix; I'll open a separate bug so I don't forget.
Created attachment 1704 Patch against r27141 This fixes the lag when setting properties using the slider. (DISCONTINUOUS RANGE update policy) xfwm4-settings-dialog fixes: theme-selection, title-font, focus tab, advanced tab (except for double-click-action) xfwm4-workspaces-dialog fixes: ws-count TODO: button-layout title-alignment double-click-action keyboard-shortcuts workspace-names
Created attachment 1705 bz4065-slider-issue.png Cool. There is still something odd with the sliders, them don't reach the upper value, the windows remain slightly transparent and the slider itself is not at the max (See screenshot).
There is also some options missing (See bz4065-options-missing.png) in the focus tab and also some issues with widgets size/positioning (See bz4065-widgets-truncated.png). I might also be missing some bits as the header does not show and glade complains about libxfce4.so missing.
Created attachment 1706 bz4065-options-missing.png
Created attachment 1707 bz4065-widgets-truncated.png
(In reply to comment #15) > Created an attachment (id=1705) [details] > screenshot > > Cool. There is still something odd with the sliders, them don't reach the upper > value, the windows remain slightly transparent and the slider itself is not at > the max (See screenshot). I noticed that too -- it seems the trick is that you actually have to set the max value of the widget in glade to be 1 *more* than you want. It's kinda weird.
(In reply to comment #16) > I might also be missing some bits as the header does not show and glade > complains about libxfce4.so missing. Yes, the glade detection auto-foo in libxfcegui4 isn't working all the time for some reason. On my todo list to fix.
Created attachment 1708 bz4065-xfwm4-options-missing.png There is also an option missing in xfwm4 settings, which makes me wonder if you may be basing the new dialogs on an older tree of the code.
(In reply to comment #21) > Created an attachment (id=1708) [details] > bz4065-xfwm4-options-missing.png > > There is also an option missing in xfwm4 settings, which makes me wonder if you > may be basing the new dialogs on an older tree of the code. > Sorry, I actually based the dialogs on screenshots of 4.4. I did not contaminate my system with mcs to make sure I didn't accidently forget stuff ;-). I'll add the missing components :)
(In reply to comment #22) > Sorry, I actually based the dialogs on screenshots of 4.4. I did not > contaminate my system with mcs to make sure I didn't accidently forget stuff > ;-). That's what --prefix is for :-P
Created attachment 1712 cumulative patch for xfwm4 xfconf intergration r47154 Button layout configuration and the combo boxes added.
when you have multiple settings windows open and you change the setting in one window the setting also change in the other window (this is good) but this works for most settings, it doesn't work for theme switching, radio buttons and some of the checkboxes
I've been meaning to add a method to only allow a single settings dialog open, but I haven't come up with anything great yet that isn't overly complicated. In that case, that won't matter. Except... it will, because if someone uses xfconf-query to change the value while the dialog is open, we want the dialog to change too.
the slider for raise delay on focus tab in window managers settings seems to be inverted, slow means fast and fast means slow ;)
(In reply to comment #27) > the slider for raise delay on focus tab in window managers settings seems to be > inverted, slow means fast and fast means slow ;) > yuh, labels are wrong... should say 'short' and 'long'. Will fix that with the next update of the patch. (When I added the stuff olivier mentioned missing)
Created attachment 1718 Patch against r27187 Fixes slider-issue and missing options. Only kb-shortcuts and ws-names do not work yet. Olivier: could you take care of those last 2 issues?
(In reply to comment #29) > Created an attachment (id=1718) [details] > Patch against r27187 > > Fixes slider-issue and missing options. > > Only kb-shortcuts and ws-names do not work yet. > > Olivier: could you take care of those last 2 issues? > stupid me... missing a few files in the last patch :p I'll add a fix this evening.
Created attachment 1724 initial keytheme code added. ok.. now all files are in this patch :)
Created attachment 1727 more keytheme code added Some more keytheme stuff
Created attachment 1728 Loads keytheme contents and allows new keythemes to be created TODO: - Update the GUI - Edit Shortcuts - Remove Keythemes - Toggle sensitivity of shortcuts treeview.
Sorry I did not have time to work on the missing bits :(
Created attachment 1745 Fix compile issues and add a little more functionality.
Ok, the patch is making good progress but as a side effect it's becoming harder to manage through bugzilla. There are quite a few regressions here and there, and one single huge patch is not the proper way to allow cooperation on the code, therefore I would now recommend merging to svn and keep working from there (ie the patch is not perfect but good enough as a starting point to commit to svn). What do you think?
Patch committed to svn trunk, rev 27421.
I leave this bug open to track possible regressions and improvements required relative to xfconf support in xfwm4.
Created attachment 1758 Glade With this patch a bit more stuff is broken, but it does a better job in the HIG specs. Also changed the keyboard shortcuts tab in a way I think it would be easier to work with.
Added Jannis since he might be interested in the glade patch.
(In reply to comment #39) > With this patch a bit more stuff is broken, but it does a better job in the HIG > specs. Also changed the keyboard shortcuts tab in a way I think it would be > easier to work with. You are right, this patch improve things on the UI side, but that patch indeed break things that were working (like the title button drag and drop) for no reason (ie do not see why changing the UI has to break stuff that worked). That brings to another point, the glade XML files are inlined in the code, but the precise point of using liglade is to be able to change the XML file without recompiling, so I don't get it.
I said the patch was not perfect ;-), just played around a bit. Glade makes editing the interface easier and removed all the interface build code from the source. Of course you can load the file externally, but when you embed the text is will _always_ work (and it's probably a bit faster too, esp when you let exo strip the source).
I think we can call this fixed. :-)