New GUI
BlitzMax Forums/BlitzMax Programming/New GUI
| ||
| I am working on a new cross-platform windowing and GUI system to replace MaxGUI, along with a MaxGUI driver. This will allow MaxGUI programs to be recompiled with no code changes, using the new GUI. Each widget is controlled with a Lua script that handles events and drawing. To skin the GUI, just make a copy of the script and replace the drawing code with your own. The system uses GDIPlus, X11, and Cocoa for drawing. It does not use an OpenGL rendering context. The GUI can be set to any scale for high-DPI displays. I think the second video is rendered at 200% resolution. |
| ||
| Sounds interesting. So you are managing box margins gutter layout alignment palette etc. yourself? Do you plan to use scintilla for text? |
| ||
| Looking good. For a consistant look of a cross platform app, this is crutial! |
| ||
| So you are managing box margins gutter layout alignment palette etc. yourself? Do you plan to use scintilla for text? Yes, everything is done from scratch. The partial window refresh is some of the hardest stuff. You have to be careful to only redraw the stuff that changes. I am not sure yet if I will use Scintilla or not. My text field control could be made into a full text area with a little more work, and it's only 400 lines of Lua code. So maybe a finished text editor would be <1000 lines, which would be a lot more compact than Scintilla. You can see in the second video the text field behavior is quite advanced. |
| ||
| I assume code lines will rapidly grow once you add convenience functionality. - code folding - gutter lines - word wrapping - Ctrl+left/right (word skipping) - syntax highlighting / font/display format (multiline and stacking!) - proper undo/redo - LTR/RTL-direction - Clipboard-Handling (copying utf8 into ansi encoded textfields) - customizable/extendable functionality (think this is "easy" with Lua) Do not underestimate the efforts needed to write a fully-fledged text-field-control. But yes, I understand that people wont need all features eg. scintilla (or others) provide. Nonetheless I would like to see a cross-platform-consistant look for ones apps (once you ignored/declined the "native look"-idea ). Am also excited how you will approach "drag n drop" ... I ones found a nice sheet how wxWidget is doing it, but since then I never was able to find it again. How do you intend to handle touch devices/touch input ? (long click etc.) @ only redraw what changes Couldn't you just have a flag indicating whether a widget is "dirty"? With chains between the widgets (if composited of different widgets) it should automatically return parents as "dirty" too. If you adjust the visuals of a widget, this is done similar. As long as the visual rect of a child widget is within the parental widget, this portion needs to get redrawn - if outside, parent can skip redrawing. bye Ron |
| ||
| Looking very good so far. Will be following your progress with interest. |
| ||
| @Ron, when a widget becomes "dirty" it sends an invalidate rect message through Windows. A clipping region is created and all widgets that intersect that region are rendered in their hierarchy. Unfortunately, these systems just have a single buffer so right now the panel underneath is flashing one frame before the child widget is redrawn. So I will have to figure that out. Parent widgets clipping child widgets is also kind of complicated to keep track of. Not crazy hard, but it is a lot of work and it is important for it to be really fast. I suppose touch input could be managed by just mimicking the mouse. This is really designed for PC but can be easily extended for mobile. I intend to use this together with BMXNG as my application platform going forward. It also doubles as the in-game GUI for Leadwerks Game Engine, because it can also render to an OpenGL context or a texture. |
| ||
| Did you find a solution for the SVG rendering, in your other thread? |
| ||
| Great n. Gl |
| ||
| Very interesting! |
| ||
| Thanks for the insight/elaboration. @ Clipping child dimensions If you think of "move/resize" as being not called on each update, you could send out move/resize-events and react on that in the parent widgets (so they recalculate things afterwards). @ flashing I do not really understand why this should happen: if a parent is redrawn, the childs get the "redraw(rect)" command too... in the very same update tick. if a child gets enforced to redraw, the very same happens (all other "inflicted" elements should be redrawn until next frame). You will surely get around this problem in your own way. @ mimicking mouse MouseOver / Hovering ... For this I added a "first click positions cursor"-option to my input class (so you "tap" to position and then single/double/... tap to do the corresponding click-type). I also added "long click" for right clicks... so keeping your finger on the touch screen for >X and <Y milliseconds leads to a "right click", if >Y ms you get a "left mouse button kept down"-thing (no way to bring in "right mouse button down" ...). Of course this is not directly connected to the GUI but I think it should get at least thought about it. bye Ron |
| ||
| Did you find a solution for the SVG rendering, in your other thread? No, I am just not going to bother with it for now. |
| ||
| Nice work! |
| ||
| More info here: http://www.leadwerks.com/werkspace/blog/1/entry-1731-clipping-and-resizing/ It handles some extreme variation in resolutions, everything from 75% to 400%+. |
| ||
| Looks really good. I like the style. |
| ||
| If you have a Leadwerks account you can download a demo here: http://www.leadwerks.com/werkspace/topic/14867-gui-demo/#entry100890 I implemented double buffering and the rendering is totally flicker-free and solid now. |
| ||
| Just "FYI", Josh, you don't have to be logged in, it seems (downloading now), and your site is running *extremely* slowly right now... DDOS maybe? Downloading 2.8 MB with 3 minutes left! |
| ||
| Works great. Site's working now, too. |
| ||
| I've got it working on Linux now, with double buffering: http://www.leadwerks.com/werkspace/blog/1/entry-1734-leadwerks-gui-for-linux/ |
| ||
| Just checked it out on Linux (Mint) - noting down the odd things now: - app is utilizing 100% of a single core here. - spin controls: arrows (up vs down | left vs right) are differently sized (same on your screenshots) - input does not accept Euro signs (Alt Gr + E) but umlauts (good) - "< number >"-control does not disable elements when reaching the limit - same for all scrollbars or "arrow buttons" - buttons react on "mouse down" rather than "clicks" ... because of touch-compatibility? - scrollbars / "arrow buttons" do not continue scrolling down while the mouse is kept pressed (Todo?) Good things I recognized: - mousewheel works for scrollbars (list control and that Progress-thingy) - input control works pretty good Think what is a "must have" is a panel (with scrollbars if needed). Also radio-buttons (option groups). A Dropdown/Combobox is of interest too. ... and then the more complex/"component-mixtures" like "drop down + input" etc. And when this is done the whole interaction stuff (tooltips, drag-n-drop, programatical adjustments like adding/removing elements). But I know: first the basement, then the other floors of a building. Nice progress. bye Ron |
| ||
| app is utilizing 100% of a single core here. Good spot -- just checked, and same here on Windows 7 64-bit. |
| ||
| Thanks for the feedback. If you look in the "Scripts/GUI" folder you can actually see all the Lua scripts and modify anything you like, if you want to play around with it. |
| ||
| The text area widget is going to be read-only. You'll still be able to select text and copy it (which is hard enough to implement properly!). For a full multi-line text editor I'm going to rely on Scintilla. http://steamcommunity.com/sharedfiles/filedetails/?id=735774551 |
| ||
| Looks promising! |
| ||
| Text area is pretty much done and I am starting the LeadwerksMaxGUI driver class, to replace the GTK, FLTK, Cocoa, and Win32 drivers: http://www.leadwerks.com/werkspace/blog/1/entry-1736-text-area-widget/ |
| ||
| I've got it compiling into BMX now: http://www.leadwerks.com/werkspace/blog/1/entry-1737-leadwerks-maxgui-driver/ This program is compiled without including maxgui.drivers or win32maxguidriver. |
| ||
| I've got Leadwerks GUI working seamlessly with BlitzMax events. Which means it plus into existing code and just works with no changes. |
| ||
| Really advanced DPI scaling is now working. BlitzMax apps can be run at 4K or any other resolution with no code changes: http://www.leadwerks.com/werkspace/blog/1/entry-1759-resolution-independence/ Leadwerks Game Launcher is now using the new MaxGUI driver:  |
| ||
| Working on Linux, sans images: http://www.leadwerks.com/werkspace/blog/1/entry-1762-a-first-look-at-leadwerks-gui-on-linux/ |
| ||
| Sweet! |
| ||
| Now uploaded on beta branch on Steam: http://www.leadwerks.com/werkspace/blog/1/entry-1765-leadwerks-game-launcher-on-linux/ |
   |