r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Make-doc] moving forward

Ammon
29-Mar-2005
[494x2]
The Header File value on your MDP-GUI script needs to point to the 
script not the ZIP.  I believe that is your problem...
So changing the File value in the script header to %mdpgui1-4-1.r 
should make it work...
shadwolf
29-Mar-2005
[496]
well in fact the script countains lots of different files and handle 
them one by one it a true torture
Ammon
29-Mar-2005
[497]
Is the actual ZIP file that you are uploading named %mdpgui1-4-1.zip 
???
shadwolf
29-Mar-2005
[498]
no I dont even arrive to the upload pannel
Ammon
29-Mar-2005
[499]
Have you tried changing the script file extension from .ZIP to .R 
???
shadwolf
29-Mar-2005
[500x2]
yes I do it
k found ...
Ammon
29-Mar-2005
[502]
The good news is that there is now a different error.  With .ZIP 
it said that mdpgui1-4-1 was not a package now it is saying the package 
is unavailable...
shadwolf
29-Mar-2005
[503x2]
pfffffffffffiouuuuuuuuuuuuu OOOOOOOH MY it was hard  !!
type: [package] that was my problem
Ammon
29-Mar-2005
[505]
Ah, I see  TYPE needs a Block!
shadwolf
29-Mar-2005
[506x2]
yes I notice that it's hard
files have been uploaded but I can't dl them with repack
Ammon
29-Mar-2005
[508x2]
THat error means that you have the files set as not downloadable...
Browsing the package information on REBOL.org gives me this:  "Available?	false. 
This package is NOT available for download. The owner may be updating 
it."
shadwolf
29-Mar-2005
[510x4]
...
how can i change that ?
I foiund oki it's available now
good
Ammon
29-Mar-2005
[514]
Sweet!  There it is. ;~>
shadwolf
29-Mar-2005
[515x3]
so ppl now to  dl MDP-GUI 1.4.1 all you need is to append a rebol/view 
console and copy/paste  do http://www.rebol.org/library/public/repack.r
then find in the list MDP-GUI-1-4-1.r all the files in the package
need to be downloaded ;)
Brock
29-Mar-2005
[518]
Download/install works like a charm.  Nice job on mdp-gui.
shadwolf
29-Mar-2005
[519x5]
thank you brock it cost me a lot to put it online to rebol.org ;)
that to ashley and all the beta tester contributors idea teasers 
;) that allow me since november to heavyly enhance and make progress 
this app ;)
next step to MDP -GUI is to be made using RebGUI and encaped (wrapped) 
 by GREBOX  and a cute little installer for non rebol.org download 
;)
don't know if I could get enaought patience to make an input/rendering 
same window intaface once MDP-GUI interface will be based on rebgui 
;)
thank  to ashley and all the beta testers, contributors, idea teasers 
;) that allow me since november  2004  to heavyly enhance and make 
progress tMDP-GUI ;)
Brock
29-Mar-2005
[524]
Shame on me, nice job to all working on MD, MDP, GUI, and Ashley's 
MD-Viewer and RebGui.
shadwolf
30-Mar-2005
[525]
MDP-GUI Is one person coded but community inspired I love this kind 
of work  ;)
Robert
1-Apr-2005
[526]
I'm thinking about refining how emiters for MDP can be written. How 
about this:
- The parser part will stay as is.

- There will be a generic scan-doc routine that can handle: string!, 
file!, url! and block!
  The block can be a mix of string!, file!, url!

- Than there will be one generator loop that loops over the output 
from the parser (the intermediate format)

   This loop has a gib SWITCH statement for all intermediate format 
   words generated by the parser

- The particular generator will be provided in a context to the GENERATOR 
function and than only needs to
   contain the function stubs.

What do you think?
Vincent
1-Apr-2005
[527]
Robert : For the structure, you can look at my 'Easy-Doc prototype:
http://rebol.dev.fr/view.php?sid=141
It works with 3 sets of modules: readers, parsers and writers. 

'readers have to supply a text string to parsers (ie. MS-Word files 
are scanned for text),

'parsers build a block in intermediate format (there is a makedoc 
parser,)

and 'writers output the result either in file or on screen (VID / 
html / pdf / rtf / swf).
Robert
2-Apr-2005
[528]
Thanks I take a look. Well MDP is quite old and IMO needs some refactoring 
:-))
[unknown: 5]
2-Apr-2005
[529x2]
I was thinking that another good feature to add for makedoc is a 
javascript popup link
Maybe incorporate tag symbols in the text for the parsing
Normand
5-Apr-2005
[531]
Did some one found a way to have a FAST Rebol editor.  I did remarked 
that the cursor is slowing to a crall on big texts in MDP-Gui.  It 
is also quite slow with VT-editor or ion-pe, or even with this very 
small editor in alt-me, the one with which I write now.  Tcl, for 
example, does have two tk texts widgets (text and C-text) to properly 
handle text.  Could there be a way to have a fast editor in Rebol, 
something that could handle a text of 100-200 pages in a manner that 
is as fluid as something like notepad.  I am a newbee and find MDP-Gui 
to be a nice course on how to play with text rendering.  Although 
I would rather have only one window, and alternate from the editing 
window to its rendered view.  Full window is nicer to write text. 
 Side by side is nicer to compare marked-up text to its rendering, 
but after a while, we know the rendering and simply want the fuss 
a a nicely rendered text.  I am fidling with this idea, but do stumble 
on the editor part.  I dont even know who is the culprit, area or 
the ctx-edit.  If someone has a simple solution to this, he should 
post it.
shadwolf
5-Apr-2005
[532x6]
Normand thank you for your concern about MDP-GUI. AS MDP-GUI main 
author I can say that the one vindow rendering is one of my futur 
goals. By default Area are absolutly unable to handle ritch text 
..  Carl Sassenrath plans to add a new VID widget to do so called 
TDM... (But The double formating maybe very slow). MDP redering format 
pull us to have en extensive use of VID widgets capabilities I'm 
not sure even with TMD we could reach the same level of beauty. I'm 
making some research too on my side to  found a pretty way to transform 
redered widget to editable ones keeping there settings... But so 
far I wasn't able to produce a relevent soution in this issue :)
One pist could be to systimatically clone itch widget having them 
in two ways the first one would be a redered form based on face the 
other one would be based on field and will have stricly the same 
setting than it twin  If the rendered widget recive a mouse down 
even then we substituate the redered widget base on face by it's 
clone base on field  once this last receive a key  enter  event type 
we affect the clone content to the redered widget .... But with this 
system pref will be verry slow !!! and memory consumsion will be 
twice important ...
My actual effort in dev leads me to rebGUI project so MDP-GUI is 
in pause until rebGUI reatch stability then I would make a brand 
new version of MDP-GUI including the RebGUI look&feel. Once all this 
work will be done I could switch back to "One render/input window" 
problem :)
But as you say it normand it's not an easy topic so being able to 
solve it will be in my opinion a community effort because we need 
a little more than TDM  (to render tables for example... )
Last thing the pointer is slow on hudge text because of this F***King 
mad system base on caret  to handle the cursor position you store 
the current text that belongs after the cursor Writing and rewriting 
every time into this caret buffer the most part of the document is 
super slow  !!!
that explain why on hudge text the cursor of an area widget is slow 
;)
Normand
5-Apr-2005
[538x3]
If I understand you well, the only way that we will be able to settle 
the two problems of :
1- caret repositioning in a big text and 2- rendering text in the 
same window that we edit
will be to settle it by inverting the problem : edit text in a console 
or an editor, and have the console or editor to parse the text and 
transform it according to the commands it find in it.  I did search 
for that.  The closest library to such goal I found is either scintilla 
for an editor or tkcon, the adaptable tcl console.  But all this 
suppose that we dispose of Rebol source code to put the language 
parser in it, right (like ion.pe)?  So we would have to rely on R# 
(open source) instead of Rebol?  Either way, it does seem that handling 
the problem well is pushing us out of Rebol; not a charming proposition. 
 I am just expressing my frustration of not being able to solve a 
problem that is not existing in other languages.  As a priority, 
I do think that the repositioning of the caret is the show stopper. 
   I could live with NOT rendering in the SAME window as the editing 
window; I consider it a form of cosmetics.  But I can hardly ask 
people to start edit documents in a lame editor that takes seconds 
to go from page 120 to 130.   It would be nice if RT could find a 
solution to that, as it would ease the way to specialised IDE's, 
Ide for Rebol and the many specialised dialects.  By the way, did 
Ammon Johnson finished to wrote his REBOL-based IDE, called RIDE?
sqlab
5-Apr-2005
[541]
Carl offered at least the source code for the Rebol console in his 
Blog about Rebol/Coop http://www.rebol.net/article/0146.html.


As I routinely use Scite based on Scintilla, I think, that this should 
be sufficient regarding the perfomance.
shadwolf
5-Apr-2005
[542]
hum MDP rendering is far away more complex than scite capabilities 
... So we have no other choice than invent a new way to deal with 
this
Allen
5-Apr-2005
[543]
If you want a renderer and text box on the same page, just throw 
a wrapper around http://www.ross-gill.com/make-doc/and have the 
results show in an i-frame. piece of cake