• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp235
r3wp2632
total:2867

results window for this page: [start: 1601 end: 1700]

world-name: r3wp

Group: !CureCode ... web-based bugtracking tool [web-public]
Graham:
5-Feb-2010
Would be better to create a R3 GUI project  now ... or filter them 
off and import them later on?
Henrik:
24-Nov-2010
Doc, you can create an R3 GUI project in Curecode, if you like (or 
can). This way, we don't pollute the REBOL 3 project with GUI bugs.
Henrik:
6-Dec-2010
Any news on having an R3 GUI project under Curecode?
BrianH:
6-Dec-2010
The problem with making a separate project is that it is difficult 
to move tickets from one project to another when they are misfiled. 
The other problem is that some tickets apply to both the core and 
the GUI. I would be OK with creating a separate project if we had 
a way to move tickets. But I would be even more happy with being 
able to filter by category in the detail view, which would allow 
us to effectively do the same thing with a single project.
BrianH:
6-Dec-2010
There are tickets in the REBOL 3 project already that apply to the 
GUI, and others that apply to CureCode. Both would be nice to move.
Dockimbel:
6-Dec-2010
So, I'll add a R3 GUI project as soon as the "move ticket" feature 
will be put online.
Henrik:
26-Jan-2011
any update on adding the R3 GUI as a project to curecode?
Dockimbel:
27-Jan-2011
R3 GUI project added to CureCode, ticket http://issue.cc/r3/1837
moved to R3 GUI.

I've added alpha 110 & 111 to versions list, let me know if you need 
categories too (I would need an ordered list of items for that).
Group: !REBOL3 ... [web-public]
Graham:
19-Jan-2010
We should start creating subgroups ... .. as we have for  R3 GUI 
and R3 Schemes
Claude:
27-Jan-2010
but we need first a good R3 GUI
Gregg:
2-Feb-2010
With the progress Graham, Andreas, and Steeve (and maybe others I've 
missed) have made on schemes, I would like to see their momentum 
and work leveraged. 


The host kit is probably also very important, so others can pursue 
that. Redirection, for writing pipe and filter apps. If the GUI console 
for Windows isn't too hard, that would be great IMO.
Graham:
3-Feb-2010
A GUI table would be nice ...
Graham:
4-Feb-2010
I was going to have a look at the R3 gui sources but they're all 
flattened..  Is there a pretty print for r3?
Henrik:
10-Feb-2010
there are many subtle changes, so I wouldn't expect too many scripts 
run out of the box. GUI scripts won't work at all.
Robert:
14-Feb-2010
As object! is being used more and more now in R3 and (within the 
GUI) a lot of words in objects will only be present if there is a 
value available, we have to cross-check a lot more if specific words 
are present. And this can pollute the code.
Pekr:
23-Feb-2010
Jerry ... we all wish for things to proceed faster. However, we have 
to wait a bit. Hopefully Carl is doing wildly in the HostKit/Extension 
area, so that guys can proceed with other areas, as GUI for example 
...
Graham:
24-Feb-2010
Still tracing ... seems to be doing a lot with nothing happening. 
 I would have thought the whole GUI would be in a wait
Graham:
26-Feb-2010
Carl is still tidying up the GUi documents ... taking much longer 
than was expected
Graham:
28-Feb-2010
I use 'use a lot attached usually to GUI buttons.   Wonder if it's 
worthwhile to have a version like funct that automatically makes 
all set words local so that we don't have to declare them
Pekr:
6-Mar-2010
any comment towards !REBOL3 GUI wait & CPU sleep times topic? :-)
Henrik:
19-Mar-2010
The most "action" seems to be in R3 GUI documentation here: http://www.rebol.com/r3/docs/gui/gui.html
BrianH:
25-Mar-2010
No impact for end programmers because there isn't much written in 
R3 yet outside of the mezzanines. But it would impact the GUI code 
as well, so we should get this done before too much of that is written. 
And people are working on that now (mostly Henrik, but still). This 
is a really time-critical change: Whatever we choose, it should go 
into one of the next two R3 releases.
btiffin:
14-Apr-2010
I could google and poke around, but I'd rather Ask a Friendly Human. 
 Where are we at with GUI and GNU/Linux?  I get a crash;
** Script error: size-text has no value

** Where: font-char-size? make make-text-style parse fontize do do 
either load-gui
** Near: font-char-size? self

Is if worth digging in for?  Fonts?  etc.  Or, is it a don't bother 
yet?
btiffin:
14-Apr-2010
from
>> load-gui
that is
Pekr:
14-Apr-2010
we are not far ... yet ... R3 GUI should be pushed forward by Robert's 
team, but guys are mostly waiting for Carl to turn View into regular 
Extension, and releasing its sources, so that low-level View enhancements 
can be done. As for VID itself, we are still in kind of wait mode 
imo ...
Pekr:
21-Apr-2010
Is there any resolution to this topic? (Console) ... when playing 
with R3, I can't stand that ugly Windows "console" more and more 
:-) We can't even have multiline cut & paste :-(

http://www.rebol.net/r3blogs/0282.html


I don't remember the outcome - will we put R2 console back to Windows 
distro? Or wait for our own GUI based one?
BrianH:
4-May-2010
For that matter, accessors can be written in functional or procedural 
style, often more efficiently too, as they are in R3's GUI.
BrianH:
4-May-2010
So the main thing that the property feature does (from my extensive 
experience using that feature in other languages) is to hide complexity. 
Which is great, until you actually need to know what the heck is 
going on - something that happens almost immediately. At that point, 
hiding the complexity means destroying your ability to understand 
your own code by looking at it, even a simple assignment statement, 
and forcing you into a particular model of operation that may or 
may not be appropriate. So it's great for Delphi, which comes with 
a built-in GUI framework and is supposed to be easy for VB-level 
programmers to use; it's not so good for REBOL, where the GUI is 
swappable and our users are in some cases some of the smartest people 
I've ever met.
Steeve:
4-May-2010
I used that technic in an GUI trial for R3, the syntax was pretty 
 light.
Maxim:
4-May-2010
and glass even uses the liquid (trans)mutation feature where you 
swap classes on the fly based on oranisation of GUI
BrianH:
4-May-2010
(Sorry, phone calls) Processed fields are great, and accessors are 
a great, but there are at least 3 different ways of doing accessors 
(method, procedural, functional) and syntax support would only support 
the method-style accessors. And because of REBOL's object model, 
method-style accessors have a lot of memory overhead, whether they 
are supported by syntax or not. This is why R3's GUI uses procedural/functional 
accessors.
Steeve:
5-May-2010
but there is a memory overhead, so take it with care... (actually 
it's not suited for intensive computings inside a GUI,, just my opinion)
>> same? d/pane d/pane
== false
Maxim:
5-May-2010
the hostkit extraction is a pretty huge endeavour, because he has 
to change the core model and open it up much more.


the GUI pokes at just about every level into the core things like 
actions (callbacks into the core), devices, object access, these 
can't be side-stepped IMHO.


yes the A98 (or whichever release fully extracts view from the core 
as an extension), will be the mother of all releases.   The only 
REBOL release I have been waiting for... for over a decade.
BrianH:
5-May-2010
For one thing, gobs can't copy their data references even if you 
use COPY/deep, because gobs don't understand what is in those references, 
and because in almost all cases there are reference cycles in the 
GUI between the gob and the object referred to by the data. I can't 
imagine it ever being safe to copy gobs in a real GUI.
BrianH:
5-May-2010
In R3, the GUI objects have a reference to their gobs, for high level 
code, and the same gobs have a reference to their higher-level objects 
in their data field, for low-level code. Both of these references 
are necessary. So im most cases there is a reference cycle in real-world 
code.
Pekr:
6-May-2010
hmm, 395 KB, so GUI-less release. Preparation for View externalisation 
:-)
GiuseppeC:
7-May-2010
It seems that the migration of GUI to the external host is more difficult 
that expected.
shadwolf:
13-May-2010
i was reading doc about moblin now meegoo os and i was stunned to 
learn all their gui where based uppon QT  &and ...
shadwolf:
13-May-2010
why not rebol ,,, serriously if you have to fall that low as using 
javascipt + QT for you gui only to say we do quick qt developpements 
why not using rebol?
Maxim:
13-May-2010
Gab, yes I actually have some secret little links into the batcave 
 ;-)


but I don't have specific details beyond the fact that he is commited 
to the view extraction and that its not a piece of cake.


the rest of my comments really are just by obvious architectural 
analysis and having tried to plug into the core myself and realizing 
how much is still missing to provide an integrated GUI which cooperates 
with the core.   even the event/device/messaging system isn't totally 
usable externally right now.


the command! concept is being rewritten from the ground up so it 
supports some kind of contextualized operation (could this be the 
basis for callbacks into the core?  :-)

and when I mean design changes, Its realy things like: 

   before we could call an action directly within a face... there is 
   no callback procedure in R3 hostkit beyond running a string in the 
   global context.


   there is no object/function support in the extensions, cause that 
   opens up a big can of worms (and some secrets into the interpreter's 
   operation?).


   the current R3 relies on the protection it has living within core, 
   now, Carl will have to open up the core a lot so that he can plug 
   back into it, and yes, since Carl is a perfectionist, he won't allow 
   that openess to be a security risk or half-assed solution.
BrianH:
14-May-2010
Not systematically yet, but yes on an ad-hoc basis for a few years 
now. Even during the GUI design phase before the first 2.100 public 
alpha.
Henrik:
24-May-2010
I don't think you should do that yet. Wait 6-12 months and see what 
tools are around. What RM Asset is developing is mostly backend/tools 
stuff, to make sure that developing boring business apps becomes 
a smooth and quick process and some of these things wouldn't work 
well in R2 or would be hampered by various already known showstoppers. 
We have to think forward and build this stuff under R3 now, otherwise 
we will have two things: A fast and poorly supported platform to 
build apps on (R3) and a slow and limited platform to build apps 
on (R2), and we don't want that, do we? Besides, RM Asset already 
has some target apps in mind for R3.


Also given how R3 uses a hostkit, gives everyone much more control 
over how they want certain things done or add special extensions 
to, say, graphics or database capability without having to ask Carl 
to add it.


I think you will appreciate that this stuff is done first, so you 
can build a good app in a few days, rather than spending 2 months 
doing it. It'll save you a good bit of money too. This involves GUI 
test tools, customer feedback mechanisms built into the GUI, quickly 
integrating a GUI with a database, completing the GUI generally, 
various extensions, such as the high speed networking extensions 
needed for xpeers-II.
Pekr:
24-May-2010
Customer feedback into the GUI? I am really interested to know, what 
is VID turning into :-) Or is functionality as "customer feedback 
mechanism" an addon?  Maybe it would be helpful to have some high-level 
diagram, about GUI components ...
Maxim:
26-May-2010
with view extraction from the coe, he has NO CHOICE in giving us 
a means to execute loaded, bound, code, since all a GUI really does 
is trigger code.
code which is managed by the core.


I also know that vector and image datatypes will definitely be part 
of next extension, its really important.


I am in the process of requesting that the argument frame be increased 
to 15 arguments by default... 7 is ridiculously low, especially if 
you want to use refinements.
Pekr:
2-Jun-2010
... well, that was for a host kit and maybe a GUI ... as for RIF 
and R3/Services - wait 5 years ...
Robert:
1-Jul-2010
IMO it's more critical to use to get a good GUI up & running with 
a broad set of styles.
Robert:
1-Jul-2010
My goal is to get R3 out of alpha, beta to release. To get the GUI 
to a state that you can create apps with it.
Graham:
1-Jul-2010
Well, a GUI a nice, but the working out network details seems a little 
more basic :)
Pekr:
1-Jul-2010
as for apps - GUI, networking, DB drivers ....
Henrik:
2-Jul-2010
Graphics extension loads:

http://rebol.hmkdesign.dk/files/r3/gui/217.png

List of graphics functions:

http://rebol.hmkdesign.dk/files/r3/gui/218.png


There was a small demo to display a random collection of gobs, but 
a bug in the host kit prevents me from taking a screenshot.
Gregg:
2-Jul-2010
IMO it's more critical to use to get a good GUI up & running with 
a broad set of styles.


I agree Robert. Even if the set of styles is not broad, if we have 
a few good examples of how to write styles (and maybe some docs, 
which I am willing to help with), we can turn the community loose.
Gregg:
2-Jul-2010
We should also have a list of styles, and if a core GUI team member 
sketched out rough designs or inheritance/composition thoughts and 
prototypes, we stand a better chance of our work being used.
Graham:
2-Jul-2010
you have to be part of the gui developement team ...
BrianH:
17-Jul-2010
We have the !REBOL3 GUI and !REBOL3 Extensions groups to handle that 
request. It's a work in process. What else?
Graham:
21-Jul-2010
Interesting .. so I can start my gui that way as a task
BrianH:
22-Jul-2010
With Silverlight/Moonlight, you don't need a side interface, it has 
a GUI. That GUI will be accellerated by OpenGL or whatever is available. 
With Mono, you can integrate anything.
BrianH:
22-Jul-2010
Oh, then this conversation is more off-topic in this group than I 
thought. Well, here's what you missed:

- The R3 GUI is being actively developed by commercial developers, 
and it is much faster than the approach you just mentioned.

- We have had a couple releases in the last week, with more to come. 
In other words, we're not stuck.

- The GUI code has been moved to the host, and is thus open source.

- Everyone involved is hard at work, communicating, and busy. This 
includes Carl.
- All of your criticisms of the project are outdated.
Pekr:
31-Jul-2010
GUI, console (not willing to experiment that much with the Windows 
default one), call, protocols (ftp, email, easy-cgi), DB (mysql, 
sqlite)
Graham:
31-Jul-2010
Well, of those, I think I only see 'call and 'gui as blocking ... 
as the others are either usable in some sort of fashion
Robert:
1-Aug-2010
GUI: This will result in a bunch of styles we need.
TomBon:
1-Aug-2010
robert, great to hear about the gui. what kind of styles you are 
planning?
some advanced ones like treeview etc.?
Oldes:
1-Aug-2010
Do you know when is planed the unicode support in gui's textfields?
BrianH:
2-Aug-2010
Having trouble finding it. The function is more than 2 years old, 
and first came about during the first closed GUI development project.
Graham:
12-Aug-2010
he doesn't say what fails though ... whether it was the core or the 
gui
BrianH:
12-Aug-2010
Here's an interesting subject: What value does R3 have as a library 
in another app with its own GUI and networking?
BrianH:
13-Aug-2010
The only platform that I know of that would prohibit native REBOL 
is Win7 (don't know about BB). However, some platforms (especially 
iPhone) won't allow the full REBOL experience including the GUI. 
Most GUI layouts would need rethinking for the small screen anyways, 
and using native tookkits matters much more on phones (memory, consistency), 
so that's not as big a deal. It does mean that we need to pay more 
attention to embedded profiles of the host kit.
Pekr:
13-Aug-2010
but GUI (VID) is exactly our advantage imo, to show the world, how 
easy is it to do basic form apps. There is not much to adhere toGUI 
wise imo. Each app can look totally different, like in old Amiga 
days, no?
BrianH:
13-Aug-2010
The pricniple behind VID - simple dialected GUI layouts - is REBOL's 
strength. The actual implementation would not be as much of a strength 
on a memory-constrained system with a native GUI toolkit and strict 
UI design rules. However, you can make a simple cross-platform layout 
dialect for phone UIs that tells the native toolkit what to do, and 
then make platform-specific implementations for the various native 
toolkits. Dialecting is REBOL's greatest strength.
Maxim:
13-Aug-2010
a lot of VID's dialect can be used to describe the layout even on 
native GUI toolkits.
BrianH:
13-Aug-2010
Exactly! You would need to redo your layout anyways for the small 
screen (unless the layout dialect is *really* properly strict about 
not allowing sizes, offsets and real colors in its layouts, the way 
the R3 GUI is supposed to be), but the layout dialect itself could 
be very compatible and you could reuse a lot of code.
Robert:
16-Aug-2010
WRT to all the discussions in ~Vent / Rebol3 GUI etc. I want to make 
some points clear. And, don't interpret things that are not written 
 as these will be false.
Robert:
16-Aug-2010
3. rebol3 gui: We are working on getting VID to a state that it can 
be used for app development. For this we did a complete new resizing 
system, changed the styles etc. This is not yet ready for release 
because to much flux in the design and code. We will release it either 
in form of the official VID via Carl or as our own VID fork, if Carl 
decides that the official VID should look differently.

No decision taken yet and I hope that we don't need to fork VID.
Henrik:
22-Aug-2010
android: should be possible, as it allows native C libraries, but 
not sure about GUI stuff.
Robert:
23-Aug-2010
Answering to Petr's R3-GUI question, here, as it's not GUI related.
Pekr:
23-Aug-2010
I posted in R3-GUI as I consider it being "your group" :-) Well, 
1-2 month bug-fixing could be usefull, but I know ppl - noone will 
consider R3 ready, unless the basic infrastructure is in-place. And 
not having tasking/IPC is one big handicap - e.g. Doc will surely 
not start the Cheyenne transition (if he will port it at all) ..... 
that's how I feel about it. 'Call needs to be implemented too, or 
R3 stays in isolation for system related scripting. Your aproach 
limits R3 to only GUI realated usage ... if we are rushing to have 
R3 1.0 stamp on it, then priorities, or simply target feature-set 
should be discussed, and set ....
Pekr:
23-Aug-2010
... but - then we are getting into Max's territory of GUI aproach 
... so Max - better release your stuff, before Carl does so :-)
Maxim:
24-Aug-2010
yes... most applications now are multi-threaded if only to make them 
smoother...  the GUI in one thread, heavy lifting in another, for 
example.


async, doesn't allow you to scale, only to time slice.   you can 
still only compute on a single request at a time.

if the request needs time to finish (rendering, for example), it 
effectively blocks all async and I/O handling.
Steeve:
28-Aug-2010
but maybe it will be a real GUI
AdrianS:
10-Sep-2010
Henrik put up a link to his newest build in REBOL3 GUI:
http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3
Ashley:
10-Sep-2010
show and size-text are natives not mezz. Without them you can't build 
a GUI.
AdrianS:
10-Sep-2010
Should I expect something different?:

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
>> source show
show: make command! [[
    {Display or update a graphical object or block of them.}
    gob [gob! none!]
]]
>> source size-text
size-text: make command! [[
    {Returns the size of text rendered by a graphics object.}
    gob [gob!]
]]
>>
AdrianS:
10-Sep-2010
I was trying to make a build with r3-gui.r included, but when running 
the generation step of the build make-host-init.r outputs the error 
"Invalid tuple -- 2.147484e9x2.147484e9" when processing this file. 
Is there something wrong with this tuple?
AdrianS:
10-Sep-2010
the offending line in r3-gui is:
        max-size: 2.147484e9x2.147484e9
Henrik:
10-Sep-2010
skimming... r3-gui.r3 requires A105. anything below will give a size-text 
error.
Claude:
10-Sep-2010
>> demo
Fetching demo...

Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none
This R3 release does not provide a graphics system.
The demo cannot be shown.
>> do http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3
Script: "Untitled" Version: none Date: none
** access error: cannot open: %shape.r reason: none

>> system/version
== 2.100.107.4.2
AdrianS:
10-Sep-2010
I believe that the build that was posted didn't have the draw stuff 
in - on my own build, I get this error when I try the demo after 
loading your r3-gui script:

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
>>
>> demo
Fetching demo...

Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none
Fetching GUI...
GUI Version: 0.2.1
(Developer test GUI theme)
** Script error: expected command! not font

** Where: size-text font-char-size? make make-text-style parse fontize 
do do either load-gui case catch either either applier do try demo
** Near: size-text gob
BrianH:
30-Sep-2010
No, it wouldn't, because there are still a few opt-in modules that 
are included but not imported by default. For instance, modules that 
implement conflicting functionality, such as CGI vs. GUI.
Andreas:
19-Oct-2010
(Besides, I got the impression from the R3 GUI team that they have 
A108 pre-releases with graphics enabled. Might have read a bit too 
much between the lines, though.)
BrianH:
19-Oct-2010
Except the history of the R3 releases since RMA took over the R3-GUI 
project.
Pekr:
20-Oct-2010
Well, it will be possible, once R3 is not going to be a GUI app.
Pekr:
20-Oct-2010
Andreas - power console can't work. I tried Console2. The outcome 
is, you can't have both the true console mode and the GUI app. Look 
at the above link. Or simply Carl was not able to achieve that. Some 
ppl said, that is the reason why Python has two executables - one 
for plain console mode, and the other for GUI mode. But I might not 
interpret it correctly ...
Andreas:
20-Oct-2010
RT binaries are built as GUI apps, the above is built as Console 
app.
Pekr:
21-Oct-2010
launch from cmd.exe is fixed. Although I would like to see R3 to 
reuse cmd console, if it does not include GUI ...
ChristianE:
21-Oct-2010
Cyphre, Andreas, that's what I was seeing, too. Build as console 
app --> no unicode chars displayed, build as gui app --> unicode 
chars are fine, but you can't run in a console window. I don't know 
what other languages are doing or if there is a way to fix this at 
all. From the information I gathered back then, I'd say, probably 
there isn't.
Cyphre:
21-Oct-2010
ok, that is in the 'console app' mode....sorry I meant that there 
might be a way how to check if the 'GUI app' is run standalone or 
from console and then decide what approach to use. But I haven't 
tried to play with it yet.
Andreas:
21-Oct-2010
unfortunately there seems to be no way for a GUI app to keep an association 
to the console it was launched from.
Andreas:
26-Oct-2010
(Ah yes, console not GUI build, so that last part is for free :)
Pekr:
26-Oct-2010
ok, what about having console (not GUI) build of R3, and loading 
View extension? Could it work?
Pekr:
26-Oct-2010
yes ... that is why I am confused, because there was a saying, that 
under Windows, you can't have both worlds - console, and GUI app 
in one, and that e.g. even python uses two separate executables ...
Group: DevCon2010 ... this years devcon [web-public]
Pekr:
2-Feb-2010
One day, once we rebollers become rich, we buy some nice piece of 
land ourselves. It will be renamed to Reui ... and new GUI system 
will be called the same name :-)
1601 / 286712345...1516[17] 1819...2526272829