[fossil-users] ui cosmetics
recently, I've started to use `ui' more heavily (due to the requirements of a new collaboration which makes use of the wiki and ticket system). while the ui sure is usable and provides all important functionality, I think a few things could be improved, especially when having novice visitors to a fossil driven site in mind. I list them here in no special order: == timeline == * it is non-obvious how to get to the display of file content related to a specific check-in: currently one has to do [timeline-sha1] -- [changes-to-sha1]. this is not what the new user would expect. rather he will look for the filename. but the filename link in the check-in page jumps to the history of the file. proposal: 1. link the filenames shown in the timeline when activating show files to the file content. 2. unlink the file name in the modified file.name from xxx to yyy line of the `check-in' page and add instead a history link on the same page (in the Timelines: line, probably) * the order of entries in the timeline menu is sub-optimal in my view. currently it is 200 entries | checkins only | events only | show files | older | tags only | tickets only | wiki only which mixes subsetting actions and timeline length or appearance actions. I propose to change (and rephrase) this to show file names | previous (and next in the other direction instead of older/newer) | more | less | checkins | events | tags | tickets | wiki this sorting order seems more natural to me (notably the user will directly see the file names tab). also, it would be nice to enable the user to increase/decrease the length of the time line display beyond choosing between 20 and 200 (and without knowing that this number can be edited in the URL). so I propose to increase/decrease the length of the timeline by a certain factor (of 10, e.g.) with each click on more/less (keeping the minimum length at 20). alternatively, one could keep the current 200/20 switch and add an all switch. == wiki == * the list of all wiki pages does not really stand out and is not reachable by a single click. if the new user starts at the home page and then goes to the `wiki' tab he sees a least on top of which is the link to the home page from where he just came (by default, anyway) and the link to the table of content (list of all wiki pages) is somewhere at the bottom. proposal: I would find it more convenient if the `wiki' tab would take the user directly to the table of content (list of all wiki pages) and that tabs were added beside the current `all' tab on that page for the other actions (recent changes, new wiki, etc.) or, at least, a single tab taking the user to a page listing these (essentially the page currently reached by the `wiki' tab). == files == * it would be nice if directories where differentiated from files (e.g. in unix `ls -F' fashion) by trailing `/'). * it would be nice if a one-column display where available (or configurable via a switch): it is easier to locate a file of a given name in a one-dimensional list. just my 2c, hope this makes sense (and I know that tastes do differ). but maybe some of the above proposals are found acceptable. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui cosmetics
On Wed, Oct 30, 2013 at 5:13 AM, j. van den hoff veedeeh...@googlemail.comwrote: recently, I've started to use `ui' more heavily (due to the requirements of a new collaboration which makes use of the wiki and ticket system). while the ui sure is usable and provides all important functionality, I think a few things could be improved, especially when having novice visitors to a fossil driven site in mind. I list them here in no special order: == timeline == * it is non-obvious how to get to the display of file content related to a specific check-in: On the Check-in page, the first link to the right of Other Links: is files which takes you to a display of all files for that one specific check-in. currently one has to do [timeline-sha1] -- [changes-to-sha1]. this is not what the new user would expect. rather he will look for the filename. but the filename link in the check-in page jumps to the history of the file. proposal: 1. link the filenames shown in the timeline when activating show files to the file content. There are two files: The before and the after. Which do you want to link to? Presumably the after file. But what then to do about deleted files, such as seen at http://www.fossil-scm.org/fossil/timeline?n=8c=1f498a6v - leave them unlinked or link them to the before vesion? 2. unlink the file name in the modified file.name from xxx to yyy line of the `check-in' page and add instead a history link on the same page (in the Timelines: line, probably) So, instead of saying: Modified dir/filename.txt(1) from 0123456789(2) to abcdef0123(3). (Where hyperlinks are shown with (#)) you think it would be better to say: Modified dir/filename from 0123456789(2) to abcdef0123(3). [history](1) I'm not so sure that is an improvement. You're going to need to really sell this one. * the order of entries in the timeline menu is sub-optimal in my view. currently it is 200 entries | checkins only | events only | show files | older | tags only | tickets only | wiki only which mixes subsetting actions and timeline length or appearance actions. I propose to change (and rephrase) this to show file names | previous (and next in the other direction instead of older/newer) | more | less | checkins | events | tags | tickets | wiki this sorting order seems more natural to me (notably the user will directly see the file names tab). also, it would be nice to enable the user to increase/decrease the length of the time line display beyond choosing between 20 and 200 (and without knowing that this number can be edited in the URL). so I propose to increase/decrease the length of the timeline by a certain factor (of 10, e.g.) with each click on more/less (keeping the minimum length at 20). alternatively, one could keep the current 200/20 switch and add an all switch. == wiki == * the list of all wiki pages does not really stand out and is not reachable by a single click. if the new user starts at the home page and then goes to the `wiki' tab he sees a least on top of which is the link to the home page from where he just came (by default, anyway) and the link to the table of content (list of all wiki pages) is somewhere at the bottom. proposal: I would find it more convenient if the `wiki' tab would take the user directly to the table of content (list of all wiki pages) and that tabs were added beside the current `all' tab on that page for the other actions (recent changes, new wiki, etc.) or, at least, a single tab taking the user to a page listing these (essentially the page currently reached by the `wiki' tab). == files == * it would be nice if directories where differentiated from files (e.g. in unix `ls -F' fashion) by trailing `/'). IIRC, we used to do it that way. But people complained about it so we took it out. :-( * it would be nice if a one-column display where available (or configurable via a switch): it is easier to locate a file of a given name in a one-dimensional list. just my 2c, hope this makes sense (and I know that tastes do differ). but maybe some of the above proposals are found acceptable. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui cosmetics
On Wed, 30 Oct 2013 10:49:58 +0100, Richard Hipp d...@sqlite.org wrote: On Wed, Oct 30, 2013 at 5:13 AM, j. van den hoff veedeeh...@googlemail.comwrote: recently, I've started to use `ui' more heavily (due to the requirements of a new collaboration which makes use of the wiki and ticket system). while the ui sure is usable and provides all important functionality, I think a few things could be improved, especially when having novice visitors to a fossil driven site in mind. I list them here in no special order: == timeline == * it is non-obvious how to get to the display of file content related to a specific check-in: On the Check-in page, the first link to the right of Other Links: is files which takes you to a display of all files for that one specific check-in. yes, I know. but consider the checkin concerns a single file (it frequently does) and that file is in dir/sub1/sub2/sub3/file.name it still'd be a pain to get to it (even if you perfectly remember in what subdir it is). I feel it should be essentially a straightforward 'one-click action' to reach the file content. currently one has to do [timeline-sha1] -- [changes-to-sha1]. this is not what the new user would expect. rather he will look for the filename. but the filename link in the check-in page jumps to the history of the file. proposal: 1. link the filenames shown in the timeline when activating show files to the file content. There are two files: The before and the after. Which do you want to link to? Presumably the after file. But what then to do about deleted yes, definitely after. I would say there is no ambiguity here: if you do display a file name in the timeline and link to it's content it should be the content _after_ checkin and that sure is what the user would expect to see, when going to that link files, such as seen at http://www.fossil-scm.org/fossil/timeline?n=8c=1f498a6v - leave them unlinked or link them to the before vesion? definitely unlink: I'm concerned with a probably rather common desire: look at file content _after_ some modification+check-in. so displaying the before content for deleted files would be inconsistent (and displaying the content of a file _after_ deletion (empty) is not very illuminating ;-)). luckily, you already show the status as (deleted) in the timeline. so leaving these unlinked would not cause confusion. 2. unlink the file name in the modified file.name from xxx to yyy line of the `check-in' page and add instead a history link on the same page (in the Timelines: line, probably) So, instead of saying: Modified dir/filename.txt(1) from 0123456789(2) to abcdef0123(3). (Where hyperlinks are shown with (#)) you think it would be better to say: Modified dir/filename from 0123456789(2) to abcdef0123(3). [history](1) I'm not so sure that is an improvement. You're going to need to really sell this one. I can try. 1. when I was rather new to `fossil' (and also not using the ui much) I demonstrated it to a svn customer in my group. first thing he asked: I want the logfile of changes for a selected file. how do I get it? empirical fact: I hardly didn't find it (that's the non-obvious location/name problem I see here). I bet most other new user will have the same problem. 2. unlinking the file name in the check-in page was just a proposal. actually, my problem is, that I find it just strange that _only_ the file name link here takes the user to the history of that file. having a link spelling out what's under the link is usually better I believe. so I would think even just changing the respective line to dir/filename.txt (history(1)): modified from 0123456789(2) to abcdef0123(3) or, possibly, dir/filename.txt(3) (history(1)): modified from 0123456789(2) or dir/filename.txt(3): modified from 0123456789(2) (history(1)) would be an improvement compared to the current version in my view. 3. if the change to the timeline regarding linking file names to file content after checkin would be realized I also would add a history tab to the 'artifact content' page. this would be another rather obvious location where to look for the history in my view. * the order of entries in the timeline menu is sub-optimal in my view. currently it is 200 entries | checkins only | events only | show files | older | tags only | tickets only | wiki only which mixes subsetting actions and timeline length or appearance actions. I propose to change (and rephrase) this to show file names | previous (and next in the other direction instead of older/newer) | more | less | checkins | events | tags | tickets | wiki this sorting order seems more natural to me (notably the user will directly see the file names tab). also, it would be nice to enable the user to increase/decrease the length of the time line display beyond choosing between 20 and 200 (and without knowing that this number can be
Re: [fossil-users] ui cosmetics
On 30-10-2013 12:15, j. van den hoff wrote:
On Wed, 30 Oct 2013 10:49:58 +0100, Richard Hipp d...@sqlite.org wrote:
== files ==
* it would be nice if directories where differentiated from files
(e.g. in
unix `ls -F' fashion) by trailing `/').
That can be done using CSS, nowadays. Since directories get a class of
dir, you can specify the following in the CSS to get a trailing slash:
li.dira:after {
content: '/';
}
Or, if you’d rather the slash not be part of the link:
li.dir:after {
content: '/';
}
It’s also possible to change the bullet into a circle, for example:
li.dir {
list-style-type: circle;
}
or even into a folder icon:
li.dir {
list-style-image:
url('http://icons.iconarchive.com/icons/deleket/sleek-xp-basic/16/Folder-icon.png');
}
(Of course, deeplinking like this is not recommended, so it would be
preferable to store the icon image in the repository, and refer to that).
That’s why I prefer the current CSS class-based method to hard-coded
inclusion of the trailing slash: it enables fairly extensive
customization. :-)
--
Martijn Coppoolse
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil internal error: repository does not exist or is in an unreadable directory
Andy, Thanks for your reply and offer of help. When I went to recreate the problem I found the solution. For anyone having this problem you need to rm .fslckout in the directory the contains your fossil repository. Be careful, I assume doing this will wipe out any stashed changes. db On Mon, Oct 28, 2013 at 9:50 PM, Andy Bradford amb-sendok-1385610625.phfkgoidnieliniml...@bradfords.org wrote: Thus said David Blanford on Mon, 28 Oct 2013 16:33:11 -0600: Fossil internal error: repository does not exist or is in an unreadable directory: Can you cause this to happen again with a different fossil file? If so, will you share the exact commands you typed to cause this? Thanks, Andy -- TAI64 timestamp: 4000526f30a1 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui cosmetics
Martijn Coppoolse wrote:
On 30-10-2013 12:15, j. van den hoff wrote:
On Wed, 30 Oct 2013 10:49:58 +0100, Richard Hipp d...@sqlite.org wrote:
== files ==
* it would be nice if directories where differentiated from files
(e.g. in
unix `ls -F' fashion) by trailing `/').
That can be done using CSS, nowadays. Since directories get a class of
dir, you can specify the following in the CSS to get a trailing slash:
li.dira:after {
content: '/';
}
Or, if you’d rather the slash not be part of the link:
li.dir:after {
content: '/';
}
It’s also possible to change the bullet into a circle, for example:
li.dir {
list-style-type: circle;
}
or even into a folder icon:
li.dir {
list-style-image:
url('http://icons.iconarchive.com/icons/deleket/sleek-xp-basic/16/Folder-icon.png');
}
(Of course, deeplinking like this is not recommended, so it would be
preferable to store the icon image in the repository, and refer to that).
I'm stoked that someone else uses (or at least is aware of) this. I
added it a few months back for my own selfish purposes. And, yeah,
replacing the standard bullets with icons is exactly what I do. You can
even add icons based on a file's extension (files with no extension get
the class file, *.c files get file-c, *.txt files get file-txt, etc.).
Also, an alternative to adding the icons to your repository is to embed
them in your stylesheet as data URIs. You can use a site like this to
convert images: http://dataurl.net/#dataurlmaker
That’s why I prefer the current CSS class-based method to hard-coded
inclusion of the trailing slash: it enables fairly extensive
customization. :-)
Agreed, that's why I added it! Although I suppose we can always argue on
what the default style should be (at least until Richard says that the
bike shed will be yellow and that's that).
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui cosmetics
On Wed, 30 Oct 2013 15:23:40 +0100, Martijn Coppoolse
li...@martijn.coppoolse.com wrote:
On 30-10-2013 12:15, j. van den hoff wrote:
On Wed, 30 Oct 2013 10:49:58 +0100, Richard Hipp d...@sqlite.org wrote:
== files ==
* it would be nice if directories where differentiated from files
(e.g. in
unix `ls -F' fashion) by trailing `/').
That can be done using CSS, nowadays. Since directories get a class of
dir, you can specify the following in the CSS to get a trailing slash:
li.dira:after {
content: '/';
}
Or, if you’d rather the slash not be part of the link:
li.dir:after {
content: '/';
}
It’s also possible to change the bullet into a circle, for example:
li.dir {
list-style-type: circle;
}
thanks a lot for this info. I don't know anything of CSS related things, I
was not aware of this possibility. and it sure fixes the issue for me. on
the other hand, I still believe that the average not-so-experienced user
will not want to dive into these sort of do-it-yourself configuration and
that a basic built-in solution would be good to have.
or even into a folder icon:
li.dir {
list-style-image:
url('http://icons.iconarchive.com/icons/deleket/sleek-xp-basic/16/Folder-icon.png');
}
(Of course, deeplinking like this is not recommended, so it would be
preferable to store the icon image in the repository, and refer to that).
That’s why I prefer the current CSS class-based method to hard-coded
inclusion of the trailing slash: it enables fairly extensive
customization. :-)
yes, I understand that, but see above: not everybody wants to do it,
presumably, and a basic builtin solution would be good to have. and I
believe another issue is that the configuration is local to the respective
repo. so if I fix the configuration on some server-side repo, the local
clone of somebody else will not profit from it.
anyway, thanks again. I at least know now how to fix it for my own repos.
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui cosmetics
On Wed, Oct 30, 2013 at 3:38 PM, j. van den hoff veedeeh...@googlemail.comwrote: ... thanks a lot for this info. I don't know anything of CSS related things, I was not aware of this possibility. and it sure fixes the issue for me. on the other hand, I still believe that the average not-so-experienced user will not want to dive into these sort of do-it-yourself configuration and that a basic built-in solution would be good to have. ... yes, I understand that, but see above: not everybody wants to do it, presumably, and a basic builtin solution would be good to have. and I believe another issue is that the configuration is local to the respective repo. so if I fix the configuration on some server-side repo, the local clone of somebody else will not profit from it. anyway, thanks again. I at least know now how to fix it for my own repos. Fossil supports skins, so it would be possible for people to each contribute their favorite skin incorporating some of these CSS mods. Personally, I'm content with the default skin, though I might try 1 or 2 of these mods. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] interactive patching?
'Lo. It's fairly common, in git, to do this sort of thing: 1. Make a load of unrelated changes. 2. Use git add --patch to stage commits consisting of sets of the changes. The reason this doesn't work to well is probably obvious to most fossil users: You don't know that each set of separate staged changes compiles and works properly, because you're not compiling against a clean working copy with only those individual changes. I don't know if git has a better way of doing things now, as it's been quite a while since I used it. The somewhat better analogous sequence in fossil is: 1. Make a load of unrelated changes. 2. fossil stash 3. fossil stash diff stash.diff 4. Use some external tool to interactively apply bits of stash.diff 5. Compile, run unit tests, commit if everything works. 6. If there's anything left in stash.diff, repeat step 4. This is better because it means each set of changes are tested against a clean copy of the source (so each subset of unrelated changes can be shown to not be dependent, etc). The main problem: Where is the tool to achieve step 4? I've looked and am not aware of any standalone tool that can essentially break up a patch and interactively apply parts of it to a directory. I personally use the 'Team - Apply patch' tool built into Eclipse, but I'm curious as to what other people to do achieve the above. I realise that often the answer is don't make a lot of unrelated changes at once, but for the sake of discussion, let's assume that this is sometimes unavoidable (and undesirable). M ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
