Adding a DBUS backend (possible migration to GtkApplication)

[Ed-von-Schleck]

This bug is a request for comments on how to proceed with certain modernization aspects of tilda.

I had started the seemingly simple task of eliminating these slightly irritating deprecation errors regarding GtkAction in the context of the (right click) popup menu. These are to be replaced, as I learned, with GAction, and preferably defined within a GMenuModel. While this is all fine and well, the concept of GAction is somewhat tied to having your application run as a GtkApplication, where these GActions are centrally managed. All this introduces quite a lot of code churn, which is unfortunate, but it all seems somewhat reasonable to me.

Now with an application being a GtkApplication, there's seems to be a different idea of starting and stopping an application. It seems to be implied that there's just one running instance, and when started from the desktop or the command line more than once, the already running instance receives the signal "activated". I presume apps like tilda are expected to start one or more terminal windows and manage these child instances itself.

This would be a major departure from the current model, where just more tilda processes are spawned on invocation, although I would think migrating makes sense (also to gain features like being able to be activated by DBus, etc.). It also raises the question of configuring these different terminal windows separately, as has already been stated in the TODO. (Somewhat related, I also entertain the idea that a migration away from libconfuse to GSettings would make sense, because, among other things, one could move the configuration UI to a different binary and would not have to worry about locking, since dconf would handle this transparently. But this is really worth a different ticket.)

I personally do not use multiple instances of tilda. Instead, I use tabs extensively. If I were asked how to handle this problem, I'd just drop the ability to start multiple instances (and get rid of a whole lot of locking code), and just open a new tab on the "activate" signal. This, maybe together with the ability to configure individual (or groups of) tabs differently, would solve this issue for me. However, I assume there are users of the current multi-instance model, and probably good arguments for it, of which I am not aware. So I'd really like some feedback on how I should proceed on that.

Thanks for your time!

[lanoxx]

Hi Ed,

thanks for your thoughts. Yes this is definitely something that I would like to see in tilda. However before you start working on this, please take a look at Issue #30, this issue has already a number of suggestions on how dbus integration could work.

The question would be if it is still possible with GtkApplication to start multiple processes or if it has to be multiple windows in a single process.

I think a possible route towards GtkApplication could look like this:

• Convert tilda to GtkApplication but keep the current approach of separate processes
• Provide command line options to either start a new process or a open a new tab (optionally with a custom command)

I think one argument for the multi instance model is when using multiple screens. Then one can have one instance per screen. There are probably other use cases. Migration to GSettings is something I would like to discuss in a separate ticket.

[Ed-von-Schleck]

Hi Sebastian,

thanks for your feedback! I haven't really thought about multiple screens, so thanks a lot for that line of thought. Yes, I see multiple terminals are really necessary, and tabs alone don't cut it.

I do believe, though, that multiple terminal instances in the same process would do suffice. The user would configure on which screens he would like a terminal instance, and the single tilda process would create as many terminal windows as asked for. In other words, the "activate" signal would not spawn a new process, but the creation of a new terminal window (or tab, as configured), similar to what, say, Firefox does (it doesn't allow multiple instances, but multiple windows).

What I am aiming for is a) code simplification, and b) avoiding an awkward configuration situation – as I understand, configuring multiple tilda instances in a totally different way is currently not really possible (please correct me if I'm wrong here). So having multiple different processes doesn't really add anything to just having one process with multiple terminal windows. From a UI view alone I have a hard time imagining separate configurations for an open-ended number of possible tilda instances. So I'd limit them to: What button raises a terminal on a given screen. But as I said, I could be totally off here. Technically, I believe GtkApplication would not stand in the way of the current model (which is just a 'fork()' away), but would make the previously described model easier.

I have read https://github.com/lanoxx/tilda/issues/30, but I don't yet understand what it has to do with porting to GtkApplication. I would assume that the configuring issue raised (with libconfuse not allowing unstructured data) could be solved with workaround, and in the long run by migrating to GSettings – which is related to this ticket, but as you said, well worth a different one.

So my proposal would be: Keep multiple terminal windows, but have them live in the same singleton tilda process. Then add configuration for which screens should have terminals (and which Buttons bing them up).

Again, thanks for your feedback. I will have to think about it some more, and maybe I can start working on it this week or the next.

Cheers Christian

2014-03-17 15:18 GMT+01:00 Sebastian Geiger notifications@github.com:

Hi Ed,

thanks for your thoughts. Yes this is definitely something that I would like to see in tilda. However before you start working on this, please take a look at Issue #30 https://github.com/lanoxx/tilda/issues/30, this issue has already a number of suggestions on how dbus integration could work.

The question would be if it is still possible with GtkApplication to start multiple processes or if it has to be multiple windows in a single process.

I think a possible route towards GtkApplication could look like this:

• Convert tilda to GtkApplication but keep the current approach of separate processes
• Provide command line options to either start a new process or a open a new tab (optionally with a custom command)

I think one argument for the multi instance model is when using multiple screens. Then one can have one instance per screen. There are probably other use cases. Migration to GSettings is something I would like to discuss in a separate ticket.

— Reply to this email directly or view it on GitHubhttps://github.com/lanoxx/tilda/issues/50#issuecomment-37819989 .

[bnkr]

as I understand, configuring multiple tilda instances in a totally different way is currently not really possible (please correct me if I'm wrong here).

I believe this is not the case. If you start multiple tilda processes it will use different configuration files.like ~/.config/tilda/config_[0-9]+ I don't use this feature but I've seen others using it.

I also think that multiple windows but one process is the way to go. Mostly because I can't fathom how you would move gui tabs and data from process to process. For example we could detach and re-attach tabs if there is one process. The main reason to have several processes for me is to protect from crashes but it's probably not enough to worry about.

[Ed-von-Schleck]

Ah, thanks! I didn't see that documented anywhere! OK, so the possibility to configure each terminal window differently must be preserved in order not to regress feature-wise. Hm, I really need to think about this some more. But thanks for the re-assurance that moving to one process might be a good plan.

2014-03-17 23:06 GMT+01:00 James Webber notifications@github.com:

as I understand, configuring multiple tilda instances in a totally different way is currently not really possible (please correct me if I'm wrong here).

I believe this is not the case. If you start multiple tilda processes it will use different configuration files.like ~/.config/tilda/config_[0-9]+ I don't use this feature but I've seen others using it.

I also think that multiple windows but one process is the way to go. Mostly because I can't fathom how you would move gui tabs and data from process to process. For example we could detach and re-attach tabs if there is one process. The main reason to have several processes for me is to protect from crashes but it's probably not enough to worry about.

— Reply to this email directly or view it on GitHubhttps://github.com/lanoxx/tilda/issues/50#issuecomment-37877078 .

[Ed-von-Schleck]

Thanks for your input; I'm closing the issue for now, as I probably won't have time to work on it for the next two weeks. Besides, I found that I find the conversion to GSettings more pressing (as it plays a lot into any kind of refactoring) and I've started a branch for this, but as I said: There won't be anything new from me for some time.

[lanoxx]

After thinking about this a little more I also think at one process and multiple windows is the way to go. I want to release Tilda 1.2 in a few weeks so this will not make it into version 1.2 but afterwards the master will be open to new features again. So if you would like to work on it, then feel free to do so.

I am reopening this issue to it can be more easily found in the issue list.

I have read https://github.com/lanoxx/tilda/issues/30, but I don't yet understand what it has to do with porting to GtkApplication.

Currently when running tilda a second time it just causes a new process to be spawned, in the future we would like it to be possible to run something like

tilda --new-tab --command="ipython"

And what that should do is to send this command to an already running Tilda instance and exit. The already running Tilda instance should then opened a new tab and execute the command ipython in that tab. I think a port to GtkApplication is required to to implement this functionality of sending commands from one processes to another one.

[lanoxx]

I have pushed some commits that remove the deprecated GtkAction classes and cleans up the menu popup code. As a side-effect now the menu accelerators work properly. That means that keyboard shortcuts are now displayed at the side of the menu and they are also updated correctly when the keybinding changes. The next step will probably be a cleanup of the config system and probably a migration away from libconfuse to some other configuration system, then I am going to revisit this bug.

[lanoxx]

This issue was originally about migration to GtkApplication, there are two possible benefits from this:

• Singleton application, e.g. singe process multiple windows
• We get dbus support for "free".

However we should discuss if a single process model is the best approach or if there are use-cases that require a multi-process model. Second if all that we want is actually DBUS support, then we should discuss other option to support this. As a result I have renamed this bug to reflect this discussion.

With respect to a DBUS interface I think a particular open question is how to address individual windows in DBUS commands. If we go for the single process model, then all dbus commands go the the one running tilda process and we need to specify a name or id for the window that should receive the command, for example:

tilda --window 2 --new-tab --command="htop"

On the other hand if we decide to continue to support multiple processes as in the current design, then each process would probably act as its own dbus server and messages in one process need to be forwarded to another dbus server. Possible example:

tilda --pid 5443 --new-tab --command="htop"
#or alternatively:
tilda --name="foo"--window 2 --new-tab --command="htop"

I am not familiar enough with DBUS to tell how difficult it would be to support the second approach.

[pik]

I've been playing around with this and should have a PR using the second approach this weekendish. I tend to agree that GTKApplication and single process may be a more 'correct' way to add DBus but that requires quite a bit more work. Especially since one of the requirements Sebastian has is that Tilda should be able to run without the DBus dependency which if I'm not wrong is likely to mean maintaining both multi-process and single-process code at the same time. Also as Sebastian mentioned I'm not sure what we gain in terms of actual features from rewriting as single process (I guess draggable tabs between windows would be quite hard to implement with separate processes -- but this seems somewhat like a luxury feature).

@lanoxx Have you had any further thoughts on this? I think @egmontkob should know quite a bit more about this as well.

[pik]

Here is my initial attempt: https://github.com/pik/tilda/tree/tilda-dbus -- I've never written a non-toy program using dbus so let me know if something looks very wrong. At the moment it only supports one method addtab which can be called via ./src/tilda -T <tilda_instance_number> (properly it should also take an --addtab or --method addtab flag but atm there is only one method anyways). A command can be specified with -c (but note we currently exit a tab when a command exits by default, so this should be modified for commands passed via. dbus probably).

I moved the default arg parsing to a struct - tilda_cli_opts because i don't want to setup config values if we are just using dbus (since this will modify the physical config file). Preferably we shouldn't take out a lock on a config file at all if sending a command to DBus because this might lead to weird conditions (suppose we are simultaneously sending a command and starting a new instance, the new instance will skip a lock number which will be released when the command exits). In conjunction with this it would be nice to add named config support - so that you can start a window as e.g. tilda --name foo and call it e.g. tilda --addtab --name foo --command redis-server. Third major thing to consider is of course the command-line option interface - I would like to do something like what tmux does e.g. tmux a -t 0 and have the a action trigger a DBus command specific context group - unfortunately I couldn't figure this out how to do this with Gnome goption (I asked on irc without luck also).