Re: [fossil-users] looking for interesting new fossil skins
Hello Stephan,
Here is a short patch that removes the use of the element which
has never been part of the standard. I have found that it is used solely
in stat.c to display the URL stats.
The fix is to replace by and add span.nobr {
white-space: nowrap; } to the default CSS in style.c. The diff is
against the master branch.
The patch for data-* attributes should follow...
Samuel
Le 14/02/2014 16:49, Stephan Beal a écrit :
> On Fri, Feb 14, 2014 at 4:43 PM, Samuel Debionne
> > wrote:
>
> Yep adding data-* is not that straightforward… If you want I can try
> to create a patch with that functionality alone (a subset of the
> diff I send you earlier).
>
>
> Yes, please.
>
>
> Something I noticed while hacking the wikiformat code is the use of
> which is not valid HTML AFAIK. Closing
> tags should not have attributes right ?
>
>
> Correct. i'm not familiar enough with the parse to know why it's doing
> that off-hand, but will take a look (no promises!).
--- C:/Developpements/fossil/master/src/style.c Mon Feb 17 16:21:28 2014
+++ C:/Developpements/fossil/fossil-lthe/src/style.cMon Feb 17 16:24:20 2014
@@ -1191,6 +1190,10 @@
"odd table row color",
@ /* Use default */
},
+ { "span.nobr",
+"NOBR tags deprecated, use ",
+@ white-space: nowrap;
+ },
{ "#canvas", "timeline graph node colors",
@ color: black;
@ background-color: white;
--- C:/Developpements/fossil/master/src/stat.c Mon Feb 17 16:21:28 2014
+++ C:/Developpements/fossil/fossil-lthe/src/stat.c Wed Jan 29 15:16:12 2014
@@ -18,7 +18,6 @@
** This file contains code to implement the stat web page
**
*/
-#include "VERSION.h"
#include "config.h"
#include
#include "stat.h"
@@ -262,7 +261,7 @@
cnt = 0;
while( db_step(&q)==SQLITE_ROW ){
@ %h(db_column_text(&q,0))
-@ %h(db_column_text(&q,1))
+@ %h(db_column_text(&q,1))
cnt++;
}
db_finalize(&q);
@@ -277,7 +276,7 @@
cnt = 0;
while( db_step(&q)==SQLITE_ROW ){
@ %h(db_column_text(&q,0))
-@ %h(db_column_text(&q,1))
+@ %h(db_column_text(&q,1))
cnt++;
}
db_finalize(&q);
___
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] looking for interesting new fossil skins
Here is an other short patch that enables the use of div elements in the
wiki formatting rules.
For instance the index.wiki beginning could be rewritten from
Simple, high-reliability, distributed software configuration
management
to
Simple, high-reliability, distributed software configuration management
With .jumbotron defined in the CSS as :
.jumbotron {
font-size: 3em;
padding: 30px;
border-radius: 6px;
background-color: #eee;
}
In some cases it may help separate content from presentation...
Samuel
@@ -948,9 +948,9 @@
if( p->nStack ){
int iCode;
p->nStack--;
iCode = p->aStack[p->nStack].iCode;
-if( iCode!=MARKUP_DIV && p->pOut ){
+if( p->pOut ){
blob_appendf(p->pOut, "", aMarkup[iCode].zName);
}
}
}
@@ -981,9 +981,9 @@
static void popStackToTag(Renderer *p, int iTag){
int i;
for(i=p->nStack-1; i>=0; i--){
if( p->aStack[i].iCode!=iTag ) continue;
-if( p->aStack[i].zId ) continue;
+/* if( p->aStack[i].zId ) continue; */
break;
}
if( i<0 ) return;
while( p->nStack>i ){
@@ -1482,8 +1482,10 @@
if( p->inVerbatim ){
p->inVerbatim = 0;
p->state = p->preVerbState;
blob_append(p->pOut, "", 6);
+ }else{
+blob_append(p->pOut, "", 6);
}
while( p->nStack>iDiv+1 ) popStack(p);
if( p->aStack[iDiv].allowWiki ){
p->state |= ALLOW_WIKI;
@@ -1547,8 +1549,9 @@
/* Push markup onto the stack together with the id=ID attribute.
*/
if( markup.iCode==MARKUP_DIV ){
+ renderMarkup(p->pOut, &markup);
pushStackWithId(p, markup.iCode, markupId(&markup),
(p->state & ALLOW_WIKI)!=0);
}else
<>___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] libfossil www interface: looking for ideas
Hi, all, over the weekend i put together some proof-of-concept code demonstrating CGI pages created using libfossil, e.g.: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/timeline?showSrc=1&limit=5 This post is about gathering input for, say, the top 5 things a fossil WWW UI needs to provide, so that i can be sure to shape the code to be able to do these things. Some of the main features i have in mind include: - it must be able to support various types of pages: HTML, plain text, JSON, and those outputing raw data (e.g. for fetching images or PDFs out of a repo). - For HTML-based pages, the framework should take care of wrapping the main content (the "app") in the site's preferred header/footer, and catching exceptions thrown from the app so that they can be displayed inside the normal page layout (as opposed to ending the page abruptly at the error point). The framework supports multi-level output buffering (modeled on PHP's ob_start() and friends) so, for example, it is possible for a page to decide, halfway through rendering, that it will set a cookie (it's not normally possible to set cookies after page output has started, but buffering enables that) or even that it will simply discard all current output, change the Content-Type, and output something completely different. - it must be relatively extensible by the client. One of my goals is that clients can add pages by dropping scripts into some specific directory (or store them in a db table) and, after that, some CGI path, e.g. /pages/mySpecialPage, will Do The Right Thing, wrapping the page/app up in the main layout, or allowing the page to specify that it will generate all output itself (e.g. JSON or raw binary output). - rather than think in terms of pages i'd like to think in terms of "apps" or "applets." There's no reason that a "page" should not be able to turn around and embed 4 other smaller "pagelets." There's also no reason those pagelets can't load JavaScript, fetch JSON data from the server, and be completely interactive. There are no compatibility constraints vis-a-vis the fossil we all know and love. This is about creating alternate UIs for it. Before asking some concrete questions, let me briefly explain current caveats (due to current limits of libfossi): - it's read-only: libfossil doesn't currently know anything about fossil's authentication model. i.e. only public content can currently be rendered by apps, and editing anything (while possible at the library level) won't be on the UI's TODO list for the near-term. - There is no ticket support for the time being. Fossil's tickets are closely tied to th1, and i currently have no plans to integrate th1 into libfossil (but may eventually do so via a higher-level optional API). Now the questions... what are the top 5 (or so) pages you all use in the Fossil WWW UI (the fossil 'ui' command, or the page shown by a fossil server/CGI)? Mine, in no particular order: - /timeline - browsing version diffs from the timeline - /reports (i love these!) - the wiki often in some repos, but not at all in others. - occasionally /dir, but not too often In your opinion, what page is missing from Fossil, which you would like to see (keeping in mind the caveats mentioned above)? :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ 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] libfossil www interface: looking for ideas
opinion polls are always fun, because everyone has one. On 17 February 2014 18:33, Stephan Beal wrote: > what are the top 5 (or so) pages you all use in the Fossil WWW UI (the > fossil 'ui' command, or the page shown by a fossil server/CGI)? in this order: - /timeline - /tree of trunk or particular checkin/tag - /taglist - /vdiff of sourcetree (glob) between 2 tags - all the rest (replace /tree with /dir if convenient) > In your opinion, what page is missing from Fossil, which you would like to > see (keeping in mind the caveats mentioned above)? Can't think of anything now; it's very complete for my use. Michai ___ 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] libfossil update
On Fri, Feb 14, 2014 at 10:55 PM, Stephan Beal wrote:
> That will be the basis of the up-coming checkout support, but solving
> checkouts at the library level first requires figuring out how to allow for
> user-level interaction ("overwrite file? Yes/All/No/Cancel?") for each file
> (like fossil does) while still hiding the gory fetching/looping details
> from the application. A prototype is in place, but is as yet untested.
>
Why does the library need to do any user-level interaction? Isn't that is
the job of the application? The library sends the file path/contents to the
application, and let the application do whatever it wants with it. If the
application decides that what it wants is to save it to disk and there is
already a file by that name, it is it's responsibility to do some form of
user-interaction to figure out how to handle this, no?
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
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] libfossil www interface: looking for ideas
On 2/17/14, 5:33 PM, Stephan Beal wrote: [...] > - rather than think in terms of pages i'd like to think in terms of "apps" > or "applets." There's no reason that a "page" should not be able to turn > around and embed 4 other smaller "pagelets." There's also no reason those > pagelets can't load JavaScript, fetch JSON data from the server, and be > completely interactive. This sounds very much as if what you're actually looking for is a web servlet engine with libfossil bindings, rather than anything that's actually specific to Fossil. In which case I'd strongly urge that the best option here is to pick a third party servlet engine based on its own criteria rather than inventing yet another one --- they're harder than they look and there are too many as it is! (Particularly if you want something session-based; sessions are surprisingly hard to get right.) [...] > In your opinion, what page is missing from Fossil, which you would like to > see (keeping in mind the caveats mentioned above)? I'd like a page that allows browsing the repository *by filename*. There are many occasions when I want to be able to link directly to the tip version of a particular file, and currently I can't do that --- I either have to link to a file by artifact ID or force the file to be available via doc/ somehow, which isn't always possible. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "You cannot truly appreciate _Atlas Shrugged_ until you have read it │ in the original Klingon." --- Sea Wasp on r.a.sf.w signature.asc Description: OpenPGP digital signature ___ 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] libfossil update
On Mon, Feb 17, 2014 at 8:48 PM, Baruch Burstein wrote:
> On Fri, Feb 14, 2014 at 10:55 PM, Stephan Beal wrote:
>
>> That will be the basis of the up-coming checkout support, but solving
>> checkouts at the library level first requires figuring out how to allow for
>> user-level interaction ("overwrite file? Yes/All/No/Cancel?") for each file
>> (like fossil does) while still hiding the gory fetching/looping details
>> from the application. A prototype is in place, but is as yet untested.
>>
>
> Why does the library need to do any user-level interaction? Isn't that is
> the job of the application?
>
Indeed! The interaction part is, but collecting a version's checkout data
is a relatively messy thing for clients to have to deal with. i have a set
of callbacks in place which allow a generic "yes/always/no/cancel"
mechanism which some types of applications can use to offer feedback. If
the callback is NULL, assume "always" and overwrite everything. So the
client doesn't have to provide one. Extracting the data is not all that
hard, it just requires some deal of knowledge of how fossil works. A
checkout-like operation can (with one minor currently missing detail) be
implemented using only public APIs.
> The library sends the file path/contents to the application, and let the
> application do whatever it wants with it. If the application decides that
> what it wants is to save it to disk and there is already a file by that
> name, it is it's responsibility to do some form of user-interaction to
> figure out how to handle this, no?
>
The new repo-extract functionality does exactly that, but i want to provide
a shell or GUI client the option to offer the user a choice of operations
when an extract would overwrite anything (eventually with undo support -
that's not been ported yet). Ideally they pass a simple callback to the
checkout func. The callback will get the name of the file and a flag will
tell the user what's happening:
- extracting a new file
- about to replace this file (prompt if needed)
that can be used to provide a status report of what's going on (it can take
a while) and give the user a chance to cancel it by returning non-0 from
the iteration callback.
A client which wants more control over the process could implement a loop
similar to this one:
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/artifact/cb2e81023e24b675?ln=1166-1215
That can all be done using the public API.
:)
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] milestone: libfossil CGI demo
On Sun, Feb 16, 2014 at 4:38 PM, Stephan Beal wrote: > Here's a more interesting example: > Even more so, a (very!) simple manifest browser: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest?version=trunk&baseline=1 http://libfossil.local/th1ish.cgi/manifest?version=1 With a bit of JS we could do some interesting things with that. The source code for that page: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest?showSrc=1 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ 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] milestone: libfossil CGI demo
On Mon, Feb 17, 2014 at 11:10 PM, Stephan Beal wrote: > http://libfossil.local/th1ish.cgi/manifest?version=1 > That obviously should have been: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest?version=1 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ 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] libfossil www interface: looking for ideas
On Mon, Feb 17, 2014 at 10:59 PM, David Given wrote: > This sounds very much as if what you're actually looking for is a web > servlet engine with libfossil bindings, rather than anything that's > actually specific to Fossil. > Almost, except that i have no grand delusions about it being used for everything. It's primarily: a) a testing ground for the lib. Can it provide users the data they need easily? Scriptability of a library is sort of a benchmark for me on its usability/flexibility. b) proof of concept. Until someone can actually "touch" libfossil, nobody but me is going to be using it! c) it's just fun to tinker with the script bindings. i'm not looking to provide a universal solution to all WWW UI needs, just a demo/proof-of-concept. In which case I'd strongly urge that the best option here is to pick a > third party servlet engine based on its own criteria rather than > inventing yet another one --- they're harder than they look and there > are too many as it is! (Particularly if you want something > session-based; sessions are surprisingly hard to get right.) > Can you recommend one in C? i'm self-imposed bound to C here. i "might" be convinced to write it in C++. i actually have sessions support implemented in C already[1], but it's not used here because i really don't want to have sessions in the db. Once libfossil gets fossil authentication support, i wouldn't mind storing non-anonymous/guest-user sessions (as a JSON object) in the repo, because that number is bounded (manx = one per registered user). That's a ways down the road, but it's not far out of reach (just not high on the priority list). A new demo, just uploaded : http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest?version=1 http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest?version=trunk&baseline=1 http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest?showSrc=1 Good night! [1] = http://fossil.wanderinghorse.net/wikis/cson/?page=cson_session -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
