> Resizable widgets?
Sure, and a scroll bar on the right.
But I think its important that the widget stay a large panel.
It's where you work, where all your preferred documents are.

I will work on this, I will try to improve the mockup to make him more
precise.

Perhaps we can also easily hide the widget like I shown on the older mockup
for GAJ.

An idea complementary (or rival) to this widget, he's this excellent
implementation of Zeitgeist in Nautilus.
http://www.youtube.com/watch?v=PbHsO2GL9lM
If we add a button project to this, it's can be powerfull.
I still prefer the widget because we keep it on the front. Without a good
minimize handling, we need to keep it close to us.






2010/5/13 Sean Brady <[email protected]>

> Speaking of implementation, does anyone know anyone willing to code a test
> version of this? I was thinking that some "mockup" code would be good to
> actually touch and feel the workflow, make changes as necessary, get it
> right, then submit it for inclusion to the rest of the project.
>
> So far all my solicitations have come up empty.
>
>
>
> On 05/13/2010 02:11 PM, Giovanni Campagna wrote:
>
>> On Thu, May 13, 2010 at 8:15 PM, Kao Chen<[email protected]>  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<[email protected]>
>>>
>>>
>>>> On Thu, May 13, 2010 at 1:57 AM, Kao Chen<[email protected]>  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<[email protected]>
>>>>>>>         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
>>>>>>>         [email protected]
>>>>>>>         http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gnome-shell-list mailing list
>>>>>>> [email protected]
>>>>>>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> gnome-shell-list mailing list
>> [email protected]
>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>>
>>
> _______________________________________________
> gnome-shell-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
_______________________________________________
gnome-shell-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Reply via email to