480926 - Selects the former path in dashboard

Status: RESOLVED FIXED

(Skywriter Graveyard :: File Explorer, defect, P2)

Description

[Julian Viereck]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; de-de) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
Build Identifier: Bespin 0.1.3 as on 03/02/09

When editing an file and click on the icon to go back to the dashboard the former selected path to the edited file is not selected again.

Reproducible: Always

Comment 1

[Julian Viereck]

Attachment: a hg-bundle to fix the bug

Comment 2

[Julian Viereck]

for more information see: http://groups.google.com/group/bespin-core/browse_thread/thread/4b2365123610b542

Comment 3

[Julian Viereck]

Attachment: Additional improvement for "Selects the former path in dashboard" (hg-bundle)

+ fixes a litte bug
+ brings the calls to scene.render() / scene.paint() to a minimal

Comment 4

[Julian Viereck]

Attachment: fix + one patch for all changes

+ fix bug for repainting

(the last .patch-file contains all the changes done in ONE file)

Comment 5

[Dion Almaer]

Julian,

This is awesome! We will check this out today and try to get it in. Great stuff!

Comment 6

[Dion Almaer]

Julian, Got this checked in.

One subtle thing: when you go back to the dashboard it selects the file that you were just in whereas I was expecting it to select the file that I selected when I was last in the dashboard. What do you think?

Comment 7

[Julian Viereck]

Dion,

your right. Could you give me a hint how to save the path to the last selected file in dashboard (save this within the session variable I guess. But I have no idea how to do this within bespin...).

Julian

Comment 8

[Dion Almaer]

This fits into another bug (when selecting a Project call project:set on it).

We need to add to the click handler on the dashboard item (where it now selects the file and changes the color) to set the filename and path.

For example, this code lets you double click with the shift key and open the file in a new tab (well, try):

panel.bus.bind("dblclick", panel, function(e) {
  var newTab = e.shiftKey;
go.editor(e.thComponent.session.project, e.thComponent.session.path + "/" + e.thComponent.session.filename, newTab);
                    });

Comment 9

[Julian Viereck]

Attachment: jump really back to selected path

+ Improve "dashboard memory": jump really back to selected path

Comment 10

[Dion Almaer]

Hi Julian,

Just found a bug. Because this occurs in displayProjects() it keeps resetting the project even if you select another one!

To fix either:

a) Have the loggedIn version pass in a "check URL" param to do the check, and in the other cases don't do it
b) Preferred: When the user changes the path by clicking around, change the #hash URL to point to their selection, this way reload / bookmarking works

Makes sense?

Comment 11

[Julian Viereck]

Dion,

I've got to look at that issue.

To your fixes:
a) I don't get what you want (I'm sorry)
b) It's the question wheter we want to do so. Adding to the #hash-url means each time the user selects a new file within the tree a new history-entry is generated. This is maybe not what most users expect. I guess they would expect to get back to their last edited file when clicking on the "back" button in the browser. What do you think?

Julian

Comment 12

[Dion Almaer]

Julian,

a) We call displayProjects from many places. Right now, each time we call it we run the hash lookup logic. Instead, we should only do the hash lookup logic the FIRST time we call displayProjects.... the time when we load the page. To do this, we could have that onload call pass in displayProjects(files, checkHash) where checkHash == true. Then, every other time, we don't do the hash check.

Does that make sense?

b) Ah, that is a good point. I would rather have the URL in sync with reality though, and maybe put in a UI element for "back to last edited file" link (we have the bottom open sessions too for people).

Cheers,

Dion

Comment 13

[Julian Viereck]

Dion,

a) okay, thats not a to big deal to be fixed.

b) I've done that nearly already. My problem at the moment is how can I figure out, that the URL hash has changed, as it does when the user clicks on the navigation back button. Is there a certain event fired in Dojo / Bespin when the URL hash changes?

Julian

Comment 14

[Dion Almaer]

Julian,

We already have the hash checking code available actually.

Check out urlbar.js.

What we should do is change:

            bespin.publish("bespin:editor:openfile", { filename: urlchange.get('path') });


to be:

            bespin.publish("bespin:url:changed", { path: send in the changed path });

And then in the editor we can subscribe to that and do an openfile, and in the dashboard we can do your change.

What do you think?

Comment 15

[Dion Almaer]

I just set this up:

http://hg.mozilla.org/labs/bespin/rev/25b518cb13eb

Note: I did the generic work, but didn't apply it to your changes. Cool? (need to include the urlbar in the dashboard dependencies, and then subscribe to the changed event to do the real work).

Comment 16

[Julian Viereck]

Dion,

thanks for your work. I putted it together and got a version "running" with the history working withing dashboard. The issue I'm facing in the moment is to bring down the numbers of fetching new filelists (via XHR) to a minimum. When selecting a file in the same directory and clicking on the history back button, the former file is selected (jep, that works ;)), BUT the whole tree is reloaded, which is really to slow for productive work. That's why I have not applied a patch yet.

I'm up to improve this and I've got a really good idea how to do this, but it turned out, that my code commited is really bad. I've got to put the things in a much more generic way. The work for that started but needs some time... 

Julian

PS: is it okay to do this conversation on this issue within bugzilla or should that be done in private emails? I'm just new to open source and have no idea how to handle all this "simple" things.

Comment 17

[Dion Almaer]

Julian,

Great work. Talking on Bugzilla is fantastic as then people have a record of the discussion, and we can go back and remember ourselves.

Feel free to put in a patch for the current "not optimized version" and then circle the wagons again with a new one. That way, you don't go too long without something that I can patch in and run into bit rot. Also, right now, the dashboard is in a weird state so having it just work as a step one is fantastic.

Again, I very much appreciate your contributions. This is high impact for little ole Bespin!

Cheers,

Dion

Comment 18

[Julian Viereck]

Attachment: Rewrite of Dashboard History (hg-bundle)

+ fixes bugs within the Editor
+ the editor link to get back to the dashboard calls now "bespin.util.navigate.dashboard()"
+ rewritten and improved Dashboard history
+ loading the history is now much faster
+ fixes a lot of bugs within Dashboard history

Julian

Comment 19

[Julian Viereck]

Dion,

please have a look at this bugreport: https://bugzilla.mozilla.org/show_bug.cgi?id=481416.

I think this bug should be fixed with the new patch, but I would prefer to have your oppinion ;)

Julian

Comment 20

[Dion Almaer]

Awesome! Works great. Committed. One minor quibble. The URL on the editor becomes something like:

http://localhost:8080/editor.html#project=SampleProject&path=/index.html&pathSelected=bespin/backend/java/tests/

Maybe we change it to be a bit clearer 'fromDashboardPath':

http://localhost:8080/editor.html#project=SampleProject&path=/index.html&fromDashboardPath=bespin/backend/java/tests/

SOmeone asked why there were two paths.....

What do you think? VERY minor.

Comment 21

[Julian Viereck]

Attachment: Change path arguments in the url hash

+ changes Dashboard URL hash from "pathSelected" to "path"
+ changes Editor URL hash from "pathSelected" to "fromDashboardPath"

Comment 22

[Dion Almaer]

Fantastic. Commited.

Comment 23

[Julian Viereck]

Attachment: Fixes + Cleanup of Dashboard History

diverse Dashboard History Fixes
+ the Project List cannot be deselected anymore
+ cleanup of the history code
+ reduce calls of "render()" at some points
+ diverse other fixes and improvements

---

There are some litte bugs left, but I think it would be much easier to implement the "th.components.HorizontalTree" in a new way. I will send a proposal within the next days.

The more generell question: Is this good to improve the dashboard that much, or should we / I concentrate on the editor itself...

Comment 25

[Gordon P. Hemsley [:GPHemsley]]

This is a mass migration from Mozilla Labs :: Bespin to Bespin :: Dashboard.