Use a data engine for Workareas and not a local file

[dovidhalevi]

Might use data engine for the pager and other interactions as well. Data engines are they way to clean up this code, I think.

[psifidotos]

-About the pager I believe you mean a new pager which is going to be used for WorkAreas? It is not a bad idea if a data engine for WorkAreas exists then a qml pager it shouldnt be a difficult task, (there are also some very beautiful mockups in KDE Brainstorm for a new pager)

-About using data engines to clean up the code. Do you mean taking out all the hacks (cloning, showing widgets explorer, loading wallpaper etc.) and put them in a data engine? What would you suggest, a second data engine or the WorkAreas one? (I am not negative, but I want to discuss it a little more)

[dovidhalevi]

On Wednesday 05 September 2012 21:59:05 Michail Vourlakos wrote:

-About the pager I believe you mean a new pager which is going to be used for WorkAreas? It is not a bad idea if a data engine for WorkAreas exists then a qml pager it shouldnt be a difficult task, (there are also some very beautiful mockups in KDE Brainstorm for a new pager)

-About using data engines to clean up the code. Do you mean taking out all the hacks (cloning, showing widgets explorer, loading wallpaper etc.) and put them in a data engine? What would you suggest, a second data engine or the WorkAreas one? (I am not negative, but I want to discuss it a little more)

I think that a data engine would treat on particular data-stream so you might need a few. But these are reusable components that other programs can use as well, are self-contained (getting rid of spagetti code), etc. There may even be components already available. You might ride changes to desktops, changes done in the new or old pager, other activity managers. Some Akonadi stuff might also be integrated.

[psifidotos]

About the WorkAreas data engine I am definitely positive for the next version. About the other data engines I think I will not follow that road. For many reasons: 1)The hacking parts do not have data to show, only functionality 2)I dont want the user to have to install many data engines.

A little explanation about the hacking parts. The code is a spaghetti one because I could not find another way to implement that specific functionality from public APIs either KDE one or other Data engines. Some examples are cloning for activity, showing widgets explorer, finding updating Activity wallpaper etc... The spaghetti implementation occurs because in order to implement a functionality I have to trace 3-4 signals from the system. These signals create a Domino style code in which each signal triggers the next step of the code. All these domino parts code can be found in the c++ code and in the qml one. This is why a big spaghetti occurs... :) I am open of course in implementation alternatives if there is an easier way to do something.

Based on the above I think I will follow this path: 1)Create one data engine for WorkAreas (which is going to be a wrapper around Activities and Virtual Desktops in order to support any needed functionality)

2)Every hacking part is going to be moved in the WorkAreas Data engine as a separate class (like a plugin system).In that way all the code is going to be ready for future changes in KDE, for example when it is decided that cloning will be officially supported for KDE etc..

In that way, maintainability is not going to follow a spaghetti case, and future transition in new libraries is going to be very smooth. The only disadvantage I see is that the WorkAreas Data Engine is going to provide functionality that is not relevant completely with WorkAreas, but in future I believe piece by piece the irrelevant code in the data engine will be removed by officially KDE APIs.

[dovidhalevi]

So your data engines will define an extended activity and workspace APIs. Which is another reason this should then go to the playground.

Should speak with Aaron Siego about this.

[psifidotos]

I am working on this. It is the first priority for me. A workareas data engine is being created and will provide the api for handling them. All the other hacks in the code, e.g. cloning, finding the background etc. will be each one a different class (like a plugin) in the plasmoid.

[mdaffin]

Just had a look at the data engines available on a kde 4.9 install and found both an activities and tasks one already.

I suggest moving over to use these as it will simplify the code base allot.

Run plasmaengineexplorer to see the available engine on your system as well as what data they contain.

The only problem I can see is I see no way to change the activity a window (task) is on through it. This really should be implemented upstream though.

[psifidotos]

james I had started that specific implementation with two data engines. But the data engines did not provide all the needed functionality. Ivan also proposed that because the plasmoid's functionality is more like a manager he suggested to use the kactivities library. After that the taskmanager was also the most logical choice to go like the tasks applet.

Until now the workareas data engine is going to be a wrapper around the activities data engine. Is going to provide the data and the functionality missing for workareas. More specific is going to provide for each activity just its workareas and its order.

The activities order is also a reason why I can not use the default activities data engine.

I know that my code is messy, hard coupled etc ... :) but I wanted to deliver fast to all the kde users an activities paradigm that would push forward activities in the desktop. Cleaning up the code, changing designing decisions etc. when improve the code quality but at the same time provide the same functionality from the user's perspective are more than welcome....

P.S. james do you have any idea why the shortcut is not saved from the plasmoids config dialog?

[mdaffin]

I know that my code is messy, hard coupled etc ... :) but I wanted to deliver fast to all the kde users an activities paradigm that would push forward activities in the desktop. Cleaning up the code, changing designing decisions etc. when improve the code quality but at the same time provide the same functionality from the user's perspective are more than welcome....

I understand this :) just trying to help clean it up and making suggestions to help improve maintainability but yes, keeping the existing functionality is most important.

[mdaffin]

I have started to port the widget over to the official activities data engine and seperate qml plugin to handle things that the dataengine cannot (see my branch dataengine-port).

I have the basic framework done, and have started to rewrite the WorkAreasAllList (and renamed it to ActivityLists). Currently only the window titles work (minus some of the buttons), but they show that is is possible to use the dataengines and a qml plugin in place of the current solution.

@psifidotos what do you think of this approach? (if you ignore the missing content as well as the changed behaviour as I have not completely finished writing all the components yet).

The new components are mainly in src/package/contents/ui/components/ and the plugin is in components/.

[psifidotos]

Ok james, it looks very interesting, I havent worked qml like this before but it is cleaner of course and worths the learning curve if you can guide me...

Two questions: in qml I saw: property ActivityManager activityManager

is this a link in QML or it creates ActivityManager every time an Activity Button Group is needed(for perfomance issues) ?

The qml plugins as you are describing them are in the plasmoid right? I thought that plugins as you were describing them are global accessible in kde from other plasmoids

With that approach I think that with small steps we can decouple a lot the code (the parameters part and many other...)

[mdaffin]

Ok james, it looks very interesting, I havent worked qml like this before but it is cleaner of course and worths the learning curve if you can guide me...

Glad you think so and this is why I have been pushing it so much :)

Two questions: in qml I saw: property ActivityManager activityManager

is this a link in QML or it creates ActivityManager every time an Activity Button Group is needed(for perfomance >issues) ?

It is a simple property type name expression and does the same thing as

property int value

The only thing to note is that there is no default value and it uses a custom type from the qml plugin I created. If you look in ActivitiesLists you can see the value is assigned there. This means the manager is only created once per ActivitiesLists instance rather then per Button instance.

Edit: I find this a better way of passing parameters down the tree, rather then trying to access elements higher in the tree as it makes the code more self contained.

The qml plugins as you are describing them are in the plasmoid right? I thought that plugins as you were describing them are global accessible in kde from other plasmoids

They will be accessible from any qml code by adding the line

import org.kde.workflow.components 0.1 as WorkFlowComponents

in the qml file not just from our plasmoid. I don't see this a problem and lets other programs use our work if needed.

With that approach I think that with small steps we can decouple a lot the code (the parameters part and many other...) That is the idea behind this approach I have already remove most of the coupling from ActivitiesList and associated components though some still remains (mostly things that will be available in the config which needs the qml to be the main entry point for the code, I have been leaving TODOs where these changes are needed)

PS: I have just pushed my latest changes which adds animation back to the buttons and cleans some things up

[mdaffin]

I think I have reimplemented all the functions of the activity headers, except the add widget and clone buttons.

There are a few differences with the original such as:

• I used the default icons (these can be changed as needed)
• IconButton is used by all icon buttons as this gives a more consistent experience.
• The edit title uses the standard TextField, I only did this for simplicity, it can replaced with another component later the matches the function of the last text editor better if you want.
• ActivityIcons are not rotated by default, I felt this made some icons look odd, they still rotate when you mouse over them. This can be changed as well if you want.

I have removed all the functionality from the ActivityManager as all the implemented functionality was available in the DataEngine (no need to maintain code that is already implemented), but I have left it in as this is where the clone and any other needed functions will be implemented.

I also added a wrapper for the icondialog so the qmlcode has access to this now.

My next step will be to replace the other components rather then reimplementing the rest of the missing functionality (ie the virtual desktop/windowing) as I wish to convert to a pure qml widget as soon as possible (this will allow me to make use of some of the features presented with it without having to re-factor all the code afterwards).

[psifidotos]

I like it James, even the editing icon... Is it possible the TextField in Activities to be two lines? (for big Activities names)

[mdaffin]

I spent a bit of time looking it to the two lines, and I am afraid that the widget will have to be rewritten from scratch for this to work (Plasma.TextField does not support it at all and Plasma.TextArea is missing the activated signal and accepts enter as a character). I am not against this at all, but want to get the rest of the widget working first.

On the upside now that the code is more decoupled it is easer to create a drop in replacement for it later on.

[psifidotos]

Hello James, I hope I am not disturbing but I need some guidance in the development decisions. I am trying to use qml plugins and I find them pure magic. I have started an effort in branch stepto03 in order to cleanup the code as much as possible.

About version 0.3 what I would like is to have the same appearance, and any visual changes to happen (if any) after the code restructure and clean up.

So the steps are going to be: 1.code cleanup,restructure -> 2.visual changes, add enhancements

So the guidance I need is about the following: currently the plasmoid uses 3 inline qml ListModels (Activities, Tasks, Workareas)

-I am definitely positive that the tasks one must be replaced by the tasks plasma engine (I will remove some of the dirty fields there e.g. there is a field inDragging for every task which is used to know if a task in being dragged, my code is horrible I know :) but I think I can learn fast)

-The big question is about the Activities and the Workareas qml models in order to give me your opinion. I have three thoughts:

1. Unify them in one ListModel as a QML Plugin
2. Create a workareas data engine which is going to be the activities one but with enhanced functionality for example (background fields, order, workareas names) (Big Question here:Can the sources in a data engine change order?)
3. Create a workareas data engine that provides only the missing functionality from the activities data engine. (Order. workareas names, activities backgrounds)

I was thinking implementing 1 because is the easiest for me (and going to 2 or 3 afterwards) and all the functionality can be definitely supported. On the other hand 2 is the most challenging for me but it is going to clean the code a lot.

Thanks a lot again

[mdaffin]

My plan was to have activities in one ListModel, with one ListView to show the running ones and one to show the stopped ones. Inside the running activities ListView I was going to start off by using a Repeater and see if that was enough to implement the functionality, if not then create a separate DataEngine, and use a separate ListModel and ListView (one for each activity).

I can see why you want to clean up the code before applying visual changes, however I found that it was easier to remove allot of the code and rewrite it cleanly, then add in extra code to make it look like it was before.

In my dataengine port, I don't think I am too far off (though I haven't done much work on it of late) to adding most of the needed functionally back. I was planning on adding a global settings Item and then reimplementing the stopped activity list again. Once this is done I only have to port over the workspaces and tasks. I am trying to reuse as much of the code as I can, but I find it easier to rewrite the parts that a very reliant on other parts of the system.

If I have the time, and no unexpected complications pop up I think I can help all the functionally back in about a week or two. Given this, do you think it would be better to try and work together (on either your port or mine) and reduce the duplicated efforts or continue to work separate and try to merge in the best bits of both?

[psifidotos]

Στις 17/12/2012 10:10 μμ, ο/η Michael Daffin έγραψε:

My plan was to have activities in one ListModel, with one ListView to show the running ones and one to show the stopped ones. Inside the running activities ListView I was going to start off by using a Repeater and see if that was enough to implement the functionality, if not then create a separate DataEngine, and use a separate ListModel and ListView (one for each activity).

Ok, I think your approach can be definitely supported. The activities ListModel you believe that it should be the default one (the same with activities plasma engine) ? My plan is that the following fields are needed for enhanced Activities:

order(int), background(QString), workareas(QStringList)

That was my thought for the workareas data engine and of course with the corresponding service. On the other hand the previous fields can be added in the default activities ListModel in order to have one ListModel to rule them all :) The Repeater you are describing I think that can be done with both approaches either one ListModel for any activities/workareas aspect or two ListModels (one for activities and one for workareas). But I can not decide yet which approach is the best. On the drawback side I think that plasma data engines do not support ordering for sources or sorting by order field. So ordering if it can not be supported in the data engine side it should go to the plasmoid side

I can see why you want to clean up the code before applying visual changes, however I found that it was easier to remove allot of the code and rewrite it cleanly, then add in extra code to make it look like it was before.

In my dataengine port, I don't think I am too far off (though I haven't done much work on it of late) to adding most of the needed functionally back. I was planning on adding a global settings Item and then reimplementing the stopped activity list again. Once this is done I only have to port over the workspaces and tasks. I am trying to reuse as much of the code as I can, but I find it easier to rewrite the parts that a very reliant on other parts of the system.

If I have the time, and no unexpected complications pop up I think I can help all the functionally back in about a week or two. Given this, do you think it would be better to try and work together (on either your port or mine) and reduce the duplicated efforts or continue to work separate and try to merge in the best bits of both?

You are fast :) I need definitely more time. I think the best way for now is to remain is separate branches and look each others work. My work will be in the stepto03 branch. There are many from your restructures already there e.g qml plugins etc.

[mdaffin]

My main concern about the separate workflow is that it will be harder to merge at the end, if it can be at all.

I am about to start implementing the virtualdesktop's part of the applet. My plan is to have the virtualdesktops as a separate data engine from the activities, or possibly a simple plugin depending on how complicated it needs to be.

I was going to change the behaviour slightly to line up with how kde currently works and to make better use of their libraries.

1) Use kde naming for the virtual desktop and remove our naming system 2) Remove the delete desktop option and replace it with a hiding mechanism

The basic layout is already done for this but non of the behaviour or styles are finished yet.

My plan is that the following fields are needed for enhanced Activities:

order(int), background(QString), workareas(QStringList)

I was going to implement the background in the virtual desktop handler and the workareas (virtualdesktop names?) I was going to move to the virtual desktop handler as well. That only leaves ordering, which I was going to leave out until I have the rest of the functionality back. So I was not planning to change how the activities dataengine works yet as I think most of it should be implemented else where.

The next thing I am going to do is qml plugin wrapper around KWindowSystem to expose the needed options for the virtual desktops and then get the virtual desktops working again.

You might also be interested in how I implemented global settings in the dataengine-port branch. It is done fully in qml/javascript, saves changes when ever a value is changed and support binding on the values to other properties. It is basically a Settings.qml object with all the settings in it mixed with a stateless library that stores an instance of the qml class.

I have also made use of the PlasmaComponents.QueryDialog for the deleting of the activities. Which I still need to test on 4.9 or earlier but is working very well on 4.10. What do you think about it?

[psifidotos]

Óôéò 18/12/2012 09:02 ìì, ï/ç Michael Daffin Ýãñáøå:

My main concern about the separate workflow is that it will be harder to merge at the end, if it can be at all.

I am about to start implementing the virtualdesktop's part of the applet. My plan is to have the virtualdesktops as a separate data engine from the activities, or possibly a simple plugin depending on how complicated it needs to be.

I was going to change the behaviour slightly to line up with how kde currently works and to make better use of their libraries.

1) Use kde naming for the virtual desktop and remove our naming system 2) Remove the delete desktop option and replace it with a hiding mechanism

1) Hm, I dont know about the change in naming. The plasmoid is not an effort to support VDs but an effort to enhance them to WorkAreas. VDs do not support different number in different Activities, and different names in each one.

2) I was thinking the same, but I am trying to think a way that visually does not create clutter

The basic layout is already done for this but non of the behaviour or styles are finished yet.

My plan is that the following fields are needed for enhanced
Activities:

order(int),
background(QString),
workareas(QStringList)

I was going to implement the background in the virtual desktop handler and the workareas (virtualdesktop names?) I was going to move to the virtual desktop handler as well. That only leaves ordering, which I was going to leave out until I have the rest of the functionality back. So I was not planning to change how the activities dataengine works yet as I think most of it should be implemented else where.

The next thing I am going to do is qml plugin wrapper around KWindowSystem to expose the needed options for the virtual desktops and then get the virtual desktops working again.

You might also be interested in how I implemented global settings in the dataengine-port branch. It is done fully in qml/javascript, saves changes when ever a value is changed and support binding on the values to other properties. It is basically a Settings.qml object with all the settings in it mixed with a stateless library that stores an instance of the qml class.

I think you are using the plasmoid object with plasmoid.readConfig plasmoid.writeConfig to set parameters if that is possible also in hybrid plasmoid (c++ / qml) I have no problem at all. In branch stepto03 I have separated the parameters in storedParameters (which are stored for the plasmoid) and sessionParameters (qml plugin)which provide information for the environment to be used from the plasmoid. I think storedParameters
c++ class can be replaced from your code. I will test it.

I have also made use of the PlasmaComponents.QueryDialog for the deleting of the activities. Which I still need to test on 4.9 or earlier but is working very well on 4.10. What do you think about it?

---

I had many issues with PlasmaComponents Dialogs especially when they were used in the Dashboard( the Dashboard was closing and that was creating confussion). I will try it out to tell you. Of course when the behaviour is the needed one, all the dialogs should be replaced to the default ones.

[psifidotos]

Michael, your dataengine-port is a pure qml plasmoid, so your mechanism to store settings can not be used by my plasmoid. For me is not clear yet that all the functionalities can be supported by a pure qml plasmoid but we will see....

[mdaffin]

What do you think cannot be done in pure qml with plugins? So I know what to expect ;) On Dec 19, 2012 11:35 AM, "Michail Vourlakos" notifications@github.com wrote:

Michael, your dataengine-port is a pure qml plasmoid, so your mechanism to store settings can not be used by my plasmoid. For me is not clear yet that all the functionalities can be supported by a pure qml plasmoid but we will see....

— Reply to this email directly or view it on GitHubhttps://github.com/psifidotos/workflow-project/issues/11#issuecomment-11527056.

[psifidotos]

Michael I played with your code in dataengine-port in order to support the activities data engine model. The transimission was very easy because the code had been prepared for something like that. But then the first problem arised. The remove activity mechanism from the data engine is not working straight forward for me. It was the first hack in the plasmoid in summer :). In order to remove an activity must first be stopped and then you can remove it. So you need to stop the activity and then afterwards catch the stopped activity changed state to remove it. After that most of my hacks need such signaling mechanism to accomplish most of the features.

For the qml plugins and clean qml plasmoid I dont know how some parts of the code can be supported that way for example all the parts that use the containment() object to access its configuration for example and I dont know how the wId for the dashboard can be found without effectiveWid(). I havent any other hacks in mind but I think that will definitely exist more.

[psifidotos]

Michael do you know how to catch in qml from the activities data engine the signal activityAdded? Also do you know why in a plasma dataengine e.g activities data engine its signals are set as public slots? All public slots in a data engine can be accessed as signals?

[mdaffin]

But then the first problem arised. The remove activity mechanism from the data engine is not working straight forward for me.

I am not seeing this, my code just removes it using the activities dataengine without issue or needing to stop it first...

I dont know how some parts of the code can be supported that way for example all the parts that use the containment() object to access its configuration

I don't see any part of the code that really need to access this object from within qml...

I dont know how the wId for the dashboard can be found without effectiveWid().

I haven't looked into this yet, but I still think a solution can be found.

My qml port is already running fine without the c++ wrapper code, it is still missing quite a bit of functionality, but I have yet to come across anything that I cannot do in qml or a c++ plugin.

Note: You need to delete the c++ plasmoid or it will run instead of my qml only version, best to uninstall it completely before installing the qml only version. Also, my main qml file is now WorkFlow.qml (meant to replace Activites2.qml entirely) which should be launched if you are not running the old c++ applet.

do you know how to catch in qml from the activities data engine the signal activityAdded

There is no such signal in the dataengine (it is more abstract then that). I would use the onSourceAdded signal instead as each activity is added as a source in the dataengine so this should be called whenever an activity is added.

What I do in my code is just add all the Activities to both the running and stopped lists and then change the width and opacity to 0 if they are not running (or opposite for the stopped panel). This works really well and results in no hacks to remove and add the activities to each list.

Also do you know why in a plasma dataengine e.g activities data engine its signals are set as public slots? All public slots in a data engine can be accessed as signals?

Not sure what you mean by this.

[mdaffin]

1) Hm, I dont know about the change in naming. The plasmoid is not an effort to support VDs but an effort to enhance them to WorkAreas. VDs do not support different number in different Activities, and different names in each one.

I think it would be better to change the way kde works rather then trying to hack a widget to support the way you want it to work. Unfortunately this is not a simple matter, it seems to have been suggested before but turned down as it would take allot of work to do - https://bugs.kde.org/show_bug.cgi?id=251267

Personally, I think we should attempt to look into this bug and see if we can get kde to support it, then the plasmoid can be more integrated into kde rather then being a small layer on top that adjust how you think it should work.

But this is not a short term goal...

For now this is what I propose (at least for my qml port)

1) Finish adding the functionality back into the plasmoid using the current kde way of doing this (ie use the kde desktop names, only support hiding virtualdesktop not removing them) 2) Attempt to get support for the new idea for virtual desktop (ie to make them independent of activities) into kde, though this could take a while.

Reasoning: I know you are trying to make a plasmoid to work with the way you want kde to work, but I think it is better to have a version that works the way kde works (for better or worse) and then try to add the functionality you want into kde. This makes the widget more consistent with how kde works and stops users being confused when their settings don't change everywhere (ie you change a name of a vd, but it doesn't actually change its name).

The aims of this is for the qml port to eventually replace the c++ widget, but for now it would be best to continue to implement the needed functionality into the c++ version and keep releasing it (hopefully working towards the qml port). Then when kde has the needed functionality we can simply switch to the qml port for the newer kde versions and keep the old version for older kde versions.

Note: Although that bug report above was closed with "wontfix" I think that was because they don't want to work on adding it as a feature but from the comments it looks like if we get the implementation right they will be willing to accept it.

What do you think about this? (You continuing on improving your branch to add missing functionality and work towards releasing 0.3 then possibly 0.4, and I will work on mine port to being the widget inline with how kde works and then attempt (possibly with your help) try to bring kde inline with how you want the widget to work (ie separate virtual desktops for each activity).

Edit: I have sent an email to a kwin developer to see if it is possible and about how much work would be involved. So we can better plan what we want to do.

[psifidotos]

Óôéò 19/12/2012 11:24 ìì, ï/ç Michael Daffin Ýãñáøå:

But then the first problem arised. The remove activity mechanism
from the data engine is not working straight forward for me.

I am not seeing this, my code just removes it using the activities dataengine without issue or needing to stop it first...

maybe I have a different kde version ? I use kde 4.9 in opensuse 12.2

I dont know how some parts of the code can be supported that way
for example all the parts that use the containment() object to
access its configuration

I don't see any part of the code that really need to access this object from within qml...

that' s perfect, if you have alternative implementations I will take your bits... :)

I dont know how the wId for the dashboard can be found without
effectiveWid().

I haven't looked into this yet, but I still think a solution can be found.

My qml port is already running fine without the c++ wrapper code, it is still missing quite a bit of functionality, but I have yet to come across anything that I cannot do in qml or a c++ plugin.

Note: You need to delete the c++ plasmoid or it will run instead of my qml only version, best to uninstall it completely before installing the qml only version. Also, my main qml file is now WorkFlow.qml (meant to replace Activites2.qml entirely) which should be launched if you are not running the old c++ applet.

I didnt have any problem running your version

do you know how to catch in qml from the activities data engine
the signal activityAdded

There is no signal in the dataengine (it is more abstract then that). I would use the onSourceAdded signal instead as each activity is added as a source in the dataengine so this should be called whenever an activity is added.

What I do in my code is just add all the Activities to both the running and stopped lists and then change the width and opacity to 0 if they are not running (or opposite for the stopped panel). This works really well and results in no hacks to remove and add the activities to each list.

I had many problems in implementing ListViews in your way. For some reason the width of the ListView was not behaving correctly that is why I had to make this hack with counting the running activities for one listview and counting the stopped activities for the other. I also like a lot your way of implementing things in QML, I am definitely a newbie scratching my head all the time, so I am going to take a lot from your way of implementation e.g. The selection mechanism I couldnt make it work your way which is the official one so now I have a running example that I can use... :)

Also do you know why in a plasma dataengine e.g activities data
engine its signals are set as public slots? All public slots in a
data engine can be accessed as signals?

Not sure what you mean by this.

Sorry my mistake, I thought I had seen some signals relevant to the activities data engine (activityAdded, activityRemoved) but it was sourceAdded,sourceRemoved

[psifidotos]

Óôéò 19/12/2012 11:56 ìì, ï/ç Michael Daffin Ýãñáøå:

1) Hm, I dont know about the change in naming. The plasmoid is not an
effort to support VDs but an effort to
enhance them to WorkAreas. VDs do not support different number in
different Activities, and different names
in each one.

I think it would be better to change the way kde works rather then trying to hack a widget to support the way you want it to work. Unfortunately this is not a simple matter, it seems to have been suggested before but turned down as it would take allot of work to do

• https://bugs.kde.org/show_bug.cgi?id=251267

Personally, I think we should attempt to look into this bug and see if we can get kde to support it, then the plasmoid can be more integrated into kde rather then being a small layer on top that adjust how you think it should work.

But this is not a short term goal...

For now this is what I propose (at least for my qml port)

1) Finish adding the functionality back into the plasmoid using the current kde way of doing this (ie use the kde desktop names, only support hiding virtualdesktop not removing them) 2) Attempt to get support for the new idea for virtual desktop (ie to make them independent of activities) into kde, though this could take a while.

Reasoning: I know you are trying to make a plasmoid to work with the way you want kde to work, but I think it is better to have a version that works the way kde works (for better or worse) and then try to add the functionality you want into kde. This makes the widget more consistent with how kde works and stops users being confused when their settings don't change everywhere (ie you change a name of a vd, but it doesn't actually change its name).

I had also the same goal in order to implement some how the new functionality in kde. But on the other way around. Because I am not sure that I can take such a big mission I just wanted with WorkFlow to demonstrate the benefits and the use case to push things forward from the kde developers. You can answer of course "If not us, whom ?" :), I will try to help as mush as possible Michael. To be honest seeing your code is like a Summer Of KDE for me (tutoring from you - I say it in a good way) and at the same time trying to keep WorkFlow alive. Thanks a lot for all the help actually.

The aims of this is for the qml port to eventually replace the c++ widget, but for now it would be best to continue to implement the needed functionality into the c++ version and keep releasing it (hopefully working towards the qml port). Then when kde has the needed functionality we can simply switch to the qml port for the newer kde versions and keep the old version for older kde versions.

Note: Although that bug report above was closed with "wontfix" I think that was because they don't want to work on adding it as a feature but from the comments it looks like if we get the implementation right they will be willing to accept it.

What do you think about this? (You continuing on improving your branch to add missing functionality and work towards releasing 0.3 then possibly 0.4, and I will work on mine port to being the widget inline with how kde works and then attempt (possibly with your help) try to bring kde inline with how you want the widget to work (ie separate virtual desktops for each activity).

I am definitely positive. I like also this style of cooperation. I am going to take a lot of bits from you during the process because for many things I couldnt use the straight forward way of implementation. Except the selection mechanism in qml, dragging was also a problem for me, this is way I created the DraggingInterface.qml for moving tasks.

[mdaffin]

I am not seeing this, my code just removes it using the activities dataengine without issue or needing to stop it first... maybe I have a different kde version ? I use kde 4.9 in opensuse 12.2

Are you sure you are using my latest version? I just tried it on my laptop (kde 4.9, Archlinux) and the plasmoid doesn't run (due an unrelated issue: visualParent in QueryDialog in ActivityButtons.qml, commenting out that line fixes it for now). The remove activity however does work in kde 4.9 bug as well as the rest of widget as far as I can tell.

So as far as I can tell the dataengine does support removing activities without you needing to stop them first in kde 4.9.

that' s perfect, if you have alternative implementations I will take your bits... :)

Once and if I get them working again :)

I didnt have any problem running your version

Are you sure, because I just tried it on kde 4.9 and it didn't work out of the box ;) I do most of my development on kde 4.10 so far which is why I missed the visualParent bug (It has been added to kde 4.10 so isn't supported by kde 4.9) if you also did not encounter it then something is off somewhere :S I would advise checking your install.

And I am a little curious, how are you testing it on your system? I am installing mine to a local directory (~/localapps) and have the kde environment set up to find plugins and stuff from there. This lets me just delete ~/localapps at will if I want a clean install.

I had many problems in implementing ListViews in your way.

To be honest I had a few problems as well, mostly with the scrolling in two directions for the main listview. But I think I have a fairly clean implementation of it now :)

I had also the same goal in order to implement some how the new functionality in kde. But on the other way around. Because I am not sure that I can take such a big mission I just wanted with WorkFlow to demonstrate the benefits and the use case to push things forward from the kde developers.

It is sort of working :) as someone has decided to give it ago... although I have not contributed directly to kde before.

You can answer of course "If not us, whom ?" :),

That is how opensource software works generally :) either you code it or encourage someone else to.

Thanks a lot for all the help actually.

Your welcome, I hope I haven't been too pushy I just like the work you have done and I am trying to improve upon it.

dragging was also a problem for me, this is way I created the DraggingInterface.qml for moving tasks.

Dragging is going to be interesting... I think QML does have some support for it but I will have to look that up after I have reimplemented task/window support.

As a side note: do you think it is time for another release? I know there was allot you wanted to do before 0.3, but there have also been so many improvements to the master that I think it would be good to release it earlier. I tend to prefer rapid releases for small project like this then sitting on new features for many months while you implement other things you had planed for the release. As a bonus this can also help to stir up more interest in the project.

[psifidotos]

Óôéò 20/12/2012 03:11 ðì, ï/ç Michael Daffin Ýãñáøå:

Are you sure you are using my latest version? I just tried it on my laptop (kde 4.9, Archlinux) and the plasmoid doesn't run (due an unrelated issue: visualParent in QueryDialog in ActivityButtons.qml, commenting out that line fixes it for now). The remove activity however does work in kde 4.9 bug as well as the rest of widget as far as I can tell.

So as far as I can tell the dataengine does support removing activities without you needing to stop them first in kde 4.9.

The code is pretty simple for the dataengine:

                     var service = 

activitySource.serviceForSource(model["DataEngineSource"]) var operation = service.operationDescription("remove") operation.Id = model["DataEngineSource"] service.startOperationCall(operation)

---

I had this issue from KDE 4.8 and continued in KDe4.9 both the plasma engine above code and the libkactivities library remove function had the same problem (the plasma data engine is using libkactivies for implementation), so I think something is wrong with libkactivities

Once and if I get them working again :)

Are you sure, because I just tried it on kde 4.9 and it didn't work out of the box ;) I do most of my development on kde 4.10 so far which is why I missed the visualParent bug (It has been added to kde 4.10 so isn't supported by kde 4.9) if you also did not encounter it then something is off somewhere :S I would advise checking your install.

And I am a little curious, how are you testing it on your system? I am installing mine to a local directory (~/localapps) and have the kde environment set up to find plugins and stuff from there. This lets me just delete ~/localapps at will if I want a clean install.

I had installed your version some days ago and in general I am just browsing your code to take ideas, I dont install it. what I am doing for installation, is installing it as root and then: "plasmoidviewer workflow or WorkFlow" to test it fast and kquitapp plasma-desktop, plasma-desktop & to test it full I didnt have any problems with your version when I tried it back then.

Your welcome, I hope I haven't been too pushy I just like the work you have done and I am trying to improve upon it. No problem, thanks again

As a side note: do you think it is time for another release? I know there was allot you wanted to do before 0.3, but there have also been so many improvements to the master that I think it would be good to release it earlier. I tend to prefer rapid releases for small project like this then sitting on new features for many months while you implement other things you had planed for the release. As a bonus this can also help to stir up more interest in the project.

That's a good idea but before a release I test a lot, so I think it would be good if we could decide until which point in commits and test it to make small fixes...

[mdaffin]

The code is pretty simple for the dataengine:

 var service = activitySource.serviceForSource(model["DataEngineSource"])
 var operation = service.operationDescription("remove")
 operation.Id = model["DataEngineSource"]
 service.startOperationCall(operation)

I had this issue from KDE 4.8 and continued in KDe4.9 both the plasma engine above code and the libkactivities library remove function had the same problem (the plasma data engine is using libkactivies for implementation), so I think something is wrong with libkactivities

That code works for me in kde 4.9 and 4.10, though I cannot test it in 4.8 easily. Does it not work for you? If it doesn't work I would suggest trying out plasmaengineexplorer and see if it works with it, that way you will know if it is a kde bug or a bug in your implementation.

That's a good idea but before a release I test a lot, so I think it would be good if we could decide until which point in commits and test it to make small fixes...

I would take the current master branch, test it, fix and major issues and then tag and release that. Assuming you have not added any broken code to the master branch since I last looked at it :) I would recommend spending the next week on the master branch to test and fix any problems with it then release it, after that continue our work in the other branches.

As far as I can tell since I joined the project the master branch has been quite stable and it would be a good idea to keep it that way - ie don't develop major changes in it :) much like we are currently doing. Then when we think it is a good time for a release we just repeat the testing cycle.

[psifidotos]

Michael in Christmas I will have some time, so developement will be a little fast. I will decouple a lot the code and then I will test it. Probably around New Years Eve I will try to release 0.2.2

One question when you remove an activity your way does it remove from the activities bar? In my system lives a ghost activity with no name. That way are created many ghost activities and you have to make a log in - log out to be removed.

[mdaffin]

I noticed that as well, though I wasn't sure if it was directly related to our code as the ghost activities where in the official activity manager as well. It is likely a bug with the data engine or underlying technology.

When I had planned to look into it in more detail when I have more time. On Dec 22, 2012 12:06 PM, "Michail Vourlakos" notifications@github.com wrote:

Michael in Christmas I will have some time, so developement will be a little fast. I will decouple a lot the code and then I will test it. Probably around New Years Eve I will try to release 0.2.2

One question when you remove an activity your way does it remove from the activities bar? In my system lives a ghost activity with no name. That way are created many ghost activities and you have to make a log in - log out to be removed.

— Reply to this email directly or view it on GitHubhttps://github.com/psifidotos/workflow-project/issues/11#issuecomment-11636564.

[psifidotos]

I noticed that as well, though I wasn't sure if it was directly related to our code as the ghost activities where in the official activity manager as well. It is likely a bug with the data engine or underlying technology.

When I had planned to look into it in more detail when I have more time. On Dec 22, 2012 12:06 PM, "Michail Vourlakos" notifications@github.com wrote: This is why I stop the activity first and then delete it. With stopped activities there is no such issue.

[mdaffin]

I was getting ghost activities in the stopped activities as well... It is worth reporting upstream. I know you have to stop the activities before you remove them in the official activity manager but I figured this was to make it harder to delete running activities by accident and even if it is then deleting running activities is less well tested.

What I think we should do is this: Report the issue upstream and help them fix it this should be the minimum we do. In addition to this I think we should consider a behaviour change in the widget, similar to the official activity manager and only let stopped activities be deleted. For this we simply need to move the button to the stopped panel delegate, a very easy change. Not only does this avoid the bug I think it would be far less annoying (I have accidently deleted my workflow activity by accident about 10 times already, mostly due to testing, but I can see other users doing it as well occasionally. I also don't see any down side to this change (other then familiarity) as I don't think users will create and delete running activities often enough to warrant not having the extra step to stop them first. It also makes it less likely to delete an activity by accident if you have widgets unlocked and are switching between them (as the delete button will no longer be near to the areas you can click to change activity).

So what do you think about moving the delete button to the stopped activity panel delegates? On Dec 22, 2012 4:49 PM, "Michail Vourlakos" notifications@github.com wrote:

I noticed that as well, though I wasn't sure if it was directly related to our code as the ghost activities where in the official activity manager as well. It is likely a bug with the data engine or underlying technology.

When I had planned to look into it in more detail when I have more time. On Dec 22, 2012 12:06 PM, "Michail Vourlakos" notifications@github.com wrote: This is why I stop the activity first and then delete it. With stopped activities there is no such issue.

— Reply to this email directly or view it on GitHubhttps://github.com/psifidotos/workflow-project/issues/11#issuecomment-11638894.

[psifidotos]

What I think we should do is this: Report the issue upstream and help them fix it this should be the minimum we do. In addition to this I think we should consider a behaviour change in the widget, similar to the official activity manager and only let stopped activities be deleted. For this we simply need to move the button to the stopped panel delegate, a very easy change. Not only does this avoid the bug I think it would be far less annoying (I have accidently deleted my workflow activity by accident about 10 times already, mostly due to testing, but I can see other users doing it as well occasionally. I also don't see any down side to this change (other then familiarity) as I don't think users will create and delete running activities often enough to warrant not having the extra step to stop them first. It also makes it less likely to delete an activity by accident if you have widgets unlocked and are switching between them (as the delete button will no longer be near to the areas you can click to change activity).

So what do you think about moving the delete button to the stopped activity panel delegates?

Michael that's ok with me....

[psifidotos]

Michael will you try to do this in stepto03 branch or I'll take the lead in this?

[mdaffin]

Who ever can do it first :) I wont be able to work on it for a few days, but will try then if you have not already done it (possibly after I play around with it in my dataengine port branch to get the look right).

[psifidotos]

I moved it Michael, and you were right it fits much better now

[mdaffin]

In case you want to look at it I have created a very basic dataengine for the virtual desktops. It currently doesn't do much more then list all of the virtual desktops per activity with their names and some other basic info and it currently does not differentiate the desktop names per activity but should not be hard to implement this.

[psifidotos]

That's good Michael, I will have a look. About the data engine I had created one that was showing the Workareas from the current storing structure(I stopped when I had to create the actions), I can upload it if you want.

I am not rushing in this one because the steps to this one have changed priority:

1. Deprecate the qml tasks model and use a C++ one just like the activities one (the tasks plasma engine is very slow, you can not even move a window from a desktop to desktop)
2. Use a different storing system for workareas. ( The storing file is going to be clean xml in order to support easy new functions for example, ordering and hiding workareas instead of deleting)
3. Move workareas storing system from the plasmoid to qml plugin and then to a data engine. This can be done directly from the plasmoid to the data engine but until then we will see....

[psifidotos]

Michael the data engine looks very good. You have added it in the same code base, I will do the same after the 0.2.2 release in a new branch.

[psifidotos]

this is ready ...., the data engine is in tempsync