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: 601 end: 700]
world-name: r3wp
Group: All ... except covered in other channels [web-public] | ||
James: 23-Jan-2005 | Hey, I found a really neat GUI interface in the Picasa photo organizer program from Google. (http://www.google.com/downloads/) If you download it or already have it, just click the "Timeline" button near the top of the screen. I think it would be really neat if someone could make a REBOL clone of that screen. | |
Guest: 15-Feb-2005 | I like the admin-gui but on my developer machine I always use apache. | |
BrianH: 9-Apr-2005 | There's a Free clone of Delphi out there called Free Pascal with a GUI-alike called Lazarus, but I doubt its COM support is that good, and they can't do the GUI as well because the best features of Delphi's GUI are patented by Borland. I think Microsoft licenses those patents for Visual Studio. | |
Volker: 17-Jan-2006 | Had to search my hd a bit, long not used. found it in a few places, uploaded one here: http://polly.rebol.it/test/test/museum/diff/gui/ | |
Gabriele: 12-Mar-2006 | it's the same difference as having view or using whatever the os provides for the gui | |
Pekr: 12-Mar-2006 | I am not sure - even with rebol (core), if you want gui, you have to download View :-) I am not against kind of standardising upon good modules, but not sure if I want one big exe with everythign inside. :-) | |
Ashley: 12-Mar-2006 | Would you really want a non-native GUI, with every call to / from it going via slow [in relative terms] routine! APIs? I agree that having one *huge* exe that does 100% of what *everyone* wants but only has 20% of it's functionality used by the average coder is a bad thing. The problem is defining what constitutes huge and what functionality is needed by most coders. Here are some typical components: Graphics Sound Networking Maths Encryption Data storage Installer Registry access Library access Which should be built-in? Which should be loadable modules? Is your preference going to be the same as mine? These are not easy design questions. | |
Pekr: 12-Mar-2006 | Every OS is done in modular way for a reason - give a break please - one of the best OS designs I looked into a bit imo is QNX - even something like event system for gui is external to kernel - in fact, the kernel is really small and nearly everything is module. Aren't we talking real-time OS here? | |
Group: !AltME ... Discussion about AltME [web-public] | ||
Anton: 9-Jan-2007 | I say this to myself occasionally. It means "build more GUI, then things will be easier". | |
Anton: 9-Jan-2007 | Qtask with a rebol front-end requires a fairly advanced rebol GUI. | |
Gabriele: 24-Feb-2007 | denismx: the password is saved when it is asked via the gui. so it's not asking you because you have set it already :) | |
BrianH: 23-Mar-2008 | The bandwidth is fine - it's an architectural bug. AltME shouldn't block on retrieval at all. Any blocking should happen after the message has been retrieved, just long enough to post the message to the GUI, no more than a millisecond. | |
Graham: 17-Jul-2008 | ICarii will take this information so he can build a better GUI :) | |
amacleod: 19-Jan-2009 | I got it to work on a different port. On windows you do not seem to need to declare the port like on linux. Windows opens multiple worlds from the gui | |
Maxim: 30-May-2009 | the post dropping is the # 1 bug in Atlme. lets just prevent it from flushing the text area before it receives the post, and at least we won't be frustrated. the clearing of the view when a connection is dropped is also EXTREMELY annoying... you have to click back on the group, and it clears te "unread" bg color and resets the scrollbar. these can be changed without any real coding change required... its just preventing a few things in the gui/network event handling. maybe we could just the bg of the Network status to RED, that accomplishes the same goal, but doesn't turn us into enraged altme users. | |
Pekr: 31-Aug-2009 | Will be done in R3. R3 Chat system is said to use similarities to AltME system, just more robust. It just needs GUI client ... | |
Maxim: 20-Jan-2010 | there is one issue which is SO ANNOYING, I sometimes close altme before throwing out my computer by the window. when the display becomes a blue screen if the client loses its connection with the server... this is both useless and highly irritating, cause when the world re-connects (99% of the time on its own) you have to re-click on the group, which looses the "unread msg" beige highlight. it also forces you to have to re-click on the text entry with the mouse. when your internet connection is buggy or a server has troubles... disconnection may happen repetitively every few seconds. the blue just makes altme unusable in a situation where it should just stall, until a new message is sent. when a world disconnects, it should just change the color of something or put a label somewhere obvious in red color... but don't touch the GUI's functionality.... please | |
Sunanda: 27-Jan-2010 | As Graham says, the REBOL.org archive does cover the network shemes group: http://www.rebol.org/aga-display-posts.r?post=r3wp763x1814 But not the REBOL3 GUI group -- Brian did not set that to [web-public] -- if he his happy for it to be [web-public] we can easily add it to the archive. Please report rebol.net problems via RAMBO for best results. | |
Group: RAMBO ... The REBOL bug and enhancement database [web-public] | ||
Anton: 7-Dec-2006 | (The script I was working on which led to this bug was this one: do read http://anton.wildit.net.au/rebol/gui/demo-future-progress.r | |
Volker: 17-May-2007 | i had such a problem with massive gui and async. Workarounded the following way: recycle is off permanently. there is a thread (do-every or such) which checks how much memory was allocated and when it is to much it recycled. crashing stopped. | |
Anton: 19-Jun-2007 | First run View 2.7.5.3.1 and do this: site: select load-thru http://www.rebol.net/reb/index.r[folder "Anton"] clear find site %index.r load-thru/update site/patch/caret-to-offset-patch.r Do the main demo, showing patched AREA: do-thru site/patch/demo-caret-to-offset-patch.r Three patched styles; AREA, FIELD, INFO: do-thru site/gui/demo-area.r do-thru site/gui/demo-field.r do-thru site/gui/demo-info.r The initial experimental testing script: do-thru site/patch/test-caret-to-offset-patch.r | |
GrahamC: 31-Oct-2010 | as cmd is a non gui product | |
Group: Core ... Discuss core issues [web-public] | ||
Volker: 28-Jan-2006 | they have a website and there are some binaries. on linux i found a few in my distor, the second worked nearly automatic, after editing something. for windows i guess there is something more comfortable. binaries makes sense because they are in my login-script :) I guess windows could pop up browser too, as gui is closer coupled to scripting? | |
Jarod: 27-Mar-2006 | that is my primary need or want to use rebol for, is to manipulate text. I like perl, but love rebol's small footprint, if it can give me the same power of perl in a much smaller package, with a gui, that is all the better. I could potentially replace access and a lot of proprietary tools with a small rebol view application. | |
Gabriele: 16-May-2006 | the BCC header field is a field used by mail clients to let users type addresses that will *not* be included in the header. it is, basically, a user interface. back at the time mail clients did not have a gui, and just processed mail from a file or by letting you type them on the terminal | |
Gabriele: 16-May-2006 | graham: that's a good idea and the desktop already has something like that, a gui that lets you type to subject and message. we could just add bcc and cc | |
Group: View ... discuss view related issues [web-public] | ||
Ashley: 27-Apr-2005 | http://www.rebol.cz/~cyphre/trans-gui.r http://www.rebol.cz/~cyphre/trans-win.r | |
shadwolf: 15-May-2005 | I have a proble to submit to VID GURUS... My problem is the following I writing a click and scroll algorithm. (ike In MDP-GUI you have the floating toc window panel when you click on on of the title shows in the floating toc window the visualisation scroll to the related title. But this show the title on the middle of the screen and no on the top of the visualisation pane. The forumal I apply is sld/data: related-offet/y / sub-pane-visualisation/size/y and then I apply the scroll function. What must be the for mula to have always the related title in the visualisation pane on the top part of the screen | |
shadwolf: 12-Jun-2005 | When I was working on MDP-GUI some month ago basing me on the very first intent of ashley we were using a layout compositor (and a layout call) to renderize the docuement view than Ashley comes with a design based on pre contructed minimal enherited face system and using only show the gain inthe do view area rendendering process was about 300 %:) | |
Henrik: 12-Jun-2005 | and easier if you "only" need a tradition GUI ? | |
shadwolf: 12-Jun-2005 | pekr make the try take a very frirst version of MDP-GUI and take the lastest You will be suprise ;) | |
james_nak: 17-Jun-2005 | I was happy to see "request-dir" as I was updating a 6-year old tool that I use off and on. I was wondering if, for sake of continuity, there is a "windows" gui for this? | |
Gabriele: 25-Jun-2005 | it's not that VID is not good, it's that its purpose was not to be the ultimate gui framework, but more of an example of what you can do; indeed, now we have RebGUI too. but, the problem with that way of thinking, is that in practice developers need a solid base to start. so it's much better for everyone to provide it. | |
Volker: 25-Jun-2005 | . vid2: Has somebody ever tried oberon/blackbox-builder? Thats the kind of layouting i like. They use text with "active-x-controls" inside (only better and simpler ;) . blackbox can do really windows-style guis that way. then while developing you can mark part of that gui and just copypaste it somewhere else. gives a lot easier control than typical gui-builders IMHO. | |
Anton: 12-Jul-2005 | do http://www.lexicon.net/antonr/rebol/gui/demo-rotate-knob.r | |
Anton: 29-Jul-2005 | Check out this old script. It's a bit messy, but the example works. http://www.lexicon.net/antonr/rebol/gui/transparent-events.r | |
Anton: 2-Aug-2005 | site: select load-thru http://www.reboltech.com/index.r[folder "Anton"] clear find site %index.r load-thru/update site/gui/rotate-knob.r load-thru/update site/gui/demo-rotate-knob.r do-thru site/gui/demo-rotate-knob.r | |
[unknown: 10]: 2-Aug-2005 | IIm not often complaining but Im getting a bit disapointed about this.....Well anyway.. Im killing GUI time here with some alternatives...Hope RT do thier best.. | |
Anton: 10-Aug-2005 | do http://www.lexicon.net/antonr/rebol/gui/iterated/list-of-checks.r | |
Anton: 10-Aug-2005 | do http://www.lexicon.net/antonr/rebol/gui/iterated/list-of-toggles.r | |
[unknown: 10]: 13-Aug-2005 | Does anyone have a good performance with Rebol/view and i.e. Hummingbird Remote Desktop? Seems Rebol is quiet slow here where GTK GUI is flashing over my screen my Rebol gui's do need far more time.. Any hint of tip is welcome.. | |
Group: Parse ... Discussion of PARSE dialect [web-public] | ||
BrianH: 5-Nov-2008 | These changes to PARSE are another example of changes to the R3 core happening as a side effect of the new GUI work :) | |
BrianH: 8-Nov-2008 | I am the editor of the PARSE proposals. It was decided that I perform this role because Carl is focused on the GUI work right now and someone qualified had to do it. With Carl busy and Ladislav not here, I am the one left who has the most background in parsing and the most understanding of what can be done efficiently and what can't. When the PARSE REPs of old were discussed, I was right there in the conversation and the originator of about half of them, mostly based on my experience with other parsers and parser generators. Because of this I am well aware of the original motivation behind them, and have had many years to think them through. It's just head start, really. I am also the author of the current implementation of COLLECT and KEEP, based on Gabriele's original idea, which was a really great idea. It is also really limited. Collecting information and building data structures out of it is the basic function that programming languages do, and something that REBOL is really good at. I am not in any way denigrating the importance of building data structures. I certainly did not mean to imply that your appreciation of that important task was in any way less important. The role of an editor is not just to collect proposals, but to make sure they fit with the overall goal of the project. This sometimes means rejecting proposals, or reshaping them. This is not a role that I am sorry about - someone has to do it to make our tool better. We are not Perl, this is not anything goes, we actually try to make the best decisions here. I hate to seem the bad guy sometimes, but someone has to do it :( PARSE is a portion of REBOL that is dedicated to a particular role. It recognizes patterns in data, extracts some of the data, and then calls out to the DO dialect to do something with the data. It doesn't really do anything to the data itself - everything happens in the DO dialect code in the parens. It is fairly simple really, and from carefully designed simplicity it gets a heck of a lot of power and speed. That is its strength. The thing that a lot of people don't remember when making improvements to a dialect like PARSE is that PARSE is only one part of REBOL. If something doesn't go into PARSE, it can go into another part of REBOL. We have to consider the language as a whole when we are doing things like this. Here is the overall rationale for the PARSE dialect proposals: - All new features need to be simple to explain and use, and fast at runtime. - A good feature would be one of these: - An extremely powerful enhancement of PARSE's language recognition. - A fix to a design flaw in an existing feature, or a compatibility fix. - A serious improvement to a sufficiently common use case, or common error. The reason I didn't want to put COLLECT and KEEP into PARSE is because it is a small part of a much bigger problem that really needs a lot of flexibility. Different structure collection and building situations require different behavior. It just so happens that the DO dialect is much better suited to solving this particular problem than the PARSE dialect is. Remember, PARSE is a native dialect, and as such is rather fixed. There are some PARSE proposals that make parse actually do something with the data itself: CHANGE, INSERT and REMOVE. We were very careful when we designed those proposals. In particular, we wanted to provide the bare minimum that would be necessary to handle some very common idioms that are usually done wrong, even by the best PARSE programmers. Sometimes we add stuff into REBOL that is just there to solve a commonly messed up problem, so that a well debugged solution would be there for people to choose instead of trying to solve it again themselves, badly. (This is why the MOVE function got added to R3 and 2.7.6, btw.) Even with that justification those features might not make it into PARSE because they change the role of PARSE from recognition to modification. I have high hopes, though. Another proposal that might not make it into PARSE is RETURN. RETURN is another ease-of-use addition. In particular, the thing it makes easy is stopping the parse in the middle to return some recognized information. However, it changes the return characteristics of PARSE in ways that may have unpredictable results, and may not have enough benefit. The proposal that has a better chance of making it is BREAK/return, though I'd like to see both (we can hope, right?). Most of the REPs from Gabriele's doc have been covered. Most of them have been changed because we have had time in the last several years to give them some thought; the only unchanged ones are NOT and FAIL, so far. Some have been rejected because they just weren't going to work at all (8 and 12). THROW and DO are still under discussion - the proposals won't work as is, but the ideas behind them have merit. The rest have been debated and changed into good proposals. Note that the DO proposal would be rejected outright for R2, but R3's changes to word binding make it possible to make it safe (as figured out during a conversation with Anton this evening). There are other features that are not really changes to the PARSE dialect, and so are out of scope for these proposals. That doesn't mean that they won't be implemented, just that they are a separate subject. That includes delimiter parsing (sorry, Petr), tracing (sorry, Henrik), REBOL language syntax (sorry, Graham), and port parsing (sorry, Steeve, Anton, Doc, Tomc, et al). If it makes you feel better, while discussing the subject with Anton here I figured out a way to do port parsing with the R3 port model (it wouldn't work with the R2 port model). I will bring these all up with Carl when it comes to that. I hope that this makes the situation and my position on the subject clearer. I'm sorry for any misunderstandings that arose during this process. | |
BrianH: 8-Nov-2008 | Right now the driving force is building better dialects - Carl needs it for the new GUI dialects. The data parsing improvements have just accumulated over the years and now seems like as good a time as any, especially because of the R3 compatibility break. | |
BrianH: 10-Nov-2008 | Carl is focussed on the GUI stuff right now, and his feedback is needed since he will be using the feature for that. | |
BrianH: 12-Nov-2008 | Cyphre is a member of the development world for the new GUI. | |
Group: Syllable ... The free desktop and server operating system family [web-public] | ||
Kaj: 24-Aug-2007 | Server currently doesn't have the Syllable GUI yet, but it will come | |
Graham: 6-Oct-2007 | When is the GUI due ? | |
Graham: 6-Oct-2007 | I'd consider using it as a virtualisation platform, but I guess I'd wait till a GUI was wrapped around at least the installation | |
Robert: 18-Dec-2007 | I mean, on the server I just need a text interface and no GUI frills. Just lean and mean machine. | |
Graham: 15-Sep-2008 | to make sure the mouse, and clock work and the video too I think .. though that's not so necessary in a non-gui environment | |
Graham: 18-Sep-2008 | so, no gui then? | |
Kaj: 18-Sep-2008 | Syllable GUI on Desktop, maybe a remote REBOL GUI on Server | |
Graham: 18-Sep-2008 | A rebol gui thru ssh to the server? | |
Kaj: 2-Sep-2010 | For example, the first goal for a graphical server was to port the Syllable Desktop GUI to Server, but that project is stalled for the moment being because the developer is gone | |
Evgeniy Philippov: 12-Jan-2012 | I've installed Syllable Desktop 0.6.6. Didn't run my nvidia card so I switched to vesa mode. I didn't find my PS/2 Defender mouse, and navigation over GUI elements is degraded when only keyboard is used (underimplemented)? I can provide any details about my hardware. The primary problem at question is a mouse. | |
Evgeniy Philippov: 13-Jan-2012 | Kaj: BTW Congratulations on achieving a fast GUI at the OS! Even Oberon/A2 GUI is slower---though A2 uses bigger screen resolution. | |
Group: !RebGUI ... A lightweight alternative to VID [web-public] | ||
Graham: 2-Nov-2005 | I'm sure it is, but that defeats the purpose of rebgui which is to build a complete gui toolkit without having to know the internals. | |
Ashley: 9-Nov-2005 | CTX-REBGUI/COLORS is an object of value: window tuple! 236.233.216 widget tuple! 244.243.238 edge tuple! 127.157.185 edit tuple! 255.255.255 over tuple! 255.205.40 menu tuple! 49.106.197 btn-up tuple! 200.214.251 btn-down tuple! 216.232.255 btn-text tuple! 77.97.133 CTX-REBGUI/EDIT is an object of value: ... tabbed block! length: 5 hilight-on-focus block! length: 2 caret-on-focus block! length: 4 action-on-enter block! length: 3 ... ctx-rebgui/widgets/set-sizes unit-size font-size Plus many widgets have various option flags to control some aspect of their behavior. Probably not skinning in the true sense but enough to change basic scale, colors and behaviors to cover the major use cases as they have been presented to me thus far. Skinning that lets you change "look & feel" to the extent that the GUI can mimic native Windows, OSX, C64, etc could be done but at what price in complexity and delivery time? And what percentage of folks would just stick with the default look & feel anyway. Another way of saying this is to ask whether it is a good idea to put 80% of your effort into satisfying the needs of 5% of your user-base? | |
Ashley: 10-Nov-2005 | Right at the beginning of RebGUI I asked if anyone had good pointers to a consistent graphical style that we could follow (other than WindowsXP, Mac OSX, KDE, etc) ... in the ensuing silence I chose to go what I'm familiar with, XP. I'm still keen to have a modern looking REBOL style that doesn't look too out of place on Windows, Mac or Linux; but I'm not a gfx guy. Jaime's BEER interface (the GUI config front-end) is about the best I've seen far. | |
Graham: 10-Nov-2005 | I've had good feedback on the GUI for my RebGUI application. | |
Volker: 10-Nov-2005 | Overlooked that gui-interface for beer. Where is it? | |
Geomol: 10-Nov-2005 | Making the GUI look right and not just a copy of something else is tricky. I often think about it. I also had to deside with Canvas, both for the tool panel and the requesters. I went with a very basic, clean style for the requesters, maybe even a bit boring. I see two needs. One is for 'normal' application like business application, where the GUI shouldn't for any sake come in the way. A basic, clean look is needed for that. The other is 'special' application, that would benefit from something more eye-candy like. Examples are a visual remote control, or a music player. | |
Geomol: 10-Nov-2005 | I'm wondering, if users on the different platforms, that REBOL runs on, would find it very strange to use an application, that doesn't use the normal GUI look for that platform. I remember some guy (a developer, I think) many years ago, that would trash an application immediately, if it didn't use the OS own GUI. | |
Geomol: 10-Nov-2005 | With REBOL, we have options. We can make our GUI look exactly like the host OS (maybe even read the system files to see, what theme is selected), or we can build our own, maybe better GUI. | |
Maxim: 13-Nov-2005 | The fundamental thing which makes one GUI better than others is consistency. period. design is all about making the looks and feel work for target a target audience, but if its inconsistent accross the experience, then its instantly unusable for anyone. . | |
Chris: 16-Nov-2005 | I am inclined to agree that consistency is important in GUI design (imo. down to the last detail, it reflects competency), but *the* most important thing is that form meets function, and a part of this is selecting the best possible visual metaphor for the task at hand. While widgets are a means to this end, it's all too easy to overuse them. | |
Chris: 16-Nov-2005 | I've thought much lately about the difficulty in introducing a third-party style into any given OS environment (which we as cross-platform developers must consider short of using native libraries) and it is difficult. The subtleties of eg. OS X and WinXP are far different, so is there a happy medium? I'd like to think so, but having tried /View on OS X, I'm not so sure that my previous attempts at platform-neutral GUI style are as successful as they could have been (though anti-aliased fonts may be a key missing feature). | |
Robert: 17-Nov-2005 | Look & Feel: Getting close to OS look but still let it look different is a good idea. Users won't expect exact behaviour. The GUI must be simple to use. That's it. Tooltips are IMO a very good quick-and-dirty help-feature. | |
Volker: 19-Nov-2005 | About gui-look: How about mimicing amiga? | |
Graham: 19-Nov-2005 | How about using the new Canvas GUI images ? | |
Graham: 4-Dec-2005 | As for the GUI issues, I am confident that Ashley and contributors will fix those issues and so I have released it as is. I don't resize anyway. | |
shadwolf: 28-Dec-2005 | VID editing system is all not not natural ... the caret system is the most awfull thing i saw this far on rebol and that 's a pitty because it limitate so mutch inventivity (well in fact ... yes and not ... i played a lot with caret sytem when i as working on MDP-GUI Some hard things are relatively easy to make like flags insertion to born a sleected piece of text and some easy things are hard to do like keeping the selection on the selected text and not on the begin inserted flag ...) | |
Group: rebcode ... Rebcode discussion [web-public] | ||
Henrik: 15-May-2007 | Gabriele, are you planning to follow up on the design document you posted when we talked R3 GUI design? | |
Oldes: 15-May-2007 | I'm sure I don't want VID improvements before of rebcode.... I want CORE with rebcode first... And I really hope that some release will not be postponed just because there is no new tree-list GUI or something else | |
Group: !REBOL3-OLD1 ... [web-public] | ||
Pekr: 7-Jun-2006 | but that is not the point. I just first could not follow, how they work with widgets, and then I found out - they have separated code and widget definitions. At first it looks strange .... it is like having 'feel(s) , event maintanance, app logic, without seeing what actually you are working with. But I do understand, why they keep widget defs outside in external file, which is kind of simple (as VID is), with static positioning - it is very easy to import to visual GUI builder .... | |
Henrik: 7-Jun-2006 | widgets and their functionality are defined in .nib files for a cocoa program. this is because much of the binding between the widgets and the code is created during runtime. this is also why Interface Builder is able to create much of the initial functionality for a Cocoa GUI, just by defining attributes to widgets and let you test the interface to a fairly high level without compiling any code. | |
Henrik: 31-Jul-2006 | it would also help if the community could do a little bit. GUI Design for example didn't have to stop, just because Carl goes to France. | |
Group: Postscript ... Emitting Postscript from REBOL [web-public] | ||
Henrik: 24-Jun-2008 | Geomol, I built a printer abstraction system called system-print for my apps. It's not finished, but for what it does it works sort of OK. You can choose printing method via a GUI and it auto-detects Ghostscript and uses it if necessary. | |
Henrik: 8-Feb-2009 | I'm still working on my VID->Postscript thing. I will need it for work on a paper layout GUI later this month, so there will be some progress there. | |
Group: !Cheyenne ... Discussions about the Cheyenne Web Server [web-public] | ||
Robert: 16-May-2009 | A bit OT but Lad and I started a test-dialect for RebGUI. You could send CLICK to GUI objects etc. and compare results and state, make screenshots of something was wrong etc. | |
Janko: 16-May-2009 | Robert what you describe even if for GUI app sounds somewhat similar too.. I also take screenshots for example , and I also need some methods to chech and compare the state of app , that is still totally missing (and many other things) | |
Robert: 16-May-2009 | you reference the CONTEXT the test should be executed in. Then you can use all GUI word. Using set-word! sets the GUI widget to the value, state etc. (the dialect makes the most useful setting). You can press widgets, check values in widgets (fields, tables, check, ...) You can even use different paths depending on results. | |
Maxim: 21-May-2009 | for my part, when R3 goes open, I'll be integrating liquid-paint with OpenGL asap... which will completely alleviate my need for /view. we will have a 3D native GUI :-) | |
Pekr: 22-May-2009 | BrianH: I think that what Doc means by Windows console is R2 kind of console, not that ugly black monster Windows offers you by default :-) There was lots of talk about the console topic and we imo need both - system default one, for admins, and GUI based one, for normal users. But GUI console could be created using View, as Cyphre showed, even in R2 it was nicely usable ... | |
BrianH: 22-May-2009 | Yeah, the intention is that a GUI console will be written in REBOL, part of the community-created, open-source portion. Then you can use or adapt the console for your own apps as well if you like. How about having RConsole being implemented with that? :) Right now the GUI doesn't have good-enough Unicode support to make the console yet, so the GUI console will have to wait for the release of the host code (the current priority), and the subsequent resumption of the GUI work. | |
Maxim: 24-May-2009 | cheyenne-admin also has a *VERY* nice GUI, using GLayout. | |
Maxim: 24-May-2009 | Note this is a linux server-side only tool (currently). currently: -remote browing of files in a gui. -uploading/downloading any files to/from the webserver -running command-lines remotely soon: -chmoding remote files -handling webserver start/stop/restart remotely. -more as time goes by. | |
Dockimbel: 20-Jun-2009 | I hate Apache config file. Because I hate having to read tons of docs to just "switch on" some app. Cheyenne's config file has never been designed to copy the Apache way, nor to be used by average end user. It's just a placeholder waiting to be replaced by a builtin web GUI allowing a simple, fast and straightforward way to manage the server. That has been the plan since the beginning and one of the main motivation for building Cheyenne. Unfortunately, I never had the required time to complete that goal yet, so I'm stuck with that, and that's also why Cheyenne is still at 0.9.x. | |
Dockimbel: 20-Jun-2009 | Documentation can be replaced by a well designed GUI. | |
Dockimbel: 20-Jun-2009 | The config GUI is supposed to be remotely accessible (using authentication). | |
Maxim: 20-Jun-2009 | if the config GUI is web based... then it relies on the server actually working... but I'm not trying to argue with you, just pointing out the fact that server configuration is usually much better handled in text and I think many admins prefer it. the fact that everything in windows is GUI based is the most annoying aspect about it. | |
Dockimbel: 20-Jun-2009 | Well, I always thought that GUI was an improvement other text files. Cheyenne is suppose to work out of the box with a default config file. The admin web UI would be reacheable with http://server-ip/admin/ (just an example). | |
Maxim: 20-Jun-2009 | I have a generic configuration managing library... the documentation is directly embeded in the configuration engine... if you save out the config or print it on screen, you have all the docs right there with it. if you build a gui which uses the configuration data, you can also pull out the text from it. maybe that is what should be done.... allow string types within the config dialect (and store it appropriately). then you/we could easily build tools using that info directly. | |
Dockimbel: 20-Jun-2009 | Embedding docs that can be extracted for a GUI is a good idea. | |
Maxim: 20-Jun-2009 | this being said, I understand the appeal for GUI-based configs, but most power users are much more effective with raw data than having to fiddle with a screen hiding the data. | |
Dockimbel: 20-Jun-2009 | screen hiding the data you're already supposing that the admin GUI will be badly designed...I'm not talking about doing a Webmin clone (this is the typical example of *bad* UI design, IMHO). | |
Maxim: 20-Jun-2009 | as long as the config GUI is only a tool over the files, and it doesn't overwrite the files automatically, I won't complain :-) | |
Maxim: 20-Jun-2009 | as a point of fact, it is very possible that some modules (like remark) will require stuff to be setup which is hard to simulate through a gui. managing a system of nested parameters and list is very complex to handle programatically. | |
Maxim: 20-Jun-2009 | I'm adding words which are commands within remarks' module using the do variant of config definition... this allows me to grow a config by calling the same command multiple times.... this would be very unweildy to implement any other way (but not impossible)... maybe a function-based api could allow us to "hook" into the GUI but its pretty hard to cover all possibilities in any case... anhow... back to modulating remark. |
601 / 2867 | 1 | 2 | 3 | 4 | 5 | 6 | [7] | 8 | 9 | ... | 25 | 26 | 27 | 28 | 29 |