Could you give a specific example why you need the profile name for matching? Or why other criterias (like title) does not work for your need?

The first thing to consider is konsole supports mutiple tabs created from different profiles in one window. Then after switching tab, should konsole update the "window role" dynamically? Or is it technically possibe to update "window role" in the runtime after the window has been created ?

Need a concrete use case to explain your need better.

The window title is sth that shows what is happening in the session while a window rule usually cares which kind of session this is. The title may contain a lot more detail info of the session and may also be very hard to match using regex in the window rules even if it does contain some info about the type of the session (therefore, the profile in use).
Since konsole already set the window role for each of it's windows, I think it is also useful to provide a way to set window role for different sessions just like the window title with a default value of e.g. MainWindow#%i where %i is a id that konsole can generate automatically for the same profile.

(In reply to Jekyll Wu from comment #2)
> Need a concrete use case to explain your need better.

I apologize to take three years to answer. I do have a dedicated profile called "Chat Window". I usually have only one window of that profile open, and I want this one to be in the lower left corner of the screen.

This is a workaround since the default window placement has been changed when migrating from KDE 3 to KDE 4. The old behavior was perfect for my needs, but is not available any more, so I need functions to work around this. But, otoh, I have gotten accustomed to manually moving the chat window where it belongs since I filed this bug.

Greetings
Marc

Konsole exports a KONSOLE_PROFILE_NAME environment variable, you can use that together with escape sequences[1] to set the window title to include the profile name.

[2]bug 325178 comment 2

That would mean that the profile name would be visible in the window title, task bar etc. That might be a technical solution, but it's ugly.

Six years after filing this bugreport, I now see that the issue was marked as "resolved" without anything happening on the code. If something happened on the code, it was not made visible in the bug report. It's a pity.

Also, it is likely that the modification on the window title will only happen after window rules were applied if one does that from the prompt, for example. You cannot be seriously recommenting this method - straight back from the 1980ies - as a serious solution.

(In reply to Marc Haber from comment #6)
> Six years after filing this bugreport, I now see that the issue was marked
> as "resolved" without anything happening on the code. If something happened
> on the code, it was not made visible in the bug report. It's a pity.
I changed it to "resolved: waitingforinfo", this is so that instead of leaving the report open for another six years, it'll stay closed until the OP gives feedback.

(In reply to Marc Haber from comment #7)
> Also, it is likely that the modification on the window title will only
> happen after window rules were applied if one does that from the prompt, for
> example. You cannot be seriously recommenting this method - straight back
> from the 1980ies - as a serious solution.

Actually the window title will be set as soon as you open a window with that profile.

As the reporter of this issue, you can simply reopen the report if you disagree.

FTR, some other options:
- Launch konsole with "--name NAME" and NAME will be added to the wm_class for that window
- Disable "Show window title on the title bar", then:
  - Launch konsole with "--title TITLE" and TITLE will be used as the title of that window OR
  - For a particular profile set the tab name to a static string, "tabText", that will always be used as the window title when that profile is used.