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: 1801 end: 1900]
world-name: r3wp
Group: Ann-Reply ... Reply to Announce group [web-public] | ||
Oldes: 20-Dec-2010 | That's the old (Carl's) GUI version which is causing confusion now as it does not work anymore. | |
Ladislav: 10-Jan-2011 | Shadwolf: {If I had better relation with Robert and RM-Asset I could have updated MDP-GUI the only browser of MakeDoc Pro documentation made in rebol/vid 2. :)} - interesting, what exactly it is you announced, then? | |
DideC: 2-Feb-2011 | This one http://www.rm-asset.com/code/level1/r3-gui/gui-panels/ | |
Ashley: 2-Feb-2011 | Also consider changing the page heirarchy: Clicking "Code" then "Level-1" then "R3-GUI Library" then "GUI Panels" is not very intuitive. | |
james_nak: 2-Feb-2011 | Thank you all for providing the r3 gui code. Pretty nice stuff. | |
GrahamC: 5-Mar-2011 | Jocko .. load-gui works I think | |
jocko: 5-Mar-2011 | Yes, it works with the RMA build, but my tests are to check the level of compatibility with the standard r3 build, and, to that respect, I need to replace the load-gui by a do %r3-gui.r3. (At least, I suppose, I have not checked) | |
Robert: 5-Mar-2011 | Only our version of R3 loads our version of R3-GUI | |
JoshF: 6-Mar-2011 | About disreb: Sorry to be unclear originally. At the moment, it's R2 only (I'm currently sticking with the latest version of R2 because I understand that it has a more stable GUI), however I am very willing to incorporate changes for R3. I'm not yet sure what the best fashion of collaboration with the Google code site is, but hopefully I'll have some time to investigate tomorrow. Sorry for the late reply, but I have imperfect access to AltMe (it's firewalled at work and I forgot my password (ha!) so I don't have it working on the computer I'm programming disreb with). @Oldes, I hope you find it useful should you chance to use it! Thanks! | |
Henrik: 17-Mar-2011 | Moving to REBOL3 GUI... | |
james_nak: 24-May-2011 | Robert, code, including gui's, created by other code and then executed, is a great feature of Rebol. | |
Pekr: 2-Oct-2011 | Robert - thanks a lot, I really enjoyed run-tests.r3 demo, watching how GUI moves around in an automated fashion :-) | |
Group: !REBOL3 GUI ... [web-public] | ||
BrianH: 5-Jan-2010 | For discussion of the R3 GUI (which doesn't have a name yet). | |
BrianH: 5-Jan-2010 | The current non-host-kit builds of R3 can use the current GUI, with some bugs. Carl has a new resize model that he hasn't implemented yet. The GUI has been put on hold until after the first full R3 release. The R3 beta won't support or require a GUI. | |
Pekr: 5-Jan-2010 | BrianH: there are more changes planned, no? Like adding layers, etc. Henrik summed it up somewhere, maybe he can repost. And as far as I remember - the changes might influence your code, so I am not sure if it is good to do any GUI related work in recent VID state ... | |
Graham: 5-Jan-2010 | Is there a tutorial on using the ??? gui ? | |
Pekr: 5-Jan-2010 | BrianH: I will not argue, I just don't know ... we need Henrik to post conscise list - he has it somewhere. If GUI would be useable, Henrik would not stop his work :-) | |
Graham: 5-Jan-2010 | Top link for R3 Gui is for Syllable! | |
Graham: 5-Jan-2010 | http://www.rebol.net/wiki/R3_GUI | |
Henrik: 5-Jan-2010 | Something will happen here possibly in February to April, but I need to finish another project first. Things will be slightly different than originally, because I want to take advantage of some techniques used in the VID Extension Kit for face navigation, keyboard navigation, etc. Not doing work on the GUI has largely been because of announced changes not yet implemented, and also having lots of work elsewhere, fortunately almost all REBOL related. | |
Pekr: 6-Jan-2010 | I just found Henrik's summary. I think it is the post I had in mind: --------------------------------------------- Indeed VID3.4 is far from done. You can probably use it for a few things, like getting a name from a user in a text field or submit a very simple form, but not much more than that. To reiterate the state of the UI: - No unicode yet in graphics (when Cyphre gets around to it). - Resizing acts like a drunken sailor. (Carl) - Skin is not published. (Me) - Style tagging is not implemented. (Carl) - Reasonable requesters are not yet implemented. (Carl or me) - Layers are not yet implemented. (Carl) - Guides are not yet implemented. (Carl) - Better font rendering. We are not taking advantage of what AGG can do. (Cyphre again) - Event system is from Gabriele's VID3. (Carl) - Many features are untested, like drag&drop. (Me, I guess) - Proper material management for skin. (Me). - Many styles are not implemented, especially lists (Me). - More elaborate animation engine (Carl or Me). - Form dialect (Carl talked about this). - More/better icon artwork (Me). Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, but I don't know if they can be implemented. The overall design of the GUI engine is very good. Whenever a change or addition is made, you alter 3-5 lines of code in one place, and it works. I doubt the entire engine will be rewritten. You won't see GUI bug reports in Curecode for a while. There could easily be 2-300 reports, once we get to that point. My work regarding skins is rather big: I need to work out the basic styles first, so we have a reasonable way to build compound styles. These are being done using a very simple, but pixel accurate GUI using plain colored surfaces. This is easier for testing out, as draw blocks are small, but as Pekr likes to complain: They are not pretty to look at. Once the real skin goes into place, the draw blocks will grow a lot. I would love to see a low-level GOB management dialect, like Gabriele's MakeGOB. | |
Pekr: 6-Jan-2010 | Can't wait for when we get back to GUI :-) Hopefully Carl is back to Host Kit soon, so that View will be adapted to command! interface, and its source released, in order for Cyphre to proceed ... | |
GiuseppeC: 7-Jan-2010 | Pekr, you forgot animated effects on every place of the GUI and 3D GUI ;-) | |
Ashley: 8-Jan-2010 | I realize the GUI is still a WIP ... but is the underlying [native] gob! system settled? (i.e. is it likely that the details of http://www.rebol.net/wiki/GOB will change?). | |
Ashley: 8-Jan-2010 | Good. That means the building blocks are in place for those who want to experiment with Gob-based GUI's ;) | |
Ashley: 8-Jan-2010 | The way I see it, there are at least four ways to build an R3 GUI [based on gobs]: 1) Heirarchical, where gobs are grouped into faces, which are in turn grouped into windows 2) Flat, where a DOM-like object maps all gobs (i.e. removes the need for intermediate faces/windows) 3) Draw-based, where each window consists of a single gob with the entire window rendered in a draw block 4) Image-based, similar, but the draw block is pre-rendered into an image. | |
Ashley: 11-Jan-2010 | Getting a window plus event handler up and running only using View (no load-gui) is pretty simple. The code, for those interested, is: system/view/event-port: open [scheme: 'event] system/view/event-port/awake: make function! [[event][print event/type]] f: make system/standard/font [size: 36] d: make gob! [text: "Title" offset: 50x50 size: 300x200 flags: [resize]] append d make gob! [text: [font f "Text"]] append system/view/screen-gob d show system/view/screen-gob wait system/view/event-port | |
Graham: 15-Jan-2010 | What sort of widgets do we actually have so far in the GUI ? | |
Henrik: 15-Jan-2010 | graham, if you have an account to the r3-gui world, there is a list in there | |
Graham: 15-Jan-2010 | R3 gui is supposed to be easier to code for than VID isn't it ? | |
Graham: 15-Jan-2010 | I don't know anything about the intricasies of GUI programming .... | |
Graham: 15-Jan-2010 | I have noticed some instability. If you halt from a GUI script and then try and close it ... r3alpha crashes | |
Graham: 15-Jan-2010 | Hmm.. no messages in GUI in R3 chat for this year | |
Graham: 15-Jan-2010 | My first gui script http://rebol.wik.is/Rebol3/R3_GUI/Sendfax.r I'd like to have the output from net-log appearing in the area .. but I can only get it do that once and then nothing ... | |
Graham: 16-Jan-2010 | I wrote this to try and update the area with network trace set 'net-log funct [ txt /c /s][ data: rejoin [ get-face a1 newline txt ] if c [ data: join "c: " data ] if s [ data: join "s: " data ] set-face a1 data set-face/field a1 tail get-face a1 'locate wait .1 ; update gui txt ] | |
Robert: 23-Jan-2010 | As we still have the chance to make some changes to R3 GUI, I would like to get the opinion of the community for this idea: R3 is designed for development-in-the-large, this means modularity is key. IMO a GUI system where widgets just send messages and where I can register handlers for a widget-name/mesage combination would help a lot. Such a system could call several handlers in a chain, it could be re-configured at run-time, etc. Further I think a concept like a (virtual-) finite-state-machine can help a lot here. | |
Robert: 23-Jan-2010 | I have used such an approach in one of our apps.For example I have three tables, that depending on the app state, show different columns and data. So, when app state switches this will trigger the change of the tables. And other example is changing the language just where you are. No need to re-enter the current GUI etc. There will be just a change-lang XY event send. | |
Graham: 24-Jan-2010 | Wasn't Max proposing a message passing gui in one of his various liquid thingies? | |
Pekr: 24-Jan-2010 | I think we just need to finish R3 GUI as Carl started it (VID 3.4). We might think about some by Max proposed enhancements to Draw, making GUI kernel more powefull, and let's see, where it leads us, before we start to think about another overhaul. Msg passing concept is surely interesting, but it imo creates another layer to implement, understand, to work with, so I am just not sure, unless I see the currently implemented solution does not allow us to easily work/extend the GUI. | |
Henrik: 24-Jan-2010 | Carl's original goal for the GUI was to make it so a child could use it. We should not deviate from that goal. That's part of what Rebrowse is meant to do. I don't want to risk a forking of the GUI work. | |
Henrik: 24-Jan-2010 | I don't mind advanced features at all, but we must be careful not to make the GUI difficult to use from the outset or having to place the user into a specific mindset, when starting to learn it. | |
Henrik: 24-Jan-2010 | I think it's possible to make it strong for industrial strength applications, without making the usability a hindrance. I also wouldn't want to lose the ability to write a GUI in 2 minutes for your boss to use. | |
Henrik: 24-Jan-2010 | It's important to lift the UI out of the domain of appearance and into the domain of meaning. When your UI intelligently finds the default window close button or the first field in a form automatically, and automatically assigns correct keyboard navigation shortcuts, because of the underlying architecture's emphasis on meaning, there's no need to write any code to handle that at all. It's just there. You build your styles to adhere to the meaning that was setup by the GUI system. In the VID extension kit, this is done through flags and powerful face handling features. You don't need to add any code for that in the dialect. | |
Ashley: 25-Jan-2010 | I've spent a bit of time going over R3/View and believe it now has all the "building blocks" required to build a modern/fast gob! based GUI. The amazing thing is that these building blocks are the 10 natives that View adds [to Core]. They are: gob! caret-to-offset cursor draw effect map-event map-gob-offset offset-to-caret show size-text With these 10 natives (gob! is actually a type!) we should be able to construct simple but powerfull gob!-based GUIs with a smaller mezz footprint than R2. My preliminary conversion of RebGUI to R3 seems to take about 50% the code to do the same thing [compared to R2] ... very promising at first glance. To get a feeling for how tight the code can be the next post is the entire [skeleton] source of a working gob!-based GUI. | |
Ashley: 25-Jan-2010 | ctx-rebgui3: make object! [ cursors: make object! [ app-start: 32650 hand: 32649 help: 32651 hourglass: 32650 arrow: 32512 cross: 32515 i-shape: 32513 no: 32648 size-all: 32646 size-nesw: 32643 size-ns: 32645 size-nwse: 32642 size-we: 32644 up-arrow: 32516 wait: 32514 ] colors: make object! [ page: white edit: white text: black true: leaf false: red link: blue theme: [165.217.246 0.105.207 0.55.155] outline: [207.207.207 160.160.160 112.112.112] ] metrics: make object! [ cell: 4 gap: cell * 2 line: cell * 5 margin: cell * 4 margin-size: as-pair margin margin radius: 2 ] ; Private functions set 'make-gob make function! [[ spec [block!] ; offset, size and one or more attribute/value pairs /data object /local size text gob axis ][ size: spec/2 if any [negative? size/x negative? size/y] [ text: select spec 'text all [block? text text: first find text string!] size: 8x4 + size-text make gob! compose [size: 9999x9999 text: (text)] all [negative? spec/2/x spec/2/x: size/x] all [negative? spec/2/y spec/2/y: size/y] ] gob: copy [] ; attributes are (text, color, effect, image and draw) foreach [attribute value] spec [ switch attribute [ box [ attribute: 'draw value: compose [ pen (get value/1) line-width 1 fill-pen (get value/2) box 0x0 (spec/2 - 1x1) (metrics/radius) ] ] pill [ attribute: 'draw axis: either spec/2/x >= spec/2/y [2] [1] value: compose/deep [ pen (colors/outline/3) line-width 1 grad-pen linear (spec/2/:axis * .1) (spec/2/:axis * .9) (all [axis = 2 90]) [(colors/outline/1) (white) (colors/outline/1)] box 0x0 (spec/2 - 1x1) (metrics/radius) ] ] ] append gob reduce [attribute value] ] spec: gob gob: make gob! compose [offset: spec/1 size: spec/2 (to set-word! spec/3) spec/4 data: (make object! any [object copy []])] foreach [attribute value] skip spec 2 [ append gob make gob! compose [offset: 0x0 size: spec/2 (to set-word! attribute) value] ] gob ]] ; Public functions set 'display make function! [[ title spec /local gob xy max-x max-y left-to-right? after-count after-limit here arg append-widget widget last-widget word action handler size text color ][ xy: metrics/margin-size max-x: xy/x max-y: xy/y left-to-right?: true after-count: 1 after-limit: 9999 gob: make gob! compose [text: (title) data: (make object! [])] append-widget: make function! [[][ unless widget [exit] unless handler [ handler: compose/deep [on-down: make function! [[event][(action)]]] ] append gob switch widget [ bar [ make-gob compose [(xy) (as-pair max-x - metrics/margin 1) color (colors/outline/3)] ] button [ all [none? size size: 15x5] make-gob/data compose/deep [(xy) (size * metrics/cell) pill none text [center (text)]] handler ] text [ all [none? size size: 15x5] make-gob/data compose/only [(xy) (size * metrics/cell) color (white) text (text)] handler ] ] last-widget: last gob/pane ; 1st reverse item? unless left-to-right? [ last-widget/offset/x: last-widget/offset/x - last-widget/size/x ] xy: last-widget/offset ; max vertical size max-y: max max-y xy/y + last-widget/size/y ; horizontal pos adjustments all [ left-to-right? xy/x: xy/x + last-widget/size/x max-x: max max-x xy/x ] ; after limit reached? either after-count < after-limit [ ; spacing xy/x: xy/x + either left-to-right? [metrics/gap] [negate metrics/gap] ++ after-count ] [ xy: as-pair metrics/margin max-y + metrics/gap after-count: 1 ] all [:word set :word last-widget] word: widget: action: handler: size: text: color: none ]] parse reduce/only spec [after bar button handler return reverse rich text] [ any [ opt [here: set arg paren! (here/1: do arg) :here] [ 'return ( append-widget xy: as-pair metrics/margin max-y + metrics/gap left-to-right?: true after-limit: 9999 ) | 'reverse ( append-widget xy: as-pair max-x max-y + metrics/gap left-to-right?: false after-limit: 9999 ) | 'after set arg integer! ( ; return unless this is first widget if widget [ append-widget xy: as-pair metrics/margin max-y + metrics/gap ] after-count: 1 after-limit: arg ) | 'handler set arg block! (handler: arg) | 'rich set arg block! (text: arg) | [set arg integer! | set arg pair!] (size: arg) | set arg string! (text: arg) | [set arg tuple! | set arg none!] (color: arg) | set arg block! (action: arg) | set arg set-word! (append-widget word: :arg) | set arg word! (append-widget widget: arg) ] ] ] append-widget gob/size: metrics/margin-size + as-pair max-x max-y gob/offset: system/view/metrics/work-size - gob/size / 2 append system/view/screen-gob gob show system/view/screen-gob ]] set 'undisplay make function! [[gob][ remove find system/view/screen-gob gob show system/view/screen-gob ]] ; Start global GUI event handler active-gob: none system/view/event-port: open [scheme: 'event] system/view/event-port/awake: make function! [[event /local evt gob][ evt: map-event event gob: evt/gob while [not object? gob/data] [gob: gob/parent] if all [event/type = 'move gob <> active-gob] [ attempt [active-gob/data/on-away event] active-gob: gob attempt [active-gob/data/on-over event] ] evt: to word! ajoin ['on- event/type] attempt [gob/data/:evt event] ]] ] | |
Ashley: 25-Jan-2010 | add a closing ']'. An example app is: blk: copy [] foreach word words-of ctx-rebgui3/cursors [ append blk compose/deep [ text (form word) handler [ on-over: make function! [[event][cursor (ctx-rebgui3/cursors/:word)]] on-away: make function! [[event][cursor ctx-rebgui3/cursors/arrow]] ] ] ] display "Test Window" compose [ text 83x10 rich [size 36 center red "Reb" black "GUI" leaf "3"] after 5 (blk) return bar reverse button "Close" [undisplay event/gob] button "Open" [ display "Alert" [ after 1 text 50x5 "Some more text." bar reverse button "Close" [undisplay event/gob] ] ] ] | |
Ashley: 25-Jan-2010 | do http://www.dobeash.com/gui.r | |
Pekr: 28-Jan-2010 | this group is imo ok, no? Or - REBOL 3 View, if we want to separate low-level engine from the GUI one ... but I see no reason for it ... | |
Henrik: 29-Jan-2010 | Gabriele, maybe you should upload your old GUI to R3 chat for reference. | |
Pekr: 29-Jan-2010 | I think R3-alpha is still alive as well, so Gab's GUI should be there too. It was many files IIRC. The question also is, if it will work with new R3 releases. So maybe it is easier for ppl to just get to r3-alpha ... I think each of us has access there :-) (note: I understand your message, why you want it in R3 chat, I just tried to point out, it is already available) | |
Graham: 3-Feb-2010 | Is the lack of a table face ( or whatever the new jargon is ), a reflection of the difficulty of building it, or some other issues with the gui engine? | |
Henrik: 3-Feb-2010 | the resize engine is still the main issue for troubles and so the best result looks something like this: http://rebol.hmkdesign.dk/files/r3/gui/166.png | |
Graham: 3-Feb-2010 | Gabriele, were you going to upload your GUI system as well? | |
Graham: 3-Feb-2010 | I see R3-gui has a gob called 'code-area which uses a monospaced font. | |
Graham: 3-Feb-2010 | Also, I've read thru the docs ( but not the sources ) and it's not documented on how to create a GUI event | |
Henrik: 5-Feb-2010 | Make sure the word is not used anywhere else in the R3 GUI. Font changing, AFAIR is a little cumbersome. In the R3 GUI, fonts are a resource, similar to colors, certain draw blocks or materials. | |
Graham: 5-Feb-2010 | Pekr, I'm the last person to make GUi contributions! | |
Graham: 5-Feb-2010 | Luckily there is very little GUI code out there so it's easy to change :) | |
Pekr: 5-Feb-2010 | exactly ... I think, that what we are aiming at, is natural understanding of written GUI code. When reading the code, strange words should not disrupt my flow of thoughts ... | |
Henrik: 5-Feb-2010 | I see Graham is already submitting GUI reports to Curecode. I think we need a separate project for that. There could be hundreds of issues and they shouldn't be mixed with Core bugs. | |
Graham: 5-Feb-2010 | >> stylize [ bt: button [] comment { }] ** GUI ERROR: Invalid style syntax: comment | |
Graham: 5-Feb-2010 | Is that a GUI or core error ? :) | |
Graham: 5-Feb-2010 | r3 gui | |
Henrik: 5-Feb-2010 | Better to be prepared for a flood of reports. I suspect the GUI might be a bit popular. | |
Pekr: 5-Feb-2010 | :-) So when the work on GUI is supposed to be restarted? Do we wait for its inclusion into HostKit section? | |
Graham: 5-Feb-2010 | face - 2nd level gui object with gobs, like a scheme facet - part of a face faced - local variables for a widget instance | |
BrianH: 5-Feb-2010 | I don't know about "faced" though - it's been a while since I looked at the GUI code, so I don't remrmber what it means. | |
BrianH: 5-Feb-2010 | However, I don't remember enough of the GUI model to know what the right word would be to use instead of "faced". | |
BrianH: 5-Feb-2010 | Attribute is too generic a term. There are many things in the GUI that have attributes. | |
Graham: 5-Feb-2010 | http://www.rebol.net/wiki/GUI_howto_styles | |
ChristianE: 5-Feb-2010 | Yes, but currently there isn't any, is it? (I am aware of the fact that the GUI is barely alpha) | |
BrianH: 5-Feb-2010 | You're too generous. The GUI is pre-alpha, and wouldn't be considered alpha without the layout model changes Carl has said he has planned (but then had to take a break to work on lower-level stuff for a year). | |
BrianH: 5-Feb-2010 | It might not be a good idea to access these faces outside of the GUI code. There might be synchonization or multitasking issues. | |
Graham: 5-Feb-2010 | that's going to make separation of gui from code more difficult | |
Henrik: 6-Feb-2010 | http://rebol.net/wiki/R3_GUI_Specs This is not the list Carl made. | |
Pekr: 6-Feb-2010 | My take on naming - I will probably learn anything we come-up with. My english is pretty weak, so I am not a good measure, but I never ever used word FACET. I might have old brain already, but I always forget what it means. And I can assure you, there will be many such users as me. So more general naming would not hurt. It is really laughable, like we use special word (FACET), and then in its docced description to explain its meaning we use words like attributes, properties. So - why use FACET at all then? Quite contrary though, I was able to remember FACED. It sounded for me like sticked to the face instance :-) Anyway - I think that we have much more important things for the GUI to work on. And good docs with some diagram might be worth a thousands words ... | |
MikeL: 6-Feb-2010 | Only the text language displayed in the GUI. If there is no position on GUI text language or user input then I suggest that a statement of same belongs in R3_GUI_Specs so that it continues to be addressed or specifically ignored ... but will not be a surprise to new readers. | |
Henrik: 6-Feb-2010 | A frozen face does not respond to input, but is otherwise normally visible. A disabled face is visibly disabled. Frozen faces may not be necessary, but they are a first step toward creating a GUI layout editor. | |
BrianH: 6-Feb-2010 | Some of the global functions could be limited to the scope of the gui module and not exported. | |
BrianH: 6-Feb-2010 | It's good to see someone going over the gui docs - the existing ones got a bit scrambled when someone reorganized the wiki with no understanding of the gui model. Docs for Gabriele's and Carl's guis were mixed together and the result made no sense. | |
Henrik: 6-Feb-2010 | For now, I'm ignoring the docs and sticking with the source. As the GUI system develops, we'll write new docs. | |
Graham: 6-Feb-2010 | Who is able to go over the GUI docs to fix the mess? | |
Henrik: 6-Feb-2010 | I'm also kind of expecting that the R3 GUI no longer uses objects for panes. That simplifies the code a little bit. | |
Henrik: 6-Feb-2010 | Got basic face traversal working: LOCATE-FACE, NEXT-FACE, BACK-FACE, TRAVERSE-FACE, INSIDE-FACE?, FIND-RELATIVE-FACE, GET-TIP-FACE are now ported from the VID Extension Kit. Requires no modification to VID3.4. It can be tested here: do http://rebol.hmkdesign.dk/files/r3/gui/traversal.r | |
BrianH: 6-Feb-2010 | I wish I had the time to review the GUI code right now, but I'm working on LOAD of compressed scripts/modules. | |
Henrik: 6-Feb-2010 | There are a few changes in this, from the VID Extension Kit: All error generation is removed and replaced with NONEs. This was due to how VID is not pure enough a structure to work in. Consistency in the face tree for R3 GUI seems much better, but also because only a few styles exist and they all adhere to structure. | |
BrianH: 6-Feb-2010 | I've really been wanting to review the GUI code again. The R3 language is really quite different from when the GUI code was written. | |
Graham: 11-Feb-2010 | Henrik said he was starting working on the GUI this month .... is anything public happening? | |
Henrik: 12-Feb-2010 | ok, the basics are here: http://rebol.net/wiki/R3_GUI_Specs#Style_and_Face_tag_principle | |
shadwolf: 12-Feb-2010 | for rebol3 GUI what ever you put in it really it has to work the same way every where it exists .... the differencies between R2 windows and R2 linux are so big that advanced projects are a pain to make | |
Henrik: 12-Feb-2010 | Shadwolf, those are low level things, so Cyphre is the one to bash, if it doesn't work everywhere. :-) With any luck the R3 GUI shouldn't have any need for adapting to various OSes and hardware. | |
Robert: 12-Feb-2010 | @Shadwolf: If Carl doesn't agree with what we do or wants to position VID34 different than it will be a fork. Overall I still think we should avoid creating to much GUI forks and fragment our little community forces but instead pool forces to faster move forward. | |
Robert: 12-Feb-2010 | But our mission is clear: We will get a R3-GUI up & working that will hold for big apps. | |
amacleod: 12-Feb-2010 | Carl seems to have some specific stuff in mind for vid direction but he is just not going to get to it anytime soon...I do not see a prob with you guys coming up with an alternate vid (rebgui for r3) in the mean time...each gui may be addressing different needs anyway. Carl's VID, when ready, can become the defacto and distributed with R3 but in the mean time we can use the alternate to push R use forward. | |
Henrik: 13-Feb-2010 | It would be preferable, yes. It depends how we can push it around, as I'm not sure Carl will want to go into GUI work now. | |
Pekr: 13-Feb-2010 | well, such claims sound very strange. One of the reasons why Carl forked GUI was, that he did not agree to some concepts. So it really surprises me, that you plan to continue to work on VID, without any coordination ... that once again asks for later fork. I think that for Carl to explain/document his ideas would not mean more than few hours of his work ... | |
Pekr: 13-Feb-2010 | so we really are talking fork here :-) Well, I will be glad for any GUI for R3, that is a fact. It is just that I thought managing Carl for some 1-2 hours chat on some isolated group here would not hurt, and you would simply know, what Carl's plan is. I can understand business driven decisions ... but anyway ... | |
Graham: 13-Feb-2010 | Any working GUI is preferable to an official broken one. | |
amacleod: 13-Feb-2010 | Even if an official GUI is released tomorrow it will not be all things to all people and some will develop other gui's (rebgui, maxim's glass etc) why not start now as opposed to later. It need not be considered a folk of the offical vid...just an alternative choice. the official when released will be adopted if it works well enough so you won't be stepping on carl's toes. | |
Group: Core ... Discuss core issues [web-public] | ||
BrianH: 9-Dec-2010 | Then we need a ticket for that. I would think that there would be some GUI reasons for doing SWAP, though more for doing MOVE. |
1801 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 17 | 18 | [19] | 20 | 21 | ... | 25 | 26 | 27 | 28 | 29 |