Open psifidotos opened 11 years ago
Version 0.2.2 is almost ready, the current master branch is going to be used For anyone interested in helping somehow:
New Feautues: --window previews when the plasmoid is in the panel --use the current activity's icon in the panel (you can enable it from the configuration dialog) --Tooltip for the plasmoid when used in the panel --new zoom slider --delete activity button moved to the stopped activities of course, many bug fixes from 0.2.1 ...
A couple of issues:
1) You can delete activities even when the activities are locked 2) Tooltips can cover the buttons (noticed this on the close task and change window state buttons, but only sometimes) - also some of the tooltips seem to be place far away from the button.
Also, I don't think the tooltips should appear so quickly (they appear instantly here). Having a small delay would be much better.
Hmm, the stopped activity panel contents started to twitch up and down (see the gap below the add activity button, it switches between these two images many times a second). This didn't happen the first time I opened the widget.
After restarting plasma-desktop it seems to have fixed itself... not sure what was causing it though.
Also, the play buttons zooming in while becoming visible looks a bit off, I think it is better to not have those buttons zoom in while mousing over them as the change in opacity should be enough to make the user think they are clickable (the delete button should still zoom in to indicate the click area)
Seem my latest push for an example of this (note also that in my version you can click anywhere on the stopped activity to start it except the delete button).
I think I have fixed them Michael, can you check them please? the fixes are in master now...
Michael in the next days I'm going to update the Opensuse package, one question, for the components should I create a different package? or is it better to keep one rpm for both the plasmoid and the workflow components?
I would keep them as one package. There is little point in a separate package unless something else depends on the other components.
Ok, one package it is then... Have you noticed any other issues to fix before the release?
If you have more windows open on a desktop then the size of the desktop preview allows you cannot access the lower windows.
This existed and in the previous versions also, but by clicking in the corner that shows the number of windows in each workarea a dialog opens with all the relevant windows. This dialog supports also previews with scrolling.
Cannot see any other regressions, though I have only done quick tests.
One usability issue I have noticed with a new feature: The widget icon changing to the current activity, once enable it is hard to tell what the widget actually is (looks just like any old launcher). Considering this is not the default I don't see it as an issue for this release.
Not sure how we can solve this, it requires some thought. I think the ideal solution would be to make the widget still identifiable as the activity manger even when the activity icon is shown.
OK then there will be a release in the next days. Opensuse packages have been tested with the new structure so I I have to create only the announcements for the new release...
For the current activity icon we can improve it (e.g. add a small icon indicator above the current activity icon) but I like it a lot even with its current state.
I have noticed you have started labelling allot of classes as plugins when they really are not. Plugins should be able to compiled or changed separately from the main application and should be able to be removed or added at will. The classes you have named as plugins do not satisfy either of these are are so just separate components of the system.
In doing these changes I am wondering if you are making the program more complicated then it needs to be.
Michael you are right, these are not plugins. They are just hacks in order to provide the needed behavior from KDE. The clone hack and the show widgets hack for example in order to not get in the way (in qml code and c++ code) I decided to put in separate classes. Each hack is a separate class with all the signals it needs etc. I wish that some day there will be a public api which is going to make our life easier but until this api exists the hacks are going to do the job. When a new api is published with the needed functionality is very easy with the current structure to remove that code and use the default api.
A very good job in the future could be for someone to try to take each plugin class and make it standalone (that way I believe is very easy to add it afterwards as a qml plugin).
For making the program more complicated I dont agree, it makes it simpler from maintenance point view. All the plugins' code was inside various files which had a different purpose.
Can they be supported simpler? I am open in ideas. But all the logic that has already removed from qml is because these classes were created.
From naming point view, I agree they shouldnt be called plugins but I couldnt think something better. Maybe hack classes could be better? I dont know?
P.S. What are your thoughts around providing the following functionality? Do you know an API that supports them?
Activity's wallpaper, Clone Activiy, Show Widgets (minimize windows in that activity) Changing to a workarea of different activity (It can not be done in parallel, must be sequential change to the relevant activity and then desktop)
All the above hacks were inside qml and activitymanager. An enormous spaghetti. The current structure isnt the best one but it is simpler until the day an official api exists. Why a plasmoid must provide a clone activity functionality or show widgets in a specific Activity? (it shouldnt)
I am open in ideas as with the current structure is very easy to move them to standalone qml plugins most of them. The two that cant are the activity's wallpaper and the show widgets I think. They need containment() and corona() which I cannot find a way to access them outside the plasmoid.
Michael during Christmas I played a lot with data engines in order to adapt them for the plasmoid. I made the plasmoid to cooperate with both activities and tasks data engine but I ended up in deciding the following structure for the near future.
Qml will need two models: one for Activities enhanced for workareas , this has been implemented and is ready for advance features like activities ordering which is a killer function and hiding workareas. Data engines don't support I think moving sources so for ordering the order data will be in the workareas data engine with the background information. This Qml model can be a Qml plugin, with the current structure is very easy to be moved from the plasmoid.
The second model will be the tasks one. The responsiveness of tasks dataengine was awful in my experiments. I will wait for your experience in this one. So a second model for tasks that uses libtaskmanager can be a Qml plugin (this is scheduled for 0.2.3) all the.irrelevant logic that way will have been removed from Qml.
For request about hiding workareas and not closing. This will be after the workareas data engine implementation and it will be a selectable behavior. I have thought that a way to go is by showing a thin transparent frame for hidden workareas but this creates clutter. A lot of thinking in that one because in VDs state multiple add workareas buttons are not needed and orphaned windows do not exist. So there will be two states for Qml ui thinking, one for workareas which the current one and the default VDs one which must be thought.
As a reference I point to the following article from which I started all this effort: http://opentoolsandspace.org/en/projects/development/plasmoid-workflow/172-plasmaactivitiesandworkareas
I think there should be three dataengines, the activities one (which I think the offical one is good enough if you add the extra functions to a qml plugin), a virtual desktop/workarea one which should list all the virtual desktops as mine currently does and a tasks one, which i still have to look into the official one but I don't see why it cannot be used in the same way the activities one is used.
Michael I am almost ready to move to qml plugins the following (taskManager, previewsManager, workflowManager(contains activityManager, workareaManager and the ActivitiesEnhancedModel). After that you will be able to use them if you give them from qml what they need to operate from qml.
One question around the plugins in my source that are not plugins. How would you name them? I will rename them but I can not end up in a meaningful name...
During the moving process the code which can not be moved yet to QML plugins is going to stay behind. This is the showing widgets and the find activity's background. I am going to create an EnvironmentEngine which is going to provide them to QML.
Feature Planning for next release: Next release will be 0.2.3 or 0.3.0 I dont know yet.... If it is 0.2.3 then the current master features are going to be supported If not the timetable is the following: -> workarea data engine -> activities ordering -> workareas two states ( through the data engine, clean VDs(hide/unhide workareas) or Workareas(current implementation) ) ,the user will be able to choose...
Big UI changes for 0.3 to be tested if the current UI quality and appearance can increase: -> Everywhere panel and Stopped Activities to use the default theme panel appearance and font coloring -> Choice to disable the plasmoid's background and use the theme's one with the correct font coloring -> Investigate if for the Activities Panel can be used a theme's one panel (even though I find it difficult)
For all the above the default Oxygen theme is going to be used as a test base.
Future Thoughts: -> Change the handmade Dialogs to theme one. This can proceed only if the dialogs are not creating issues with the popup and dashboard behavior ->1. appear in front of the Popup, ->2. Popup is not hidden when the dialog appears I think this means that the dialogs must be modals
for timetable and thoughts the discussion can continue here...
With the current level of changes and restructuring I would bump the minor version number (to 0.3) rather then the release number. This indicated allot of changes might have been undertaken and the code might be less stable, but includes more features.
Does anyone know how to access a data engine through a c++ qml plugin? workareas data engine is alsmost ready but I must connect it to a qml plugin...
What is the qml plugin meant to do? It sounds like a bit of a hack if you need to do this. Though there is a c++ api: http://api.kde.org/4.9-api/kdelibs-apidocs/plasma/html/classPlasma_1_1DataEngine.html#accb20ef9b196ce72938c4e80201559a3
Don't know of any good tutorials as dataengines tend to be used from scripts such as javascript or qml.
I have sent an email also to plasma-devel mailing list to be sure. I found a way but it is the same hack from which I access containment() and corona(). I dont like it but it works actually.
Ordering Activities mechanism is almost here in tempsync branch:
--this commit enables all the ordering mechanism (limited
version, I have disabled the change activity
(running activity icon - locked state),
and instead to test ordering when you click in the
previous icon that activity becomes first.
IN NEXT COMMIT MUST BE RESTORED the functionality.
Please write ideas about ordering for the UI: I am thinking about a Dialog that shows a list of all activities and the user drag n' drops to make the desired order.
Changing activities order in live state without dialog is a lot of pain I think with no reason... What do you think about the above implementation for the dialog?
I have always hated dialogs to rearrange elements in a list, I find it unintuitive and a easy/lazy solution for programmers to take. I would rather see the reordering elegantly handled within the listview, but it might take some time to achieve this correctly. This dialog is fine for now to get the functionality down, but I would hope to move to a more elegant solution later on.
I see that many do not like the Dialog way... :)
well in tempsync branch I have started the live way of dragging and I believe is going to be ok in the end. To achieve this I have simplified the way Dragging is organized in the plasmoid. By using the Task way of dragging (dragging between different elements and Items) I think Activities will also be ok, we will see.
If someone wants to see the first steps of Dragging Activities in unlock Activities state drag an activity icon. (you will see only the appearance, no functionality yet there).
My next big goal before trying live activities order in to clean up the messier file, that is TaskPreviewDeleg.qml.
This file is doing a very important job, it provides the Window Delegates(with previews for three different Views),
Everywhere task (in the bottom panel), Desktop dialog and Windows list in the Previews Calibration Dialog. The way to go is to create three different files and each one will use the functionality and elements of the previous one. BasicTaskDeleg -> TaskPreviewDeleg -> ScrolledTaskPreviewDeleg
initial alpha support for activities ordering in orderactivities branch... It works but there are some issues with dragging the first activity in each list....
I need some ideas.... I have the following situation. I am implementing the Passive Mode(this is clean VDs experience with hiding the workareas and not delete them). This choice is for the data engine in order to be global for all plasmoids that use it (for example a new pager in the future or the kwin effect). I would like the user to be able to make that choice from the plasmoid because I dont know if it is to create a new System Settings Module for this.
The question is where in the plasmoid must go such a choice?
Idea 1: It can be inside the plasmoids configuration dialog with some small hacks.
Idea 2: It can be put inside the plasmoid's qml interface in a new Dialog which is going to use the beautiful
Plasma Switch.
Idea 3: The previous dialog can get all the configuration settings from the original configuration Dialog and can keep only the Shortcut choice...
Idea 4: Do it with system settings and create a kcm module for workareas
Hi
I have to admit I don't really know or grasp it from your short description what the passive mode is so could you explain more about it? There are some key questions which would influence how to implement it.
Well about Passive mode, this occured as a behavior choice about how workareas work in a computer. It is the solution for issue #8 and issue #24 . Active mode will be the current state in which when you delete a workarea, that workarea is disappeared and the VDs must always follow the workareas maximum size. So you cant add or remove a VD outside from the plasmoid.
The Passive mode will imitiate the current KDE way of doing things. When you close a workarea is not hidden but it shown as empty rectangle for example. All the activities are going to have the same number of workareas but some of them can be hidden (e.g just a border with no wallpaper or name). The user can add VDs outside the plasmoid and the workareas will always follow the maximum number of desktops.
I hope I gave you an idea. The passive/active mode will be used from all applications using the workareas data engine.In the future a new pager and a kwin effect.
BTW from version 0.2.2 window previews are supported in the panel.
Personally I think the modes should be merged into a single mode that works like this:
All virtual desktops are shown by default. The user can hide each virtual desktop they want to, this removes it from view completely (like the delete currently does). There should be an extra button to temporarily show the hidden virtual desktops so the user can unhide them.
I think that is the simplest and most initiative way to implement the idea. On 5 Feb 2013 23:34, "Michail Vourlakos" notifications@github.com wrote:
Well about Passive mode, this occured as a behavior choice about how workareas work in a computer. It is the solution for issue #8https://github.com/psifidotos/workflow-project/issues/8and issue
24 https://github.com/psifidotos/workflow-project/issues/24 .
Active mode will be the current state where when you delete a workarea, that workarea is disappeared and the VDs must always follow the workareas maximum size. So you cant add or remove a VD outside from the plasmoid.
The Passive mode will imitiate the current KDE way of doing things. When you close a workarea is not hidden but it shown as empty rectangle for example. All the activities are going to have the same number of workareas but some of them can be hidden (e.g just a border with no wallpaper or name). The user can add VDs outside the plasmoid and the workareas will always follow the maximum number of desktops.
I hope I gave you an idea. The passive/active mode will be used from all applications using the workareas data engine.In the future a new pager and
a kwin effect.
BTW from version 0.2.2 window previews are supported in the panel.
— Reply to this email directly or view it on GitHubhttps://github.com/psifidotos/workflow-project/issues/54#issuecomment-13158730.
There are some questions, 1)How about VDs, what is going to happen when someone adds/removes a VD outside from the plasmoid ? (The workareas that do not correspond to the new desktops number? - I can not delete them and this can create circumstances where the user clicks in a workarea that a corresponding VD does not exist)
2)All the other workareas application what are they going to support e.g. the workareas pager ? (workareas are handled from a data engine)
3) When all the desktops are shown isnt there a indicator to show that this frame is not a created workarea? Can you rename a not created workarea?
many UI assumptions here I think and behavior issues also,...
4) What is the use case that a user wants to see all the desktops and not create the workareas needed with the current structure?
I have started to believe that this feature is not so important.... If there arent any clean mockups about the changes that need to be done I think that I am not going to follow that road....
Hi
I have started to believe that this feature is not so important....
I agree with that as I also see only more confusion than any clarification in the current proposals. Maybe pushing the current plasmoid's behavior to KDE is a better thing to pursue than trying to add temporary workarounds here. The only thing that may be helpful is to explain it to users why there is a difference between the plasmoid and what they see in KDE. Don't know if that justifies to show some artefact of the removed workareas or it should just be mentioned on the plasdmoid's homepage or help.
I agree with the previous statement... It will also keep the situation cleaner. When the pager will be available the situation can be improved... Call for help: Can anyone start working with the new pager? It is just going to use the workareas engine...
Well some news here..... version 0.3.0 version 0.3.0 will be released around the end of February and will be the last supporting KDE 4.9.x until then I decided to remove:
version 0.3.1 soon after that. There will be a 0.3.1 which is going to support per Activity Resources but only for versions after KDE 4.10.x ( I have talked with activities library maintainer about that, I think this is going to be a killing feature - I will try to give the user the ability to drag a resource(file or link) over the panel icon and that resource is going to be linked with the activity automatic).
I think that a bug from add widgets hack has already shown... So it is a necessity to remove that code as soon as possible.... :)
Please test new version in development for missing tooltips strings and icons, in order to update as soon as possible transifex and give translators the time to make the translation... Especially for new features that didnt exist before e.g. dragging and changed behaviors e.g. renaming Activity by clicking and not double clicking....
Thanks a lot...
I could not find any missing tooltips or icons and the strings seem ok, too. Some things though:
Besides that get the next version out as people need to see it and use it :)
Óôéò 10/02/2013 08:17 ìì, ï/ç Bogdan Mihaila Ýãñáøå:
I could not find any missing tooltips or icons and the strings seem ok, too. Some things though:
- The tooltip for the window state button as seen below contains inconsistencies how the word Workareas is spelled. Once it uses camel-case and once not. Same issue in the help tour and the tooltip for the close window button. Maybe you should stay with the non-camel-case and grep all the files for the camel-case occurrences.
I think you prefer Workarea than WorkArea right ? Very good notice....
- Maybe a matter of personal taste but I would not write the tooltip text like "You can ... if you want". For example the close button, the rename button, the pause, the enable, the zoom buttons text. I would make it simple and short so instead of "You can delete this Workarea if you want" for the close button something like "Delete the Workarea" and "Zoom out in order to gain more space" etc. The "if you want part" is redundant and meaningless. Don't know what usability people recommend there, though but a fast look of various KDE apps confirms that they use short and active verbs for the tooltips of the actions.
nice description, I will use it...
- How are the users going to know about the drag&drop reordering and the search field and the keyboard navigation keys? Is there going to be something in the release notes or in the help tour? As these features are cool but not that easy to find by just playing around with the plasmoid.
I was going to make a video in vimeo showing new features etc and adding in the Release Notes the new behaviors... I will update the Release notes soon so you can give it a try to see if I change something...
Besides that get the next version out as people need to see it and use it :)
We 've got enough time around two weeks to make it as stable as possible...
I think you prefer Workarea than WorkArea right ?
Yep. Just search the files for the later and replace it with Workarea.
I was going to make a video in vimeo showing new features etc and adding in the Release Notes the new behaviors..
Good idea. Somehow this project needs more attention as it makes activities in KDE finally not a pain in the ass anymore ;) and all that with a great look. Should replace one day the activities UI in KDE but well, way to go till that... hehe
We 've got enough time around two weeks to make it as stable as possible...
Ok, I will try to weed out as many bugs as possible.
Ok, tooltips have been updated in the development branch and WorkArea has been changed to Workarea. (WorkArea has not been changed only in the help tour, this is because the translators would had a lot of work)
The release in going to be available this weekend... So until then for any strange bugs and I have to create announcements, packages, videos and screenshots... :)
Well video for v.0.3.0 is ready and you can watch it at: www.opentoolsandspace.org/Art/v0.3.0.mp4
in a few days I will upload it in vimeo........
Btw, nice video ;) Set it free!
One tiny improvement suggestion for the next videos for future versions. Try to not be so fast when showing things. This is a problem that happens with most of the demo videos of programs. People need to read and understand what you want to show them. Then they need to follow the mouse and all the things that happen there and then connect that to the things they read before and well they might just want to admire the nice look a bit ;) so try not to be so fast and move on to the next thing. Of course the video can get too slow and boring, too if things are statically shown forever and the video also gets too long for the attention span of most people so one has to find a good middle ground.
The video can be seen at: https://vimeo.com/60116122/ I fixed also a small issue for video's fps... So the video must be playing almost in the half speed. The issue was that I had recorded at 16fps but I had exported at 25fps.
I will delay the release for one or two days because I managed to do something very beautiful for those using the default plasma theme with the plasmoid (disabling the default background) ... I will make videos and screenshots from the beginning because of this... :) But I think that the delay is necessary... :)
What is it and where can I try it out? ;)
:) well this is very beautiful... :) check branch fixpanels and start changing various plasma themes.... I love it...
Well, new feature (better integration with plasma themes... much better :) ) is in the main branches, that is (master and development)....
Checkout the new updated video in vimeo: https://vimeo.com/60116122
I think you are gonna like a lot (added a relaxed music also)
For the official release, I believe in the weekend it is going to be published....
A way to communicate through github with anyone interested...