First, I defined a Plasma::PackageStructure for layout templates. So now with a zip file or a directory tree with contents/layout.js and a .desktop file we could list and find layout templates on the system. A layout template is basically just a bunch of Javascript that creates panels, activities, widgets, etc. A template can be associated with a given Plasma shell (e.g. plasma-desktop) and advertise what kind of containment it creates (e.g. a panel of some sort). So far, with all 4 lines of actual code involved it wasn't too exciting, but I could start to smell success down the hall.
So next I made it possible to load a layout template from a Javascript run via the Plasma desktop scripting support. So now you can do something like "loadLayout('org.kde.plasma-desktop.defaultPanel')" and it will load the template (if it exists) for the default panel. So now such scripts can call any template by name that is installed, allowing these scripts to become a bit more modular if desired. This still wasn't quite the needed solution, but while working on that I did implement persistence in the desktop scripting console so you can close/open it and whatever was in there last will be in there again the next time you start it. While nice, this was even more irrelevant to the problem of getting back your default panel if you terminate it.
Then I tore out the hard-coded default layout in plasma-desktop and re-wrote it using a Javascript run on first start due to being installed into share/apps/plasma-desktop/init/. This new script makes a loadLayout call to load the default panel template, and so I made such a template and set that to be installed as well. This dropped a few dozen lines of C++ and turned them into about half as many lines of Javascript.
The final piece was to alter the Add Panel action so that it was aware of templates. This means that you now get this when you right click:
That "Default Panel" entry does what you'd expect it to, and whenever we (or our downstreams) change what the default panel layout is then it changes, too, because both the init script and the context menu action trigger the same layout.
This also means you can create your own customized layouts. Which means one could even implement a "save this panel as a template" feature. It would also be feasible to add a "close this panel, but save it for easy restoration later" without too much effort. We could even GetHotNewStuff those panel layouts. We could provide the same functionality in the upcoming Activity Switcher for the desktop layer. Some of these "could"s will likely happen for 4.5, though I'm not sure exactly which ones yet as I'm now off to making the desktop toolbox a little less craptastic, as it's up next on the "to polish" rotation.
28 comments:
This would be great for people like me too, who would like to be able to see the new defaults without trashing out own setup or creating a new user.
So that means no longer having to rescue .plasmarc and friends whenever we mess up our ~/.kde?
Great!
You may have answered that in other places: Why isn't a panel treated like any other widget e.g. add it via WidgetExplorer?
When the WidgetExplorer would act like a bag you could drag any Widget/Panel to it: They would be saved and could be restored later.
just a silly idea - good night
Maybe we should rename 'Panel' then to 'Empty panel'?
or "blank panel"
Whoohoo. Instead of just adding a menu option with hard-coded defaults, you've created a layout-package-manager-engine being exposed as a simple menu option. :p With so many benefits, which I can really appreciate. Nice work! :D
wow, this seems like it has endless new possibilities.
first and foremost, i can envision it taking themeing to the next level, where a theme author not only can define how it looks on buttons and gizmodoodads, but where panels are placed, a clock widget here, a rss widget there.
and there could be a simple checkbox to de-click if you want to keep your current widget setup when applying a new theme.
fi fo fu fum, i smeel awesomeness in a can...
hugos kudos to you aaron :)
This could be a good start for some kind of "meta-package" which contains wallpapers, widgets, color scheme and why not (if possible ?) font-settings and so on... like CryoGenFX, with some checkbox to ensure that we only get what we want.
So when one see a great screenshot on kde-look and the author created a "super theme" for this look, one can simply says : "I want that !" and install it in a few steps
Neat.
But I think scaling plasmoids is a bigger concern than rotation, because it just sucks overall... and not many people give a crap about rotating plasmoids.
A nice feature. What do you think about a "Recently Closed Panels" submenu in the "Add Panel" menu? This way, the user does not have to decide whether he wants to save a panel before removing it or not.
Not directly related to this, but how can we immediately 'write' desktop changes to KDE? When X crashes or a system is remotely rebooted, all config changes to the KDE desktop get lost. A clean log-out is needed for these changes to be stored, and that shouldn't be the case. On the flip side, manual edits to the config files should be able to be loaded on the fly as well...
Thanks for KDE, this addition alone looks great!
This seems really useful! :)
A usability data point for you - could it be made easier to select where a (blank) new panel appears? Currently, if you want to add a vertical panel, you need to add horizontal panels first, because the "Add Panel" option chooses the new panel location in that order. Of course, the template could solve this as well.
As already brought up, this would bring great flexibility for themers to offer a ready theme for users who do not want to customize it byself. But that should only be optional. Like question applying a theme "do you want apply custom plasma-desktop theme?" etc.
But what I really think should be improved is the plasma locking mechanism. I know there have been a littlebit talking or someone just mentioned it. But I think it has a design flaw currently because user needs to have plasma unlocked to actually use some widgets. Like note-widget is useless when not possible to move and create new ones without first unlocking plasma.
---- Littlebit offtopic ------
And when we do have a unlocked desktop, we end up situation where we loose our panel.
The right click on the panel > remove this panel. Is just too easy.
If the only way to remove the panel is to unlock plasma > Panel toolbox > More Settings > Remove panel. Then there should not be actually a problem in mistakenly to remove it.
Maybe the widgets should be possible to "pin" to desktop.
Locking / Unlocking would just allow add/remove widgets. But would not stop moving them around.
If user pin widget to desktop, it would stay still. Otherwise it could be resized, moved and rotated.
And pinning down would not affect the widget function. Like user could just click/push note-widget "new" -icon and get a new note what would be by default unpinned.
In panel case, the locking would affect its size and position. And possible to widget arragement. But you could still drag a file/shortcut to panel and it would be added there.
I like very much about the feature to drag from the Konqueror a website logo (in front of the addressbar) to desktop as bookmarking to be used later. Then resize the icon for bigger for that task. I do not like to use nepomuk for quicktasks because I have no easy way to remove the links from database afterwards.
----- / littlebit Off topic ------
But does this means that we can have custom toolbars as well on different activities? That we are not forced to have same panels on all activities?
That is one of the biggest wishes of mine that I could have one panel in activity "Media" with wanted widgets there (Folder viewes on video/music etc directories). Two panels on activity "Office" for needed apps and folder views using nepomuk.
And third activity for social networking with two panels and shortcuts to websites in panels.
Just so great to hear that panels gets more love in next versions of KDE SC.
ps. Is it possible to make a panel from what the widgets would be popping up? Like animate the application icon (only the icon) in taskpanel to start jumping or grow bigger so it would come littlebit over the panel? Or is the panel as container what does not allow any drawing outside of it?
Great feature but I gotta agree with Ivan in suggesting that Panel is renamed to something like 'Empty Panel'.
Having a 'save current layout' option or 'recently closed panels' option would be even awesomer :P
@KTheorem: "This would be great for people like me too, who would like to be able to see the new defaults"
or just to try out other people's layout ideas. i really hope that we see some interesting / fun / cool layouts appear as contributions from creative users in the future.
@Dion Moult: "So that means no longer having to rescue .plasmarc and friends whenever we mess up our ~/.kde?"
it will limit the need for that a lot, yes.
@Nik: "Why isn't a panel treated like any other widget e.g. add it via WidgetExplorer?"
internally, Plasma::Containment subclasses from Plasma::Applet, so there is very little difference.
but putting them in the Add Widgets interface become tricky from a UI perspective. it's not where people tend to look for them to be, it really doesn't work well with non-desktop UIs like the netbook UI, and it doesn't make much sense to go from the desktop layer -> add widgets and get the option to create panels mixed in there.
and no, containments do no go into other containments.
for desktop activities, this same feature for the desktop layer will be merged into the activity launcher.
"When the WidgetExplorer would act like a bag you could drag any Widget/Panel to it"
rather unintuitive and difficult to define (clearly) where such a drag should be started from.
@Ivan Čukić: "Maybe we should rename 'Panel' then to 'Empty panel'?"
this is already what it is in svn. the screenshot above was taken without having run kbuildsycoca4 again, though, which is why the old name ("Panel") is shown in it.
@Diederik: "Instead of just adding a menu option with hard-coded defaults, you've created a layout-package-manager-engine being exposed as a simple menu option."
heh, yeah, it sounds a bit like crushing a bug with an atomic bomb, but as you note there are so many possibilities with this. it also was the easiest way i could think of for our downstreams to keep it all in order (just change one small javascript and everything works consistently everywhere: initialization, the Add Panel options...).
this kind of "thinking big picture" type design certainly is not the fastest/easiest way to do things but plasma is built around the idea that doing so pays off :)
on the other hand, Plasma::Package, the work already done on the Javascript API for plasma-desktop scripting and KDE API for things like KServiceTypeTrader made it as painless and easy as possible.
i actually wrote this while at a conference over the weekend while listening to presentations :)
@CryoGenFX: "a theme author not only can define how it looks on buttons and gizmodoodads, but where panels are placed, a clock widget here, a rss widget there."
yes, i think this is will be a natural evolution of the feature.
i don't know if it will end up paired directly with the existing SVG themes, but rather this opens up a new -kind- of theming.
with the activities switcher, i think this could be really rather cool all around :)
your screenshot shows two menu-entries: "add widget" and "add panel" - i newer saw a/the panel appearing in the widgetExplorer. Thats why i say they are treated differently.. For a programmer they are the same (subclass) to the user they are separated
@Dread Knight: "But I think scaling plasmoids is a bigger concern than rotation, because it just sucks overall"
besides not really knowing what aspect of scaling you are talking about (it's a vague word), rotation wasn't mentioned at all anywhere. colour me completely confused by your comment.
@andreas.huesgen: "What do you think about a "Recently Closed Panels" submenu in the "Add Panel" menu? This way, the user does not have to decide whether he wants to save a panel before removing it or not."
saving the last N panels automatically could be nice if implemented as a sort of "undo" feature.
there will still be use/need/desire for an explicit "save this panel" option, though, i think for more permanent storage and/or storing-without-closing.
so many possibilities here though :)
@lefty.crupps: "how can we immediately 'write' desktop changes to KDE?"
i'm pretty sure you don't want your disk spinning every single time anything changes any internal option. especially when you're on battery.
so what we do is compress the write events so that there's never more than one write every 10s, and only when there's been a change.
"When X crashes or a system is remotely rebooted, all config changes to the KDE desktop get lost. A clean log-out is needed for these changes to be stored, and that shouldn't be the case."
firstly, i kill -9 plasma-desktop rather frequently during development and can tell you that this is not the case. it is possible to lose up to the last 10s of configuration changes when plasma-desktop is kill'd, but when you kill an app like that all bets are off: you are interrupting it's processing in an undefined state.
plasma-desktop is pretty resilient to such things, but it doesn't, and likely never will, offer the same data guarantees as an acid-compliant database.
"On the flip side, manual edits to the config files should be able to be loaded on the fly as well..."
not going to happen. trying to coordinate automatic changes due to internal states with random edits made with a text editor is insanity.
there's a very good reason i wrote the javascript support for plasma-desktop. in addition to actually working, it's faster, easier and you don't need to figure out how plasma-desktop stores things on disk. use it.
DE SC."
they get some love in pretty much every release, actually :)
"ps. Is it possible to make a panel from what the widgets would be popping up?"
it's possible, but it probably also requires some work in plasma-desktop's PanelView class to work properly. we get requests for such things from time to time, but nobody steps up to implement them.
just like in this case, lots of asking for a solution ("I removed my panel, oh no!") and nobody submitting solutions. which is ok, it just means you all have to wait until one of us gets around to it eventually.
@Gareth: "Having a 'save current layout' option or 'recently closed panels' option would be even awesomer"
yes, it would be awesome. this lays the foundation for such features. would be terrific if someone would step up and spend some time working on making them a reality.
anyone with an interest in doing so can find us in #plasma on irc.freenode.net or via plasma-devel at kde.org
@V: "could it be made easier to select where a (blank) new panel appears? "
this would just make the simple task of adding a panel more complex. "Add Panel -> Empty Panel -> Top Left" hello, kicker.
"Currently, if you want to add a vertical panel, you need to add horizontal panels first, because the "Add Panel" option chooses the new panel location in that order."
or you could add the panel, open the panel toolbox, click on "Screen Edge" and drag it there.
or you could do "desktop console" in krunner, then enter something like this in there:
panel = new Panel
panel.location = 'left'
@Fri13: "But what I really think should be improved is the plasma locking mechanism."
locking is to provide a locked down system. whenever people use it for anything else, it starts getting in their way. making it more convenient for the people misusing it would destroy the feature for the people who actually need it to lock down the layout.
"The right click on the panel > remove this panel. Is just too easy. "
there's a confirmation dialog. and this new feature helps cushion the blow for people who can't or don't read.
"If the only way to remove the panel is to unlock plasma > Panel toolbox > More Settings > Remove panel. "
yes, if it is locked, then Remove Panel does not show up.
"Maybe the widgets should be possible to "pin" to desktop."
like some of the other suggestions in the comments here, this leads to UI complexity for nearly zero value.
we'd still need global locking, and then everyone else would need to deal with Yet Another Button that just pins things down. this is neither intuitive, nor straightforward to explain.
it also interacts with the global locking, making the feature more complex to use and the code beneath it more complex to maintain.
"But does this means that we can have custom toolbars as well on different activities?"
no, this is something fairly unrelated. this about templated layouts, not saving/restoring actual configuration in tandem with activity selection. it has been possible for quite a while to save/restore individual containments in libplasma, but the UI simply doesn't support it yet.
we don't want something clumsy.
"Just so great to hear that panels gets more love in next versions of K
@Nik: "Thats why i say they are treated differently.. For a programmer they are the same (subclass) to the user they are separated"
yes, that's sort of the whole point.
from the average person's POV they are very different things.
internally, they aren't so different. but we don't expose the literal design to the user in every case because that doesn't always match what the user perceives. and the split between "this is a panel" and "this is stuff you put in a panel" is a good example of that. :)
agree on the other hand you dont add a panel to the desktop every day (i dont like to menus with many entries) - and it will get complicated with other containments
I agree with nik, this can clutter up/complicate the menu.
How about an "Add Panel" dialog that pops up when you click on "Add Panel". In this dialog you will have a bunch of buttons or a grid where you are able to choose between different panel templates/layouts?
@Fri13: "But what I really think should be improved is the plasma locking mechanism."
locking is to provide a locked down system. whenever people use it for anything else, it starts getting in their way. making it more convenient for the people misusing it would destroy the feature for the people who actually need it to lock down the layout."
I'm sorry, but you're wrong, what's providing is broken experiences, product of a broken logic (the cashew in the panel), but more precisely, and down to the user experience, a simple task, like browsing in the kickoff menu for an application you want to add to the panel, can be quite frustrating, as it will (in 99% percent of the usage scenarios, probably more, since the panel is usually locked down)require to have the panel unlocked to add such a simple thing to it.
Not only that, but the features vanish, the user may never discover the feature, or even worse, could see it once but not the next time he tries it, making him believe something is broken (and it is, by design, not by software bugs), even people like me, users who visit planet KDE and comment on developers blogs, found myself clueless the first time this happen to me, it took me about like 10-15 seconds of "What the hell is going on?" to realize it was probably due the locked down panel. Most users won't realize, they will simply step away thinking: meh...
@Luis Augusto "(in 99% percent of the usage scenarios, probably more, since the panel is usually locked down)require to have the panel unlocked to add such a simple thing to it."
That is just one scenario why the current plasma locking is flawed by design. The locking should mean something what does not come in the way of the user for using widgets and panel.
Just like that.
a) Adding a icon from KickOff to panel or desktop.
b) Having a interactive widget like the ball or note.
c) adding a shortcuts or files as shortcuts to desktop or panels.
Now user needs to have the plasma most times unlocked if wanted to use the great features of plasma. And the widget-bar (rotation, resize etc) comes up all the time when mouse moves over the widget. What is not nice. And the panel has the toolbox button open and user can accidentaly move widgets from panel to desktop or even remove them or the whole panel.
Something is needed to done and that is somekind state between unlock and locked state. So lock would not allow adding new widgets or removing them via widget explorer.
While widgets are locked, you could still work with widgets (add new notes without first unlocking widgets and then opening widget explorer) or add special ones like shortcuts, resize and rotate them as they would be objects.
Touchscreen usage needs that as well. Very hard to think how the plasma should work when locked but still being interactive and being away from user way.
The plasma panel has same problem now as the application toolbars has. They are by default unlocked and user can by mistake drag or close them (what is the problem as well with the idea to have interactive widgets. But something must be done for that) and someway fix for that would be making something else than just making the default as locked panels.
@lefty.crupps: "how can we immediately 'write' desktop changes to KDE?"
@aseigo: "i'm pretty sure you don't want your disk spinning every single time anything changes any internal option. especially when you're on battery."
It's not about internal options, it's about user actions. Any changes made in configurations dialogs(or other user initiated changes) should be written to disk immediately when the dialog is closed. It's not like users changes their setting continuously, they change one or more settings and then get on with their tasks.
@Morty: "It's not about internal options, it's about user actions. Any changes made in configurations dialogs(or other user initiated changes) should be written to disk immediately when the dialog is closed."
when a configuration dialog is closed, a config sync is requested. that is delayed for up to 10 seconds, however. this is both an interactivity and a power usage issue (we end up triggering an fsync at that point).
on a -clean- exit, it syncs as well.
unclean exits within 10s of a config change are not something we are willing to throw away power or interactivity benefits for.
i'd also note that SIGKILL'ing an app is a very silly thing to do when there are ways to do it properly that allow the process to do on-exit processing.
Hey aron :)
playing with destkop console i got this :
var panel = new Panel
panel.length = 27
panel.height = 8000 // THIS DOESN'T WORK :(
it's too much short on the left side
some trick ?
Post a Comment