• 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: 2301 end: 2400]

world-name: r3wp

Group: !REBOL3 Extensions ... REBOL 3 Extensions discussions [web-public]
Pekr:
26-Aug-2009
What I would like to look into is the possibility of speed-up of 
GUI refresh. Not 3D based GUI, just a refresh/rendering/blitting 
- whatever is possible. Cyphre told me, he has general DLL, which 
allows to accelerate even R2 faces ...
Maxim:
26-Aug-2009
but my OpenGL extension is not to replace view.  Its for gaming, 
and a totally new GUI experience...
Geomol:
26-Aug-2009
I've got impression, that OGL is slowly dying, and feature lacking, 
in comparison to DirectX?


I don't see that. All *NIXs use OpenGL. OS X GUI is based on OpenGL. 
Playstation 3 use OpenGL (PS1 and PS2 used a proprietary Sony API).

From http://www.opengl.org/

The Khronos(TM) Group, today announced OpenGL(R) 3.2, the third major 
update in twelve months to the most widely adopted 2D and 3D graphics 
API (application programming interface) for personal computers and 
workstations.

It seems, OpenGL is growing.
Maxim:
26-Aug-2009
in any case, when you build a GUI with OGL, you build in such a way 
that everything scales, cause its sooo easy to do... its in fact 
free... like AGG.  so the fact that a GUI isn't exactly pixel perfect 
is secondary... since often you don't even have the same fonts on 
various OSes  ;-)
Oldes:
26-Aug-2009
I prefere GUI to be pixel perfect.
Maxim:
17-Sep-2009
callbacks are also required for any serious windows api programming, 
so many systems use them.  timers, gui, disk, low-level gfx.
Maxim:
18-Sep-2009
yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.
Maxim:
18-Sep-2009
GLASS is a general purpose GUI using advanced dataflow programming 
at its core.  I've got some prototypes of various pieces of GLASS 
using R2 and AGG which work really well, but I've been waiting to 
be able to do HW gfx before Investing time on the real GLASS, which 
integrates the prototypes and new stuff too.
Robert:
29-Nov-2009
That's bad because it's IMO an enabler and promoter for R3. As long 
as the GUI is missing, at least R3 can be used on the server with 
extensions.
Pekr:
31-Jan-2010
Robert - R3 Chat is official SVN for R3 and soon even for R2. I would 
learn to use the Chat. Hopefully once R3 Veiw is available, GUI client 
will emerge ..
Maxim:
17-Jun-2010
a little question... how will the gui be able to call rebol functions?
AdrianS:
12-Jul-2010
there's a GUI front end for cmake too, though I guess one could be 
made for REBOL just as easily - this lets you resolve env var issues 
and other things
Carl:
16-Jul-2010
Well... I find that most coders don't pay close attention to their 
garbage side effects, but in a GUI sysetm, it's wise to do so.
Maxim:
16-Jul-2010
liquid uses state to control processing.  each node is like a mini 
kernel only aware of itself.  by linking stuff together and with 
messaging, all the nodes cooperate.


right now, liquid is able to completely control a complete GUI forking 
of only the refresh of data which actually changes.  but i cannot 
implement some liquid's low-level code within extensions because 
they can't look up the nodes.
Maxim:
16-Jul-2010
there's REBOL3 GUI
Graham:
20-Jul-2010
If I bring up a GUI in Qt or something .. I'll need a way to call 
rebol from the GUI as otherwise I have no way of communicating except 
on exiting the GUi
Maxim:
21-Jul-2010
using OS threads is the only way we can use multiple hardware threads 
in the same application.  otherwise, they will be completely different 
processes, and that makes a BIG difference in memory consumption, 
especially on GUI Oses which open up a lot of libs on startup.
Pavel:
31-Jul-2010
Pekr I think in port event model the only what is neccessary is open 
events to OS events (what possibly is already done, but we don't 
know how to use it), not only GUI events. Than you can use local 
pipes (managed by OS including event signalling). Question is if 
multi machines IPC would go this way. Anyway all this is solved in 
QNX (signalling abstraction local/external). Question if they use 
sockets for this.
Group: !REBOL3 GUI ... [web-public]
GrahamC:
17-Nov-2010
you're loading the wrong gui
GrahamC:
17-Nov-2010
load-gui references Carl's old GUI but you need to manually load 
Henrik's Gui
jocko:
17-Nov-2010
Is it the r3-gui file ? Then the gui doc page should be corrected 
accordingly ...
Henrik:
17-Nov-2010
Now provides a visible frame for keyboard navigation:

http://94.145.78.91/files/r3/gui/248.png
Claude:
18-Nov-2010
henrik, could you tell me if your r3-gui.r3 will works on linux ?
Claude:
18-Nov-2010
do you think carl will choose your gui for R3 standart ?
Henrik:
18-Nov-2010
that's not certain yet as he has not made any evaluation yet, but 
it will be a publicly distributed GUI, so you can at least get to 
use it.
Henrik:
18-Nov-2010
http://94.145.78.91/files/r3/gui/style-browser.r3

I think that works.
ssolie:
18-Nov-2010
Henrik: I have buttons working on the Amiga now using your r3-gui.r3 
script. I'll blog about it soon-ish.
Pekr:
18-Nov-2010
Guys - what is the reason of kind of slow R3 GUI progress? At least 
from external observer point of view? That is not complaint nor is 
it any kind of attack. It is just that I thought that you need R3 
GUI for a commercial project? And from external pov we could see:

- new resizing system
- some new higher-level systems (validation, tabbing/focusing)
- some news about low level tweaks
- Cyphre posting REP about new possible rich-text system
- some endless work on styles


However - from external point of view, and unless it all plugs together, 
Carl's original VID felt more concrete, more complete. Is there any 
estimate when stuff will plug together to form usable system? Simply 
put - maybe if system would be docced, ppl could start working on 
additional styles? Or is it still too early, and non-yet-finished 
subystems could break any such code?
Pekr:
18-Nov-2010
My whole point was, that Carl took some rewrite route back then, 
and in 2-3 months timeframe produced kind of basic, but working GUI, 
which could be demoed by 'demo function of R3, while with R3 GUI, 
we are not there yet. I don't need to be pointed out to such facts, 
that 2 years old GUI apparently does not work with latest R3 builds 
:-)


Also - "you can wait ... or be active on your own ..." is not an 
argument for me. Noone apart from maybe 1-2 guys here want to work 
on yet-another GUI project. The whole thing is about me (and maybe 
others) not seeing a "big picture" - things plugging-in together 
into useable form timeframe. I know that giving any terms is very 
tricky, but my point was not to get exact nor even estimated date 
- just some rough ideas about what's still left to be done ....
Henrik:
18-Nov-2010
What's left (not necessarily in order):

- test framework for GUI
- dialogs
- form validation, which meshes with dialogs
- help system, which meshes with form validation
- database record management, which meshes with form validation
- actor documentation parsing

- better View function that supports initial states for forms and 
dialogs
- some issues with resizing
- work on text editor core
- general style work
- skin comes last


Of course over time we get new ideas or stumble into design issues 
that need to be solved, before we can move on. That's necessary to 
make sure that some future feature is going to be simple to do.


All this is of course separate from hostkit, font rendering, and 
DRAW enhancements.
Henrik:
18-Nov-2010
Anyway: Just start using the GUI now. The style browser is built, 
I have a build system test GUI also and both work fine, so what we 
need is input on things that are silly or missing in the GUI now.
Ladislav:
19-Nov-2010
Pekr, what is the reason you don't help either by:

* wring tests for Parse
* writing test for Mold

* writing tests for CureCode tickets that don't have tests in the 
core-tests suite yet
* writing some GUI styles

* responding to user polls, letting us know what your preferences 
are

* reading the documentation and/or new proposals pointing out at 
the problems you are having with them
* doing other useful work to help R3?


That is not complaint nor is it any kind of attack. It is just that 
I thought you needed R3? And, from my point of view there is no obstacle 
you could not do any of the above? However, you have still a lot 
of stuff you can pick and help to make R3 better. Do you still not 
feel like wanting to do something? Simply put, there is enough oportunities 
for you to pick from, and the quantity is getting bigger over time. 
Or, is it still too early, and any effort from you can be expected 
only when none will be needed?
Henrik:
19-Nov-2010
I would probably agree, if I didn't have other experience with the 
VID Extension Kit. The trick is to make the focusing mechanism flexible 
enough to handle all situations. We are not building a GUI that handles 
specialized situations. We are building a GUI for large business 
applications with dozens of windows, hundreds of widgets and tons 
of forms. We absolutely do not want to have something like focusing 
being a special case per style as other than a special option.
Oldes:
19-Nov-2010
I'm far from the GUI project, but I guess that the best would be 
centralized default focusing with possible per style extensions (using 
style's own focusing if required). Style should provide some required 
info of course.
Oldes:
19-Nov-2010
My opinion above is for special focusing-- like using tab to cycle 
thru gui items (like buttons).
ssolie:
19-Nov-2010
Are there any GUI tests available that will demonstrate all the various 
GUI features available in R3?


I'd like to know how complete my GUI port is for Amiga so I was hoping 
there was some benchmark to work towards. I imagine all the platforms 
will need such a test in the future to guarantee a certain level 
of basic functionality across all platforms.
Rebolek:
19-Nov-2010
There's style browser that's for testing styles, but you probably 
wait when Henrik builds new version of r3 gui.
Henrik:
19-Nov-2010
http://94.145.78.91/files/r3/gui/style-browser.r3
http://94.145.78.91/files/r3/gui/r3-gui.r3

Both style browser and GUI updated.
ssolie:
20-Nov-2010
Just tried to run the style-browser.r3 on Amiga and hit the following 
problem
>> do %r3-gui.r3

Script: "Untitled" Version: none Date: none

>> do %style-browser.r3

 Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1179 
 2010-11-19 18:11:46Z Rebolek $ Date: none
** Script error: cannot 
 MAKE/TO image! from: make gob! [offset: 0x0 size: 400x300 alpha: 
 0 draw: [clip 0x0 400x300 anti-alias false pen false fill-pen 192.192.192 
 box 1x1 399x299 0 fill-pen false pen 64.64.64 line-cap square line-width 
 1.0 variable line [0x0.5 399x0.5] line-cap square line-width 1.0 
 variable line [0.5x0 0.5x299] line-cap square line-width 1.0 variable 
 line [0x299.5 399x299.5] line-cap square line-width 1.0 variable 
 line [399.5x0 399.5x299] clip 6x6 394x294 translate 6x6 line-width 
 1.0 variable pen 255.255.255 fill-pen false anti-alias true clip 
 0x0 0x0 pen false line-width 0.0 variable grad-pen linear normal 
 1x1 0x2...

Any ideas?
Pekr:
21-Nov-2010
to the focus discussion. I don't know why, but I agree with Rebolek 
this time :-) I know that I am fan of concepts, and subsystems. IIRC 
VID2 used something like abstracted feel storage. Maybe it was initially 
a good idea, but how often were 'feel objects actually reused? This 
was imo an example of a concept, which did not live to its expectations.


I know that R3 GUI is abstracted in better way. But I also feel, 
that we more clearly kind of encapsulated styles - they have all 
those on-* actors, which let the style to react to various events 
in its own way.

So - stating above - are we really sure that:


1) having abstracted all-styles-related visual representation of 
focusing brings us an advantage? One advantage might be, that if 
it is not central, lazy style coder might not implement visual focus 
representation, and then half of styles might miss it, or we might 
face some weird situations, when the style author implements the 
visual focus representation a different visual way.


2) are we sure that one central system will work for e.g. for some 
complex styles, where some special tricks might be needed to display 
focus visual representation correctly?
Henrik:
21-Nov-2010
Whenever you are creating a concept in a GUI, such as keyboard navigation 
and focusing, you immediately want to centralize it with the option 
of per-style overrides. This is the illusion of control in that you 
want to meddle, when in fact, you are moving toward a lack of control 
a lack of unification and opening up all sorts of opportunities for 
bugs.


It is *much harder* to develop large applications, when concepts 
are not centralized, in the same way if you don't have a single mechanism 
for help bubbles, for determining which button is default, have a 
single, unified resizing system (hello, RebGUI), have a standard 
method for exiting windows, have a standard method for creating and 
displaying any number of dialogs (hello, VID), have a standard method 
for validating forms, have a standard method for reading and writing 
face properties (hello again, RebGUI).


With all these things properly in place, GUI development is reduced 
from weeks to hours.


Of course the other method of thinking may prevail, if you have never 
coded a large GUI before, and therefore don't consider the testing 
process, which can take *weeks* and *costs money*, because you have 
to test every single implementation (N number of implementations) 
of the concept that would otherwise be done in a central system (1 
implementation). It's really the testing that constantly is underestimated.


One can only determine that something cannot be centralized if it 
will create too much code, compared to a per-style solution, but 
it will in general always cause the GUI developer to create functioning 
and *bug free* layouts with much less work.


In that same thinking, R2 View centralizes the generation of a face 
image gradient, background, text display and edge appearance. It's 
not flexible, but it makes it darned simple to skin and generally 
does not have bugs.


And you FEEL object question: Yes, they are reused a lot, otherwise 
VID would probably be 100 kb bigger.
Pekr:
21-Nov-2010
what about new gui not working with A107? Is there A110 exe somewhere? 
I was able to get it built using Carl's git, but I somehow can't 
sync it now ....
Henrik:
21-Nov-2010
A110:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll
Pekr:
21-Nov-2010
a small glitch with style browser - I do mouse over of preview tab, 
it crashes. In console I do unview none, but consecutive start of 
style browser fails. Ditto when I try to re-do r3-gui.r3
Pekr:
21-Nov-2010
Also - I noticed that with field button, arrow down-up moves to the 
first/last position - it does not work like this in Windows. What 
it does (in opposition to current R3 GUI) is it hilights the whole 
text ...
Kai:
21-Nov-2010
Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui:
Kai:
21-Nov-2010
Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui:
Kai:
21-Nov-2010
Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui:
Kai:
21-Nov-2010
Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui:
Kai:
21-Nov-2010
Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui:
Kai:
21-Nov-2010
Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui:
Kai:
21-Nov-2010
GUI version 0.2.1 snip ...size-text has no value ... snip
Andreas:
21-Nov-2010
load-gui references Carl's old GUI but you need to manually load 
Henrik's Gui
Andreas:
21-Nov-2010
download http://94.145.78.91/files/r3/gui/r3-gui.r3
do %r3-gui.r3
Kai:
22-Nov-2010
>> do %/c/r3/gui/r3-gui.r3
Script: "Untitled" Version: none Date: none
** access error: cannot open: shape reason: "module not found"
Andreas:
22-Nov-2010
You'll need a "/View" build of A110, such as:
http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll
Henrik:
23-Nov-2010
ssolie, since it tests styles, the app should be complete, but may 
occasionally encounter styles that are unfinished. the program should 
be used, every time r3-gui.r3 is updated.
Kaj:
23-Nov-2010
Isn't R3 GUI in CureCode?
Henrik:
23-Nov-2010
I think it would be too noisy to have curecode bugs for the GUI just 
yet, but that's up to Carl or Rebolek.
Oldes:
23-Nov-2010
But then the GUI project could be on GIThub as well.
Henrik:
26-Nov-2010
http://94.145.78.91/files/r3/gui/panels.zip

All panel tests.
Henrik:
26-Nov-2010
http://94.145.78.91/files/r3/gui/r3-gui.r3


PANEL and GROUP no longer exist. You need to use HPANEL/VPANEL or 
HGROUP/VGROUP.
Henrik:
26-Nov-2010
http://94.145.78.91/files/r3/gui/style-browser.r3

Style browser is updated as well to reflect this change.
Henrik:
29-Nov-2010
But even under Windows, the different GUI systems may not behave 
identically. I would try things in Control panel and other Windows 
standard dialogs.
GiuseppeC:
2-Dec-2010
We have a big project that needs Android TabletPC and Phones to run 
on.

How difficult would it be to have a an R3 GUI for these touch based 
devices ?
BrianH:
2-Dec-2010
But to break it down, assuming you want R3-only apps, we would need
- A native C compiler for the platform

- A rewritten host for the Android application model to support native-only 
GUI apps (are those possible?)
- An AGG port to the hardware/os
- Some tweaks to the event model to support touch and multi-touch
- Some tweaks to the R3 GUI that deal with the new form factor
- A new set of styles that are designed for touch
BrianH:
2-Dec-2010
Of course that would depend on what native plugins are allowed to 
do on Android. I haven't even heard of a fully native GUI app for 
Android (they might exist but I haven't heard of it), only CLI apps.
BrianH:
2-Dec-2010
They do have a free GUI. It's just that it's written in Java.
BrianH:
2-Dec-2010
Order entry apps seem like the kind of thing that the existing Android 
GUI would be able to do easily.
BrianH:
2-Dec-2010
The R3 GUI will eventually need multitouch support and support for 
modern touch-screen devices (meaning: not treating touch like a mouse). 
That support would be portable to a variety of devices, some of which 
would be running OSes that the R3 GUI already runs on.
BrianH:
2-Dec-2010
Kaj, if you have any links to fully native GUI applications for Android 
that don't use any Java or Dalvik at all, please post them. I have 
been looking for any indications that such things are possible, and 
haven't found any yet. The SDL seems to be linked as an NDK library, 
not as something used to make native apps. All of the native apps 
I've seen are command-line only and not runnable from an icon in 
the applications list. I'll keep looking.
BrianH:
2-Dec-2010
It looks like you might be able to use a combination of the standard 
NDK and a third-party cross-compiler to make fully native GUI apps. 
You would get the libraries from the NDK, including SGL (that's Skia 
Graphics Library, not SDL, it owns the framebuffer). I haven't seen 
anyone try to do this yet but since it may be possible then it might 
have been done already by someone.
Sunanda:
8-Dec-2010
Am I missing something really basic......Here's my first attempt 
in many months to play with the R3 GUI.
New console session, R3-a110.exe:
    >> load-gui
    Fetching GUI...
    GUI Version: 0.2.1
    (Developer test GUI theme)
    ** 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
BrianH:
8-Dec-2010
You need to get a GUI build and download Henrik's compiled R3 GUI 
code. Look above here for the links.
Rebolek:
8-Dec-2010
Please, don't expect LOAD-GUI to work. It loads old Car's GUI that's 
not compatible with A110 anymore.
BrianH:
8-Dec-2010
http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll
http://94.145.78.91/files/r3/gui/r3-gui.r3
Sunanda:
8-Dec-2010
Thanks.....I was trying to follow the step-by-step example:
    http://www.rebol.com/r3/docs/gui/guide.html#section-3
BrianH:
8-Dec-2010
The recent R3 builds have focused on core changes. The GUI has been 
developed separately.
Henrik:
8-Dec-2010
http://94.145.78.91/files/r3/gui/style-browser.r3

is perhaps useful too.
Andreas:
8-Dec-2010
We should probably just get rid of LOAD-GUI, for the time being.
Andreas:
8-Dec-2010
Or adapt it to load r3-gui snapshots from somewhere instead.
Oldes:
8-Dec-2010
The load-gui issue is there too often.. we should remove/replace 
it ASAP
GrahamC:
8-Dec-2010
load-gui: func [ ][ alert "See faq" ]
jocko:
9-Dec-2010
I also see as a priority to fix the status of gui :

- declare publicly if r3-gui is the official gui development or not
- then fix the load-gui call function
- and finally update the gui official documentation page.

It should not be too difficult, and, to my opinion, it it really 
important and urgent, because it prevents to develop experimental 
visual applications.

Could the gui development team meet Carl in order to convince him 
to take a decision ?
GrahamC:
9-Dec-2010
the GUI team should be in daily contact with Carl via their scrum 
system
Pekr:
9-Dec-2010
But I am not sure Carl is involved with the GUI team decisions, to 
go this or that direction. But as Carl has nothing better, I just 
hope he will integrate. But as we know Carl, he might want to revise 
the code first. Let's hope one months black-out period is over soon 
- Carl is not available on any public channel ....
Henrik:
9-Dec-2010
Carl is currently only observing, but I've not seen any comments 
from him on GUI development. But at this time, the number of RM Asset 
programs and tools that requires the R3 GUI is growing, so we are 
not in a position where we can hand things over to Carl and expect 
him to evaluate, rewrite and finish it.
Henrik:
9-Dec-2010
As for docs, I'm not sure when they will be done as some GUI concepts 
are not finished, but perhaps after beginning to write the first 
apps.
Pekr:
9-Dec-2010
And I agree, it is a one way ticket. Carl was way too long away from 
the GUI topic. RMA surely is going to use its own gui for its own 
apps. And the official R3 GUI? Who knows, but I bet ppl will prefer 
RMA's work, than having nothing in the end ....
Pekr:
9-Dec-2010
... after all - anyone can have suggestions to R3 GUI, so even general 
R3 community should get what will mot probably fit us all ....
DideC:
9-Dec-2010
load-gui.r must be update to check the Rebol version and print an 
error if it is not compatible.
Oldes:
9-Dec-2010
what was the last version compatible with load-gui?
Group: !REBOL3 Source Control ... How to manage build process [web-public]
Fork:
29-Oct-2010
One of the things I like about Git, and am quite proud of, is the 
data structures are simple and you can reimplement it if you wish. 
It's a well-defined data model. There are Git-related projects like 
GUI tools, for example, with the Eclipse IDE.

   http://www.computerworld.com/s/article/print/9126619/Q_A_Linux_founder_Linus_Torvalds_talks_about_open_source_identity
GrahamC:
29-Oct-2010
Henrik, you could start by putting the R3-GUI into Git!
Cyphre:
29-Oct-2010
I don't know why it was so big..I installed it half year ago, maye 
they fixed that. I guess your link is just some cli version? I want 
gui version.
Oldes:
29-Oct-2010
No, it has gui as well.
Andreas:
29-Oct-2010
gitk and git-gui, yes.
Andreas:
29-Oct-2010
(And yes, even plain msysgit comes with minimal, optional explorer 
integration in the form of "launch a git shell here" and "launch 
git gui here", if I remember correctly.)
Carl:
29-Oct-2010
Quick notes:


I downloaded via the Git link that Oldes posted above. It's ~12MB 
(reasonable.)


Installed fine on XP.  Yes, this is a shell version, which is fine 
with me since I like to use scripts anyway for merges, builds, and 
releases.


I have yet to try git with github. It would be great if someone could 
post the magic command line to checkout  the existing repository 
(anonymous currently),


Regarding GUI version: it would not be difficult for someone to wrap 
a few REBOL calls it to give you a bit more GUI feel. Not perfect 
of course, but something clickable.
Pekr:
30-Oct-2010
I use GUI though ....
2301 / 286712345...2223[24] 2526272829