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

World: r3wp

[Ann-Reply] Reply to Announce group

Gregg
17-May-2010
[1902]
Dang, I replied in Announce. For anyone working on AltME, or an AltME-like 
forum, if you have special groups like Announce, or Links, where 
responses should be hidden by default, don't make us go to another 
group to post them.
Maxim
18-May-2010
[1903]
Cyphre, really cool.
Cyphre
18-May-2010
[1904]
Guys, thank you all for positive feedback (either here or in the 
Announce group ;)). There is still lot of work to reach Beta version 
but I hope I planned the next milestones realistically so those interested 
will have something for play relatively soon :)
Oldes
3-Jun-2010
[1905]
Rober: will you publish some examples and or tutorials?
Robert
3-Jun-2010
[1906]
Yes, going to add the stuff to rm-asset.com tomorrow. But it's really 
just a basic demonstrator.
AdrianS
4-Jun-2010
[1907]
Robert, are you using an IDE for working with D or just an editor? 
I've taken a look at D-IDE and it sort of works, but seems kind of 
flaky. Going to check out the VisualD add-on for Visual Studio next. 
Also tried Sublime Text - it's a pretty nice text editor with Python 
scripting and it has partial TM bundle support (snippets, language 
defs for syntax coloring, themes).
Robert
4-Jun-2010
[1908x2]
Just an editor and the CLI.
I don't see that much value by using an IDE. The compiler is pretty 
easy to use.
AdrianS
4-Jun-2010
[1910]
Yeah, most extensions probably wouldn't involve too many files to 
manage and code should be easy to debug by printing to output. I 
never looked at D closely, but it does seem to be a really nice alternative 
to using C/C++.
Robert
4-Jun-2010
[1911]
It is, it makes your life a lot simpler and is worth to get into 
the language.
Maxim
4-Jun-2010
[1912]
this might be what I needed to get me into looking more closely at 
D.

thanks for your efforts Robert.
TomBon
8-Jun-2010
[1913]
great! very cool code ladislav, and extrem usefull to solve the lack 
of handling pointers, nested structs etc. in rebol.

with peekpoke.r we are now able to use a much greater bandwith of 
external libs and a very important improvement 

for rebol in creating commercial apps.  could this be incorporated 
directly/native into R2/3?
Ladislav
8-Jun-2010
[1914x2]
There are two discussions going on related to this subject:

http://www.rebol.net/wiki/DLL_Interface

and

http://www.rebol.net/r3blogs/0317.html
But, as far as I can tell, none of them looks "concrete enough" to 
be useful
TomBon
8-Jun-2010
[1916x2]
cool, just tested with a complex C lib I am fighting a long time, 
handling various pointers
and nested struc arrays. now it works! thx ladislav.
well ladislav, you are a real gentleman and understatement too, the 
'other ones' 

are concepts, peekpoke is here now and ready form use, just that 
simple. 

btw greeg's notice; I second this, peekpoke.r should be named clearer.
Ladislav
9-Jun-2010
[1918]
Name suggestions welcome
TomBon
9-Jun-2010
[1919x2]
lib-handler.r  | struct-handler.r ?
because for a search at rebol.org I would use keywords like: lib 
| struct | pointer etc.
Anton
9-Jun-2010
[1921]
Ladislav, nice code.
AdrianS
9-Jun-2010
[1922]
Max, the dark look, chiseled/scratched steel of moliad.net makes 
me think of a gaming type site - is that what you were going after?
Maxim
9-Jun-2010
[1923x5]
I wanted to try out a different style, using texture and specifically 
going against the white & "pure".


It evolved into this dirty "workshop" style, which I find appropriate 
for a site about tools.
I just realized that it was going towards a gaming look today  :-)
I'm a Warhammer 40k player (tabletop), so I guess there is some subconscious 
inspiration there  ;-D
eventually, the style will be a preference, so its not a permanent 
thing in any case.
the whole page is generated with just this markup. 

<!page-header>
<!main-menu>
<center><img src="/images/under-construction.png"></center>
<!page-footer>
AdrianS
9-Jun-2010
[1928x2]
The beveled steel font seems to not quite fit for me - kind of just 
floats there with no drop shadow or some other integration into the 
background graphics and the lighting isn't consistent with the lighting 
on the background. The background graphics dimpled steel looks to 
be lit from the top right while the steel font seems to be lit more 
from the side (though not all characters seem to be the same - note 
the right vertical on the capital M in moliad).
How do you see styling being done in remarq? How is styling kept 
in sync between the html a designer might create and the html produced 
by the code behind the tags?
Maxim
9-Jun-2010
[1930]
actually, only the "under construction" banner isn't lit in the right 
direction.  the brushed steel is lit from top-right, with some ambient 
light refracting from the bottom left.
AdrianS
9-Jun-2010
[1931x2]
the dimpled steel seems to be lit from 45 deg, while the brushed 
steel looks lower than 45 based on the highlight on the "o" in moliad 
- at least it does to me
anyhow, this is nitpicking if this is not finalized
Maxim
9-Jun-2010
[1933x4]
The styling mechanism is all up to you.  currently, the site is a 
mix of CSS, images and run-time html generation.


As I start adding dynamic content tags, I might start using some 
remark code within the CSS to keep the style programmable.


things like colors, texture-names, could all be resolved from remark. 
 Where and how that information is stored is totally separate from 
the engine.


remark tags are little dialects which are created & parsed dynamically, 
stored as sets, which are called document models.   Using a smart 
caching system and a feature I call "dialect Learning" you can *merge* 
different document models together and leverage code from a variety 
of sources.


In the above the <main-menu!> might generate markup containing remark 
tags which you define before or later, the menu will adapt its style 
for your needs.   so the same menu, will in fact generate different 
html output based on what mix of document models you are using.  
 one might build animated javascript, the other might be only static 
HTML.


the style is much more than just "looks" its actual content, but 
the nice thing is that your source HTML is totally unchanged, and 
there is no "Code" in your pages, only markup.
Remark also doesn't require coding skills for the content side, even 
if its generating dynamic content, making it much more appealing 
for anyone to learn.


the fact that REBOL (or any processing, in fact ) is running on the 
server is totally invisible for the content creator.
thanks for the visual nitpicking.  I hadn't realized that the lighting 
orientation discrepancies where notable for users.  I'll but a little 
more effort in future texture work & revisions.
but=put
AdrianS
9-Jun-2010
[1937]
Are you saying that all text resources served will be processed by 
remarq, including stylesheets?
Maxim
9-Jun-2010
[1938]
for this site probably.  Even some javascript will be generated on-the-fly.
AdrianS
9-Jun-2010
[1939]
I guess what's not clear to me is how is a designer who is including 
some remarq tags into the page going to know the IDs and class attributes 
of the generated HTML so that he can create appropriate CSS for that 
HTML - can he specify the class, ID (or a set depending on the type 
of content) on the remarq element so that these will be used in generation?
Maxim
9-Jun-2010
[1940x2]
it all depends on the remark tags you use (and build).


there is already a tag which outputs <P class="xxxx">content</p> 
 where "xxxx" is the actual label of the remark tag.

so 

<!TITLE This is my title>

outputs 

<P class="TITLE">This is my title</p>
the <!main-menu> tag itself might return: <!TITLE item-1>  as part 
of its markup so that will ultimately use the p.title  CSS class.
AdrianS
9-Jun-2010
[1942x2]
Well, this can work for simple content where the name of the remarq 
tag pretty much matches the output one to one. I was wondering about 
more complex cases, e.g. a table, where all parts of the generated 
content need spearate styles. It might be useful to allow something 
like <!FANCY_TABLE classes="fancyHeaderClass,columnClass,rowClass" 
ids="..."/> or something like that. The exact values for these would 
be based on some well documented definition of the FANCY_TABLE. Another 
possibility would be to provide another tool for parsing the various 
remarq tag implementations and generating or updating (if already 
generated) a CSS file that the designer would then work on and have 
ownership over.
not sure it was clear in the above that I meant that remarq would 
use the passed in set of classes, ids, etc, parse them based on some 
convention, and use them in the generated output
Maxim
10-Jun-2010
[1944]
you can do all that, each tag is its own dialect which you define 
however you wish  :-)
AdrianS
10-Jun-2010
[1945]
sure, but a convention would be useful so that a designer wouldn't 
have to learn a different dialect for every tag - at least not for 
just doing the styling
Maxim
10-Jun-2010
[1946x5]
what I'm saying is that these things will part of document model 
which you either define yourself, or pick and choose from 3rd party.


moliad.net is a test bed for this new remark technology and out of 
it, quite a few document models will be born.  One big feature of 
remark is that rtags use REBOL data, not HTML syntax.  so you can 
structure stuff with the cleaner rebol syntax, ex:


<!table  labels:  [ name birthdate city ]   label-styles:  [inverted-label 
label label ] column-styles: [bold-text text text ] data: <sql! select 
[name date city ] from users-table >>


note here that the <sql! tag is parsed first, so its data will be 
fetched and inserted within the table.
alternatively, for simplicity, one could build a  <!user-list> tag 
which is defined as <sql! select [name date city ] from users-table 
>  and use that simpler tag in the !table definition.
the styles might also be rtags and the sets of tags too.    all is 
parsed as text within the engine, which you can load as data or as 
text within your rtags.
this way all tags can inter-operate even if they are defined in different 
document models.
this means a <!users-table> tag which is defined via <!table>  could 
actually generate different content if the <!user-list> tag from 
various document models are used in different parts of your site 
or one different sites.   


meaning that the same content pages, will ultimately adapt to the 
document models used, and not the other way around, which is how 
we are used to building web pages.
AdrianS
10-Jun-2010
[1951]
Sounds powerful, but how do you see this stuff working in standard 
tools for editing web apps? What you describe above is not valid 
xhtml, for example.