AltME groups: search

The button style is called MINI-BUTTON and is derived from BUTTON. 
It's meant to be used in groups and confined spaces. It took about 
5 minutes to write. The font is custom for this application.

BrianH, can you talk about the set [a: b:] issue and what it means 
for us?

Brian: same as there is a conversion between the Linux UTF-8 APIs 
and the internal 16 bit array, there is a conversion between the 
Windows UTF-16 APIs and the internal 16 bit array. In the same way, 
we can eventually support 32 bit arrays and convert those UTF-16 
strings that can fit into it to just 8 bit arrays.

Gabriele, cool, I was just concerned about speed. I suppose calls 
to external APIs are likely to be less frequent than internal manipulations, 
and UCS encoding would make the internal code faster. Either way 
I'm sure that it will be handled :)

The SET [a: b:] issue:


In current REBOL a block argument to SET for the word parameter needs 
to be filled with values of the word! type, not any other word types. 
This is in contrast with just passing a single word value, which 
can be of any word type. The result of this is that values in word 
block argument need to be converted to word! before being passed 
as a parameter.


There is no reason that those words need to be of the word! type, 
particularly since the block isn't evaluated. One interesting thing 
about REBOL is that a word! bound to a context will refer to the 
same value as words of the other word types with the same spelling 
otherwise. This means that if you set a lit-word! to a value, you 
can get the same value from the corresponding word! or get-word!.


Now, the current behavior has some bad consequences as well, usage 
issues. Some word block arguments had to be preprocessed. The big 
problem we ran into was when we wanted to use SET inside of functions 
created with the new FUNCT function (temporary name).


FUNCT collects set-words from the code block and nested blocks and 
adds them to the function's locals. This is cool and works a lot 
better than I thought it would, and all action handlers of the new 
GUI are turned into functions with FUNCT. The problem we ran into 
is that when we had to use block SET to set local variables, those 
local variables would leak into an outer scope, wreaking havoc. If 
you are specifying the function spec directly there is an easy workaround 
for that: Just specify the locals that aren't caught with your own 
/local vars. However, you can't specify the function spec of an action 
handler in the dialect, just the code blocks (security/stability). 
This meant that if you wanted locals to be captured, you had to set 
them to none earlier in the function. How soon do you expect that 
to fail?


An easy solution to this would be to specify the words you want local 
as set-word! values in the literal word block argument to the SET. 
Those set-words would then be caught by FUNCT without any overhead. 
No problem, except for that SET doesn't allow it right now.


This is what we are going to fix in the next build: You will be able 
to do SET [a: b:] value.

In some circumstances like with FUNCT above, you will likely *have 
to* do SET [a: b:] value. This is where we get to the implications, 
what it means for us: We are making changes to the core, sometimes 
subtle changes with big implications. These changes are coming as 
a result of the work on the new GUI. Some of them are bug fixes, 
some of them are new functions or other enhancements, some are fixes 
to design flaws in the language expressed in functions we have already. 
They will affect the code you write even if you aren't doing GUI 
code. Every change like this is going to make R3 a cleaner, easier 
and more powerful language than R2, even with the backports. Something 
to look forward to :)

Pekr, since the words and set-words in the word argument of FOREACH 
get bound locally to the code block, they can't refer to local variables 
in an outer scope even if you wanted them to. So FUNCT has no effect 
on FOREACH.

A bit of status:


- Carl ran into a bug in the AGG C++ code: "draw 10x10 []" in the 
console will crash R3 and it's a tough one, as it might be compiler 
related. Not fixed yet.

- Some of the stuff that BrianH has talked about above is now implemented 
in a new build of R3 as well as some additions to MAP!.

- My ramblings on DRAW has caused me to pause on skinning until I 
can get a clear picture of whether the problems will be fixed. Otherwise 
I'll have to redo a lot of work later on. I experiment with compound 
styles instead as well as some simple color palette tools.

- It was decided that popup graphic elements are to be done in separate 
windows for greatest flexibility. No code done yet though.
- No talk about overlays or drag'n'drop yet.

Henrik:

- what do you mean by "overlays" please?

- what do you mean by pop-ups being done in separate windows? Pop 
up dialogs were always separate windows, no? Or are you talking menus 
for e.g. too?

- hopefully Cyphre gets contracted to do some fixes/enhancements. 
Do you think, that once it happens, community could dig most important 
bugs in draw layer, and ask for fixes?

- It means elements that are floating above the layout at any position.

- Popups are windows, popup menus, bubble help and other graphic 
elements that may extend over the edge of the window.
- I have no idea what can be fixed or if it will be fixed.

Well, that's what comments in the blog and here are for. Please provide 
a list of things you consider important and we can discuss the list 
and get them included, or come up with alternate features that do 
the same thing but better. Don't assume that any features we already 
have will conflict with what you want. Feedback is king here.

Simple answer: I don't think we are currently talking about finalization 
and the color picker was an example, not a feature.


Longer answer: The new GUI is going to be part of the open source 
portion of R3, and open source projects are never really finished 
until they die. So the question here is not "finalized" but "ready 
for a release to the wider developer community". In order to do that 
we need to put together the core design of the infrastructure and 
enough styles to get the new DevBase GUI up and running. Right now 
we are focussing on styles and features that have the most impact 
on the system as a whole, or the most potential to flush out bugs 
in the underlying runtime.


If it all seems low-level, that is because it is. We will have a 
development release before we have most of the styles you mention 
because we will need the help of the developer community to make 
those styles and more. However, don't expect the styles you list 
to be missing - some of them meet the criteria I lested above, like 
helping flush out design flaws or use in DevBase.

This is good to know, and imo Carl should update his blog. For many 
ppl over the years, the real show stopper was missing styles. The 
blog article almost sounds like we would be finished ...

The new GUI is going to be extensible with new styles. No list of 
styles will be sufficient for everyone, so we are enabling and encouraging 
developers to make their own. For instance, I would like some styles 
inspired by the Office 2007 UI: ribbons and contextual toolbars. 
I know whole applications that are less complex to implement than 
those styles, so I would not expect them to be included in the core 
release at first.

Nonetheless, some design decisions and features are getting somewhat 
finalized as part of this process, so you weren't off in that.

amacleod - services are in rebol in general (rebservices, aka LNS), 
and they will be supported by R3 too. But - as for "rebol browser", 
so far I can once again see only business graphics being a target. 
      More casual design should be possible though.

Pekr, I understand Services will be there in R3 but Carl blogged 
about this concept of a button linking to the www...It was a little 
vague and Henrik did try to clear it up buy the new GUI seeems void 
of this..

I thought it was to be tightly intergrated into the gui and a major 
reason for the delay of vid 3.4. I thought it was a bold new step 
in the concept of GUI's but it does not seem to be a part of what 
we have been privy to.

amacleod - I can see no problem with what you describe and with what 
is currently finished. Look - the concept of top level (VID) "reactors" 
is already there, is extensible imo, and that is all that is needed. 
Rebservices are imo underneath, and are going to be called by reactors 
like 'submit for e.g.

What I can't imagine right now is the browser concept. Well, it is 
a layout window, it can be for e.g. a panel. But when you look at 
various web sites, e.g. news portals, you can see that their design 
is more "free form", or casual, dunno how to express it precisely. 
So - what would you need to mimick for e.g. www.OSNews.com ? Define 
few styles, decide upon the columns design (group, panel), prepare 
styles for particular sections/zones (portlets - IBM, web parts - 
Microsoft, iViews - SAP terminology) and fill them with information 
....

What I hate about many websites is that they have very inefficient 
layouts. This is particularly so for forums and certain newssites, 
where perhaps 10 or 20% of the information on the page is relevant 
to you. Now imagine AltME's GUI inside a webpage. It's very efficient.

Pekr, let's say you want to read a blog post on a "rebpage". Would 
you want to download a rebpage, formatted as a webpage from that 
location or would you want to get a custom fullscreen reader that 
downloads only the compressed plaintext as makedoc format, compiles 
it on the fly and displays it?

and updated through services???

The parser for this is 54 lines of code including empty lines and 
comments. The style itself is 20 lines including empty lines and 
comments.

You have a block of strings and words which represents the rich text, 
a caret position, some caret movement handling code, and a style 
that displays rich text. The biggest amount of work sounds to me 
like the code to set/get the caret position as well as movement. 
Manipulating the rich text block itself is trivial.

Then we are not referring to the same thing. All I remember was attempt 
of several ppl to rich-text using R2, and it really was not something 
you would like to use as your editor.

Multiple draw blocks are now supported inside the style and a function 
has been added to help switching between them. This should simplify 
making horizontal and vertical versions of the same style.

You could call it that. Building SCROLLER and SLIDER became way too 
difficult with a single DRAW block.

Henrik - looking at your latest screenshots, are those all inkscape 
based? One thing is imo clear, we need gradients for lines, hence 
your request. I would like to ask about so called "default skin" 
- do you have some concrete artistic idea, or do you aproach it by 
trial and error aproach? What I e.g. like about Carl's Autumn skin 
is gradients for backgrounds. So far I like mild blue (Fedora, Vista) 
tones, and I think that the era of "grey" systems is over ...

Pekr, it's trial and error. There's no guarantee that I won't come 
up with something better later. Right now I'm redesigning text field 
to make it work better in more situations.

The symbols, the rounded triangle and the octagon are inkscape based 
and yes, you can see the scaling errors there, which are not apparent 
in the circle. And that is exactly why I want gradients in lines.

The reason the octagon and triangle are inkscape based are also because 
scaling a rounded corner is very hard to do unless you to it correctly. 
It even took some time to get right in Inkscape.

OK, and for your default skin, which will be included, do you plan 
other than grey background? :-) I know it can be probably easily 
changed, but the thing is, that sometimes buttons or other widgets 
might not work with some background types ....

Are we any closer to "more ppl being involved"? :-) It is few more 
weeks from such statement. Not being impatient, just asking .... 
it seems that there is still major design work being ongoing, and 
now it is dialogs ....

dialogs are nice (although I hate them as a concept :-), but the 
most important for ppl will be lists - tex-list, list, grid, tree-list. 
Those are more complicated style, and highly expected ones (looking 
into blog comments). At least one of those styles should be tried 
to proof the concept. So far the most difficult style which was build 
seems to be scroller (area)?

Minimalized faces and the gob model are partly designed to make iterated 
faces less necessary. We haven't needed them yet.

I have not studied that, and I don't think that part is complete 
yet.

so that we can't mix and edit easly draw blocks wich contain text

most slowdowns are because of excessive redraws, so as we move along, 
those are weeded out and the GUI speeds up.

My sentence is english wise confusing in itself, so :-) hmm, I thought 
that redraws, correct clipping (decision what needs to be drawn and 
what not), is View's job. IIRC we have some helpers in View2, via 
'changes field or so ...

Yes. And it's all turned off right now. :-)

So we have it, and it is turned-off? :-) Why? :-)

Maarten;  Not to purposely pollute the REBOL3 discussion; but isn't 
rule 3, a Rule of Management?  Not something Carl (fortunately for 
us, or many rebols come to think) prescribes to.  Anti bloat being 
part and parcel of our long winter of wait for REBOL/3?

Yes, new VID starts being bloated. It went from 13KB compressed to 
22KB so far, and I start to think of buying new harddrive because 
of it :-)

Maybe Maarten meant it the other way - simply put - first things 
first. If Carl would design it with the whole VID scope (focusing, 
many other styles, adding other subsystems from the very beginning), 
the design could be shifted, and hence bloated?

I don't know why Carl needs to work on a VID3.  Why not just release 
and distribute VID as an addon.

The plan is to get the core concepts and infrastructure done, make 
enough core styles to make sure the infrastructure works and make 
DevBase, and then let the community bloat it with their own styles 
at their option. Modularity means that we don't have to ship a monolith 
anymore.

... as for me, I like View, so I am OK with it. But as I already 
said - imo after the VID, Carl should return to Core, to get it to 
beta releasable state, and upload host source codes to DevBase, as 
promissed. I am for less functionality for 3.0, but beta code. Untill 
that happens, Carl is the only one working on R3 ...

No, not just the underlying View component, low-level system enhancements 
and even mezzanines that can be used for non-graphical development 
- Core changes. The work on the new GUI is generating benefits for 
people who don't need a GUI.

BrianH: but that is "coincidence" or simply side effect of VID development. 
What Doc and others had in mid was "real" Core development - modules, 
plug-ins, tasking/threading, devices, networking, etc. But - let's 
finish VID now, and move to something else ...

Of those you list there, only modules are getting some love as a 
result of the GUI work so far, as the GUI will be modularized. However, 
the new GUI will be used to implement the new DevBase, and that will 
bring us open source code and more people.

I think we're doing pretty well on catching bugs and getting things 
redone and simplified that are too hard to work with. Carl needs 
a lot of convincing in this department, and will ask me if there 
isn't a different way to do the same thing. He needs convincing that 
his code or methods are too hard to work with, but when there is 
a change, it's usually a great one, such as the recent addition of 
multiple draw blocks for the same style.

So I think he will want to interfere, unless it's a component that 
I wrote that works flawlessly, is perhaps 4-5 lines of code and I 
didn't mention any problems in developing it. :-)


We're two people catching bugs a little faster than Carl can fix 
them. When the situation becomes opposite, then probably there will 
be another release or more people added.

This all sounds good. We do some real things, and they define new 
requriements or shape our opinion on other things ....

Henrik - so my words were fulfilled, when I claimed, that you can't 
cover all possible visual states of style by just one draw block 
and its parametrisation via facets :-) This is "frames" model of 
some kind, no? But if I understand it correctly, you do it only when 
you need it, so still not vasting space?

Could you please elaborate a bit, how is 'fly transition effect being 
done? Is there any concept for transitions in general, or is it just 
one effect, which will be possible and is "hardwired"?

Steeve:
http://rebol.hmkdesign.dk/files/r3/gui/101.png

The vertical and horizontal slider are two different draw blocks.

and another too for animations

Yeah I have seen and used that before.  But the default text always 
looked crappy - I always had to resort to using draw.

yes, that's because in R2, you basically have two different rendering 
engines: View for everything VID, and DRAW for special drawings. 
In R3 there is only DRAW.

It is. It's much more flexible and thanks to the much lighter View 
engine in R3, it eats much less memory and is much faster.

Sounds good! Flexible, less memory and faster. It's like x-mas! :-)

Paul - there is more to the View engine. It is sometimes reported 
being 10 or more times being faster. Whole R2 View compositing engine 
was scrapped, and replaced by AGG one. AGG is our main engine now 
...

For me the buttons are too heavy and I don't have a small resolution 
screen at all. But I believe it's easy to change it.

and bold

In any case, I think we all really appreciate and admire your work 
Henrik. The slider screenshots are simply awesome.

I see it as how I would want it to work and look myself. That's the 
best motivation.

The ticks on the slider are generated by a function, and I can freely 
choose how many total ticks, how big and how many levels there are 
supposed to be. I expect to use this a great deal more.

The above font rendering article is great work, but unfinished. It 
requires further work on both AGG and FreeType

Status of AGG is not good for us. First, - we are using AGG 2.4, 
which was really free. From AGG 2.5, it changed to GPL, and as we 
know, GPL sux :-)

But as Cyphre stated - 1) maybe we could get special licence, as 
there was good relation of RT and Maxim 2) we are far from fully 
utilising even 2.4 version ...

Not that I am a super fan of the "+" and "-" but they are a very 
popular way to organize and present data.

I know.. what's with me and the "list" fixation? I wonder if it has 
to do with always trying to order my life. Actually, I thought that 
this is the first thing that my .Net friends are going to ask to 
see.

james - your request is along of mine request and another blog posters 
- we should not even dare to release without at least simple table, 
tree, tabs. I have two friends, who use REBOL for quick prototyping 
and connection to DB. One of them works with MS SQL. He creates quick 
tools to help him manage some jobs and some of his colleagues already 
asked about the tool. I really hope that for such guys (who are not 
interested to create widget themselves, but to use some ready-to-gon 
ones) we can come up with some data friendly widgets ...

AGG is still at 2.5, a bugfix release. He never got as far as 2.6 
and hasn't updated in 2+ years.

I wonder how would AltME looked using new skin though. It would look 
like more typical OS app, and I might loose interest in it just because 
of that. What could be better is the keyboard support (in list, tabbing 
between panes, etc.). I think that special apps with special purpose 
in mind, will need special skins ...

Pekr: I guess some of the crap in the IMB of Cairo is to support 
hardware acceleration and printing.

I think we still have some homework to do even in current state. 
What I think is suboptimal is timers. Fast View actions are still 
being a CPU hog. We discussed it several times, and I found some 
resources about timers. There are 4 - 5 types of timers in Windows 
itself, compatible with various Windows versions (or not). Windows 
is so much crap, that it does not support vertical blanking period 
=  forgot smooth not jerking not smeary animations, without DirectX.

I think Queue timers might be good for us. Such low level changes 
might speed up View and make it more resource friendly. Not sure 
Carl wants to experiment, so maybe we will have to try once View 
is open-sourced.

AGG Versions: I really don't understand why Carl is not asking for 
a Rebol license? I'm doing this quite often for GPLed stuff and it's 
not big deal. Most authors are proud if what they have done and just 
want to avoid that the dark side is using their code.

Robert, I think that a good reason why Carl hasn't asked for a REBOL 
license for the AGG 2.5 is that the license is the only difference 
between it and 2.4 so far, and further development of the GPL'ed 
version seems to have stopped there. :(

Pekr, I tried and it looks horrible. This size and shape makes the 
buttons most readable.

Henrik - what I dislike about current GUI though, is its too big 
metrics overally. I especially hated it with Gnome - those guys are 
crazy. To display one dialog, it takes xy percent of your screen 
with no added value, just to display some info to users. Too much 
spacing for my liking. When I look at my current desktop - 1280x600 
notebook with Vista, and compare VID 3.4 scroller and button - it 
is unnecessary big imo, and I am not sure it should be a standard 
... Dunno if I can judge it upon screenshots (as who knows what resolution 
was it taken with), but UI elements as buttons, scrollbars are more 
than 1/3 bigger than they should be ...

What system do you develop under? OS-X? Can you post a screenshot, 
of your system button and scroller along with R3 GUI ones? :-)

Petr, that's why in my vid you could not only resize the windows 
up, but also down, making them smaller and removing unnecessary white 
space. And of course I had scaling too, though that needed improvements 
(eg. hinting, and making it so you didn't have to explicitly support 
it in the style code)

Well, you would need to create a layout or a gob with a draw block 
and some rich text with the incriminating font.

After discussions yesterday and today, we will be moving to Curecode 
for the bug database.

and Devbase ?

but in the meantime use stuff as it is .... and not delay by forever 
rewriting tools

So, pehaps people can make suggestions for a BBS ( needs tags so 
that Carl only need to filter by tags to read what he needs to read 
), and good spam fitltering

All of this needs to be up and running so that we can receive feedback 
for R3

It has been said by many rebolers all over the past, the Killer app 
should be an IDE (including code editor, screen designer and other 
wizards).

It the only manner to encourage new groups of developper in starting 
huge projets with Rebol.

There are many advantages to using a distributed vcs, all variants 
on a theme. For example:

- You can track changes within your own code without submitting it 
until it is ready.

- It is easier to collaborate with other people without having to 
put your changes into the central repository.

This makes it easier to make large changes with the help of other 
people, and is why I suggested Mercurial over CVS.


The problem with all of this is that the main purpose of DevBase 
isn't source control, it is managing development workflow. No other 
vcs handles the workflow management function of DevBase. Without 
the workflow management Carl can't manage contributions.

Yesterday I came up with a way to change the DevBase model so that 
it would keep (and enhance) the workflow management functions and 
still get most of the benefits of a distributed vcs. Yes, it would 
depend on making the DevBase client a reblet run by the browser above, 
but that would be a bonus for R3 anyways.

Steeve, the reasons for minimizing the parse proposals are given 
in the proposal doc, but they boil down to these:

- Clean, simple and powerful is not only the REBOL way, but more 
efficient at runtime. It's the greatest strength of PARSE.

- PARSE is only one dialect of many in REBOL, and they are designed 
to be used together.

If anyone wants to discuss the source control and workflow management 
of the R3 project, mention it in the !DevBase group here.

Don't know - it makes sense, only if Carl takes the list of priorities 
seriously. Maybe he has his own opinion and will choose to implement 
according to his own priorities ...

I would prefer public relese, and continuous, incremental releases. 
But - can it happen without CVS?

and he can't decide on whether to use a BBS or not.

Has anyone involved with VID3.4 development looked at MigLayout, 
the Java layout manager (http://www.miglaout.com), for inspiration? 
I've recently started using MigLayout with Groovy and this manager 
is great for intuitive programmatic control placement. I'm guessing 
that whomever is doing all the hard work in R3 has really thought 
about the problem and will provide smilar functionality and ease 
of use, but just in case, it might be worth a look.

Short VID3.4 status:

- Some extra formatting options in the DOC style.

- I added a numeric field today similar to the one on my old blog 
site for VID, except that this one took half a day to do instead 
of a week and was way easier to implement.

- Skin is changing appearance a bit, both to simplify and to extend 
its possibilities. This made it possible to build pixel-perfect text 
areas, lists and other combined faces, finally.

- Some bugs remain in the layout engine which make certain layouts 
look a little messy. Still not sure that MAX-SIZE is the right approach.

- Added CONTAINER to help produce aforementioned pixel perfect styles. 
As a bonus, such styles will have a common border, which we then 
can change in a simple way.

- Looked a bit at a CALENDAR style for a date picker, but decided 
that it is better to wait a bit with that to finish some other base 
styles first.

- No time table given, so I can't say when there will be a release. 
I can only say that we're moving forward all the time, fixing bugs, 
adding new styles.

- No DRAW fixes yet. I haven't seen Cyphre since 5th November. We 
can work around most DRAW bugs for now.

- Skin lacked a CONTAINER style to put things in. Lining up scrollers 
with text fields, lists, etc. proved to be problematic. When one 
looked OK, the other would look terrible. We had TIGHT, GROUP and 
PANEL, but none of those are useful as decorative containers. CONTAINER 
works llike the frame of a painting, and now all styles that use 
CONTAINER look almost identical and pixel perfect. It also allows 
me to build complex field styles, like a search field with icons 
or numeric field with arrows.

- MAX-SIZE: It's a combination of weighting and maximum size of a 
face. When you set MAX-SIZE, it will affect the layout of the face 
in code, even if you are nowhere near maximum size, something I would 
never expect such an attribute to do. Setting MAX-SIZE correctly 
is an annoying process of trial and error, can't be predicted and 
depends on the MAX-SIZE of other faces in the panel, which requires 
debugging and studying other styles or setting them manually with 
a lot of typing. There are also magic numbers, so sometimes you use 
a size of 4000 and other times 100000 to achieve similar results. 
This is really the only part of VID3.4 that I don't like. However: 
There are still bugs, so intended behavior may turn out to be much 
better than I think. I can't remember what VID3 uses, but I would 
guess it's a more traditional weighting model.