EiffelStudio: an EiffelSoftware project - User contributions [en]

Talk:History behavior

2007-03-28T21:56:43Z

Neallester:

--[[User:Ericb|Ericb]] 17:23, 27 March 2007 (CEST): One thing that I don't like with the history mechanism in EiffelStudio and other tools is that it's not always the oldest item which is removed from the list. Let's consider that I looked at classes A, B , C, D in that order. The history will look like that:

A B C D
^

If I then go backwards to look at B again (using the history navigation means):

A B C D
^

and then decide to look at class E, then C and D will be removed from the history, even though I looked at them more recently than A:

A B E
^

I find this situation very annoying. In a tool that I wrote, I implemented a history mechanism where only the items to the left of the history (i.e. the oldest) are removed. It is probably not a standard behavior, but I find it more convenient. It works as follow. Let's consider that I have:

A B C D
^

and want to look at class E, then my history will look like that:

A C D B E
^

B has been moved forward because that's the class I was just looking at, and then E has been added. That way I don't lose C and D, they are still in the history, still accessible using the history navigation means. Likewise, if I then drop class C in my tool, the history will look like that:

A D B E C
^

I find it more convenient than:

A C D B E
^
because C is really the most recent class that I looked at.

'''--[[User:Manus|manus]] 22:56, 27 March 2007 (CEST)''' EiffelBench implemented something like that, but we dropped it partly because it was confusing. Moreover the fact it is not standard behavior might not be a positive point for certain people. However something we could do is preserving the back and forth button behavior (i.e. acting the same way as in your web browser) and changing the dropdown to list the most recently used items first and then the history (the way it is done in some of Microsoft tools for style/font selection). What do you think?

--[[User:Ericb|Ericb]] 00:39, 28 March 2007 (CEST): Do whatever you want, but don't throw away recent items before older ones. I must say that I really like the way the history works in my tool (as described above), despite not being standard. It is very convenient and I don't find it confusing at all. To the contrary, it is less confusing than having items disappearing from the history just because I clicked a couple of times in the back button before dropping a new class. This behavior is not acceptable to me. It's not a question of confusing or not, but of acceptable or not. I don't think that history should work like a undo/redo mechanism. But the impression that I get from EiffelStudio's history is exactly that: a undo/redo mechanism, not redone actions are lost when executing a new action.

--<b>[[User:Ted|Ted]] 04:42, 28 March 2007 (CEST)</b>: I don't like the way items are thrown away neither, so I had an idea I called it Insertion mechanism. As long as one think it the way editing the text at inserting mode, it is easy to understand. It works like this:
A B C D
^
A B E C D
^
Time items are inserted or visited is also tracked, and the oldest one will be removed when a new item is inserted. I know that this mechanism also breaks the standard way. By any means, not throwing away recent items is contradictory to the standard behavior, because the standard does.
The reason I don't like Eric's is that moving items around is really confusing, at least for me, and I would rather keep it as what it is.

-- [[User:Larry|larryl]] 05:09, 28 March 2007 (CEST) Visual Studio 2005 has the same history behavior as the last behavior Ted described. I think that one it the best one so far.

--[[User:Ericb|Ericb]] 11:20, 28 March 2007 (CEST): Sorry, I still prefer the behavior I described. The behavior described by Ted is not satisfactory to me because E is more recent than C and D, so it should appear to the right of these two classes. Otherwise E will be removed (at some point) from the history before C and D, even though it is more recent. The behavior that I described is not something that I came up with one morning when waking up. I gave it a lot of thoughts. It is the result of several trials and corresponds to what is the more useful for me in practice, while not that confusing after all (at least not for me) compared to other solutions.

--[[User:Ted|Ted]] 11:48, 28 March 2007 (CEST): E will not be removed before C and D. I said the time E inserted is tracked, so the structure in fact does not anymore fully represent a sequence in time.

--[[User:Ericb|Ericb]] 14:27, 28 March 2007 (CEST): If you don't call this behavior "confusing", what do you call it?

--[[User:Paulb|Paulb]] 20:02, 28 March 2007 (CEST) Okay, so here it is. The Visual Studio mechanism works very well but the issue with Visual Studio is that it does not have a real history. Visual Studio navigates documents using CTRL+TAB, which we have in EiffelStudio. In Visual Studio it is very effective and behaves in a similar manner to what Eric is describing. In addition you cannot open a previous opened and closed document, like you can with the EiffelStudio history.

To explain the process you need to consider that an open document cannot have it contents replaced by another document, as with EiffelStudio. Opening a file will '''always''' create a new tab (I wish ES could be configured this way, as do others)

For the initial open documents, start with A through D. D will be the last opened.

A B C D

Using CTRL+TAB to access the history an select B would yield a history

A C D B

B is moved from it previous position an placed at the end. This would also be true if you attempted to reopen B. It's logical that D was used prior to B so hitting CTRL+TAB once would flip back to D.

A C B D

If the user wants to got two steps back they'll press CTRL+TAB, release TAB and press TAB again. Pressing TAB twice (same as ALT+TAB in Windows.) would end up with C as it's two positions back.

A B D C

You see C is now at the end next to D, which was opened last.

If A is then closed the history is as such

B D C

A no longer belongs to it. As I said, this is not a real history.

With the VS mechanism, using the back and forth buttons, you would only be able to switch between the two last opened documents. This can be remedied by using a cursor as Eric described in his approach of using a cursor. That is:

A B C D
^

Press back twice

A B C D
^

Press forward once

A B C D
^

What happens when you open a new document now. Current described rules dictate that it should appear after D. I say no. When you navigate back in a history and new changes at that point wipe out the future. That is to say:

A B C D
^

Now we open E

A B C E
^

D is wiped out, just like undo/redo. Eric approach although effective to himself because he knows the internals, will actually be confusing to those that don't. The same holds true for Ted method of insertion.

Neither approach works on their own. There are two approaches we can take. One with the current mechanism of being able to swap documents or the other without swapping. Without swapping is much easier to implement.

You need to maintain three separate histories. You need an open/viewed document history that monitors what tabs are opened and switched to, I'm calling the Open History (OH). This would behave in exactly the same manner as Visual Studio, as described above. The other history is implemented using a cursor and works for the back and forth buttons, I'm calling the Visit History (VH). The difference between OH and VH is that VH maintains items that have closed as well as hosting similar history items. In addition VH will track both switching of classes and features. The thrid and final history I'm calling the Recently Used History (RH), for the history combo box. RH is like OH but maintains closed items.

To exampling, let's start with A through D again.

(OH) A B C D
(VH) A B C D
^
(RH) A B C D

Press back once

(OH) A B D C
(VH) A B C D
^
(RH) A B D C

C is move in OH and RH and placed at the end.

Press back once again

(OH) A D C B
(VH) A B C D
^
(RH) A D C B

B is move in OH and RH and placed at the end, after the last viewed C.

Press forward

(OH) A D B C
(VH) A B C D
^
(RH) A D B C

C is move in OH and RH and placed at the end, after the last viewed B.

Close A, without switching to it using the X on the tab.

(OH) D B C
(VH) A B C D
^
(RH) A D B C

A is removed from OH because it only maintains the history for opened items. All other histories are unaffected.

Now using CTRL+TAB switch to B.

(OH) D C B
(VH) A B C B
^
(RH) A D C B

You see that B now appears twice in the VH. D has also been removed from VH because changing the past events affect the future. Always note that OH and RH switched to class at the right most of the history.

Now open a new class E

(OH) D C B E
(VH) A B C B E
^
(RH) A D C B E

Now this history is outlined the semantics of VH and RH need to discussed with respects to the multi-tabs editor. Currently EiffelStudio supports swapping open document tabs with different content. I also propose that we have a preference that is strict in a tab-per-document, i.e. not swapping permitted.

1. With swapping:

Now we have multiple tabs maybe the VH back and forth history should only pertain to the active tab, just like multiple-tabbed web browsers. An issue is that you could navigate back in a tabs history to open the same document that is already opened in another tab, which should not really be permitted. There are three solutions to this
* When reaching that history item, switch to the opened tab. However with localized tab history what's the consequence of switching to a new tab? Does the switched to tab history take over? It shouldn't because that's not the history the user was navigating through. That would be the only viable option unless you really want to mess up the history trying to do overly complex tracking.
* Skip or remove the history item if it's open in another tab. But this creates an incomplete history.
* Prompt the user to switch to the open tab. This is going to get annoying because what if there are other history items that you have to navigate past, that have their documents open in other tabs. You would be prompted for each one!

So, in my mind, there is no nice solution.

I discussed this with Julian and Martin and the only solution visaged would be to allow the same document to be opened in the editor. Martin actually wants this behavior because there is no way to edit the same document in two places using a vertical split editor, like most editors have. Allowing the same documents open multiple will enable this. However the multiple tab editor will need to be modified to abstract the view from the underlying buffer, so modifications are synchronized between the views.

For the RH, selecting an item would either switch to an already open document or replace the current tab with the selected unopened document.

2. Without swapping:

Without the ability to swap documents the VH back and forth buttons would act globally. That is switching to any opened tab that hosts the history item or opens a new tab if the history item is associated with a closed document.

The rules for RH are the same as using the VH.

--[[User:neallester|neallester]]

I don't have time right now to read or join the conversation, but [http://www.cosc.canterbury.ac.nz/andrew.cockburn/web_navigation.html I found this analysis of web browser navigation interesting.]

Talk:Context Menu

2007-02-08T15:56:14Z

Neallester:

Put your comments there.

--[[User:Peter gummer|Peter gummer]] 13:28, 8 February 2007 (CET)
The mechanism looks good, and the details of the various menus appear to be well thought-out.
Something I would want to see is the ability to hit the context menu key available on most Windows keyboards as an alternative to having to reach for the mouse.
Another issue is that I've submitted a change request asking that the top-level "Clusters" folder in the Clusters tool be removed, because it just gets in the way; but if you did so then you would have to figure out where to put the "Add Cluster" context menu item. I don't think this is a problem, however: "Add Cluster" could simply go on the context menu of a cluster folder.

--[[User:Jfiat|Jocelyn]] 08:11, 8 February 2007 (CET)
This sounds great for me, context menu will be very useful in many places.
I was also wondering if we could one more way to handle the "Pick&Drop/Context Menu"
For instance if we just Right_Click "Released" by default we keep the P&D mechanism, but if we keep the Right_click pressed for a moment (10ms for instance) we display the context menu.
So this would allow 3 behaviors, maybe that would be too heavy, however this could be a smooth way to integrate context menu into EiffelStudio.

--[[User:Ericb|Ericb]] 08:24, 8 February 2007 (CET)
In many applications that I use, the first entry in the contextual menu is in bold, and if instead of right-clicking I double-left-click I get the action of this bold entry executed. I realize that in text panels of EiffelStudio double-left-click might already be used (to select a word for example). But what about using double-right-click to get this behavior, instead or in addition to shift-right-click?

--[[User:Peter gummer|Peter gummer]] 13:28, 8 February 2007 (CET)
The double-click idea is a great one. I think that, wherever it's already used, that should be the first item in bold in the relevant context menu. This way, we conform to operating system standards. I still trip over pick-and-drop, right-clicking in other applications when I should be left-clicking. Failure to conform to operating system standards just slows users down. So double-'''left'''-click, please. (Double-'''right'''-click is already used, by the way, in EiffelStudio's editor and context tools. To target the editor or context tool to a class or feature currently referenced there, I just double-right-click on it. The Diagram tool is inconsistent in this respect, by the way, because whenever I double-right-click on a class bubble, instead of targeting the Diagram tool it complains that I am creating an inheritance cycle: oops!)

--[[User:neallester|Neal Lester]] 8 February 2007
For some pick targets, I think the "Pick" option will be called far more frequently than any others. For those "pick" targets, it might be better to simply do the "pick" then the contect menu. For those rare times when you want the context menu, the user could drag the picked object to a "context menu" target on the tool bar. Dropping the picked object on the "context menu" target would activate the context menu.

Building tools requirements

2006-10-27T20:34:58Z

Neallester:

[[Category:Building Tools]]
Here is a short requirements list for a graphical tool to perform automatic builds of code (Eiffel, C, ...), of documentation and anything else that needs to be build to perform a delivery of EiffelStudio. It has to be graphical because it is easier to see dependencies and will help people who do not know the format used for those scripts to modify those scripts.

==High level requirement==
* Look at other existing tools that provides a GUI front-end (e.g. [http://www.kinook.com/VisBuildPro/ VisualBuildPro] which is a commercial product) to get the best out of them. Another option is to have a syntax aware editor with project specific autocomplete capabilities.
* Command line tool so that it can be launched as a cron job.
* Multi platform.
* Notion of tasks and dependencies between tasks. That way, internally it can build a graph and can optimize the build process depending on the number of CPU you have on your machine.
* Pre-build tasks for Source control management (CVS and SVN), for file system manipulation.
* Easy to create new tasks that can be reused by other projects.
* Tasks are platform dependent so if running on windows, the unix tasks should not be ran.
* Launch task remotely on remote machine which has no binaries yet (that is to say the build tool needs to be compiled first and then the script launched). The remote access to the machine can be done using ssh/rsh.
* Failure handling: when a task fails, the build should continue until all other tasks that do not depend on the failed task have completed or failed. Then a summary should be presented and the user can after fixing the issue or the task restart the building process for that task and all the other tasks that depended on it. This feature is necessary to make the creation of new build process for very large system debuggable.