The reason: be.shell is growing, more and more people are trying it, liking it, use it as default shell.
The problem: so far it's nice, once got the fundaments of configuring and theming is fast to built your own shell. But extra widgets via labels are becoming a problem, in my opinion.
Labels are serving well the purpose, but still, i think this is problematic. As i said before there would be the need to set stylesheets for them to be aware of CSS pseudo-states, then, we would still have to deal with either reloading a FiFo after restarting be.shell or poll intervals, which is yet not the best for custom widgets.
Recently, with my collaborator we created a collection of "bash modules", files with convenient functions to be sourced from a script, trying to make scripts themselves theme-aware with no need to rewrite them from scratch. This was done for sharing scripts without the need to rewrite them everytime for a different theme.
But again, this would also mean a mess of "source /path/to/script" and so on...
And also, with this approach, PermittedCommands is hard to deal with (e.g. i have an update script which can check for many package managers if there are new updates. Then it can also start konsole --hold -e $update....Where $update is the command for the package manager in use. But this would fail with permitted commands. The only solution seems to implement a script with all of the commands and put that in the config instead of each of them....Silly example, but i hope you understand).
I would like to get your feedback about this idea, which i think would be a great chance for be.shell.
Last edit: Hombremaledicto 2015-06-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Humm?
I understoof that you find labels insufficient (though let's exclude label internal css - that could be resolved by eg. providing labelname.css in the style folder) but I frankly do not see a specification about what you mean by "API" (I know what API means, but not what you envision in this context)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry, i realize i explained myself badly, and could be this comment will not make perfectly clear what i've in mind.
I came to know that Qt supports "plugins" (if this is the right term), either linked statically or dinamically. If i understood correctly such plugins does not support css (again, might be i'm wrong), but one can paint directly with QPainter. The hope is to get support for dinamically linked plugins, to extend the features already available, and also to encourage other users to write their own and share them.
And also, to clear possible misunderstandings from my previous post: i'm not talking about replacing or deprecating labels, not at all. It's not that i dislike them. This is more a request for a new feature.
BE::Shell actually operates on a plugin infrastructure - it just doesn't load any plugins.
(I wanted to allow partial compilation/loading or at least not cut off that road but had no particular use for it)
Otoh 3rd party plugins (of variable quality ;-) are a major cause of instability in plasma.
plugins does not support css
QWidget::setStyleSheet() - it doesn't matter whether you do that from the binary or a linked or dlopen'd (<= that's the way plugins are loaded into the program) shared object.
to extend the features already available
Actually, the idea is to provide some generic objects and feed them from the outside.
Since you're talking about "paint with qpainter" I take you're not looking after some behavioral feature but a change of look? Could you get a bit more specific on this?
(Since one might even be able to do this by providing painterpath definitions)
(No offense, but I'll no way allow 3rd party modules to do "stupid things" in the main thread - that has always been my major grief with "anyone can participate" plasma - but i'd only "permit" threaded off things where you say "I want to paint something of about this size" and the main thread would pass you an image and then you come up with "done" and the main thread will then paint the result into the GUI in the next main loop paint event. This has certain restrictions and requirements notably to event processing, so we should first sort out what you'd actually like to do)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, i think to understand your concerns regarding this, as years ago i was used to install many third party plasmoids, and saw the whole plamsa-desktop shell crashing while attempting to login, simply due to a single plasmoid...
This is also an issue within Gnome Shell from what i heard, with extensions from the web causing the whole thing to kick you back to the login screen...
And this is one of the possible issues you're worried about, am i correct?
Since you're talking about "paint with qpainter" I take you're not looking after some behavioral feature but a change of look? Could you get a bit more specific on this?
No, actually behavioural features. That would be the priority to me. Forget the qpainter stuff, really, i have the bad habit to talk about details while not having a clue on them.
Look n' feel would be secondary, and i would accept compromises ;P
No offense, but I'll no way allow 3rd party modules to do "stupid things" in the main thread
No problem, although i hope there will be a way to not mess with the main thread and still have this, i can understand you must think on stability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KDE would not run into the gnome-shell issue (because it's the ksmserver which keeps the session alive, not WM nor desktop shell) but basically: yes.
Notably if two 3rd party plugins start to interact in an unpredicted manor ;-)
actually behavioural features
Being? (trigger present windows from taskbar or notification popups? ;-P)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason: be.shell is growing, more and more people are trying it, liking it, use it as default shell.
The problem: so far it's nice, once got the fundaments of configuring and theming is fast to built your own shell. But extra widgets via labels are becoming a problem, in my opinion.
Labels are serving well the purpose, but still, i think this is problematic. As i said before there would be the need to set stylesheets for them to be aware of CSS pseudo-states, then, we would still have to deal with either reloading a FiFo after restarting be.shell or poll intervals, which is yet not the best for custom widgets.
Recently, with my collaborator we created a collection of "bash modules", files with convenient functions to be sourced from a script, trying to make scripts themselves theme-aware with no need to rewrite them from scratch. This was done for sharing scripts without the need to rewrite them everytime for a different theme.
But again, this would also mean a mess of "source /path/to/script" and so on...
And also, with this approach, PermittedCommands is hard to deal with (e.g. i have an update script which can check for many package managers if there are new updates. Then it can also start konsole --hold -e $update....Where $update is the command for the package manager in use. But this would fail with permitted commands. The only solution seems to implement a script with all of the commands and put that in the config instead of each of them....Silly example, but i hope you understand).
I would like to get your feedback about this idea, which i think would be a great chance for be.shell.
Last edit: Hombremaledicto 2015-06-23
Humm?
I understoof that you find labels insufficient (though let's exclude label internal css - that could be resolved by eg. providing labelname.css in the style folder) but I frankly do not see a specification about what you mean by "API" (I know what API means, but not what you envision in this context)
I'm sorry, i realize i explained myself badly, and could be this comment will not make perfectly clear what i've in mind.
I came to know that Qt supports "plugins" (if this is the right term), either linked statically or dinamically. If i understood correctly such plugins does not support css (again, might be i'm wrong), but one can paint directly with QPainter. The hope is to get support for dinamically linked plugins, to extend the features already available, and also to encourage other users to write their own and share them.
And also, to clear possible misunderstandings from my previous post: i'm not talking about replacing or deprecating labels, not at all. It's not that i dislike them. This is more a request for a new feature.
EDIT: should be http://doc.qt.io/qt-4.8/plugins-howto.html
Last edit: Hombremaledicto 2015-06-28
BE::Shell actually operates on a plugin infrastructure - it just doesn't load any plugins.
(I wanted to allow partial compilation/loading or at least not cut off that road but had no particular use for it)
Otoh 3rd party plugins (of variable quality ;-) are a major cause of instability in plasma.
Since you're talking about "paint with qpainter" I take you're not looking after some behavioral feature but a change of look? Could you get a bit more specific on this?
(Since one might even be able to do this by providing painterpath definitions)
(No offense, but I'll no way allow 3rd party modules to do "stupid things" in the main thread - that has always been my major grief with "anyone can participate" plasma - but i'd only "permit" threaded off things where you say "I want to paint something of about this size" and the main thread would pass you an image and then you come up with "done" and the main thread will then paint the result into the GUI in the next main loop paint event. This has certain restrictions and requirements notably to event processing, so we should first sort out what you'd actually like to do)
Ok, i think to understand your concerns regarding this, as years ago i was used to install many third party plasmoids, and saw the whole plamsa-desktop shell crashing while attempting to login, simply due to a single plasmoid...
This is also an issue within Gnome Shell from what i heard, with extensions from the web causing the whole thing to kick you back to the login screen...
And this is one of the possible issues you're worried about, am i correct?
No, actually behavioural features. That would be the priority to me. Forget the qpainter stuff, really, i have the bad habit to talk about details while not having a clue on them.
Look n' feel would be secondary, and i would accept compromises ;P
No problem, although i hope there will be a way to not mess with the main thread and still have this, i can understand you must think on stability.
KDE would not run into the gnome-shell issue (because it's the ksmserver which keeps the session alive, not WM nor desktop shell) but basically: yes.
Notably if two 3rd party plugins start to interact in an unpredicted manor ;-)