It would be very useful if we could add a command-line switch or a configuration option (and associated functionality) to allow mousepad to open a file in an existing running instance of mousepad, in a new tab. Currently, if you start mousepad on the command line and specify a number of files as arguments, or from thunar, highlight a number of files and select "Open in Mousepad", they all open in the same instance of mousepad in separate tabs. If you later open another file, it creates a new window. It would be nice if we could add new files to this running instance in new tabs from the command line or via a configuration preference like "Always open new files in a tab of an existing instance" (or something like that).
Created attachment 5760 Quick 'n' dirt patch Yeah, this is really annoying. Well, I've spared some time to look at this: Mousepad has something to handle this, using DBus, to open files using an existing instance(main.c:137). I have prepared a python script to invoke this method via the DBus interface[1]. But Mousepad insists to open a new window, but using the same instance. After all this guess and trial session, I've found where the problem lies: mousepad-dbus.c#mousepad_dbus_service_launch_files:161 I've created a quick patch that seems to solve this, I just don't know if it's the best way altogether. 1 - http://pastebin.com/fiHbM6Et
Hi André, do you plan to add this to the next release of Mousepad? This would be a nice addition. The inconsistent behavior is annoying. I'd rather have all documents open in separate windows OR in a single tabbed window (I'd prefer a single, tabbed window). But having both is confusing. If your patch is working, why not push it to mousepad? It would be better than the current situation. Of course making it optional ("Options > [X] always open documents in the same window", or via a command line switch) would be the best thing to happen. Thanks
@Julien, I don't have commit rights and even if I had, I'd like receive some comments about how this should be handled. A GUI option for this is IMHO clutter. Almost every other editor opens new documents in tabs by default, I wonder how many of them gives an option to open in a new window, yet I wonder how many users use this option(or even guess this option exists). A command line option could be useful, but I don't see how. Well, it's up to Matt merge the patch or provide any comment.
I just tested the patch and it works fine. Although I don't feel qualified enough to comment on how this should be coded, from what I can tell, the code is clean and does what it intends to do. I like this option where by default, a new file is opened in an existing mousepad window. Its cleaner, less desktop clutter, and is a common approach among other editors. If you want separate windows, you can easily drag and drop the tab off the mousepad window to create a new mousepad window.
Andre, Code wise: I don't use mousepad so I hardly qualify for a thorough UX regression testing. Could you please just check where the function you modified is currently called? Would adding the patch change the behaviour of any of these functions? If so, could you either use a boolean parameter called "force_new_window" or "use_existing_window" (whichever way makes more sense to you)? Or make the D-Bus iface use a different function implementing your fix? UX wise: Gedit (until the 3.10+ versions which have quite a bunch of what I'd call regressions) opens new files in a tab, unless there is no Gedit instance in the current workspace. This is clever because it gives me a lightweight method to start working on a completely different set of files in a clean state, whilst avoiding window clutter when opening several files in a row. There are different families of habits when it comes to workspace organisation (there's research on the topic but can't remember the name of the researchers): - one WS per activity - one WS per task - one WS per app Those who work per-activity/task are well served by Gedit's default. Those who work per-app may be better served by Mousepad's default (avoiding clutter) *provided they open all the files related to a single activity at the same time*. I don't have any data to answer whether that conditional holds most of the time, but my personal experience is that you tend to need to open a new, additional file which you had not anticipated opening, when programming. Non-programming tasks may differ. The per-app class is a minority anyway, so I would suggest implementing old-Gedit's behaviour: - if there is a window in the current WS, use it - if there is no window in the current WS, create a new one Thanks.
I agree Steve, I don't use multiple workspaces, but it'll be awkward to a user that has a mousepad instance open in workspace #1 and when he opens a text file on workspace #2 apparently nothing happens(though I didn't test this scenario with the patch applied). Matt, is there a simple(non-kludge) way to handle this? I mean, per workspace instance of the app?
@André probably the only way (not sure if it's "hacky" or not) is to use XLib to find if there's a window on the current desktop, and if there is, open a new tab there, else open it in a new window. Maybe something like `_NET_WM_DESKTOP` would be useful.
A D-Bus interface held by Mousepad, which tells your newly launched Mousepad process what to do. I assume this is what Gedit does.
I want to vote on this feature. I use MousePad 0.4.0.
> Reported on: 2014-09-25 Really? 3 years and still we don't think this is something worthwhile? I'm amazed! I would be great to see some reasoning on why this feature shouldn't be there in Mousepad.
It's not about a feature being worth or not, it's about people implementing it. The reason? Xfce is run entirely by volunteers on their spare time, so they spend it where they see fit. I am not using Mousepad much these days, so not surprisingly I haven't touched it in a while. So our options are: 1 - Let it as is because the patch breaks the workflow for multiple workspace users. 2 - Merge the patch, it's better than the current behavior. 3 - Enhance the patch to handle multiple workspaces. Actually, it's quite easy to get the existing window workspace: window = GTK_WIDGET (application->windows->data); workspace = gdk_x11_window_get_desktop (gtk_widget_get_window (GTK_WIDGET (window))); But I wasn't able to figure out how to get the workspace mousepad is about to open a new window to compare and decide to open the file in the current window or a new one. If you're able to put a patch together, I would kindly review and merge.
Hello Andre! Thanks for the prompt reply. :) > If you're able to put a patch together, I would kindly review and merge. Sure! But the thing is I have never worked with GTK before (though I am excited to jump right in!) and currently I'm working on Wget under the Google Summer of Code program so don't really have much of the time. If the issue persists till GSoC gets over, I'll be happy to get my hands dirty with GTK!
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/mousepad/-/issues/14. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev