AltME groups: search

I used it only several times - to initialise GUI automatically, and 
to create a primitive gif-anim player ...

I would like to give GUI a try, but to be honest, the current public 
state is good only for reviewing, not for participation on the developement. 
I mean... I really don't want to hack one file which has 256kB. So 
I'm asking again, wouldn't it be better to put it into a real source-code 
system (or in case you have one already, which you probably have 
internaly, to create public mirror of it).

I would like to give GUI a try, but to be honest, the current public 
state is good only for reviewing, not for participation on the developement. 
I mean... I really don't want to hack one file which has 256kB. So 
I'm asking again, wouldn't it be better to put it into a real source-code 
system (or in case you have one already, which you probably have 
internaly, to create public mirror of it).

Also I miss the basic functionality in current GUI. Like chance to 
view a simple GOB. For example one of these: http://www.rebol.com/r3/docs/view/gobs.html

Maybe RMA team could set-up a blog too (re Amiga group post about 
OS 4.1 progress). I know there's probably not much time for that, 
but I do remember some of Henrik's articles, and it was really nice 
to read :-)

The GUI is still changing too much for particular blog articles. 
Around on a daily basis I get updates on 5-10 source files, which 
I don't have time to go through, otherwise I would publicize more 
information.

Henrik, wouldn't it be at least posible to pack the files separatly 
(not to have them all in one file)? It's really unusable for other 
people than you in such a state. Especially when you are modifying 
5-10 files per day.

Oldes, that's possible. I'll try to make a zip archive of the current 
source directory.

I now agree with Jerry that there is a draw problem.

I can't guarantee that it will work. There is a build script missing, 
but the resulting build should be similar to previously released 
builds. We have diverted from the build system to something else 
now, and I can't publish that build scheme.

GUI work log update: ON-CONTENT revision done, debugging the changes. 
One of the changes is a removal of the PANEL/FACES block. Reasons:


- data aren't normalized, since the contents of the panel are listed 
both in panel/gob and in panel/faces

- thus, twice as much memory used, and unnecessary maintenance of 
the panel/faces block is necessary

- the not normalized nature was visible anyway, since the order of 
faces was not guaranteed to be the same

- to get the block when needed, it is possible to use a FACES? function 
returning such a block on demand

or get-content? That would be a good match for container styles? 
....

I assume FACES? will only be used inside styles, so it should be 
a short name.

New 'X-mas' release of R3-GUI is available for download at http://www.rm-asset.com/code/downloads/

top-level changes:

-smarter face update mechanism
-improved dynamic panel content handling
-internal optimizations and more system-friendly redesign
-cleanup of obsolete code parts

some more detailed notes:


- panels can now contain normal, VISIBLE faces, HIDDEN faces (just 
invisible, but taking the same space as the visible faces), IGNORED 
faces (invisible, and not taking any space), FIXED (visible, but 
not resizing with the panel, having a fixed position and size)

- the ON-CONTENT actors for all panels (HGROUP, VGROUP, VPANEL, HPANEL) 
now are as much compatible with series function as practical, taking 
an integer index, high-level function can take a gob or a face to 
specify the position as well

- Data optimization: FACES attribute removed to not need to store 
and maintain the same information twice, risking the conflicts (they 
were already present, order of faces was not identical)


You can also download the latest R3.exe from our site which contains 
LOAD-GUI that directly loads the actual release. This way you are 
always using the latest R3GUI codebase.


We'll be updating the 'old' documentation soon to be up-to-date with 
our current R3GUI version. So interested developers can start using 
it for real or participate on the project.

it could be a good idea to upgrade demo too.

Upgrading would probably mean a rewrite

actually, there is a big bunch of tests in the zipped source code 
that I uploaded a few days ago. those contain some examples for study.

Do you a demo script ?

For example I would prefere FACES-OF instead of FACES? as Anton sugested.. 
in the latest sources is used faces? And there is more such a cases 
which I don't like. I really use the names ended with ? only for 
logic.

http://94.145.78.91/files/r3/gui/r3-gui-src.zip

Updated to latest sources and a build is now inside as well.

Anton, that might be a good idea.

Oldes: there are a number of REBOL functions with a ? that return 
something other than boolean - length? and type? immediately spring 
to mind!

They're also exceptions to the general rule, because the word without 
? is used too much as a variable or another function, as Anton says

Re: "They're also exceptions to the general rule" - the general rule 
*is* to use the question mark for such functions, though. The FACES-OF 
"convention" is not a REBOL convention. In fact, it is more like 
a C convention.

having consistent naming conventions across the board is imo always 
a tough call. Naturally I can understand, why you have selected short 
"faces", and adding question mark ...

Quite a few of the 16 existing "?" non-logic! words fall in the backwards-compatibility 
category (e.g. exists? index? info? length? modified? offset? size? 
type?).

Some of the ? words won't be able to be changed because of backwards 
compatibility (this is a #667 situation, not a #666).

EXISTS? originally returned only logic, didn't it? So its evolution 
into more than just logic should also be considered a backwards compatibility 
legacy situation, I think.

I don't mind '?' being use to indicate a question, but I think the 
"-of" words more accurately reflect what information is being extracted 
FACES?
 - it's like  "huh?" - it's vague, someone's secret language.

(Maximum-of and minimum-of were poorly named; I wanted them changed 
to 'at-maximum(-of)' etc since they return the series at the index.)

Just a warning.
Don't be seduced by the Dark Side of the Force. 

It's what I dislike the most in all actual popular languages. I mean 
, the bad habit to outrageously extend the names of variables and 
method.

The exact meaning of variables and methods is given by the context 
of the use case.
That's why they don't need to be over explicit.
And If you have any doubt, you can use HELP, at least in Rebol.

Agreed, Steeve, I'm OK with giving a +1 to the magic words method.

In human languages, words are almost all polysemous. The true meanings 
of words is given by the context.

Carl was able to expel all the horrors syntactic found in other languages. 
So we can almost read code like a human language.
Do not lose this goal, if you can.

+1 FACES?


What would a logic mean here? That there are faces? Well, it's a 
GUI thing... if than maybe FACE? could be ambigous.

Btw, I vote to keep FACES?.

When i see ? in a word's name, i know it may be a boolean or a calculated 
value (actually a function).
If the context is not clear enough, I invoke HELP.

Actually, I would have choose the name CHILDS. It's more polymorphic, 
and it can apply on faces or gobs.

Ah damn, you exposed my true nature as a Dark Side human resources 
manager.

Returning (with some effort) to serious consideration of your argument; 
I'm in agreement (how could I not), but I would like to point out 
that it's a bit like a slippery slide argument: if I accept to add 
just a few more characters (? -> -of) then I'm on the road to creating 
the API with the most unwieldy extra long function names as found 
in other languages (without the utility of Rebol contexts at their 
disposal).

It was just a warning.
The Devil is in the details. 
-of

 could be the devil seed and give birth to abominations, like: get-faces-of-a-face
But I am conforted now ;-)

Just throwing something out here (as I'm not actively involved in 
R3 and mostly lurk):  I see "-of" as a "what" or "what are" type 
of question, while "?" more like "what is" (and all the rest) type 
of question.
(does it) exist?
(what is the) length?
(what is the) size?
(when was it) modified?
vs
(what are the) faces-of
(what are the) values-of

Then of course, minimum-of and maximum-of break this idea:
(what is the) minimum-of
But this works just as well IMO:
(what is the) minimum?


So looking at that, I'd consider the "?" or "-of" question to not 
so much be based on logic values, but whether it returns a single 
value, or a list of values.

What informs about a single value or a list is the use of plural 
in the name.

Not the topic, but this function does a strange control.

In the code, why does it need to check if the contained gobs have 
a consistent data/face/gob ?

In the code, why does it need to check if the contained gobs have 
a consistent data/face/gob ?

 - because we had problems with text-faces, which contain a face-less 
 gob, i.e. a gob for which gob/data is a face, which does not have 
 face/data = gob. This caused a cycle for faceless gobs.

I have two questions about R3 GUI : 
* do you have a demo script ? 

* do you have the same design has shown by Carl in march http://www.rebol.com/r3/docs/gui/guide.html
?

Ladislav, actually I don't see what you said in this function. I 
 only see that a gob and its gob/data/gob must be the same, which 
is rather curious

faces?: funct [
    "Get a block of faces in a panel"
    face [object!]
] [
    face: face/gob
    result: make block! length? face
    repeat i length? face [
        sg: face/:i

        if same? sg sg/data/gob [append result sg/data]  ;   <<<< UH !?
    ]
    result

I  only see that a gob and its gob/data/gob must be the same

 - that is what I thought as well. But, aftter causing crashes, I 
 had to rewrite the FACES? function to make up for the "faceless" 
 gobs, as I mentioned.

Ok but, this function does not resolve the issue, it's not checking 
if the inner gobs have a face.
Or I completly lost you point.

I hope, this will help you:

faceless?: func [
    {find out, whether a gob is faceless}
    gob [gob!]
][not same? gob/data/gob gob]

To my mind a faceless gob may have its gob/data == none!
And even if it has an object , the gob property may not be here.
the faceless? function is not safe

The? problem? with? painting-a? bike-shed? is? that? everyone? thinks? 
he? knows? the? right? colour?

The last one: Gobs with a face have the face assigned to the gob's 
data field, and the gob assigned to the face's gob field. Yes, this 
is circular, but this is because there are two tree roots. FACELESS? 
checks for that circular reference.

I miss the basics... for example it's not easy to display just a 
GOB in current version.

The term "faceless" is pretty accurate. What I'm worried about is 
that it will fail if the gob doesn't have any face assigned to its 
data field. It would be more robust to do this instead:
faceless?: func [
    {find out, whether a gob is faceless}
    gob [gob!]
][not same? gob select gob/data 'gob]

It would be good to have somethink like GUI/base which could be used 
to make micro guis - as a platform for own guis.

The 'data field only refers to a face object in this GUI. It doesn't 
have to refer to a face, or even an object at all. It really is a 
generic data field.

What I'm worried about is that it will fail if the gob doesn't have 
any face assigned to its data field.

 - surely, Steeve and Brian, it has to be done, if such a situation 
 is expectable. Is it?

Throw in enough conditions and it becomes faster to just use an ASSERT/type 
[gob/data/gob object!]. Or just use a get-path :gob/data/gob and 
just accept that errors will be triggered if the function is applied 
to inappropriate gobs.

I don't want to begin a flamewar, but troubles are poping continously 
out of my mind. 

And I wondering, Wy did they choose to use a face (an objet) as the 
entry point of most of their low level graphic functions instead 
of a gob! (which is more convenient to my minf).

I can not take away the feeling that the faces?  function should 
just be a shortcut for gob/pane.

Maybe I should not expose my impression after having eaten and drunk 
in a good restaurant :-)

Most of what makes a face a face is not in the gob; the gob is just 
appearance.

I have nothing to say against it, but was that a controversy ?

Gobs were introduced so we had something lightweight and low-level 
to implement appearance, without all of the overhead of a full face. 
That is why a face can have many subgobs without necessarily having 
any subfaces.

yeah I see them like that too. But when a gob need to deal with events, 
it has to be connected with a face.

Right, because a face has (among other things) behavior, while a 
gob only has appearance and the pane.

Put the path last in the function, or use a get-path, and there won't 
be any code injection possibilities.

code injection possibilities

 - aha, you think that it might be dangerous if somebody intentionally 
 defined an "unexpected" kind of gob to somehow use that against a 
 security measure?

It would be hard to do a code injection with this code, since SAME? 
takes two arguments so you can't easily inject with a function that 
takes an argument, without causing an error in the call to SAME?. 
The only other way to inject code would need debug permissions. So 
it's not a big deal here.

Another thing to be concerned with is leaking bindings, but that's 
not a problem here (function context).

hehe, what is that? :-)

>> do-events
A mystery GUI event?

that happens when no event handler is found, which a bare GOB would 
not have:

; Obtain face or handler object, do event handling:
		either all [
			obj: event/window/data
			obj: select obj 'handler
		][
			;print ["Do-event" event/type "for:" obj/name]
			event: obj/do-event event
		][
			print "A mystery GUI event?"
			halt
		]

View is scheduled for a rewrite. It doesn't fulfill many other requirements, 
so this is going to change.

DideC, try a tuple for the pen.

What I want to do is to make a box with an Image as borer pen. Not 
able to do it with R2 nor R3 (see 'View group).

Henrik: I get crashes of R3 when doing following:

>> do %r3-gui.r3

>> do %panels-21.r3 ; close a window, and do the same example again 
- it takes 2-3 runs to crash the R3

That is a problem that Ladislav, Cyphre and Bolek are attempting 
to clarify and fix right now.

Is that a resizing bug? I tried to lower the Y size of panels-21.r3 
test window, and got following:

http://xidys.com/rebol/resizing-bug.jpg

Why some buttons got thinner?

Ok, I see now what it means. That looks like correct behavior to 
me, as you are in the child VPANELs adjusting the vertical min/max 
size of the button. The demo inadvertently uses both child VPANELs 
to define the maximum vertical sizes of the parent VPANEL cells. 
This overlaps the resizing behavior of the child VPANELs, so I can't 
tell from this test, what is causing the buttons to be squashed. 
A child HPANEL that takes up the entire vertical size of the parent 
VPANEL should display identical behavior to a child VPANEL.

On a side-note: Faces like buttons should not have any flexibility 
in the vertical size. That makes the UI less consistent to look at. 
The smaller the elements are in a direction, the less you want them 
to resize. A horizontal SPLITTER face or a horizontal BAR does not 
resize in its vertical direction.

Sorry, I mistook the third panel for a VPANEL, but that just simplifies 
the explanation that this is not a bug:


1. The button can vertically resize, as its min/max size is not the 
same. This is correct behavior according to the specs of the style. 
This is not the same as saying that this is esthetically sensible 
behavior in the button style.

2. The panel in which the buttons reside can also resize vertically, 
because the button can resize vertically. This is correct behavior.

3. The parent VPANEL, when resized vertically, can resize its inner 
faces to their limits, like an accordion. The limits are defined 
by min/max size. The second and the third panel, which both display 
squashed buttons do this, because their vertical size define the 
vertical size of the two cells of the parent VPANEL. This is correct 
behavior.


To get rid of the problem the button should have vertical min/max 
size being the same. That's all.

A simpler way to show exactly the same behavior is:

view [vpanel 2 [hpanel [button "1" button "2" button "3"]]]

btw: +1 for not allowing buttons being vertically resized as a default 
:-)

possibly a bug, but I don't know. in the code, I can see that HGROUP 
does not use the BREAK-AFTER integer for anything.

why is it so? I thought that RETRUN might be here to actually force 
the wrap, but not a requirement, when integer specifying the wrapping 
column/row is specified as part of vgroup/hgroup specification? OK, 
I'll wait for docs to see the explanation ....

the integer is accepted as an option for VGROUP/HGROUP. perhaps that 
is a bug.

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

First of all you should provide a doc how to stylize basic gui items 
like button, slider, etc.

Btw... the main problem I see is, that current R3 is not able load 
PNG24 image. If I would like to do own GUI, and or game in Rebol, 
I would like to use semitransparent images. (I know that there is 
a lot of people who don't like bitmaps, but I see bitmap usage useful). 
I can load any image to Rebol using ImageMagick, but that is not 
a way we want to go... IM is too large to be used as common Rebol 
way how to deal with basic images.

Good thing on embracing a superwindows concept. I've wanted that 
for many years

Just be careful to make it as simple as possible, because it's already 
a complex concept in itself

Kaj, yes that is correct. My own idea is to simply have behavioral 
variants of ordinary windows with slightly different keyboard navigation. 
With any luck, it can also be usable as a generic window manager 
for a general desktop. Each style can present its own layout mechanism, 
and I expect that the window management style simply provides that.

I know... I just do what I can.. to point out that we are missing 
something, what I consider as a basic functionality.. http://issue.cc/r3/1812

We will provide a developer guide for styles to get you started and 
some styles are included in the current release as well.

Henrik, could you start a page on DocBase with you plan for R3GUI. 
It will soon be lost if it remain on AltME.

Plan: The plan at first is to prioritize what styles mentioned above 
should be written first. It's not a complex roadmap.


Docs: will have to update the status on those, but some are available 
in the r3-gui-src.zip file.

The host kit should be synced at reasonably stable checkpoints. That 
way the GUI people are free to experiment, and people who are working 
on hosts that don't need a GUI or are using a different one can have 
a base that doesn't change as often and is a little more reliable.

We release a binary R3 with our stuff so that you all can use the 
RMA R3-GUI.

No need to have "releases" or any of that, just putting up the source 
or a link to a repository would be fine.

It makes sense... because I could save some time if I could work 
with your version or to be able make a diff between Carl's and yours.

And for a couple months or so before then he didn't touch the host 
kit or GUI. That is what "focusing on core development" means.

BrianH: there is no need to "defend" Carl here. I don't need to speak 
in a way for anyone to feel comfort on not to feel comfort. Let's 
follow facts - no matter what HostKit allows us, there is still the 
need for Carl being involved. Oldes is right - repos should be merged, 
period, or it still feels like we are somehow blocked. Yes, RMA or 
anyone else can experiment at will, and this is cool about the HostKit 
indeed, but as you can see, some developers might get reluctant to 
waste their time, if repos are not merged for a long period of time 
....

Not defending. We gotta do what we gotta do. I was there for a lot 
of the core development phase and involved with most of it, and it 
had almost nothing to do with the GUI or host kit. It was a major 
change that required a huge amount of work by Carl and me, probably 
the most extensive core change in the entire R3 project so far. We 
were glad that the GUI and host kit were being worked on separately 
so we could focus on this.

Actually, yes. The Unicode changes had a lot of scope, but were still 
pretty shallow. The system structure was still the same. A107 was 
in many ways pretty similar to R2. We had planned for the A108 changes 
for two years, and a lot of the existing R3 code was written with 
that in mind, but to actually do it was a big deal. Plus, I've had 
to rewrite the module system from the ground up 3 times now, one 
of which took me 2 months and was never released publically.