Hi all,

I would like to manage different work areas through differest 'service' users, running applications in one kde session (mainly dolphin, lyx, okular, falkon).
To that aim, it would be very convenient to tell different users by adding proper names or pictures to the title bar of applications .

How would that be possible?
thank you
paolo m.

Seems to me like you are trying to recreate user sessions in a single user session. Why not just have separate users? Recent versions of Plasma make switching user sessions really easy. (I suppose one limiting factor would be the amount of RAM on the machine as depending on how many users we're talking about you'd need enough for each plasma session plus additional apps each user would need).

As for implementing this with a single user, I'd recommend using Activities to separate each service user. Activities are intended to provide that separation of working environments, operating similarly to Virtual Desktops but with some additional capabilities and separate management. Activities can be configured with a name and an icon for easy identification. There are a few different widgets which can be used to help with keeping track of which Activity you are on and switching between Activities.

(for your direct question, I don't know of any ways to add info to the titlebars to help distinguish between the windows pertaining to a specific user; though I believe the use of separate User Sessions or Activities to be better solutions to the problem anyway).

Thank you for your reply and apologize for my delay
The advantage of different users in one session is in managing different kind of works, that can be resumed in the condition they were suspended, thanks to specific configuration of each application, so that lyx history of open files would be specific, falkon would open tabs and sessions that are specific (that would be the same as using different falkon profiles), dolphin would open files with specific lyx command and so specific history, okular would have its specific set of bookmarks.
In short, 'service' users would be instrumental to the 'real' user to remember the subjects pertaining to a given topic. They would be a sort of different profiles of that user.
Dolphin profiles would do the same job, if profiles were allowed, thus opening specific versions of lyx, of falkon, of okular and of any other commands.
But dolphin has no profile facility, as far as i know,
Activities have no profile facility, nor they can be managed by different users, as far as i know.

thank you
paolo m.

So I'm not sure what advantage you are expecting over just having separate logins for each 'service user'?

A fuller description of how you expect the different (real) users to interact with the system would be appreciated.

It sounds like a 'service user' represents varying roles that real users will assume at different times, where each service user has an associated set of tasks they will work on.
Are service users shared by multiple real users? If so, do the different real users expect to share the same session/history when using the same service user, or do you expect separate sessions/histories for each service user for each real user (potentially real users * service users)?

As far as i know, separate logged in users cannot share one session. Te advantage of service users is that they can run in one session.
I think service users could be shared be several real users. They would serve as 'group users'.

Talking about service users, their applications are launched by a plasma widget, by specifying that that command must be launched as another user.
A question on this regard:
Advanced options are possible for the d-bus registration:
- none (default)
- multiple dbus instance
- single dbus instance
- until termination

What do they mean?
thank you
paolo m.

xpol wrote:As far as i know, separate logged in users cannot share one session. Te advantage of service users is that they can run in one session.

How would that be an advantage, since most of your requirements indicate that separate sessions seems like a better fit?

xpol wrote:I think service users could be shared be several real users. They would serve as 'group users'.

Talking about service users, their applications are launched by a plasma widget, by specifying that that command must be launched as another user.
A question on this regard:
Advanced options are possible for the d-bus registration:
- none (default)
- multiple dbus instance
- single dbus instance
- until termination

What do they mean?
thank you
paolo m.

I'm not entirely, but I'd guess this is up to the applications to determine how they interact with dbus and is probably not useful in this discussion.

To help us understand what kinds of behaviors and functionalities you would like to see, would you please describe how you expect the people in your organization to interact with the system?
Something along the lines of: Person A gets on to the system to work on X (using Service User X, applications D and E, files J and K). When they are done then they .... Later Person B gets on the system to work on Y (using Service User Y, etc.). etc.

Include information about what kinds of things are expected to be shared in the different interactions and what things are expected to be kept separate. For example if two people end up working on the same task at different times would the second person expect to reuse the same files and settings as when the first person worked on that task? Would you expect one person to stop working on a task in the middle and a second person to pick it up right where the first person left it? Or would you expect each person to have use their own settings and files, even if working on similar/related tasks?

airdrik wrote:

xpol wrote:As far as i know, separate logged in users cannot share one session. Te advantage of service users is that they can run in one session.

How would that be an advantage, since most of your requirements indicate that separate sessions seems like a better fit?

One session is better than separate sessions

To help us understand what kinds of behaviors and functionalities you would like to see, would you please describe how you expect the people in your organization to interact with the system?

My suggestion is to use 'service' users for one real user. Service users would help to maintain the configuration of open files or links pertaining to a given subject.

If you would like to explore how more real users could exploit service users, here is my hint:
More users could share the same okular bookmarks for a given pdf documents
More users could share the same lyx history of open files to quickly find the latest updated files (they could be in different folders, so that they would not be dispalyed by dolphin in one list)
More users could share falkon or other browser sessions and open tabs adn history.

paolo m.

xpol wrote:

airdrik wrote:

xpol wrote:As far as i know, separate logged in users cannot share one session. Te advantage of service users is that they can run in one session.

How would that be an advantage, since most of your requirements indicate that separate sessions seems like a better fit?

One session is better than separate sessions

One more convenient aspect of 'service users' is that all their applications setting can be synced across devices. That would allow the real user to work in the same conditions (web bookmarks, web sessions, okular bookmarks, editor settings, ...) at different devices (laptops, desktops, linux tablets, possibly, in the future, smartphones)

Is that a feature that could be supported by developers?


paolo m.