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: 2501 end: 2600]
world-name: r3wp
Group: !REBOL3 GUI ... [web-public] | ||
shadwolf: 7-Jan-2011 | oldes Rebol GUI is just an interface on top of your local system windows management API. | |
Oldes: 7-Jan-2011 | Are we talking about same GUI? What I know Rebol gui does not use any native api and there is nobody I know working on it. | |
shadwolf: 7-Jan-2011 | so yes the goal seeked is for the rebol programer to have a transparent and portable API in rebol to make graphical user interface. But on the ground level you need to adapt the C code to your OS window management solution... With some specific tweaks for example on linux you are not obligated to have X11 started so you linux rebol/view -hostkif R3/GUI- have to detect if the X11 server is run and if it will be able to display things or warn you it can't | |
Oldes: 7-Jan-2011 | that's window... that's not eaqul to gui for me.. and I really don't understand what's the point. | |
shadwolf: 7-Jan-2011 | Oldes that's because you are not aware that all your R3/GUI calls need to be displayed on your screen and that rebol doesn't handle that part ? and that the same for the mouse / keyboard events... | |
shadwolf: 7-Jan-2011 | and since i'm considere as a pain in the ass and you all try your best to not have this discussion with me or with the others in the community then you go to what Carl did without any second thoughts in the end we will end with a strong win32 API based R3/GUI and no linux or macOS X ports. That' s the the projection I can make base on the actual work. | |
Oldes: 7-Jan-2011 | GUI is system independent.. if you need it on win, you just must modify host-lib as it was for AmigaOS. And it was possible for R2 so I really don't know why it would not be possible with R3... the only true is, that just opensourcing host-lib will not bring people who want to do the work. | |
shadwolf: 7-Jan-2011 | oldes glut is compact, it's C based, it's portable on linux, windows, macosx only 117Ko and it opens a big gate to opengl since that's it's main purpose... Agg could be adapted at some point to use hardware accelerations proposed by OpenGL API at some point or at least we can investigate that part... Glut is old so this means it's super documented, and glut goal fits what r3/GUI basic goals are manegment of windows and management of user's inputs | |
shadwolf: 7-Jan-2011 | that's the kind of port quality we are talking about ok but then R3/GUI will be no different as R2/VID | |
shadwolf: 7-Jan-2011 | GUI is system independent.. if you need it on win, you just must modify host-lib as it was for AmigaOS. And it was possible for R2 so I really don't know why it would not be possible with R3... the only true is, that just opensourcing host-lib will not bring people who want to do the work. | |
shadwolf: 7-Jan-2011 | anyway for text processing who cares even having a GUI library ... | |
shadwolf: 7-Jan-2011 | OLdes henrik and any other that wants me to make my own R3/GUI ok but since your are the gurus then I'm pending on your teaching and leading for me to achieve that goal :) | |
shadwolf: 7-Jan-2011 | cyphre yeah you want pathetic brainless followers that appauds any of your moves.... Sorry that's not my style.. The thing is the people telling me to do my own branch of R3/GUI for free obviously to there benefits don't know how to do such a project on their own to start with so there is obviously nothing to be expecting coming from them. | |
shadwolf: 7-Jan-2011 | patience ? since when do we know that R3/GUI is externalised to R3hostkit ? Since when do we know carl is having terrific problem on this matter ? | |
shadwolf: 7-Jan-2011 | I tryed to have this discussion in the early stage of R3/GUI project I was pushed aside I tryed to have it again some month after with same result and now again some month after nothing have changed and you tell me to be patient ? | |
Robert: 7-Jan-2011 | Repeating from above: We'll be releasing new version of R3GUI later today with the docs Ladislav mentioned. Unfortunately I had not enough spare time to update the old 'gui demo'. So now a question to all who cried here :) Is there any volunteer who will try to convert the demo? I think this is great oportunity to: -learn how the new version works -found possible bugs and issues and report back to RMA team or even provide fixes -give back something usable to comunity So anyone interested?... | |
shadwolf: 7-Jan-2011 | will that documentation be anought to start another branch R3/GUI ? I think that's not the topic in fact. That's documentation to allow us to test your product and be productive beta testers. | |
shadwolf: 7-Jan-2011 | once angain those documents are just here to serves you own interest not our... My interrest is to have a R3/GUI that is based on a community real effort and organisation, that produce documentation and that tends to involve everyone and not limiting them to the role of beta testers. My interest is having this library with one to one link everywhere. My interest is to have this module/library discussed all aloing and with futur granted ... We don't know if RMA will produce something affortable we don't know if after this first shot what will be the level of evolution we can expect from it ... Do we will need to pass to bounties to get new things added to it once the main release is done ? how will be integrated and rewarded external contributions to that project ? why only the 5 of RMA should get money out of this project? | |
Henrik: 7-Jan-2011 | http://94.145.78.91/files/r3/gui/252.png SCRUM tool prototype GUI example. We are exploring how to organize the GUI, as the R3 GUI can be used to prototype things now. The next step here is to get it integrated with the database reactors prototype written earlier. If that is done correctly, we should be able to switch from a prototype file database to a different database backend (SQL based) without touching any GUI code. | |
Pekr: 7-Jan-2011 | We should start talking look & feel at some point too, as it really looks completly strange :-) Cheap gradients with Aqua like old Mac look mixed with 70ties Unix grey aproach :-). How can anyone create anything like that nowadays? This is really strange, as I remember Gabriele's effect-lab, Cyphre's styles pack, and also Henrik's first UI attempts, and those looked much better ... I need to know, if it will be adressed, as I am scared to touch the gui, as I fear it will do really something bad to me :-) | |
TomBon: 7-Jan-2011 | btw what happened to the old R3 V2 gui from carl? could this be used as a starting point fpr another GUI? | |
Henrik: 7-Jan-2011 | Tom, Carl's GUI was inadequate in many ways. The one we are building now is directly based on it, but replaces parts of it, like the resizing scheme. | |
Rebolek: 7-Jan-2011 | Pekr, what you think is ugly and cheap design, is actualy THE FUTURE of UI design. Every GUI will look like this in 2-3 years, I wonder you don't see it. At least you understand this is the definite and final design of R3GUI. | |
Pekr: 7-Jan-2011 | Rebolek - my dog randomly drawing would come up with better aesthetics probably :-) One should have pleasure to play with the stuff in the process, while I have really a hard time looking at any single screenshot of new GUI. What I don't understand is, why it changed from the former look, if draw code for such style was already available? | |
shadwolf: 7-Jan-2011 | I will not participate to any bug tracker, bug correction, or testings regarding R3/GUI until we don't have a full detailled schematic of R3-host-kit, while we don't know where we are going with this project, and while we don't know if a better path can be found to avoid this project to fall in porting maze. | |
Kaj: 7-Jan-2011 | I have to support Petr's dog here. I fully understand why looks are not a priority for development, but I also know that if we proudly present the GUI functionality to the world with the current skin, almost everyone who sees that will confirm in his mind that REBOL is a thing of the past and will never touch it again | |
Kaj: 7-Jan-2011 | Shadwolf, if you want a REBOL GUI that can just be recompiled on all platforms based on OpenGL or QT or GTK, the current host kit fully supports that. You can just build such an interface on it | |
GiuseppeC: 7-Jan-2011 | I apreciate the work put onto R3GUI. I am just a spectator, I am not involved into the development. So I whish to say thank you to all the people building R3GUI. From time to time the community get nervous about lack of development or inadequate results. Please note that they are building the foundations for further work. One time in the future the GUI will have the look similar to MacOS or GUI found on mobile device. Until then an old fashioned GUI is better than nothing. Please consider all the hard work put from unpaid people on this project. | |
BrianH: 7-Jan-2011 | I like that the UI look isn't inherent in the GUI. Skinning was a value from the beginning. | |
GiuseppeC: 7-Jan-2011 | I have only a couple of request: please consider now the modification to the event system to support multitouch devices and whatever is needed for smooth GUI animation. It is important for further porting on other platform. Also, keep in mind that good documentation is essential to let people use your work. | |
jocko: 8-Jan-2011 | I think Pekr speaks of the docs included in the RMA's gui zip. The format is apparently done to be converted by makedoc2.r | |
Pekr: 8-Jan-2011 | Shadwolf - this is not the right group to discuss advocacy/strategy kind of things. But here's my take: - RMA is a commercial entity, and Robert made it clear enough - they develop GUI to the point, when it will be usefull for their business apps. The chances are, that if it is good for them, it will also be good for others - Robert is a good guy! He pays several top community guys, and - he gives result of such work - FOR FREE! - RMA guys are VERY open, to listen to other's opinion, it is just they will accept only REALISTIC proposals - trying to convince them to change to differet underlying toolkit CAN'T work at this point. Even if such a toolkit would be good time solution, there are no free resources to make such a big change - RT (Carl), plus the community, should be gratefull, to have at least RMA's GUI, if there is not other gui in the spot, and RT itself is not active in that regard. - If I should name at least something what I am not considering so optimal, then it is a bit of a closed nature of development. I mean - I might wrongly understand initial impression of a SCRUM model. I missed the big picture, plus particular reports ... but - ANYTIME I was not lazy to ask, my questions were answered. Anyone but me can do just the same - ask. This is called - communication :-) So much for RMA and their relation to development of R3 GUI .... | |
nve: 8-Jan-2011 | Ok, except that the power of REBOL was that it can run under 40 different OS ! Nowadays, it runs good for R2/View under Windows and MacOS... Linux lots of problems because there's so many version of Linux... And for R3/GUI we have Windows version... and when Windows 8 will be released... not sure it will work. Community has falling down and it is hard with no open source to attrack new developpers... I know host-kit is hybrid open source model... Real question in 2011 is : port language on JVM because every computer and device (except iPhone) has a JVM in order to reach the mass market. Make it popular and then we can found money, people to work on small VM that make the power of Power. | |
Pekr: 8-Jan-2011 | Used MDP to generate docs. Not optimal, but at least something. What I did was: - replaced =image-code by =image - shortened path, as images are just in the same dir as doc - gui-panel-sizing-3.PNG should be renamed to gui-panels-sizing-3.PNG - gui-panels-visibility.PNG is missing | |
shadwolf: 8-Jan-2011 | Pekr native is a pain that's all ... it took already 5 years to do rebol VM version 3 on windows 32 and it's not over and according to the source code of r3-host-kit there is no GUI part in linux or macOS X.. we don't know either if more than the 3 main os will be supported and in what extense. Doing a change on 1 VM means finding a way to do it on all other VM that's why if i remember well along the years R2 was supported on lesser and lesser OS and that's why too the rebol VM source code grow to a point that it was impossible for Carl to maintain it .That was the main justification for the retrofiting of Rebol VM in the rebol 3 project... mean while all the industry changed can you seriously say that java vm is the same now that it was 5 years ago same goes for mono. | |
Cyphre: 14-Jan-2011 | try this: load-gui stylize [red-button: button [facets: [area-color: red]]] view [ red-button button options [area-color: green] button ] I think this wirks just fine no? | |
Pekr: 14-Jan-2011 | The faced block is similar to facets block, but makes them local to each instance of the face. Now, they can be modified without effecting any other faces that are of the same circle style. It is taken from: http://www.rebol.com/r3/docs/gui/styles.html | |
Pekr: 14-Jan-2011 | OK, I will try new version, and see how it goes. I would welcome an example on 'intern, maybe I will find it in sources. Starting to warm-up to new gui :-) | |
Pekr: 15-Jan-2011 | I am still not sure I am comfort with group having different semantics to panel :-( .... trying to do some tests with Carl's demo, and it is going to be pain-in-the a..., to insert returns in there. From the very beginning of the R3 GUI projects my opinion was, that group should be just de-stylised panel (no visual borders), but identical in behaviour ... I hope I will change my mind later in the proces .... | |
Maxim: 15-Jan-2011 | btw Pekr, from an API designer's standpoint, these types of questions are all very good IMHO. they force us to reflect on decisions and, often, trying to do so will either confirm them or with discussion might give new ideas. I'm not part of this gui team, but I'd really like if someone asked pointy questions like this on my stuff. | |
Pekr: 15-Jan-2011 | those come from concrete effort to make Carl's demo translated to the new GUI engine :-) First and second screen is displayed, but make-panel just differs, and options argument does not exist anymore, it also has reverse order of arguments, and does not accept style, but face instead, and so on ... | |
Pekr: 15-Jan-2011 | hmm, I don't know why, but I don't like those long name functions as set-panel-content. I already disliked it in Rugby times. Too much function variants. Sometimes I think, if REBOL does not have something wrong. I thought that set-panel 'param 'value or set-panel/refinement could be a better way, but maybe it is not. I miss some level of better functionality encapsulation from time to time. We can't use set-panel, as it serves for setting of its content ... I probably prefer old-school object panel.method aproach ... that is just a philosophical note, not a complaint to R3 GUI :-) | |
Ladislav: 15-Jan-2011 | E.g. one of the examples in the gui-panels.txt | |
Pekr: 16-Jan-2011 | btw - I expect that you guys surely know what you do, and so far my gui understanding is still minimal :-) But anyway - was there really a need to make make-panel internal? Except for the options block, I found it nice, that you can easily create panel from the stored layout block, just by one function .... | |
Robert: 16-Jan-2011 | Then I found out, that their max size was set to 900 pixels. I asked Carl - why? And he told me, that fields should not be long, or it does not look nice anyway. - This is the main problem I have with VID and the "official" GUI stuff. If I want it that way, I want it. I don't need a framework that makes my life hard. There are zillions of things people want, and others don't like. For commercial apps, we need to deliver what the customer wants, not what we think is best. | |
Robert: 16-Jan-2011 | And, to do this, all parts of the GUI must be accessible and able to describe. Hence, MIN-SIZE & MAX-SIZE make sense on a face level. If I need to specify it, at least I can. | |
Robert: 16-Jan-2011 | Our GUI will not be a toy. It's not for people just starting to play around. R3 needs a full blown commercial & enterprise app enabled GUI framework. Otherwise it will stay a toy no one cares about. | |
Nicolas: 16-Jan-2011 | Content isn't bad, but I think local is more descriptive. http://www.rebol.com/r3/docs/gui/styles.html#section-19 The faced block is similar to facets block, but makes them local to each instance of the face. Now, they can be modified without effecting any other faces that are of the same circle style. | |
Pekr: 17-Jan-2011 | I think that in the new release FACED is really gone. Nicolas points to RT's docs, which imo refer to Carl's GUI, not RMA's one. | |
Pekr: 17-Jan-2011 | OK, I will adapt ... the intention is to make demo working on RMA's GUI. We will see, how it turns out down the road ... I am slow, because I still have little knowledge of GUI itself, pluse I am really not a programmer :-) | |
Pekr: 17-Jan-2011 | Should text style work? text [bold "Toggle button..."] gives me: Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none ** User error: {TO-TEXT - syntax error at: [bold "Toggle button..."] ...} | |
Pekr: 17-Jan-2011 | Got to go - but - is there anything like vpanl alignment? I got first form of demo kind of working (buttons), but the content is aligned to the bottom. Also - pressing buttons does not work so far either: ** GUI ERROR: Cannot parse the GUI dialect at: panel 240.100.80 title Alert grou p doc Button pressed! scroller | |
Pekr: 18-Jan-2011 | Could you try following code? You can eventually replace 'vpanel by 'hpanel [break-after: 1]. With vpanel, it just causes stack overflow, with hpanel, it kind of displays panel, but try to resize the window and see the mes ... REBOL [] do %r3-gui.r3 lay: [ when [load] do [print "Load trigger!"] clicker button "Do" alert "Button pressed!" button "Big Quit Button" maroon options [max-size: 2000x50] quit bar text "Toggle button..." t1: toggle "Toggle" of 'tog button "Set False" set 't1 false button "Set True" set 't1 true toggle "Mirror" attach 't1 toggle "Mutex" of 'tog bar text "Radios and check boxes" radio "Set above toggle on" set 't1 true radio "Set above toggle off" set 't1 false bar check "Checkbox attached to above toggle" attach 't1 ] child: make-face 'vpanel [] set-panel-content child lay view child | |
Pekr: 18-Jan-2011 | hmm, it really seems to be in r3-gui-src.zip ... | |
Pekr: 18-Jan-2011 | ok, then I have maybe messed r3-gui.r3 .... will unpack the latest one ... | |
Pekr: 19-Jan-2011 | http://xidys.com/pekr/rebol/r3-gui-comparison.jpg | |
Robert: 19-Jan-2011 | http://www.rm-asset.com/code/level1/r3-gui/resizing/#sect5 | |
Pekr: 19-Jan-2011 | I use the latest r3-gui.r3 | |
Ladislav: 19-Jan-2011 | (since I was unable to reproduce the problem, I bet it is exactly because I never ran the LOAD-GUI twice) | |
Pekr: 19-Jan-2011 | It works. But it was not enough to just change the view-show.r3 code, and call it after do %r3-gui.r3, as the initial redirection will remain. A bit tricky, as there is no script to build new r3-gui.r3 from sources, and sources are collapsed, but I managed it to change :-) | |
jocko: 23-Jan-2011 | Pekr, any news about porting the Carl's gui demo ? | |
Pekr: 23-Jan-2011 | One thing is clear - it will not be complete port, e.g. fly-in/out effects are not supported when changing the panel content (switch-panel function is not adapted yet). Somy styles are also not adapted to the new GUI, and some are not adapted to the resizing model. I would welcome if RMA would do that basic work. E.g. even something like view [doc "text"] is guggy, and it displays the content twice, etc. | |
Pekr: 25-Jan-2011 | Cyphre - simply put - in a demo I am porting, I am not able to get the subpanel to work - it displays, but don't perform actions. E.g. single button press causes: ** GUI ERROR: Cannot parse the GUI dialect at: panel 240.100.80 title Alert grou p doc Button pressed! scroller | |
Pekr: 25-Jan-2011 | Or I have something wrong in the demo code, not yet fully adapted: view-sub-panel: funct [ index main-pan desc ][ set 'current-panel index set-face desc form pick test-notes index pan: pick test-panels index unless pan [ pan: make-face 'vpanel [columns: 1 content: pick test-blocks index] ; insert-panel-content pan pick test-blocks index poke test-panels index pan ] set-panel-content main-pan pan ; switch-panel main-pan pan 'fly-right ] view [ title "R3 GUI Tests" text (reform ["R3 V" system/version "of" system/build]) bar hgroup [ ; List of test sections: text-list test-sections do [view-sub-panel value main-pan desc] ; Panel for showing test results: vgroup [ desc: text-area "Please read the instructions below." options [ max-size: 2000x40 text-style: 'bold ] main-pan: vpanel [ text "test" ;doc instructions ] options [columns: 1 init-size: 280x380] hgroup [ button "Source" do [ either current-panel [ view-code trim/head mold/only pick test-blocks current-panel ][ request "Note:" "Pick a test first." ] ] button "Halt" leaf close halt button "Quit" maroon quit check "Debug" do [guie/debug: if value [[all]]] check "Remind" guie/remind do [guie/remind: value] ] ] ] ; when [enter] do [ ; if quick-start [ ; if spot: find test-sections quick-start [ ; view-sub-panel index? spot main-pan desc ; for faster testing ; ] ; ] ; ;[request "Alert" instructions] ; ] ] ;[reactors: [[moved [save %win-xy.r face/gob/offset]]]] | |
Pekr: 25-Jan-2011 | We can't easily make 50x50 button for e.g.? With Carl's GUI, it was really easy - button "50x50" 50x50, but with new gui, even if initial size is valid parameter of an option block, the requested size is not prserved, as can be seen by simple: view [button 50x50 "test"] I hope we are not back to nonsense of being more clever than what user wants, limiting the size of a button? | |
Maxim: 25-Jan-2011 | no. having an engine which provides great GUI defaults is essential, but not at the cost of being able to tweak a widget . skins/themes/stylesheets provide usefull defaults, but having access to overide any of this is absolutely necessary. | |
Maxim: 25-Jan-2011 | sorry, but having built "large apps" and for clients, this freedom is very necessary. if you don't use it that will make the gui generally better, but there is always a time when its required and it has to be possible. what VID lacked had nothing to do with styles and looks. it was the fact that everything under it was insufficient at best... layout sucks, event system sucks, dynamicity sucks, no way to switch stylesheets on the fly, no locale, etc. | |
Pekr: 26-Jan-2011 | Henrik - don't even try the old crap on me again :-( The reason why Carl started new GUI was because of Gab's GUI was not all that easy. If I want 50x50 button, don't even dare to dictate me, that I can't easily have it. If I can't, I almost refuse to use such a system period. | |
Pekr: 26-Jan-2011 | This is rudiculous - so you have init-size as an option, yet it is ignored,or totally twisted, in that regard, that only X axis gets adjusted. That simply does NOT work as expected, and if you guys refuse to understand, that the freedom of expression is what ppl are interested in, then you are building completly different GUI. It is supposed to be easily used. | |
Pekr: 26-Jan-2011 | Henrik - I believe you will fail explain technical reason, why it prevents proper skinning. Carl's GUI used skinning, and was able to provide such buttons. That is just stupid limitation imo, and should be removed .... | |
BrianH: 26-Jan-2011 | You have min-size and max-size still, right? To support resizing, you need to support sizing. But that doesn't mean the syntax is the same as in R2's VID or Carl's GUI. | |
BrianH: 26-Jan-2011 | The current design is supposed to allow non-GUI-designer programmers to specify layouts. Even if you are both the layout programmer and the style designer, the work is supposed to be separated. For that matter, a proper layout dialect for the types of apps that the R3 GUI is made for (not games) should be portable to other device form factors, accessible, etc. So if you need to be a theme designer, do it in the theme section of the app, not the layout. And if you need to be picky about the styles, do it in the style section of the app, not the layout. | |
Pekr: 26-Jan-2011 | BrianH: the strange thing is, that different color is actually supported. It was not with Gab's GUI IIRC, that was even more strict. I can imagine the trouble with mateiral system, when you allow simple color override. But - how is button's size influencing or limiting the skin system? It has nothing in common imo with Carl's or other's version imo, it is just one developer applying his idea. How does new system differ to Car's version in that regard? Carl's version was supposed to use skinning too, so? | |
Pekr: 26-Jan-2011 | When I expressed my opinion on Gab's GUI to Carl, I told him, that I miss some aspects from easy of use of VID. I can understand, that when things get more complex, you have to put some limitations here or there. But - it stopped to be a fun. I need a system, which I LIKE to use, which is NOT BORING to use. If I want to use boring business GUI, I can go to Delphi with its boring the same buttons, and I even believe, that in the end it is Delhi, which allows me to shape the button WHATEVER size I want. | |
Pekr: 26-Jan-2011 | The current design is supposed to allow non-GUI-designer programmers to specify layout - no, it is apparently not. Layout user wants 50x50 button, and can't have it. | |
Pekr: 26-Jan-2011 | The worst thing we can do is to let the option there, while not acting upon the override. So - if we REALLY want button's size to be fixed, the option really has to be removed, and it has to fail on GUI parse ... | |
Pekr: 26-Jan-2011 | From Max: "I don't want to post stuff from other engines here since its not a comparison game, but I've used many APIs from prbably 20 different dev platforms, and everytime I use one which has an "unwielding" ideology where you can't modify things to make them do what you want... as a user, I get frustrated and I just look for something else to do and/or work on." And I say - Amen. Set it into stone, and you might wonder in the end, why you have no following. It is exactly the same reason most ppl are not able to understand, that no matter how logical it is to have the skin done as a last, R3 GUI did not get any following, because of the first look experience simply get's users not interested at all. And it was said here not jus by me. You can protest, but that is all you can do about it. | |
Henrik: 26-Jan-2011 | Henrik - don't even try the old crap on me again :-( The reason why Carl started new GUI was because of Gab's GUI was not all that easy. Henrik - I believe you will fail explain technical reason, why it prevents proper skinning An exact failure in understanding why face hacking is not welcome. Gab's GUI was not easy due to a number of layers needed to describe the look and feel separately, as well as requiring you to handle GOBs manually. But it supported applying proper meaning of styles, because Gabriele had the same goal as me. Carls does too and RM Asset's does this even more. We just have to take advantage of it. Have you never had to fix someone's MS Word document, so that TOC generation, links, indexes, headlines, etc. could be understood by Word, because they had resorted to manipulating the words directly with colors and style, instead of using Word's style system? This is exactly the same problem. You will be teaching beginners that their layouts won't scale properly for exactly the same reasons. Many people therefore never really learn to create correctly formatted Word documents. | |
Pekr: 26-Jan-2011 | that's rather easy, but not easy enough. Still a different concept. You guys act like button is a text, and it is not :-) If I will have whole screen of the same buttons, I might use stylize, e.g. for the calculator widget, as an example, becuase constantly repeat button 30x30 is not convenient for me. But it still does not mean, that ocassionally wanting to have button a bit differently sized does a damage. Do you think users are crazy and will make each button differently sized, just because they can? :-) (Well, as for MS Word files, some users are able to create completly twisted texts, bu still - that is a text, difficult to restyle ... while we are talking GUI here. | |
Pekr: 26-Jan-2011 | Now if I would think about comparing R3 GUI to html/css, then I am not able to compare it in my head, but doesn't inline CSS allow to override class setting? | |
Pekr: 26-Jan-2011 | Also - one question to the text style - in Carl's GUI (at least that is my undersanding from the demo) it accepted the block of rich-text dialect? That is not so with R3 GUI, probably an intention? | |
Pekr: 26-Jan-2011 | Henrik - there's no why imo yet :-) From my POV it is very preliminary, and I would orientiate myself to: - adapting existing styles to new R3 GUI engine - adding styles most commercial guis will need - table, tree, tabs - be sure all styles behave in a platform compatible way (especially area) - reskinning/respacing the elements - add support for ctrl-tab at low level to switch between the tabs - fix all hard R3 crashes later: - add support for accelerator keys, but visually, and in the code (requires rich-text, most probably autogenerated, to underline the letter, but it could be done a different way to - e.g. displaying boxes with accelerator keys upon the styles and Alt key press) - improve the text quality, that is NOT ACCEPTABLE for the 21st century! even later: - add some funky styles as Doc to make documentations, wikis, etc. :-) - HW acceleration support where possible. | |
BrianH: 26-Jan-2011 | Does a style have to have a max-size? I am worried about scaling to large screens. I remember that was a weakness of Carl's GUI. I know you guys changed the resizing algorithm, but I didn't catch what the new algorithm was. | |
BrianH: 26-Jan-2011 | I got that (was typing while you posted that). Second question: good, I didn't like that about Carl's GUI. | |
Pekr: 26-Jan-2011 | Cyphre - you misinterpret me a bit - on one hand, yes, I think those are usefull to have for occassional GUI hackers, for the fun factor. If user is an idiot, and wants to define each button differently, so be it - there is analogy with inline CSS style. But if we allow it, the behaviour should deliver it ... | |
Henrik: 26-Jan-2011 | Kaj, well, Pekr took up the challenge to rebuild the GUI demo (to great effect as we can see), so I don't think it hurts to simply ask if there is interest in the community to perform certain tasks. | |
Oldes: 26-Jan-2011 | http://issue.cc/r3/1837<- maybe you should add the GUI project to CC ASAP. | |
GiuseppeC: 26-Jan-2011 | Been away for a while. As the GUI documentation been produced ? | |
Maxim: 27-Jan-2011 | when a concept of default size is there, that is usually what you want the pair to be. when it goes beyon min or max bounds, usually you want to push these to at least match the default size... the developper is expressly asking for an adjustment to the default. the thing is that when a widget is in an auto-resizing layout, asking for 100x100 might not actually give you that size, because all the widgets are subject to the layout in which they are displayed. in row/columns, you will be subject to equalizing other lateral sizes in the list and may be given more space in the longitudinal size, such that in fact, your button may be larger than what you asked for. the only way to force a 100x100 button is for the gui to support static sizing within a dynamic layout, or support max-size and set it to the exact same as default size effectively making it a static sized button. | |
Henrik: 27-Jan-2011 | it may have scrolled out of the way, but there is an R3 GUI project in Curecode now. | |
Andreas: 2-Feb-2011 | Not that I understand anything about GUI implementation, but font rendering sounds like a mere technicality for me. | |
james_nak: 3-Feb-2011 | So you are referring to what happens when the faces are first rendered or when a user manipulates the GUI manually or both? | |
Oldes: 3-Feb-2011 | I personally don't like any automatic sizing... when I design a gui, I know exactly how I want the components large with pixel precision. | |
Ladislav: 4-Feb-2011 | %trunk/r3-gui/source/panel-make.r3 and %panel-sizing.r3 committed. Changes: - SPACING initialization moved to the INIT-PANEL function | |
Pekr: 4-Feb-2011 | I still miss simple style to group things. I always wanted a panel, with border, gradient, etc., but then also exactly the same style, but with zero visuals ... IIRC, in Carl's GUI, it was panel vs group - except the fact, that it group used opposite coordinate system - very unwise btw In RMA's GUI, if I am not mistaken, group is internally completly different - it is here for those users, used to VID2 - you have to use RETURN keyword, it does not align in grid cells, etc. So - how do I easily define inline style, which removes panel visuals? I don't want to create new style for such a simple and usefull thing. And I start to think, that 'group style is here just to confuse users ... | |
Ladislav: 4-Feb-2011 | Pekr: looks, that you will get more examples from Cyphre, who promised to pack some and make them available. So, I am afraid, that at the time being, you only have the examples from the gui-panels.html text available. | |
GrahamC: 6-Feb-2011 | I haven't kept up .. how does the GUI event model work ... is it comparable to DOM 2 event handling? | |
GrahamC: 7-Feb-2011 | is make event! attached to a particular GUI object? | |
Pekr: 7-Feb-2011 | graham - the gui has many nice features/handlers. There are things like do-face, do-style, not sure if cause-action is there (IIRC it was part of Gab's GUI) | |
Pekr: 12-Feb-2011 | I am looking for the GUI for massess, not for academic stuff ... |
2501 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 24 | 25 | [26] | 27 | 28 | 29 |