AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 235 |
r3wp | 2632 |
total: | 2867 |
results window for this page: [start: 2201 end: 2300]
world-name: r3wp
Group: !REBOL3 GUI ... [web-public] | ||
Henrik: 18-Sep-2010 | http://rebol.hmkdesign.dk/files/r3/gui/r3.exe The latest A107 with TO-IMAGE fix. | |
Henrik: 18-Sep-2010 | http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3 Newer version too. Sorry about the ballooning in size, but this is due to a change in the build system. | |
Henrik: 18-Sep-2010 | http://rebol.hmkdesign.dk/files/r3/gui/r3lib.dll | |
Henrik: 18-Sep-2010 | what I did was create a GUI similar to this one: view [ panel 1 [check] panel 1 [button button button] ] When you resize this vertically by a few pixels, the bottom panel will resize incorrectly. That is known and will be fixed. What I managed to do, was to either move or resize the window in a way, that would cause resizing to get stuck in a loop (!), so it goes up and down in size by a few pixels vertically on its own, and the window just sits there shaking up and down in size. If possible, we would like some help with reproducing that. | |
Rebolek: 18-Sep-2010 | It's gray because I tweak colors only when I have nothing better to do. Once the GUI functionality is finished, there will be some simple color/style designer written in R3GUI to make some decent look for it. | |
Pekr: 21-Sep-2010 | re build system - will we be able, in future, to bundle only styles being found in source-code, or selected ones? I can imagine having library of tens of widgets/styles, while my app might not require all of them? So far, R3-GUI is still small, so it does not matter, hence regard my question being just theoretical :-) | |
Henrik: 21-Sep-2010 | so taking apart the R3 GUI WRT styles may not work as well. | |
Graham: 21-Sep-2010 | Are we going to be loading the gui from file storage? | |
Maxim: 21-Sep-2010 | is there a way we can get the r3-gui not compressed? I'm getting strange handler errors which cause rebol to halt whever I try to open another window not from r3 gui. | |
Maxim: 21-Sep-2010 | cool also, is there a way to link an arbitrary gob within the gui defintion? | |
Maxim: 21-Sep-2010 | seems using view/as-is when r3-gui is loaded prevents r3-gui from doing its stuff... it craps out with a handler-related error... | |
Maxim: 21-Sep-2010 | (this is on a window not using r3-gui, btw) | |
Henrik: 21-Sep-2010 | new build is up with uncompressed source: http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3 | |
Maxim: 21-Sep-2010 | cause right now, the gui looks totally dead a part for the fact that it resizes (though its late by one window resize event.) | |
Maxim: 21-Sep-2010 | does the material support some sort of accumulation? a very loose example I want gui in style dark I want aluminium the issue here being that dark is not a value but a process. so you get dark aluminium ? | |
Maxim: 21-Sep-2010 | yeah I did briefly.. but there is a lot of code to sift through... it is 216 kb after all (which is pretty lean for a GUI complete engine ;-) | |
Graham: 21-Sep-2010 | Henrik, why not just put the gui on devbase ? | |
Maxim: 21-Sep-2010 | ah think I found the handler problem. view's awake function now calls the do-event (it used to be handler). so its just an adjustment to any code running after it loaded r3-gui. | |
Brock: 22-Sep-2010 | Pekr: I had a contact who worked for Adobe and was a gui designer on many of their applications. He is now an indepent contractor, but now that he's contracting he's enjoying his time to be with his family. Adobe worked him hard for many years. So, unfortunately he is not available to help out. | |
Henrik: 24-Sep-2010 | http://rebol.hmkdesign.dk/files/r3/gui/r3.exe http://rebol.hmkdesign.dk/files/r3/gui/r3lib.dll Fixes clipping bug (disappearing faces) and garbage in text fields. Please download and test. | |
Pekr: 24-Sep-2010 | I tried to use area - that style is broken by some changes? In older version, gui crashed with something like no scroller attached message, now it crashes on divide by zero message :-) I expect area is not supposed to work yet? | |
Pekr: 24-Sep-2010 | Well, I expect it being something like that - you work in an area of GUI upon which style design/architecture is not dependant ... once other guys (as Bolek) move forward, it all plug-ins together ... | |
Pekr: 24-Sep-2010 | http://www.xidys.com/pekr/rebol/r3-gui-field-text-alignment.jpg | |
Henrik: 24-Sep-2010 | Pekr, did you download the latest r3-gui.r3? | |
Graham: 24-Sep-2010 | are we using the same binaries and gui source? | |
Graham: 24-Sep-2010 | I downloaded R3.exe from henrik's site ... and the gui but he says it might be caching old versions | |
Pekr: 24-Sep-2010 | I agree with Graham - while I still am not properly used to Vista after 3 years of usage, XP is 2002 = 8 year old system - guys install Windows 7 and test there :-) Before GUI is finished, XP will be even more obsolete :-) | |
Graham: 24-Sep-2010 | it's the script header for the gui | |
Pekr: 24-Sep-2010 | maybe it is some Aero thing, system GUI metrics, etc. ....? | |
Gregg: 24-Sep-2010 | I got the new exe and dll, the re-downlaoded r3-gui.r3, dialog and validation too, but get this error when clicking on a button in the dialog demo: ** Script error: path win-gob/text is not valid for none! type ** Where: any view either create-dialog request-user do switch applier apply if foreach if do-face if actor all do-style if do-event do-event do-event either ap plier wake-up loop applier wait do-events if view catch either either applier do ** Near: any [opts/title win-gob/text "REBOL: untitled"] ds: screen/s... | |
Pekr: 29-Sep-2010 | probably so, because I did not change executables, so it has to be part of r3-gui.r3 .... | |
Pekr: 29-Sep-2010 | this is not much needed feature, imo, but any fix is good :-) We're still waiting for R3 GUI to be at least on par with Carl's VID 3.4. What's needed in order to experiment with writing own styles? | |
Rebolek: 29-Sep-2010 | Maxim, if you have some fixes for R3 GUI, please, share them with me. | |
Henrik: 30-Sep-2010 | New r3-gui.r3: http://94.145.78.91/files/r3/gui/r3-gui.r3 My domain seems to be gone. Will have to fix that later... | |
Henrik: 30-Sep-2010 | http://94.145.78.91/files/r3/gui/db-reactors.r3 This shows a simpe skeleton of what it's made of. | |
Pekr: 30-Sep-2010 | The thing is, that for multimedia, kiosk, tablet, multitouch etc. UIs, all that stuff is useless, and that is my point all the time :-) Henrik - one question - aren't you afraid, that all the stuff you work on, might be dismissed by possible change in architecture, when some other subsystems are going to be added? And also - how all this stuff is going to be optional? Look - even low-level R3 now has various boot options, so e.g. someone can write and replace even module system. Now how pluggable (functionality wise) is new GUI going to be? | |
Pekr: 30-Sep-2010 | What if I don't care for your validation, your DB reactors? What if I am used to work with form and db my own way? Will I get one bloated gui? Carl was very picky for each single function to add, and now we are adding whole layers upon the GUI, which is still far from being finished. | |
Henrik: 30-Sep-2010 | Pekr, db-reactors and validation are optional features. Reactors are made using the MAKE-FACE-ACTIONS function, which specifically is designed to add a new aspect to the GUI in a way that doesn't interfere with its original functionality. And while you don't care about it, we do, because we need specifically to builds apps that use them, and I've missed these things in VID since I first used it. There's also that little detail about shaving off months of development and testing of large apps. The "bloat" you talk about would be around 5 kb of code for now. | |
Henrik: 30-Sep-2010 | Bloat of functionality: That's not the point of these frameworks. The point is to make certain rudimentary things quick and easy to set up for anyone trying to write a GUI. I'm pretty sure that once you've fixed the 657283th bug in a javascript/HTML webform, you will really wish this was already worked out for you. If the frameworks don't work out for you, then they are poorly written. | |
Robert: 30-Sep-2010 | Petr, being able to get a database / table design right from the GUI is IMO a very good approach :-). | |
Henrik: 2-Oct-2010 | Small status update: Cyphre has completed first version with keywords for draw blocks. This means you can now use the vertices of the box model for coordinates, instead of tediously calculating them inside the draw block. http://94.145.78.91/files/r3/gui/240.png | |
Henrik: 2-Oct-2010 | New R3 GUI uploaded here http://94.145.78.91/files/r3/gui/r3-gui.r3 It should contain the feature. | |
Henrik: 2-Oct-2010 | http://94.145.78.91/files/r3/gui/resizing-new-9.r3 Contains example. | |
Gregg: 2-Oct-2010 | Go GUI-team go! | |
Henrik: 3-Oct-2010 | They seem to be the same size, but, just to be safe: http://94.145.78.91/files/r3/gui/r3.exe http://94.145.78.91/files/r3/gui/r3lib.dll | |
Henrik: 5-Oct-2010 | New R3 GUI uploaded here http://94.145.78.91/files/r3/gui/r3-gui.r3 Fixes slider crash. Is 21 kb bigger. For some reason. :-) | |
Henrik: 5-Oct-2010 | Got a pattern on the resize loop bug, but I guess it requires a very specific VM setup: 1. Start the R3 GUI and make a window. Maximize it. 2. Resize the VM desktop window 3. Hope that your resize action is slow enough to allow you to doubleclick the titlebar to de-maximize it. 4. Now it loops between maximized and normal size. Perhaps there is some confusion about screen-face size changing. | |
Henrik: 5-Oct-2010 | Uploaded panel scoping prototype: http://94.145.78.91/files/r3/gui/panel-scoping.r3 Test support file: http://94.145.78.91/files/r3/gui/file.txt It's an earlier prototype that eventually became db-reactors, but it shows much more of the panel scoping features and uses EMIT, OBTAIN, ACQUIRE and SUBMIT. | |
Henrik: 6-Oct-2010 | New R3 compile should fix a scroll-wheel issue: http://94.145.78.91/files/r3/gui/r3.exe http://94.145.78.91/files/r3/gui/r3lib.dll | |
Rebolek: 6-Oct-2010 | GUI Enviroment. I didn't like it at first too, but I get used to it. OTOH, you don't need to acces guie most of the time. | |
Henrik: 6-Oct-2010 | Since the GUI is not a module yet, I don't know whether the GUIE name stays. | |
Pekr: 6-Oct-2010 | btw - why field style metrics are so wrong? Sometimes I can see proportionally too big fields - e.g. Facebook main page. And new R3 GUI uses too thin field. Look at old R3 View demo, section 'Form, how nice it looks :-) I just hope it is just question of some tweaking :-) | |
Pekr: 6-Oct-2010 | Rebolek - those are details which could be corrected in 1 minute, and make the overall feel for the tester much better. The whole team is not even at the level of Carl's VID, not unless R3 GUI can do anything usefull. I don't care for look now, but correct system metrics, closer to typography rules, are always welcomed. The screen forms should look relaxed. E.g. I was lately suprised, that I tried some Air app, and it was unpleasant experience in that regard ... | |
Pekr: 6-Oct-2010 | Rebolek - I will be harsh, but others might feel, that what is waste of time is lack of communication and providing big picture. You accepted SCRUM methodology, but only for your team internal purposes. The rest of us knows nothing about what's happening at particular levels. If you stop informing ppl, then the only thing we would know about the GUI would be, that team of 4 ppl are working on it for 4-5 monts, with no visible result. Ppl are very eager to have GUI. | |
Pekr: 6-Oct-2010 | It took me 5 minutes, to find area style misconceptions/bugs. If you are not ready to accepts comments/critique (CC), then just don't release. But then don't wonder, if ppl will not accept the way GUI turned out, if you keep it private for 1 year .... | |
Henrik: 6-Oct-2010 | public repository is not likely to happen, as RM Asset keeps private sources in the same repository as the R3 GUI to accommodate private projects and build system, but I will continue to release the r3-gui.r3 file until a better arrangement is made. | |
Robert: 6-Oct-2010 | How want to work with the RMA team on the R3-GUI? By work I mean, really getting something done. Writing code, styles etc. not discussing generic, high-level architecture stuff and future things to do. | |
Robert: 6-Oct-2010 | No, because this will than become a community project. I'm going to pay the RMA Team, which is than indirectly a sponsoring of the R3-GUI project for the community to keep the momentum. | |
Maxim: 6-Oct-2010 | (like I did with testing of the custom renderer in r3 gui) | |
Henrik: 11-Oct-2010 | Style browser as it looks right now: http://94.145.78.91/files/r3/gui/241.png Second validation prototype test window. The use of multiple draw blocks still doesn't work, so I'm resorting to funky yellow text fields to indicate validation state: http://94.145.78.91/files/r3/gui/242.png | |
Henrik: 11-Oct-2010 | http://94.145.78.91/files/r3/gui/243.png- Shows proper indicators http://94.145.78.91/files/r3/gui/244.png- Shows validation report | |
Henrik: 11-Oct-2010 | I will, but this will be saved for the end, when the GUI is stable. I don't want to discard anymore skin work. | |
Henrik: 11-Oct-2010 | New R3 GUI at: http://94.145.78.91/files/r3/gui/r3-gui.r3 New validation prototype, which can run stand-alone, at: http://94.145.78.91/files/r3/gui/validation.r3 | |
Henrik: 12-Oct-2010 | I'm thinking there is a design issue with validation, particularly the initial state: The latest version will show that the "Only Chars" field validates as OK, which is technically correct, but confusing, as absolutely nothing has been entered in the field. The issue is that the VALIDATE-PANEL/INIT function will see the field prefilled with an empty value and this passes validation. All fields that show a black dot, actually fail validation and a black dot is shown as the initial state. I understand what this means, but it may be confusing for someone who is using the validation system for the first time. The fix is simply to add the NOT-EMPTY validator to the field, for the field to fail validation initially. Is this easy to understand? I've studied the issue with setting an initial state for each field, but then there would be a problem with the validation system understanding prefilled values, and I would have to add functions to the validation system to mimick SET-PANEL that setup fields in a special way. I don't want to bloat the GUI like that. This method works fine, as long as you know what's going on. | |
GrahamC: 12-Oct-2010 | Is validation a fundamental gui aspect that has to be dealt with now? | |
Pekr: 12-Oct-2010 | Graham - that is my ethernal question with the GUI project :-) | |
Pekr: 12-Oct-2010 | Of course I am tempted to see things we expect most - more complete styleset and at least basically usable gui, but I will test what comes-out, as I think talking about what will come next just makes guys nervous :-) Of course some basic time-frame would be usefull ... | |
Henrik: 12-Oct-2010 | new validation prototype at: http://94.145.78.91/files/r3/gui/validation.r3 requires a new R3 GUI: http://94.145.78.91/files/r3/gui/r3-gui.r3 | |
Henrik: 13-Oct-2010 | It was decided a long time ago to do future projects in R3 as we felt that continuing to write testing tools, frameworks, etc. under R2 would give a big pile of work later, when converting that to R3. Considering also that the result of that decision is that Carl is now in tight communication with RM Asset, I think it was a good decision, as we avoid the months of darkness without info. It gives RM Asset control in what direction to take the GUI and to work towards R3 being a usable product as quickly as possible, when you have to answer to other companies and customers. SDK is also a requirement, that we hope can be pushed through as quickly as possible. | |
Henrik: 14-Oct-2010 | New R3 GUI with dynamic panel content functions: http://94.145.78.91/files/r3/gui/r3-gui.r3 Style browser: http://94.145.78.91/files/r3/gui/style-browser.r3 | |
Pekr: 15-Oct-2010 | Of course, I expect "typical" - from top-left to right-bottom direction. Not sure, how gui would look like, if I would try to think about arabic support for e.g. | |
Henrik: 15-Oct-2010 | New R3 GUI which fixes a few styles, like text list, although text list will eventually be rewritten: http://94.145.78.91/files/r3/gui/r3-gui.r3 Style browser now shows style options, alphabetic sorting of style names, face debug option (currently broken in the R3 GUI): http://94.145.78.91/files/r3/gui/style-browser.r3 | |
shadwolf: 19-Oct-2010 | what about this kind of IDE looks like small talk but for rebol and Rebol/GUI having such a tools could be crazy look at this and try it illumination Software Creator http://radicalbreeze.com/ | |
shadwolf: 19-Oct-2010 | maybe in a different way / shape but since along ago i like the idea very smalltalk like to organize Applications like a UML model ... And i think rebol GUI could shape that and use that ... | |
shadwolf: 20-Oct-2010 | sounds like i'm feuding ... lol well the idea is since GUI is planned to evolve then maybe we can start thinking toward that kind of extensiv graphical use to see how this can be meaningfull with rebol context of writing applications... | |
shadwolf: 20-Oct-2010 | i like the ideal of rebol being able to gui draw iit's own gui ... in my opinion most of the interest using rebol hides there ... | |
Henrik: 25-Oct-2010 | now discussing undo/redo management. There is a small spec available here: http://rebol.net/wiki/R3_GUI_Specs#Undo.2FRedo_Management any input is welcome. | |
Maxim: 25-Oct-2010 | best is to have a simple block with named threads... and you force people to supply the thread name when using any of the undo/redo functionality. also, undo/redo is best done when its not directly part of the gui. though its nice when the undo engine is able to speak to the gui directly. the gui must not be the "brain" of the undo.. | |
Maxim: 25-Oct-2010 | having written a few, I recommend making it an external api which is fully "gui enabled" this way, undo events can automatically call face accessors, and you can put the undo stuff in the logic rather than the gui. many times, the logic might generate a few undo, or none, based on things which the gui can't properly be aware. | |
Henrik: 25-Oct-2010 | yes, the idea is also that it can be entirely decoupled from the GUI, so if you don't want it or want to use a different way to undo, that should be possible. the task for undo as I see it is to read actions and allow playing them back by taking control of the GUI. | |
Maxim: 25-Oct-2010 | take the case of a system where the undo crosses the lifespan of a window (or a few) how do you undo that? re-open a new window which isn't connected to anything? it basically has to be built with undo actions at the center. each action has to be able to handle any gui issues gracefully... the gui itself cannot manage that unless its an uber simple gui. | |
Maxim: 25-Oct-2010 | might even be that the gui which manages the effect cannot be re-opened... ex photoshop. and yes the data has to be stored somehow... another thing the undo "actions" are able to manage better/ | |
Maxim: 26-Oct-2010 | also most undo/redo tie-in commands with macros and/or actual gui buttons and menus... sort of like the internal API for the lower-level stuff. each of these commands/actions puts itself on the undo stack and usually has a counter command... add-text/remove-text, edit-record/restore-record, etc. | |
Henrik: 27-Oct-2010 | New r3-gui.r3 available at: http://94.145.78.91/files/r3/gui/r3-gui.r3 No changes to other components. | |
Pekr: 27-Oct-2010 | and changes to gui itself? at least in brief? | |
Henrik: 29-Oct-2010 | New r3-gui.r3 released at above location. New feature: Now allows reactors to be run after a specific actor in the style. If your style runs ON-DRAG, a block of reactors after an ON-DRAG keyword will be run afterwards. This opens up a lot of new possibilities. view [field on-drag [do [probe 'dragging]]] This needs a lot of testing. | |
Henrik: 2-Nov-2010 | Unofficial A110 available: http://94.145.78.91/files/r3/gui/r3.exe http://94.145.78.91/files/r3/gui/r3lib.dll | |
Henrik: 3-Nov-2010 | http://94.145.78.91/files/r3/gui/247.png Tab boxes now support drag and drop. I'll provide a built version tomorrow as I found a build problem tonight, so you can try it out. | |
Henrik: 4-Nov-2010 | style design is not really commentable, since it will be replaced, when the GUI is stable and near complete. | |
Henrik: 4-Nov-2010 | seems there are some issues with LOAD and SAVE in A110, so no r3-gui build today. | |
Carl: 7-Nov-2010 | I do not like multiline tabs either, and they violate some of the rules of good GUI design. Sure Graham, good and bad design are matters of opinion; however, they are based on what "most users" can understand and efficiently operate. If a GUI causes a user become "lost" or do the wrong thing, then it's not a good design. | |
Pekr: 9-Nov-2010 | There is now Carl's blog upon how to easily list styles in R2. I posted corresponding R3 code, although it might be preliminary: foreach [name obj] guie/styles [print [name "-" obj/about]] But - I would like the GUI team to think about following aspects: Imo the guie/styles list is highly insufficient. Imagine you want to auto-inspect (load) list of styles into your GUI designer. What you get now is a flat list of styles, where apart from 'table, you have its sub-styles like 'table-cell, 'table-row, 'table-header, etc. I am not sure that in the case of an IDE, you want to see those styles listed. OTOH those are legitimate styles, from which you might want to derive something, or just being able to change their aspects. So, I propose to resolve this situation somehow. The implementation is up to gurus, just few wild ideas: - use tagging - tag style as 'main/root/parent, whatever - but - that introduces another field to the styles? Maybe not, because I expect some tagging system being available anyway? - create guie/widgets, e.g.: guie/widgets: [table [table-cell table-header table-row] - that way we will be able to list just/only widgets as table, not having the list poluted with widget internals - the above aproach might not work well in the case, when you aproach styles more as a CSS, not as widgets. Because - even e.g. 'table-cell might be derived from a totally different style, e.g. a box, or field, so I have no idea of how to keep track of those dependencies, but this is the area I leave for gurus to think about. E.g. someone changes box style and your table is influenced and user might be confused, why it happened. But I expect style/parent or something like that being available? | |
Pekr: 9-Nov-2010 | Maybe we need two separate things - style grouping (use gui/widgets for that), and style hierarchy - tree or other map of styles, their inheritance and dependencies (maybe this is what Rebolek now referst to as an object browser?) | |
Rebolek: 9-Nov-2010 | Tags can be used, they are implemented.But, IMO, if you need a list of styles for a GUI builder, you better make a list manually. | |
Henrik: 9-Nov-2010 | > Imo the guie/styles list is highly insufficient. Imagine you want to auto-inspect (load) list of styles into your GUI designer. What you get now is a flat list of styles, where apart from 'table, you have its sub-styles like 'table-cell, 'table-row, 'table-header, etc. I am not sure that in the case of an IDE, you want to see those styles listed. We already have and use tagging. The styles you mention should be tagged INTERNAL, if they are not already, as they are part of compound styles. So it's up to an IDE to discern that properly It might be possible to make a helper function that filters in only end-user styles, but we'll see how important that becomes. | |
Henrik: 9-Nov-2010 | But it's important to note that all styles are equal citizens in the R3 GUI. Tags are used for conceptual separation. | |
Pekr: 9-Nov-2010 | OK, I've provided you with some idea, now it is your team's take to discuss. Maybe such proposal could go into the long R3 GUI doc, before dismissed right away :-) | |
ssolie: 15-Nov-2010 | Was just trying out the r3-gui.r3 script and found out the fonts are hard-coded for Windows. I changed them to some Amiga fonts and the hello world GUI popped up. We'll need to find some way of handling fonts on non-Windows platforms via freetype to keep that script generic... | |
Pekr: 16-Nov-2010 | What about finally releasint useable GUI with more than useable button style? :-) | |
jocko: 16-Nov-2010 | I have a very basic question, that I have already asked to Carl : how to get a working gui.r version ? when doing load-gui, I get the following error message : ** Script error: size-text has no value. It seems to me that this point should be definitely fixed, as it prevents anybody to do view tests (for instance the ones given in the reference doc http://www.rebol.com/r3/docs/gui/guide.html) I think that this should be done quickly and independently of any improvement and evolution of the gui styles and functions. |
2201 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 21 | 22 | [23] | 24 | 25 | 26 | 27 | 28 | 29 |