Re: Space, Times and projects
- From: Giovanni Campagna <scampa giovanni gmail com>
- To: Kao Chen <kaochen2 gmail com>
- Cc: gnome-shell-list gnome org
- Subject: Re: Space, Times and projects
- Date: Thu, 13 May 2010 22:11:08 +0200
On Thu, May 13, 2010 at 8:15 PM, Kao Chen <kaochen2 gmail com> wrote:
> I understand your critics, your comments is very enriching to me.
>
> At the idea beginning, I proposed to use links on a widget and not files in
> several desktop-folders.
>
> It's seems that Zeitgeist can easily add a project tag to a file.
> According to the discussion here on Ayatana mailing list.
> https://lists.launchpad.net/ayatana/msg01629.html
That's good - as a backend. Here I believe we need a front end,
clearly separating the History (G Activity Journal) from the current
Tasks / Projects, in a way that collects all entities from the same
project together. I don't care if the Zeitgeist backend is used (even
though I liked the idea of "ls ~/Project" to get a list of active
projects), as long as the UI is separate.
> If we can tag, we can manage files like a database, it's more powerful.
> But it can be more disturbing for the user: I erase a file from my widget
> and he doesn't disappear from my computer?
When the UI is project oriented, you can have two different commands:
one is "remove from current project", which removes the project tag
(or link from project dir), the other is "move to trash", that moves
the underlying entity (if that can be moved - you cannot move web
pages to the trash).
> So it's important in the design that we make a real difference between a
> link and a file.
Absolutely agreed.
> I first took the idea to add a widget with tab to make a real difference.
> Kde already use a plasma widget to display your preferred file, but with
> that, you hide the desktop. If a file is behind, you can't see it.
Well, the desktop keeps track of the visual position of files, so you
can place the icon in free space.
> For this different reasons, I decided to explore the possibility of a
> mutli-desktop issue. However, with links and tag files, it's can be very
> disturbing.
> Futhermore, how can I move or save my project if they are only links. I also
> need a real folder, if I created a file I need to put him somewhere.
Well... it depends on the nature of the project. For code projects,
say, you would have a repository somewhere, or at least a source tree,
and surely you don't want it on your desktop, no matter how focused on
it you are. For scientific analysis, you would have many datafiles not
directly useful when double-clicked.
When writing a journal article, you would have just a bunch of web
links and citations.
> So I pushed the idea futher and I added a desktop hierarchy.
>
> But like I said, I totally understand you critics, so I made an other
> mockup that goes in your way.
> Two is better than one ;)
>
> We keep one desktop folder.
> We use a Projects tree.
> We manage projects from the overview like the older mockup.
> We split the screen, one half for the desktop the other for a project
> widget.
Resizable widgets?
> We add a widget which is displaying the contents of a specific project
> folder. (eg. /home/angela/Projects/My new book)
> We seen tab from the others projects loaded.
> and We can display file by type.
>
> The file is here:
> http://nsa14.casimages.com/img/2010/05/13/100513081238328205.jpg
> Do you like it?
The concept is there, just waiting for implementation!
Giovanni
> Thanks for listening
> Kao
>
> 2010/5/13 Giovanni Campagna <scampa giovanni gmail com>
>>
>> On Thu, May 13, 2010 at 1:57 AM, Kao Chen <kaochen2 gmail com> wrote:
>> >
>> > Hi Giovanni!
>> >
>> >>
>> >> I've seen your page and I must admit I like it. Just I think the
>> >> "Desktop" is not the right concept here. In fact, the desktop
>> >> metaphor, while being very familiar to users, has some limits:
>> >> - like wooden desktops, it tends to become a mess;
>> >
>> >
>> > It's already a mess. I don't know anybody capable to keep a desktop
>> > clean and a strict folder organization.
>>
>> That's exactly why we should not encourage such behaviour.
>>
>> >>
>> >> - it requires you to minimize the current windows (something we should
>> >> avoid given the difficulty to restore a window).
>> >
>> >
>> > It's a big problem in my opinion, if we can't minimize windows we can't
>> > use the only desktop folder we have.
>> >
>> >>
>> >> In addition, the GNOME 2 desktop implementation has some more
>> >> "flaws" (as I see them):
>> >> - it mixes volumes (USB, SD), network shares, standard icons
>> >> (Computer,
>> >> Trash) with real existing files
>> >
>> >
>> > I don't understand, don't we already do that?
>>
>> Yeah. I pointed out it is a GNOME 2 flaw. Changing it would be
>> appreciated, at least by part of the users.
>>
>> >>
>> >> - being a Freedesktop, it uses $XDG_DESKTOP_DIR (and assumes there is
>> >> one such directory)
>> >
>> >
>> > I know it's a big change ;)
>> >
>> >>
>> >> Therefore I think that projects should be moved to a separate
>> >> ~/Projects
>> >> directory, and that an extension be made to Shell to add either a
>> >> Plasma-like widget to the background, clearly distinguished from the
>> >> remaining ~/Desktop, or something like the proposed Task Pooper,
>> >> overlaying windows from the bottom.
>> >
>> >
>> > I have made a mockup with a Plasma-like widget but it just hided a
>> > unnecessary desktop because at this time we are working in a project. I
>> > deliberately decide to not use widget and directly put the documents on the
>> > desktop.
>> > http://nsa15.casimages.com/img/2010/05/02/100502065741947598.png
>>
>> But the difference is that a desktop is spacially organized: you can
>> put files here and there, icons are not all the same size, some appear
>> in random locations...
>> A FolderView, on the other hand, is always aligned and looks
>> definitely cleaner. Plus it is a widget, not an empty space: it can
>> have icons, thumbnails can be put aside with some description, you can
>> use column view, list view or grid view, you can have like multiple
>> tabs (like separating URL from applications from documents) and most
>> important it scrolls, meaning that you get more space for more
>> documents.
>>
>> >>
>> >> Also, I think that instead of fixed directories like ~/Projects/Work
>> >> and
>> >> ~/Projects/Home, we should add tags in each directory, using a .project
>> >> file, or extending current .directory syntax. In particular we should
>> >> avoid dot-files whenever possible, as GtkFileChooser showes them
>> >> randomly
>> >
>> >
>> > I prefer working in a desktop folder, because in my idea I display the
>> > folder in full screen.
>>
>> But the desktop folder, being some sort of temporary pastebin for
>> stuff yet to classify, is not a project, which is organized and
>> tightly coupled.
>> Also, not having a desktop in the background prevents fast handling of
>> asyncronous interrupt. Think of evolution notification, new mail, has
>> attachment:
>> where do you save it for later handling? it goes to the desktop, even
>> if it is completely unrelated to your current task.
>>
>> > But if we can tag any folder, and transform it in a desktop folder, it's
>> > can be interesting.
>>
>> I didn't mean any folder, any meant any folder in ~/Projects, that is
>> putting project folders directly under the main project dir, without
>> intervening classification.
>> It is technically impossible to make any folder anywhere a project by
>> using .project, as it requires opening any folder shown in Nautilus.
>> Could you imagine the mess with automount? You could go with xattrs or
>> gvfs-metadata, but I don't think that is the best way.
>> Also, we should decide what the content of project dirs should be:
>> should it make sense to cd to a project dir? Should it hold files,
>> symbolic links or just .desktop files? Is the idea to just
>> cd ~/Project
>> git ssh://random.location/repo.git
>> cd repo/
>> <start working>
>> or you want a more complex user interface concept?
>>
>> > For technical questions, it seems important to have a draft copy on a
>> > USB stick and go with all the elements the most easily possible.
>> > For technical questions, it seems important to easily copy on a USB
>> > stick and go with all the elements as simply as possible.
>> >
>> > kind regards,
>> > Kao
>> >
>> >
>> >>
>> >> Giovanni
>> >>
>> >> > 2010/5/8 Virgil Brummond <uraharakisuke153 gmail com>
>> >> > Kao Chen, the idea about projects seems great. Just have an
>> >> > activity and
>> >> > drop it, though I think it might be better if you drop it
>> >> > twice to just
>> >> > move all the currently open ones to the workspace in
>> >> > question,
>> >> > and not
>> >> > open another copy of them. What do you think?
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > gnome-shell-list mailing list
>> >> > gnome-shell-list gnome org
>> >> > http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > gnome-shell-list mailing list
>> >> > gnome-shell-list gnome org
>> >> > http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>> >>
>> >>
>> >
>> >
>
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]