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

World: r3wp

[!REBOL3-OLD1]

Henrik
2-Dec-2008
[8578]
working a bit on date styles.

view [year-calendar 2008]

gives: http://rebol.hmkdesign.dk/files/r3/gui/153.png
Oldes
2-Dec-2008
[8579]
Looks good.. and the sliders from Carl's blog as well.
Henrik
2-Dec-2008
[8580]
http://rebol.hmkdesign.dk/files/r3/gui/007.mov<-- older video of 
slider styles here. same area as shown in the blog.
[unknown: 5]
2-Dec-2008
[8581]
Looks good Henrik.  I don't care much for the  orange.  Maybe a yellow 
would be nicer.  So square-ish - maybe round the corners on the month 
panes.
Henrik
2-Dec-2008
[8582]
Paul, yes, colors are experimental right now and definitely not final. 
rounded corners are a little harder to do.
[unknown: 5]
2-Dec-2008
[8583]
Yeah I figured the round stuff would be more difficult.
Oldes
2-Dec-2008
[8584]
Will it be possible to use bitmaps as in R2? For example extend effect 
was very useful. I really don't think, that we must draw everything.
Henrik
2-Dec-2008
[8585]
I haven't used effects at all yet, but I think it's possible.
CharlesW
2-Dec-2008
[8586]
Should new development initatives that require GUI be done in R2 
or should one wait for R3? What would the porting excercise be like 
if I were to start with R2?
Pekr
2-Dec-2008
[8587x2]
Slider is really nice, but quite honestly - how often, if ever, do 
you use slider in your app to represent data? I would welcome more 
practical styles as tabs, tree-view, list-view (grid)
As for date field, it is imo ugly - the whole skin is starting to 
look like old grey unix, weighting of fonts is overloaded for smaller 
buttons and labels ....
Henrik
2-Dec-2008
[8589x3]
CharlesW, VID and VID3.4 are very different, so it doesn't really 
pay to start out in VID and you can't port anything.
Pekr, a slider is not used to represent data. It is used to adjust 
data. And it's already used in at least two places.
Date field is not complete.
CharlesW
2-Dec-2008
[8592]
The wait is frustrating. I have been so tempted to learn and use 
NewLisp for my projects but love the lispy forthish nature of rebol.
Henrik
2-Dec-2008
[8593]
Understandable.
Pekr
2-Dec-2008
[8594]
I would also say that the 'wait is frustratig. Reading the docbase 
article about 'wait in GUI does not satisfy me. I thought we are 
away from stupidly blocking GUIs.
CharlesW
2-Dec-2008
[8595]
Do you think it would be too risky to develop with the Alpha? How 
different is the core?
Pekr
2-Dec-2008
[8596]
I think that if Carl generally releases alpha to the public, the 
more and more will be done in R3. We might be close the boundary, 
when we should start using R3, even if not complete ...
Henrik
2-Dec-2008
[8597]
CharlesW, there are some differences, like unicode, but go ahead 
and get a good feel for it.
PeterWood
2-Dec-2008
[8598]
The feeling I get from documents such as the Wait_in_Wait page is 
that R3 is still being prototyped.
Graham
2-Dec-2008
[8599x2]
Yes ...
Wait .. wait ... wait ..
Steeve
2-Dec-2008
[8601x4]
me too ;-)
sh
ou
should that not be resolved by usage of different tasks ?
Graham
2-Dec-2008
[8605]
doesn't look like we have multithreading
Steeve
2-Dec-2008
[8606x2]
it"s what i would say, thanks
differents threads
Pekr
2-Dec-2008
[8608]
... separate timers ...
Steeve
2-Dec-2008
[8609x3]
in fact there sou
argh.. what with my keyboard...
Carl is updating the wiki, but who is coding ?
james_nak
3-Dec-2008
[8612]
One of our .net programmers showed me something kinda cool yesterday. 
They were "child" windows of a main window that would align together 
if you brought one within a certain proximity to the other. From 
that point the top bar from either window moves both. Of course it's 
not as cool as having draggable screens like we did in '86 but...
Henrik
3-Dec-2008
[8613]
some mac programs does something similar. I know the technique.
Reichart
3-Dec-2008
[8614]
WinAmp does this, yes?
Henrik
3-Dec-2008
[8615]
yes
Steeve
3-Dec-2008
[8616x2]
just one question about R3:

to convert a 32 bits integer to a binary serie i currently use that 
trick:
>>my-int: 150
>>debase/base skip tail to-hex my-int -8 16

it's quite inelegant and memory consuming (especially the to-hex 
function)
we need a more speed and compact function in R3.
I know another one trick using struct! but it's slow too.

To convert binaries to integers we don"t have such problem, cause 
[to integer! my-binary] works well and is short.
idealy, [to integer! to binary! my-int] should return my-int, it's 
not the case currently
Dockimbel
3-Dec-2008
[8618x2]
You don't need to "skip tail" :
>> debase/base to-hex 123456 16
== #{0001E240}
I agree that R3 should provide a better way to achieve that.
Steeve
3-Dec-2008
[8620]
i need it cause my script works well with R3 alpha and R2 too.
to-hex returns longer strings in R3 than in R2
Dockimbel
3-Dec-2008
[8621x2]
Btw, you can also use a struct! value to convert integer to binary.
At least in R2.
Steeve
3-Dec-2008
[8623x3]
in know the trick with struct!, but my tests show that it's not faster 
than using [debase to-hex]
for info, to convert an integer to a binary with struct! , we do.
>>str: make struct! [int [integer!]] [0]
then
>>str/int: 150
>> third s 
== #{XXXXXXXX}
which is the integer in little endian format
i don't know why but  it seems that it's not faster than the [debase 
to-hex] method
Henrik
4-Dec-2008
[8626]
Observe progress of internal releases here:

http://www.rebol.net/wiki/R3_Releases
Tomc
5-Dec-2008
[8627]
... noses pressed against  window ...