Task-oriented desktop and applications?

I wanted to add a comment to Allan’s blog post The next big thing, but too late! comments are already closed (side note, I think it’s a general problem on blogs.gnome.org or it’s a WordPress issue, or both).

So, at Flock 2014, Langdon White talked about “Fedora for Developers” (video), with the following idea, among other things: Desktop integration with “tasks” (with saved state).

It reminded me about a discussion that I had with gedit developers back in 2011. We talked about profiles: being able to create different gedit profiles, for example one for the C language and one for Vala. Different gedit instances could be launched with different profiles. They would behave as independent apps, with different settings, different plugins activated, a different UI state, and so on. Of course a profile could be created for each programming project, or… task.

But a task often involves launching several applications. So to resume a complete task quickly, in one step, it either needs some desktop integration, or another application could be responsible to create tasks and resume them. But either way it needs coordination with applications.

This entry was posted in Thoughts. Bookmark the permalink.

8 Responses to Task-oriented desktop and applications?

  1. liam says:

    I agree with you, and asked about this years ago. In general, I wish the GNOME designers would look to osx’s more advanced features than emulating the superficialities like top bar based buttons (yeah, from ios but not a great idea there either as their phones have gotten larger), separating document level functions from app level functions (very confusing to know when to look in which menu and simply doesn’t seem to offer any gain in usability), etc.
    I can’t by to post this (mobile.datamation.com/open-source/why-the-linux-desktop-should-be-organized-by-tasks.html), but allowed myself a tiny bit of space to rant, as is my wont, whenever someone affiliated with GNOME shows a bit of interest in making functional improvements which can lead to a better ux.

  2. eliasp says:

    The idea of “tasks” as you describe it sounds a lot like the concept of “Activities” in KDE/Plasma.

    An activity provides an environment, which is used to fulfill a certain task.
    Applications with support for activities can change their configuration, based on the activity they’re executed in.
    An activity can track (when configured to do so [1][2]) stats/history of applications, favorites [3][4], documents, etc.
    The desktop shell (Plasma) can be customized per activity
    When starting an activity, applications configured for this activity can be started automatically etc.

    Should you pursue those efforts further to implement “tasks” in GEdit or even more generalized in GNOME, I would welcome it very much if this could be done in an XDG manner so we don’t end up with to concepts following the same idea, but being incompatible with each other. Both could benefit tremendously from each other. While the underlying mechanisms of Activities work great since quite some time, application support is really lacking in many areas.

    You also might want to get in touch with the KDE/Plasma Activities developer Ivan Čukić (http://cukic.co/) for further discussion.

    [1] http://cukic.co/2015/08/09/activities-coming-soon-to-your-system-settings
    [2] http://cukic.co/2015/06/28/private-browsing-mode-for-activities
    [3] http://cukic.co/2015/08/21/people-you-often-write-to
    [4] http://cukic.co/2015/09/07/favourites-and-pinning

    • Heywood says:

      Well, there is Zeitgeist and the GNOME Activity Journal as its frontend, which I use daily. It’s a pity, that there is no development going on any more. Maybe that would be a good starting point for improving the task oriented approach. And it would give some more meaning to the top left corner called “Activities” ;-)


      • swilmet says:

        To keep track of the activities, yes there is Zeitgeist.

        But the point is to resume a task in one step: re-launch the applications you were using for that task, re-open the files/tabs that were previously opened, have exactly the same UI state as before, etc. And that, independently for several tasks.

        Because right now, switching between tasks can take a lot of time. Langdon explained that in the real world (outside of the computer), you usually separate tasks on your desk by having several stacks of sheet of papers, or folders. To resume a task, you simply take the folder, open it and you can start working, you have everything that you need at hand.

        • eliasp says:

          KDE/Plasma Activities do what Zeitgeist already does (tracking of activities, applications, documents, …) but also offers to start defined applications or resumed sessions per activity.

  3. Berend says:

    This is what I use workspaces for. One workspace, one task.

    This is why Gnome Shell’s default launch (activate running app) and default alt-tab behaviour frustrate me. They’ll happily switch to other workspaces (tasks) when I want to switch applications in this workspace (task).

    This is why I want gnome-session to remember running apps (and workspaces) on logout or shutdown. (this disappeared around Gnome 3.8, there is a bugzilla about that)

    A task usually has an editor (text editor — recently gnome-builder, or gimp, or libreoffice, or …) and a browser (for stackoverflow) a terminal for building and possibly a mail message. Somewhere there’s an SSH session.

    One task rarely has one window, just like one construction job rarely uses only one tool. One task rarely has a unique app running, just like multiple construction jobs are likely to each have a hammer and a screwdriver.

  4. Milan Bouchet-Valat says:

    Actually this idea was also discussed in the early stages of the development of GNOME Shell. It was called “activities” and then “desktop contexts” to avoid the confusion with the top-left corner button. You can find a few links in that message: https://mail.gnome.org/archives/gnome-shell-list/2009-November/msg00023.html

    • swilmet says:

      If GSettingsList is implemented one day, this would ease the implementation of profiles in apps. Then for the coordination between apps, a common D-Bus interface that apps can implement, and with D-Bus activation to launch the applications.

      Should be feasible, but it’s a hard undertaking.

      For gedit, finally I’m working (since several years) on making the code more re-usable. So instead of having only one general-purpose text editor, having several specialized text editors. This reduces a little the need to have profiles in gedit. But of course having profiles would be nice and is not mutually exclusive. See:

Comments are closed.

Leave a Reply

Your email address will not be published.