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

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary


results window for this page: [start: 1 end: 100]

world-name: r4wp

Group: #Red ... Red language group [web-public]
GUI next?
how big is actually enlightenment (the parts you need to use, to 
get a GUI and app done using it)?
Is there going to be a built in graphic GUI like in Rebol/View or 
will Red always depend on external graphical libraries for GUI's?
GUI, nice would be a clean cross plattform ANSI C lib, handling the 
basic window & eventmanagement

and providing access via a simplified meta-api (VID-DSL). this way 
nearly all script languages could 
use this lib as a native GUI generator.
@Graham and others: I should have wrote you earlier about what I 
am currently doing instead of leaving you with no info, sorry for 
that, I was very busy these last weeks, with both real life events 
(good ones ;-)) and a new customer from which I accepted a short-term 
job to help pay the bills. The contributions I've received so far 
*are* helpful and I can't thank enough all the people that made donations! 
But their are not enough to cover all my expenses here, if I could 
get 3-4 times more from donations, that would be perfect, but as 
long as the userbase won't be larger I think that it won't be  possible.

So I've accepted a short contract (til end of june) to build a trading 
bot generator with a visual editor (GUI in View) that emits MQ4 language 
source code for feeding the Metatrader4 application. Of course, I'm 
building it in REBOL (Red not ready yet for that). The plan was to 
work part-time on it and part-time on Red, but these last two weeks 
I had to work almost only on that project. I still have a few days 
of intensive work on it, then I'll switch to part-time.

I have quite a lot of code to commit (the Red compiler), but I'll 
wait to finish first the internal modifications in Red/System (to 
ease the integration with Red) before publishing it.
Hehe :-) For the core language, from user perspective, it will be 
very similar. For the external libs (GUI mainly), Red will provide 
different options. For more detail, you can re-read all the slides 
from the two presentations I've made for Red.
e.g. that native RED GUI would be handy, one day :-)
Certainly! But I must admit that I have hesitated in the beginning 
between HTML5 and VID for the GUI.
wow, looks really nice. I was never good with R gui's so I have no 
idea how you made those custom components
I don't know. Please don't be bogged down by things like gui in Red 
too fast! You first have to make a langauge / a platform that others 
(we) can use and build upon and add libs when we need them. And for 
all the love to VID and like, my oppinion is still that usability 
matters the most and it's hard to beat usability (all the little 
conventions) with non-native GUI-s. Or big delevoloped libraries 
that emaulate them well enough (Qt, GTK, ...)
As for Janko's message - I am not suggesting changing priorirites 
too. GUI can wait imo, we need Red first :-)
In Syllable, I repackage Red and Cheyenne in a package with a Unix-like 
structure, such as a separate subdirectory for the executable, but 
it gets cluttered because they find all their other files related 
to that executable. Actually, that's the way we want it to work for 
Syllable Desktop GUI applications, but for a console program that 
needs to be in the system path, you need the Unix structure with 
separate search paths for separate subdirectories
IN block word is used in the R3 GUI. It does the same context walk 
that Doc says WITH does, but only to retrieve a word.
Petr - for a git GUI you might want to try SmartGit - free for non 
commercial use and, IMO, the best GUI. Also, it's available for all 
platforms. I use this, tortoise and the command-line, depending on 
the context
Is Rebols GUI code (view etc) going to be usable in Red? Or is it 
going to something completely different? A while back I think there 
was talk of an dedicated Red editor (Reditor?). Is this still included 
in the roadmap?
I think that guys had some kind of GUI in mind, or maybe more specifically 
- some GUI targets, as e.g. html5, etc., being native on target devices. 
Myself, I would support and sponsor bit a View plus VID3 transition 
towards the Red, but not sure if someone would pick up. So - in the 
end, some "GUI" might appear ....
... but GUI is not a priority right now I think ....
I'm not sure it's useful to repeat this, because people seem to wipe 
their memory and start over the discussion, but:

- Red's roadmap includes binding to native GUIs. That means there's 
supposed to appear a binding for every platform Red is ported to. 
The intent is to try to create one dialect that would be able to 
drive all these native bindings. This would be a common denominator 

- Some of those GUIs are actually cross-platform, such as GTK and 
Enlightenment. so those can figure as a cross-platform GUI. They 
could offer more functionality than the common denominator dialect 
but still be cross-platform.
I'm not convinced with the native GUI bindings. A lot of framework 
have tried it too and it's a lot of work to bridget the gaps. Or 
if the least common denominator is becoming to small the native look 
& feel won't help since the app feels crippeled anyway: Why don't 
they use widget ABC here?
Porting / binding R3 GUI to Red shouldn't be hard to do. It's a lot 
of work but we would get a simple and fast to use GUI. One of the 
major USPs of Rebol. I don't know any other simple to use interpreter 
that gives you a GUI out of the box. And, in these app days, it's 
no longer so critical to support native look & feel in all aspects.
Robert - it is just that talking to Cyphre, he was eventually interested 
in a "port", which would be more of a new implementation, supporting 
more advanced stuff in the backend (as switching targets, hw acceleration, 
etc.), and doing it in his free time the initial guess was 12 months. 
Such product would be surely cool, but it seems to me, that it could 
be just the second stage. 

In first stage, I would prefer having windowing/events plus AGG ported 
(still fast enough for many things, I don't understand the obsession 
about the speec, well, apart from devices lacking float support, 
here, AGG would be really slow). Such step could be done in 2-3 months 
of work? Then ppl could start port R3 GUI to it ....
That's fine; it would be one of the supported cross-platform GUIs, 
next to Enlightenment and GTK. Of course, you'll have to make sure 
you have the rights to use the R3 GUI
We don't have to be limited in GUI backend options, as long as we 
can use the same dialect (or subset of it) to program them.
About the native GUI option (using only what the OS provides), I'm 
pretty confident that the minimum common should be enough to cover 
most needs for business apps, I will do a prototype for the Red IDE. 
Having a free drawing x-platform canvas, for games and non-native 
GUI would also be needed, SDL seems to be the best backend for that 
AFAIK (that gives us also OpenGL for free).
I guess then that some code from R2/R3 applications will be reusable 
in Red (as Red uses Rebol syntax), but not the GUI code.
R2/R3: probable, for the GUI code, it depends how close our VID version 
will be (R3 VID seems to be a good model that we could push further).
The overhead of the current implementation is about 5-6 times the 
program execution time, so it's very usable. I will publish it today, 
and I hope someone will pick it up to improve it and add features 
(like a GUI front-end for the reports, with sortable columns).
REBOL code profiler released: https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r

Should work with any REBOL app. Documentation, comments and example 
included in file header.

Hope someone will pick it up and improve it (like adding functions 
sub-tree stats and a GUI). This is github, so feel free to fork then 
As for end user visibility, I can imagine one common place to have 
it - Menu/About dialog, credits section. But, what about apps without 
the GUI, right?
So, we can now say that Red/System is more advanced than R3, as it 
can make sophisticated GUI apps on ARM devices. ;-P
Yes, MSDOS uses the 'console sub-system, while Windows target uses 
the 'GUI sub-system.
The difference lies in the PE header, the sub-system required to 
run the app needs to be set to either 'console or 'GUI.
But Windows seems to be quite permissive in recent versions, so a 
GUI app can also be started from DOS console.
Yes, it would be cleaner for the day when we will have real GUI apps 
in Red, in addition to console-only ones.
I suppose GTK and SDL officially need GUI
Brian: as I've explained to Kaj earlier, Windows does make a difference 
between apps built with GUI or built for console- only. If it wasn't 
the case, we would only have the "Windows" target.
So, what is the strategy? I can see various dirs, one named MSDOS, 
but can't see Windows? So what are the targets to distinguish, when 
we build the Windows apps for GUI, or the console?
Doc, I will. The metrics will be numbers of 1. Datatypes 2. Actions 
3. Ops 4. Natives 5. Functions 6. Objects 7. Schemes 8. GUI-Components
Kaj, rebcode! isn't really in R2 anymore either. But the mechanism 
that was used to make rebcode fast in R2 has been implemented in 
R3, and it used by the R3-GUI dialect. Anyone could implement their 
own rebcode if they like, even with improvements. That mechanism 
would be worth supporting in Red.
No gob! Does this mean no GUI or just gui done in different way?
Does this mean no GUI or just gui done in different way?

 See all the presentation slides for Red, a native GUI system will 
 be provided. Also a web server with a new web framework will be part 
 of Red stack, so modern style web apps will be supported.

The GUI will probably be done in different way than R3 underneath, 
maybe a gob!-like datatype will be a good match, but such implementation 
detail is not known until implementation starts. Also, it is possible 
to extract R3 GUI code, wrap it in a shared library and plug it in 
Red (but I won't be the one doing that and maintaining such wrapper).
In the end I think, that having easy to maintain GUI is not necessarily 
related to the backend itself, and that keeps me attracted to Red, 
as I know, that Doc will not tolerate any unnecessary bloated solution 
Pekr: you have a wrong view on what the Red ecosystem is and will 
be. It is probably caused by 15 years of limited options from RT 
and closed-source nature of REBOL products.

In Red ecosystem, like in any most other languages ecosystems, you'll 
be able to choose GUI between different options. Don't give a wrong 
picture of Red by assuming that you will be limited to only one choice.
Doc, what are your current expectations about timing for a Red GUI? 
 Do you want to make it VID-like?  (my vote is for yes).  GUI was 
the "hook" for R2, and I think a GUI as simple to use as VID, even 
if not encompassing as many features, would increase RED's appeal 
VID-like: definitely. Not only because it is a simple and efficient 
way to build GUI, but also because it nicely shows the power of dialecting, 
applied rightly, so it "validates" the whole concept behind REBOL 
and Red. 

I was planning two approaches:

- prototype a VID dialect for cross-platforma native GUI once we 
have the right interfaces between Red and Red/System. (That part 
will include also mobile platforms, if possible, else, they will 
have rely on a mobile-oriented GUI dialect). I will probably start 
to play with it around Christmas, and try to reach an alpha/beta 
in Q2 2013.

- prototype a VID dialect for HTML frontend, having GUI frameworks 
as backend targets (Sensha, jqueryUI,...). The hard part here is 
abstracting the client-side coding, Topaz would be great for that, 
if Gabriele can find time to continue working on it. Else, I will 
need to work on my own Red to JS compilateur.

It would be also nice to have a wrapper over R3/View or a Red/System 
port of it, but it would need contributors to take it in charge. 
There are also more possible GUI options.
The cool stuff to show-off would be - bring your Red on your SD card/USB 
stick, plug-it-in, go to its dir = show "no-instal" option, show 
some GUI dialect, press a button, generate android app, and with 
one command or a dialect, push it to Google play. Then I can send 
you my friends short/long description, how long it took him to get 
his app there, downloading and installing all the JAVA crap and all 
dependencies ...

File and network I/O: should be done for Christmas (maybe alpha state 
for networking). I will provide then HTTP client/server support shortly 
after. Expect more network protocols to come in Q1/Q2 2013. 2D/sound 
will be part of the work on GUI, so will happen later in 2013. Mysql 
support through networking: I will very much like to have that, as 
Postgresql support too. Expect them before summer 2013 (or maybe 
before for MySQL, if I need it for a killer Red demo). ;-)
Now after observing development of several GUI systems, there are 
always some particular things I find wrong with them: They were designed 
with small details in mind rather than the big picture. This means 
that when a developer uses a GUI system, he'll find that some things 
are easy, while others are very hard. For example, none of our GUI 
systems are particularly designer friendly, meaning that building 
a skin requires a programmer with artistic skills. There are not 
many of those around and that's a real problem. Saphirion's R3 GUI 
was derived from Carl's work in a way, where several parts were rewritten, 
because they didn't scale enough for real-world GUIs. The rest of 
the work has been about beefing up the R3 GUI to handle what is needed.

Development often seems to go in isolated sections: Building styles, 
building a layout engine, event handling, skin system, animation 
or whatever, without a properly coherent view on the whole thing. 
We talk about how we have a really nice feature, but that feature 
may not mean much, if it's not functioning in a coherent way with 
the rest.

If I were to restart VID Ext Kit as a new GUI system, I would rewrite 
it top down: Start with an application with the simplest, purest 
GUI description and write the GUI system down from there. I would 
recommend that a GUI system for Red needs to be written like that, 
starting as early as possible and let it grow downwards instead of 
upwards with a real application in mind rather than some neat demos.
In short: Write apps and pretend we have a complete, perfect and 
luxurious GUI system with no work-arounds. Then write that GUI system.
It would be great if the GUI system used a combination of vector 
and bitmap rendering for widgets. Vector drawing could be used for 
initial drawing or when a GUI was re-sized. Thereafter, the widgets 
could cache their bitmap (if so configured). Maybe I'm stating the 
obvious and this is already how things are planned to work.
Henrik:I agree with your way of thinking, that is the kind of pragmatic 
approach I take often too when designing any dialects or even APIs. 
For the Red native GUI system, I will prototype it with the first 
big Red app I plan to write: the Red IDE.
I agree with Henrik 90%. The hard part is picking the target app 
and important elements. A game, or modern app with animation elements 
is a very different target than an "efficiency above all" business 
app. One of my failed attempts with REBOL was to get Carl, for just 
this reason, to identify a target audience. It guides your design. 

In the case of a Red/REBOL GUI, maybe there is no single design or 
dialect. Making small apps simple is hard to match to the needs of 
complex apps. If you're writing database/CRUD apps, wouldn't it be 
great to have a toolset designed just for that? That same toolset 
won't work well for games though.

I think using an IDE as the first target app is a *fantastic* idea. 
It covers a lot of areas, including the possibility of building on 
an extensible app framework (something lighter than Eclipse :-), 
files, documents, workflow, tool integration, customization, and 
many UI elements. And *we*, developers, are the target audience.
Well, as for me, it is easy as that - f*ck off native controls :-) 
What does that really mean today? I have really no intention seeing 
GTK or other crap. Either use your own GUI, or HTML, that's almost 
the only standard, which will prevail anyway. We should ask ourselves 
- how relevant is e.g. the Gnome GUI guide? And who cares in the 
big picture? So - for easy embedded stuff, just give me a small GUI 
system, for bigger picture, give me a  HTML5. I e.g. don't understand, 
why Kaj tries to port something like Enlightenment. I really miss 
the big picture. Who and why should ever use it? For personal purposes, 
or some specific stuff - why not, but that's not imo a strategic 
direction ...
And I even don't agree with Henrik. I really can't see, how your 
top-down aproach might work. You need a solig gfx engine (View), 
general enough, to build up. Carl's GUI was OK. And imo Saphirion 
did a bad mistake - we heard, for so long time, that the look is 
the final step. All those years, and the look is really a crap. Much 
worse, than what Carl brought up, even if I can see many improvements 
in engine itself. Look sells, take it, or leave it, and then - please 
don't even try to do your own GUI. No matter how good it is, if it 
looks like 80'ties Solaris, it will never get accepted ...
I would never want my app to look like GTK, easy as that. Maybe because 
I have zero intention to do Linux native GUI app. Linux, in a big 
picture (desktop), is irrelevant. Alway was. Who claims otherwise, 
lives in separate reality :-) Mobile will prevail classical PC sales 
very soon (if not already). Own GUI, for small niche, might be good. 
But - it has to have attractive design. The situation with Saphirion 
was, that the substantially rewritten Carl's engine. Nice enhancements, 
resizing and other stuff. But I NEVER understood, why the look was 
so totally unattractive. You see, Henrik once again claiming the 
old stuff, which was the basic reason of a failure. Design is a separate 
animal, which was supposed to come later, which could be done by 
anyone, which "just" needs material system which never appeared, 
etc. And result for me (as a sigle person)? Carl's GUI desing attracts 
me by some 60% more, just because of look. Once again - look sells 
In fact, what I think is, that Saphirion was really close to the 
GUI engine, which adressed most of what we wanted to solve by VID2 
to VID3 transition. It was just not polished. And because of that, 
ppl did not find it attractive enough to play with. And that's a 
real pity. Anyone doing native platform GUI will make me to close 
that demo at first sight, easy as that. Doc is in kind of difficult 
situation - as we can see, many former/recent rebollers are still 
interested in View like engine. The same reason why Doc dismissed 
LLVM in Carl's blog post, the same reason many will dismiss attempts 
to link to GTK, Enlightenment, etc - I don't want to use 5+MB crap 
...for easy embedded stuff, just give me a small GUI system, for 
bigger picture, give me a  HTML5

So what do you propose for the GUI, that will allow it to look good? 
i.e., what is your constructive suggestion, rather than criticizing 
all the wrongs of the past.
My suggestion, then, is to make a list of target OSs, prioritize 
the value of a GUI on them, and propose the best GUI solution for 
GTK is the native GUI for Ubuntu. I've told you many times
How many of us would ever need to do a real native Linux app?

We are talking about a cross-platform GUI framework, that means: 
write once, run everywhere. Using native widgets from the OS is an 
option, using custom ones (with non-standard look'n feel like /View) 
is another option. So, you write a Red GUI app on whatever system 
you like and your Linux users will be able to run it.
Feel free to write a custom GUI in Red
It's hard to imagine that the native UI interface would meet with 
criticism from any main stream developers - by definition, it's the 
_native UI.  Doing things that way just takes longer to port.  I 
honestly don't care which way it goes, as long as there's a usable 
GUI system with a _productive syntax_.
That is, if Doc creates your dream GUI system, what is it?
I should have asked the GUI question in private ;)
My understanding is that most people stick to one desktop OS, they 
are not switching OSes whole day (that is just a very small minority 
of computer users). Having close integration with OS can bring many 
advantages over a custom GUI like hardware acceleration or close 
integration with OS/desktop services. There are still cases where 
a custom cross-platform GUI could be good enough, so a View-like 
engine for Red is welcome. I just think that the default GUI option 
should be to provide an OS-integrated user experience.
Group: Announce ... Announcements only - use Ann-reply to chat [web-public]
Saphirion's Host-kit has been updated:
-added PNG encoder
-added Core extension module for generic additional commands
-reworked compile/build process
-fixed security flaw in Encap
-fixed bug caused non-functional networking
-improved console output handling logic
-patched ENCODE to not crash on png
-updated LOAD-GUI with currentspahirion link
-recompiled r3.exe, r3core.exe, r3encap.exe and r3ogl.exe

Update on the web-page will be available on the weekend.
made good progress over the holiday, powered by turkey sandwiches 
from France.

Prep of C source nearly done. See, not just a dump and run. Sure, 
a few problems came up, but I'm not going to hold up the release 
for them. You can decide.

Grabbed latest git source and built it for this dev box (which did 
not support 1.8 version as bin.)

Once released, I've got a number of notes to write up. Like how to 
quickly port R3. Takes about 5 mins if you know what you're doing. 
Got it up on ARM & MIPS Linux.

Also, I have some goals in mind. Android and iphone, that kind of 
thing. Getting graphics and sound back up. GUI and tinyGUI. A micro-R3 
for smallish embedded systems.

There's a lot you can help with. Delegation, right?
Made it to restore the web-project for http://development.saphirion.com

That's where we are going to publish our R3 stuff. Still some work 
to do, but you will find our R3 version there, R3-GUI etc.

I have reworked the whole site. You can download the latest R3 releases 
with graphics engine for windows for now. Further our latest R3-GUI 
release is available too.

The site contains a bounty shop as well, if you want to support / 
donate to some of our efforts. All things we will work on are listed.

Stay tuned, more to come over the next weeks.
Updated our R3 version. Changes:

- no longer links libstdc++ dynamically but statically. You get an 
error that libstdc++-6.dll is missing from your computer.

- changed startup procedure to support correct stdio redirection 
in console mode (used if you start R3 with a command line argument, 
else GUI mode)
Updated: http://development.saphirion.com/downloads/to contain the 
complete R3-GUI ZIP with additional docs, examples etc.
Group: Ann-Reply ... Reply to Announce group [web-public]
GUI looks good ... not sure what to do with it though!
I downloaded fromthis link: http://www.saphirion.com/development/downloads-2/files/heat-map-gui-demo.exe.zip
 and the models/ contains some test data
You need to update your repository from your local command line or 
Well, GUI is also important for my work. Is there an encapper for 
R3 anyway? Or you mean put script & r3.exe in a package and write 
a batch?
where is it? On our R3-GUI doc pages?
Robert, does the android port currently have GUI support?
As said, files and GUI will be next.
Sore the core builds are on rebolsource.net and the gui builds are 
on development.saphiron ....
why don't we just follow Saphirion guys? They concentrate very fine 
rebollers, it is just that as a business entity, they implement, 
what they need most. But - everybody can influence it via donations 
imo, so I did, sent few dollars to R3 droid port, and R3 GUI on droid.
in fact, it is even worse - GUI is done for quite some time, yet 
no new styles/skins appear, so nothing to complain here about - anyone 
of us can contribute. I just somehow don't believe, that yet-another-fork 
will make situation any better ....
In regards to above remark, I e.g. don't understand e.g. Nick requesting 
R2 being released, as R3 GUI is superior to R2, we just somehow magically 
don't start using it, dunno why.
Is it a not a gui-based tool?
Hopefully it would be adaptable to Red later, although Red has a 
bit different GUI priorities.
Pekr, unless this is a huge rehash that you don't want to repeat, 
could you let me know which View engine proposal you're talking about? 
I don't do GUI stuff so it's been a while since I caught up with 
current events. In the !R3-GUI group if that's appropriate.
Group: Rebol School ... REBOL School [web-public]
If this is a Gui app, wny can't you just wait ?
@grahamC: It is a gui app that sends output to seral port, so I don't 
want to block user input while waiting the job to be  done.
Next level !

Any suggestion about creating a dynamic built GUI ? I whish to create 
a GUI from a Block of data, each data is a button and each button 
has an action attached to it.
Could you please point me to some code to analize?
Thanks in advance
Giuseppe, you can experiment by creating your gui code as a block 
and then "do" it. Then view it.
a: [layout [button "hi" [print "hello"]]]
b: do a
view b
odbc drivers for windows can only be used with the rebol/view, the 
gui build, unless you paid for a rebol/command sdk
Recently I switched to R3, as I don't need the gui, just a script 
to do some webpage source code post-processing ....
here is a simple way to get the code for a face within the layout 
function ( I found it the easiest to remember):

view layout [
	text "1"
	my-radio: radio on 
	do [probe my-radio]
	text "2"

the advantage of this system is that you get the actual face with 
any facets setup as they really are in your gui.  this is often the 
easiest way to identify just where and how a specific facet affects 
a face... probe it without your change, and then run it again, with 
your change... comparing both probes in a diff or merge tool.
Group: !Syllable ... Syllable free operating system family [web-public]
I'm starting to get the GUI build to work, and it takes a few hours 
here, but Syllable Desktop can't use the second core on this machine, 
and compiling is roughly half the speed as on Linux, anyway, so that's 
roughly consistent with your timing
No, we never wanted to depend on Qt. And I have it all built now, 
but the GUI doesn't work yet
I have all of Enlightenment working except the widget set. I have 
DirectFB working and am currently building GTK and Qt on top of that. 
I have all of Qt built but nothing GUI works. I have all of GTK working 
except GTK itself, so no GUI there, either, but I'm still working 
on that
I know. But I also expect RED being kind of compatible to RED, syntax 
wise. And I think Robert would not mind, if someone tried to port 
R3 GUI to RED. As you can read on various places, ppl still want 
View, small toolkit, and some are even reluctant to join RED, if 
the clarification of GUI availability is not made ...
I have already provided a GUI for Red. It's fine if R3/View is rewritten 
for it, but I'm not going to do it
What's your GUI for RED? GTK? How big is that? No under 1MB exe, 
no sugar :-)
Group: Web ... Anything related to the WWW [web-public]
Nice, do you use some GUI for the output, kind of VId I suppose ?
REBOL 2 is no use to me because it would never run on Syllable, and 
REBOL 3 still only has a GUI for Windows and Amiga, so it hasn't 
been useful for me to make a VID frontend
1 / 2867[1] 2345...2526272829