Does it help to increase monitor-disabling-timer
to something higher?
Sorry I missed this thread.
When I ported Mousepad from rc files to Gsettings, I assumed other parts of Xfce would be doing so as well when transitioning to Gtk3 since Glib had the Gsettings API builtin. It seemed there was no longer any need to maintain a separate configuration system/daemon like there was when xfconf was created, since there was now such a system linked in to every app already. Just mentioning in case anyone is curious of the rationale :)
Maybe so, but I must admit that I don't know ATK at all.
Me either, but I assume it has APIs to interrogate/control the UI.
I don't know if you were thinking of something more "functional" with ATK
It was just in response to your mention about using xdotool
in the future, I imagined it was to simulate clicking and dragging on the UI and such, which sounds brittle, but probably you had other uses of it in mind.
Seems like a good idea, although testing GUIs is a nightmare. I wonder if ATK could somehow be used to make it independent of window position, widget sizes/themes, layout direction, etc?
Would also be cool to add some unit testing eventually too, for the like 10% of Mousepad's code that isn't GObject boilerplate and glue code.
I agree that Mousepad should switch in unison with other apps, it will be weird if half the apps/core uses CSD and the other half doesn't. @ochosi, do you expect most of core and apps will switch for the next release?
I personally don't care either way, making it a compile-time option seems totally reasonable in the meantime.
Are all xfce apps doing this? The only problem I see with your screenshot is that it looses the xfwm controls which seems like a bit of a regression. Otherwise it looks ok.
Don't hesitate to take over, close or supersede !37 (closed) if you want, I just haven't had a lot of time to hack on it. I think you would like LibPeas, it's rather simple to use and you don't have to load other languages if you don't want to.
Sounds like it's getting close to re-implementing all features of LibPeas :)
It just seems to break the "plugin" abstraction a bit, but as a initial implementation for internal use it's probably ok.
I'm not sure I'm visualizing this correctly, as the question of "adding its actions" did not arise for gspell.
Sorry, I should have linked to or commented on the code in question, I was referring to this: !92 (diffs)
It seems like the main application is hardcoded to know about the plugin for this keybinding. Would it be possible for the plugin to get the main window and add its own accelerator to the window's accel group?
It's kind of re-inventing the wheel (libpeas), particularly the finding/loading of modules and the GUI-related parts. I'm not opposed, just wondering if it's a worthwhile tradeoff when libpeas already exists. The main advantage I can see is that it's less boilerplate to implement a plugin (no need to create a GObject).
For the code, the one thing that jumps out is how the action for the gspell plugin is hardcoded into the main application. Would it be possible for plugins to dynamically add their actions?