! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Enhancement: Do not make the first mousepad a "server"
Status:
RESOLVED: WONTFIX
Severity:
enhancement
Product:
Mousepad
Component:
General

Comments

Description DarkTrick 2019-12-23 15:02:53 CET
Created attachment 9329 
**test** implementation based on version 0.4.2 of mousepad ( https://git.xfce.org/apps/mousepad/snapshot/mousepad-0.4.2.tar.gz )

Current behaviour:
The first started mousepad instance becomes a "server" for subsequent calls.
If a second mousepad gets started, instead of starting an individual instance, it calls "new window" on the existing instance.

Problem:
Calling mousepad has not always the same effect:
- Calling it the first time makes it a "server".
- Calling it a second/third time just attaches to the "server".
This becomes feeling arbitrary, especially if there are several virtual desktops with an unknown number (maybe 0) of mousepads.

Suggested behaviour:
-- start mousepad ( lets call it `instance A`)
-- mousepad checks, if there is an instance running
---- if yes: call "new window" on it
---- if no: 
-------- start a *new* instance of mousepad, that has no window (lets call it `instance B`).
-------- call "new window" on instance B. Instance B now has a window.
-------- terminate instance A

Attachment:
I provided a diff of main.c between mousepad 0.4.2 and my changes. I will also provide a full main.c in the next post.
The attachment is not aiming for release code.

I'd like to ask about the acceptance of this suggestion. If the code would be "cleaned up" and implemented for "trunc" (not version 0.4.2), is there a chance of applying it?
So far I did not hear cons for my idea and pros for the current implementation.
Perhaps the current code is not cleanable because of the process spawn? (I might have overlooked edge cases).
Comment 1 DarkTrick 2019-12-23 15:03:55 CET
Created attachment 9331 
full main.c file with applied changes. Also based on version 0.4.2
Comment 2 Matthew Brush editbugs 2019-12-23 15:32:47 CET
It's hard to see what's changed without a patch/diff.

I'm not sure if I'm misunderstanding but AFAIK the way it's supposed to work is:

  Open Mousepad from terminal/launcher/etc...
      1. If there's an existing process/instance running (ie. at least one window open)
          - Open a new top-level window in that instance rather than launching a new process.
      2. If there's no windows open
          - Start a new process/instance and open a window in it.

  Close the last Mousepad window, close the whole process/instance. Next launch, goto #2 above.

This sounds more or less like your suggested behaviour, except you say "-------- terminate instance A" which is confusing since there shouldn't be any Mousepad process/instance running unless there's at least one window open. If all windows are closed and you still see a 'mousepad' process running, that might be a bug.

I believe the current behaviour is meant to be like GtkApplication/GtkApplicationWindow stuff from GTK+3 except it was written before those APIs were available in the supported GTK+ versions.

----
Note: As an alternative to the above, you can configure Mousepad with `./configure --disable-dbus` and it will just always create a separate process/instance for each window.
Comment 3 DarkTrick 2019-12-23 15:40:35 CET
> It's hard to see what's changed without a patch/diff.
The first attachment is supposed to contain a diff.
The second attachment is supposed to contain the main.c file (I didn't touch any other file).

I'm not used to the diffing process, if I made a mistake, please let me know.

> 1. If there's an existing process/instance running (ie. at least one window open)
>    - Open a new top-level window in that instance rather than launching a new process.
If your run from terminal, you cannot stop the process with Ctrl+C

> 2. If there's no windows open
>     - Start a new process/instance and open a window in it.
If you run from terminal, you will be able to terminate that process with Ctrl+C (and all it's top level windows)

My suggestion is to ("from a users perspective") always get into case (1) and never do (2).

>  except you say "-------- terminate instance A" which is confusing since there shouldn't be any Mousepad process/instance running unless there's at least one window open.
By the time instance A is terminated (1) has already finished. I.e. the initially windowless created instance B got a new toplevel window from intance A.
Comment 4 Matthew Brush editbugs 2019-12-23 15:58:24 CET
(In reply to DarkTrick from comment #3)
> > It's hard to see what's changed without a patch/diff.
> The first attachment is supposed to contain a diff.
> The second attachment is supposed to contain the main.c file (I didn't touch
> any other file).
> 
> I'm not used to the diffing process, if I made a mistake, please let me know.
> 

Nah my bad, I just opened the latest attachment.

> > 1. If there's an existing process/instance running (ie. at least one window open)
> >    - Open a new top-level window in that instance rather than launching a new process.
> If your run from terminal, you cannot stop the process with Ctrl+C
> 
> > 2. If there's no windows open
> >     - Start a new process/instance and open a window in it.
> If you run from terminal, you will be able to terminate that process with
> Ctrl+C (and all it's top level windows)
> 
> My suggestion is to ("from a users perspective") always get into case (1)
> and never do (2).
> 

It sounds like you want the behaviour achieved using `mousepad --disable-server`? If so and you don't want to type the option (or make an alias to type it for you), recompiling with `./configure --disable-dbus` will make it always behave that way, never doing the "single instance" thing.

> >  except you say "-------- terminate instance A" which is confusing since there shouldn't be any Mousepad process/instance running unless there's at least one window open.
> By the time instance A is terminated (1) has already finished. I.e. the
> initially windowless created instance B got a new toplevel window from
> intance A.

I'm still not sure I understand. There is only ever one "instance" (aka. process) and the process starts with the first window and ends with the last window. There should never be any "windowlesss" instances.
Comment 5 DarkTrick 2019-12-24 01:01:30 CET
I tried to show the effects here in this video (please forgive the poor sound quality. There was no free USB slot for my mic): 
https://youtu.be/olxNuwW9kS0 

> It sounds like you want the behaviour achieved using `mousepad --disable-server`?
No, that's slightly different to what I'm trying to achieve, because with `disable-server` you get several instances of mousepad. My implementation is only working on one single instance.

> There should never be any "windowless" instances.
(Maybe here's the point, that my explanation lacks. Let's start this with:)
1) Why shouldn't there be a windowless instance? 
2) Why shouldn't there be a windowless instance at any point in time?
Comment 6 DarkTrick 2020-01-27 13:17:09 CET
Created attachment 9405 
Diff for new option "-d" for detaching mousepad from terminal

Maybe this is a better implementation of the idea I'm trying to express:

Added new option "-d". If `mousepad -d` is called, mousepad will fork itself and exits the parent. This will make  "init" the parent of mousepad. Even if the terminal closes, mousepad will not be terminated.

Improvement for the user: 
Using `mousepad -d` makes calls consistent in the way, that closing a terminal will not close a running mousepad instance (which might happen with something like `mousepad &`).
Comment 7 Matthew Brush editbugs 2020-01-27 16:59:59 CET
You could also use `nohup mousepad` to achieve a similar effect.
Comment 8 DarkTrick 2020-01-28 13:34:28 CET
Indeed! Good to know!

... does it now make sense to close this bug already...(?)
Comment 9 DarkTrick 2020-02-22 14:15:34 CET
Hm... but you're not finished with  `nohup mousepad`. You need `nohup mousepad &`.
Comment 10 Theo Linkspfeifer editbugs 2020-03-27 13:34:55 CET
We can close this report as Won't Fix, correct?
Comment 11 DarkTrick 2020-03-28 01:34:01 CET
I kept thinking, but yes, it's probably for the best. I closed it.

Bug #16297

Reported by:
DarkTrick
Reported on: 2019-12-23
Last modified on: 2020-03-28

People

Assignee:
Matthew Brush
CC List:
0 users

Version

Target Milestone:
Mousepad 0.4.x

Attachments

Additional information