Menu
▾
▴
sheets-devel — Sheets developer mailing list (high traffic)
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Aaron P. <ap...@cm...> - 2003-07-01 14:42:42
|
Hrm, it's a good point from a valid problem with using sheets. Novice users probably won't get the middle-click. But I think making a separate mode for editing vs. browsing could add a big layer of complexity -- how exactly would we switch to and from editing mode? I can't think of any way of doing this that wouldn't make it much harder to edit code now -- which is probably more important to users than browsing through code. I think editing code is the main feature of any IDE and browsing through the code is the secondary, supplementary, feature. I definitely think the idea of adding tooltips for the underlined links with a middle-click reminder and other useful information would be good -- and perhaps then making the links always be underlined and/or blue. How about another brainstorm to be complained about: when you left-click on a link, it does nothing out of the normal, but somewhere on the screen, either immediately below the text (like a tooltip or the new Office XP floating buttons) or in the context completion area, a button shows up saying "Browse to java.awt.Vector()". This doesn't get in the way, is more obvious than any of the other alternatives, etc. BTW, I do think the Office XP floating buttons (or whatever they call them) are a nice out-of-the-way feature... (Reminiscent of something I developed back when I tried to build a vector graphics GUI editor for Sheets and stuff). - Aaron Stephen Chin wrote: > I've been thinking about making some UI changes to sheets again, and > wanted to run it past some people. > > Here are some of the problems I have been thinking about: > 1. Middle-clicking is cool, but an awkward gesture for new users > 2. Rolling over the text to see what gets highlighted so you can click > on it is annoying > 3. When you are "navigating" code, sometimes it is easier to use the > keyboard than the mouse > > So here is my proposal (feel free to complain loudly): > 1. Make editing explicit. You can't type into a fragment until you > have turned editing on. > 2. Use the left mouse button for navigating codelinks in non-editing > mode. Control-left click while editing (with a tooltip to remind users) > 3. Underline all codelinks upon display (rather than waiting for a > mouseover) > 4. In non-editing mode, typing letters on the keyboard navigates to > the link by that name and pressing return follows the highlighted > link (sort of like the link navigation feature in mozilla firebird) > > Alternative proposal: > 1. Don't muck with the editing mode because it is fine like it is now. > 2. Add tooltips on codelinks that reminds users to middle click, and > possibly has some useful information about the link. > 3. Underline all links upon display (and don't bother turning things > blue, just underline). > 4. Add a special link navigation mode that you enter by pressing some > key combination, which temporarily turns on the keypress navigates > links mode. > > Anyway, just shooting off some ideas. No promises about actually > changing the behavior yet. :) > > --Steve |
|
From: Stephen C. <sj...@br...> - 2003-07-01 07:41:59
|
I've been thinking about making some UI changes to sheets again, and wanted to run it past some people. Here are some of the problems I have been thinking about: 1. Middle-clicking is cool, but an awkward gesture for new users 2. Rolling over the text to see what gets highlighted so you can click on it is annoying 3. When you are "navigating" code, sometimes it is easier to use the keyboard than the mouse So here is my proposal (feel free to complain loudly): 1. Make editing explicit. You can't type into a fragment until you have turned editing on. 2. Use the left mouse button for navigating codelinks in non-editing mode. Control-left click while editing (with a tooltip to remind users) 3. Underline all codelinks upon display (rather than waiting for a mouseover) 4. In non-editing mode, typing letters on the keyboard navigates to the link by that name and pressing return follows the highlighted link (sort of like the link navigation feature in mozilla firebird) Alternative proposal: 1. Don't muck with the editing mode because it is fine like it is now. 2. Add tooltips on codelinks that reminds users to middle click, and possibly has some useful information about the link. 3. Underline all links upon display (and don't bother turning things blue, just underline). 4. Add a special link navigation mode that you enter by pressing some key combination, which temporarily turns on the keypress navigates links mode. Anyway, just shooting off some ideas. No promises about actually changing the behavior yet. :) --Steve |
|
From: Aaron P. <ap...@cm...> - 2003-05-13 12:58:26
|
This is a multi-part message in MIME format. |
|
From: Stephen C. <sj...@br...> - 2003-05-13 00:39:58
|
Good point. If you have noticed, I have been spending a lot of time recently making sure sheets plays nicely with files on disk. It now is much more conservative about exporting (it will only export a java file if it has been modified... and rather than exporting to mark a file as dirty, it simply touches the file on disk). I really want to get started on doing some true versioning in Sheets. This is the ultimate goal of the project, and it will be the main differentiator in the long run. However, the same problem with filesystems exists for version control systems. Once I build a new version control system into sheets, it needs to be compatible with CVS to be widely adopted. I like your idea about storing meta information in the java files to preserve a round trip import/export. That might also be a good way to bridge the gap between CVS and the SVS (Sheets Versioning System). Following the principle of least astonishment, I'd like the export format to stay roughly the same unless the user makes a change in Sheets. For instance, if you import stuff and leave it on the default sheet, there is no need to export extra information in the Java file about the location of the methods. However, if you did a Sheets-ism like moving a few classes onto the same Sheet, or renaming the Sheet to something more meaningful, then it should export that information into the java file. I forgot to mention, I finished another project this weekend. Cassandra was born on Friday, and came home with mommy from the hospital yesterday. I attached a picture of her to this e-mail. I am taking a few weeks off to take care for mom and baby, but it looks like I may get some quality programming time while they are sleeping (like now). Cheers, --Steve ----- Original Message ----- From: "Aaron Powers" <ap...@cm...> To: <she...@li...> Sent: Monday, May 12, 2003 4:30 PM Subject: [Sheets-devel] A big Sheets idea > Here's an idea I've been thinking about for a while. > > One problem with using sheets with other developers is that we Sheets > developers really want to use Sheets dump files, because it's such a > rich format -- it saves all the hierarchies of files, fragments, etc., > puts in separators, and all sorts of neat stuff. But other developers > who don't use sheets just won't develop on a project at all if we use > dump files as our official, CVS-checked-in format*. One argument to use > dump files anyway is that would encourage more developers to switch to > sheets. But that's a Microsoft-monopoly argument -- there's so many > development environments and some programmers are so entrenched, they > really won't want to switch. > > So what if we make sheets work well without dump files? There's a way > to do this -- here's a couple tricks: > 1) Get rid of the exports list for a class and export in the order users > have organized their fragments. > 2) Turn separators into /* > ---------------------------------------------------------- */ and parse > them back out into separators when they come back in > 3) Use comments to show where fragments go in the hierarchy of sheets -- > at the beginning of a fragment, show a /* This Method's hierarchy: > Project Sheets -> Util Package -> CollectionUtils -> Collection Utils > Mouse Listener Stuff */ > (I only made up the last sheet name -- otherwise it's a real hierarchy) > This makes it human-readable and I think it has all the info that's in > Sheets dump files. > There's also a bug you mentioned with dump files that CVS and diffs > eventually work poorly on large ones -- I dunno if you fixed that, but > it wouldn't be a problem if something like this happened. Of course, > CVS merges would be harder because people can move methods around, but > that's just where CVS starts failing, not Sheets. > > I think this might be the way Sheets should evolve. Of course, it's a > tremendously large leap and requires a ton of changes to the code. > > * Of course, sheets dump files are just fine for the Sheets repository > where people are working on sheets > > - Aaron > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Sheets-devel mailing list > She...@li... > https://lists.sourceforge.net/lists/listinfo/sheets-devel > |
|
From: Aaron P. <ap...@cm...> - 2003-05-12 23:31:01
|
Here's an idea I've been thinking about for a while. One problem with using sheets with other developers is that we Sheets developers really want to use Sheets dump files, because it's such a rich format -- it saves all the hierarchies of files, fragments, etc., puts in separators, and all sorts of neat stuff. But other developers who don't use sheets just won't develop on a project at all if we use dump files as our official, CVS-checked-in format*. One argument to use dump files anyway is that would encourage more developers to switch to sheets. But that's a Microsoft-monopoly argument -- there's so many development environments and some programmers are so entrenched, they really won't want to switch. So what if we make sheets work well without dump files? There's a way to do this -- here's a couple tricks: 1) Get rid of the exports list for a class and export in the order users have organized their fragments. 2) Turn separators into /* ---------------------------------------------------------- */ and parse them back out into separators when they come back in 3) Use comments to show where fragments go in the hierarchy of sheets -- at the beginning of a fragment, show a /* This Method's hierarchy: Project Sheets -> Util Package -> CollectionUtils -> Collection Utils Mouse Listener Stuff */ (I only made up the last sheet name -- otherwise it's a real hierarchy) This makes it human-readable and I think it has all the info that's in Sheets dump files. There's also a bug you mentioned with dump files that CVS and diffs eventually work poorly on large ones -- I dunno if you fixed that, but it wouldn't be a problem if something like this happened. Of course, CVS merges would be harder because people can move methods around, but that's just where CVS starts failing, not Sheets. I think this might be the way Sheets should evolve. Of course, it's a tremendously large leap and requires a ton of changes to the code. * Of course, sheets dump files are just fine for the Sheets repository where people are working on sheets - Aaron |
|
From: Stephen C. <sj...@br...> - 2003-05-09 01:55:22
|
You are right about the Javadoc link. It was working on my computer, so it
is likely I just missed a directory while copying to sourceforge. I'll deal
with it later...
If you are interested in changing the commands, you can update them right in
the code. All of the variables are in the Profile class. In order to get
the display name, sheets takes the variable name and does some magic on it,
so what you need to do is change the variable name. Most variables are only
used in two places (initVariables which sets the defaults and trySet which
loads from a .sheetsrc file), but you can just do a goto references lookup
to find these from the variable declaration.
You also need to update the documentation under the Reference Manual sheet
(this is where the webpage is rendered from). I may have broken part of the
documentation editing feature recently, so if it doesn't work, hollar.
--Steve
----- Original Message -----
From: "Aaron Powers" <ap...@cm...>
To: <she...@li...>
Sent: Wednesday, May 07, 2003 5:48 AM
Subject: Re: [Sheets-devel] New Content on Web Site
The Javadoc link is broken:
http://sheets.sourceforge.net/javadocs/index.html
has nothing at it.
Are the commands on this page dynamically generated, and if so, from where?
http://sheets.sourceforge.net/reference.html
I've started to change some menu commands because I think the titles
aren't readable by a random user. Do I need to change them in more than
just the functional place?
- Aaron
|
|
From: Aaron P. <ap...@cm...> - 2003-05-07 12:52:37
|
Are the commands on this page dynamically generated, and if so, from wher=
e?
http://sheets.sourceforge.net/reference.html
I've started to change some menu commands because I think the titles=20
aren't readable by a random user. Do I need to change them in more than=20
just the functional place?
- Aaron
Stephen Chin a =E9crit:
> I have updated the test web site area with new content from my most=20
> recent centipede run. It now has the full Sheets documentation as=20
> rendered by forrest.
> =20
> Take a look at the new site here and tell me what you think:
> http://sheets.sourceforge.net/
> =20
> --Steve
> =20
|
|
From: Aaron P. <ap...@cm...> - 2003-05-07 12:49:04
|
The Javadoc link is broken:
http://sheets.sourceforge.net/javadocs/index.html
has nothing at it.
- Aaron
Stephen Chin a =E9crit:
> I have updated the test web site area with new content from my most=20
> recent centipede run. It now has the full Sheets documentation as=20
> rendered by forrest.
> =20
> Take a look at the new site here and tell me what you think:
> http://sheets.sourceforge.net/
> =20
> --Steve
> =20
|
|
From: Stephen C. <sj...@br...> - 2003-05-06 19:38:33
|
I have updated the test web site area with new content from my most recent centipede run. It now has the full Sheets documentation as rendered by forrest. Take a look at the new site here and tell me what you think: http://sheets.sourceforge.net/ --Steve |
|
From: Stephen C. <ap...@ve...> - 2002-11-28 07:32:20
|
I am working on moving over everything to centipede in order to unify = the code, documentation, and web-site build processes. As a result, I = had to reorganize the source tree (hence the flurry of cvs messages -- = sorry), and make some documentation improvements to sheets. The goal is = eventually to be able to edit the code and documentation as a single = unit in sheets, and have the web page automatically update to reflect = changes. By the way, more information on centipede can be found here: = http://www.krysalis.org/centipede/ The newly checked in code is based on the latest centipede codebase from = CVS, which will shortly be released as beta3. Since beta2 is outdated, = and the only way to build the new stuff is by using the centipede = version in CVS, I will leave the ant build scripts around for a while. Cheers, --Steve |
