Worklog for Brucey
Worklog 1
Return to Worklogs
| ||
| No, I haven't forgotten about it. I was kind of put off when lots of Mac-GUI things broke on 1.18... so... I got into a wee phase of Module building (libxml, cairo) for a while, which was highly rewarding. Am currently in the process of writing a Charting (pie, lines, bars etc, with keys, labels etc,) module that will plug into Cairo and allow for the creation of charts on all the output devices supported by Cairo (image, PDF and postscript). As of this post, Pie and line charts are working very well :-D Once That's done, I'm going to return to this little baby :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List *  Qt-On-BlitzMax |
| ||
Consider this a 0.00001 alpha version of the code generation.' Default Code Generator output
SuperStrict
' window gadgets
Global window1:TGadget
' textfield gadgets
Global textfield1:TGadget
' panel gadgets
Global panel1:TGadget
' label gadgets
Global label1:TGadget
' checkboxbutton gadgets
Global checkboxbutton1:TGadget
Global checkboxbutton2:TGadget
' button gadgets
Global button1:TGadget
window1 = CreateWindow("window", 50, 50, 400, 300, Null, WINDOW_TITLEBAR | WINDOW_RESIZABLE | WINDOW_MENU | WINDOW_STATUS)
button1 = CreateButton("OK", 287, 260, 100, 24, window1, BUTTON_PUSH)
label1 = CreateLabel("Type Text", 22, 141, 100, 18, window1, 0)
checkboxbutton1 = CreateButton("First", 27, 174, 100, 18, window1, BUTTON_CHECKBOX)
checkboxbutton2 = CreateButton("Second", 28, 198, 100, 18, window1, BUTTON_CHECKBOX)
textfield1 = CreateTextField(135, 140, 200, 22, window1, 0)
panel1 = CreatePanel(20, 20, 365, 104, window1, PANEL_GROUP, "My Group")
While True
WaitEvent
Select EventID()
Case EVENT_WINDOWCLOSE
End
End Select
Wend
Considering it's a first attempt, and the editor itself is far from finished, it's not a bad start really. Stuff is where it's been laid out on the form. And it saved it okay (since this was loaded). The button is a tad too low, but that's the form display missing the fact that there are statusbars and suchlike to be displayed rather than a completely empty window... Onwards and upwards ! -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Yes. The project is one month old today! Saving and Loading is almost fully working now. Child controls (those that belong inside panels etc) load back into the correct places. This means that we have "persistence"... Wooooo... All in all, for a month's work, it's not bad going really. Yes, there's still a ways to go before we'll have something useable (well, the way I want it), but it looks more and more like a GUI Editor every day. Oh yeah, and as long as all the MaxGUI bugs that I've been raising along the way (you've lost count too??) are fixed, it might even *work*!! Perhaps now will be a good time to start working on some simple code generation... Ooooerrr... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Preliminary loading of a saved form appears to be working :-) For a basic form with no containers holding controls, everything appears to load okay... even all the items in a Treeview populated properly... I know.. wonders will never cease!! Need to have a look at getting child controls to be associated to their parents, and appearing in the right places. Shouldn't be too much work - hopefully. Also had to work on getting controls to delete from the model and form. I think it'll be okay now, but more testing will be required there as there may be leaks about... (Plumber!!!!!) It's still going well. The Things to think about list of the 17th still needs to be thought about, but the rest is moving along nicely... Yay! -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
In a (possibly) vain effort to make understanding the internal workings
of GED a bit more graspable, I've thrown together a quick >Sequence Diagram< which shows an example of a Push Button being added to a form. How to read the diagram Along the top are the Types used. You read the diagram from left-to-right, top-to-bottom. This particular one starts with an onEvent() call. Each solid-line arrow represents a method/function call in the Type it points to. Each dotted-line arrow is a variable being returned. A looping arrow pointing to an inset box, is a method call to a local method in the Type. Isn't it funny when you've got some code that you know well, and then try to map it out diagrammatically, and you come to realise that it is indeed quite a complicated beast... btw, this is my first Sequence Diagram, so if there are mistakes in form, please let me know... :-p -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| After getting textfield focus out events working, I've now added support for that to all the textfield properties. Now, when you change the text of a button or the y value of a gadget, as soon as focus leaves that particular textfield, the model and visual components are updated accordingly. Currently no validation is in place, but what is there works rather nicely. Obviously, this chunk of featureness will be dependent on BRL getting their act together and adding focus change events to Max. (I can't imagine why this would not be the case as it is such an important feature) It also seems that GED is a bit too "comprehensive" :-p In that there is so much going on under the hood that without a major amount of time documenting and drawing some handy diagrams, it looks like it is going to be hard to get much help from outside to continue this... (steepish learning curves and all that) It is very OO shaped, which may be part of the problem. I shall need to work on documenting some of the more abstract stuff, I suppose. (heh.. while I can still remember what it all does...) hey man... I'm trying ! -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Been sorting out the last of the controls, which now appear work properly on the form (sliders, progress bars etc). That leaves the Tabber, which, as another container is going to be a tad fiddly... and the Toolbar. (and probably any others I've overlooked) The "window" part of the form also needs lots of work now, as its been rather neglected. It wants to show the titlebar part, the statusbar, menu bar (on the appropriate platforms), and handle niceties such as whether the dimensions apply to the whole window or just the client area. Also resizing of this will require tying all the controls to have their dimensions updated accordingly if they happen to be set to change in relation. (yucky job but someone has to do it!) Done some more on the saving of the form data. It now handles all the finished controls, including lists (tree, menu, listbox). Loading that back into the model is a different matter altogether... :-p ...not quite out of control yet... ...oh, and yes, the icon graphics are crap :-) (but I pinched them from elsewhere just to fill in the gaps) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| The win32 panel issues appear to have now been solved, thanks to some nice work by Chris Camacho. Thanks Chris :-) This means that instead of my crappy control-snapshot-as-panel-pixmap hack, you now see a live version of the control in question underneath the invisible panel, and when you click on the panel, the underlying control doesn't receive the event. Yay! It makes development that little bit easier when things work similarly on the different platforms. Still so much to work on, and lots up in the air. It will be nice to get the focus events stuff into Max at some point cuz without that, the properties panel isn't really going to work very well. But I'm sure the BRL guys are going to give that a reasonable priority... hey guys? ;-) The dragging and dropping is working very nicely now. As you drag a control around the form, the "current parent" of that control is highlighted by a green box around its perimeter. So, if you drag from the window into a panel, the green box then appears around the panel. Once you release the mouse button, the panel becomes the new parent, and the control is removed from the old parent. One wee problem with that which I have an issue on both Mac and Win32, is that the banding box of a child inside a panel won't accept mouse events. I'm thinking that it must be appearing underneath the parent container's invisible panel, which is a tad annoying. But it must be a Brucey bug as it is consistent on both platforms... Still, it's looking quite good for now. Things to finish : * get all the controls added. (some sliders and such aren't available yet) * get the xml format finished. It's half-done at the moment. Controls are storing their information appropriately. Things to think about : * The code generation I've still not gone near yet. As it doesn't need to be done til the editor is working, it'll probably end up last on the list. * multi-selection of controls would be nice, for things like alignment, moving in groups, etc... * alignment helper would be useful. You move a button and a line appears on the form to show you that your button is lined up with another control. Perhaps for that and control spacing. * control layout in relation to their parent needs worked on. So when you resize a parent, the child will need to act accordingly. This will need to be done via code so that the size/position of the child is modified if required. In which case the child will have to physically be restrained to its actual position. :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
Got some basic drag and drop running now... You can click and drag a
control and drop it inside a panel, the panel then becomes mommy panel,
and the window control forgets about it. If only it worked... When you are dragging the control around, it knows which "container" it is currently over, so when you drop it, it is removed from the old parent and added to the new. Unfortunately, I've made a bollox of the win32 stuff, where I snapshot a control to allow me to drag it : once the control (for example a button) is added to the panel, you can see it okay, but you can't click on it - since all you see is an image of the panel, not the control and its children. So I dunno really. Haven't tried it on Mac yet - will do when I get home later - but hopefully that will work fine. No idea what I can do with the win32 stuff now. just seems to me to be such a hack to get it to work. The only thing I can think of at all, is to remove the real gadgets from win32 and work instead with images of stuff, and fake the whole thing... :-( -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Started working on saving the form stuff out to file. Gone with XML as the format of choice, as it's nice and tidy, and doesn't require me to do much in the way of thinking :-) And some basic loading has been implemented too. Need to also sort out the container-type gadgets - those which can have gadgets attached to them (like window, tabber and panel), and see about a way to move controls on the form from one parent to another... (which should be interesting) The Tabber itself is going to be "fun", considering everything has to be done by hand where switching tabs is concerned... no-one said it was going to be easy :-p -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Just out of curiosity, here's a little in-progress snippet of my editor wrapper test proggy... It's obviously not finished, but it kind of gives an idea of the things it'll be doing once it is... ged_test.zip (250k win32 zip) Things that kind of work: The menu editor The lists editors about half of the controls Note that none of the text fields update automatically - waiting for focus change events in MaxGUI for that :-p anyhoo... it's just for fun :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
Isn't it funny, when you implement something on one system, get it
running just the way you want it to, then load it up on another and find
out half of it doesn't work? :-p That seems to be the story so far, as I work sometimes on Mac and sometimes on Win32 (as you can probably tell from the screengrabs as I go). This time it was the Mac-side of the GUI that let me down... Oh well... on the Mac, if in doubt, don't try to disable any of the gadgets.. ;-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
I decided it was time to tie the properties into the controls on the
forms (so changing something like the enabled flag would show up
visually). Of course, then I realized that I was missing a whole layer of architecture for doing just that :-p I have a TGEDxxxxx layer for the actual model part, storing all the attributes for each kind of gadget. There is a TPropxxxxx layer which looks after the gadget properties in the properties panel Now there is a TViewxxxxx layer which knows about taking the gadget attributes and creating *real* gadgets from them. So when you uncheck an Enabled flag, the properties updates the model, and informs the control-handler that the view may want to be updated. The TViewxxxx decides, based on flag settings and such like how much to do (whether only a simple update of the gadget is required, or is a gadget needs freed and recreated to show the new settings). Keeping everything apart like this makes it exceedingly easy to work on, and add new controls as I get to them. -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| It's getting a bit easier now to see how everything is coming together... UPDATE: With things working much better in win32 as well now...   Still haven't even begun to work out how I might store all this information, or what code will be generated... Maybe I should think about opening this up sooner rather than later and see if anyone would like to lend a hand... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
I think I found a hack for Linux to fix the mouse click problem (but
can't test it yet due to the panel events bug thingy which is
outstanding). After having a rummage through the FLTK sourcecode (kindly included with MaxGUI :-) I found a bit that seemed to give the impression that the gadget with current focus would be event-tested first. That's cool, thought I, because then all I have to do is make my invisible panel get focus. And so, with all good things, I added a check for an EVENT_MOUSEENTER, and used ActivateGadget() on my panel. And a small test seems to confirm that this should work. It does still leave me with the rather trying problem of win32. I tried the same trick with that, but the button still picks up the mouse event before the panel... *sigh*... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| So much for good ideas... The plan was to place an invisible panel over the control, which would allow the control to be visible, but being in front would accept mouse events in priority of the control behind. This works brilliantly in MacOS, and just the way I thought it should do. You click on the "control", but in actual fact you are clicking on the panel, with which you can do click and drag stuff with ease... However, on Win32, if you cover a button with a panel (regardless of the panels' alpha settings) and then click on the panel, you actually click on the button, which comes to the front and depresses. Which kind of sucks really. So either Windows works in a strange way, or MaxGUI isn't working properly. Personally, I would think that whatever gadget is on top should be the one accepting mouse events... And then we move onto Linux. The issue I'm stumped with currently here is that if you have a panel on another panel, the embedded panel doesn't pick up any mouse events at all... which kind of defeats any usefulness. Unless anyone knows a tidy way in win32 to be able to click on a control but not actually click on it (somehow hide the control from the event and catch it elsewhere) it looks like GED ain't gonna work very well on anything other than Mac... ho hum. (one other possibility would be to sense the mouse-enter onto the control, quickly grab an image of the current control, remove the control, place the image into the panel, and use that to move it around. Then when you mouse-leave, you reload the control and do away with the panel image....) Anyone know how to capture window section images in win32 / linux? ... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Things are slowly starting to take shape now... I've pulled all the bits together, and started working on the form-editor section. In my little test app, you can click on a pushbutton icon, and a button magically appears on the form...  The control can also be dragged around the form. Need to now tie the control into the prefs, and get the resizer plugged in also... Also would like some kind of drag-and-drop from the toolbar.. but I won't hold my breath for that one... :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
... I won't be expecting anyone to be thanking me for anything if it
ever gets finished (and thus I wouldn't be pulling any downloads if they
didn't) because : 1) it's really not that important in the big scheme of things 2) childishness is boring 3) some of us should do some growing up... ;-) Anyhoo... talking of worklogs, I've come up with a rather groovy way of getting the form-editor to work. My biggy problem was going to be that if I plonked a gadget of somekind down on the editor, it would sadly be picking up events if I tried to click on it etc.. Thus making it hard to click and drag it around the form. Hah haaa... but I stumbled across a way around that... so... On with the show :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
It took less than ten minutes to throw the TreeView editor together. It
uses the the Node stuff from the Menu Editor, and some of the controls
from the List editor, and appears to work fine (at least, as well as the
menu editor does) Unless I can come up with any others, that's the three big editors up and running with little in the way of issues left. I also gave the menu editor a run in Linux and it's going well. One small tweak for some button sizes and that was it. It's nice when you can simply load the source on another platform, compile, and run it, and it all "just works" :-) BRL have done a superb job, overall (ignoring the minor buggies here and there). Talking of bugs, there are some huge issues with panels and pixmaps on the Mac that I've yet to report. I suppose I should make a list, and a suite of example code for them... ho hum... Building GUIs without a form editor is such a lot of work. (Or maybe I've been spoiled with REALbasic and VS). And it's harder when controls come out different sizes on different platforms (the big example being buttons which appear smaller on Mac but fine on win32/linux). The hard work is about to begin now though... the form-editor itself. Given that I've never actually written one of these before, it should be... interesting... to say the least. :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
Almost finished with the menu editor now... The last piece of the puzzle is to generate the tags, which shouldn't be too hard... probably based on the text of menu item. (at the moment the field default is empty) Haven't tested it on win32 or linux yet, but I don't think they have the same bug that Mac treeviews have - the one where InsertTreeViewNode doesn't insert into the desired index position. (which is the only thing that isn't working (ie. is broken) in the menu editor - but it's coded to assume that this bug will be fixed at some point and once it is, it will just work) so... Yay... :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Well, it's slowly starting to take shape - the treeview handling stuff. Still not really happy with the way I'm handling all these separate trees at the moment. But at least things are kind of working. Once the menu editor is working, it shouldn't be too hard to take the bits from that and the bits I need from the list editor, to combine them into the treeview editor... Which will be the tough parts of the properties out of the way.... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
The TreeView gadget is turning out to be a bit of a pain. Unlike with
the "List" controls (combobox, listbox etc), the TreeView doesn't have
an "extra" field, which is a right handy place for putting a related
object (like your own internal node thingy wotsit). So, what's the workaround? Well, I *could* put a reference to the node in my TGEDNode type, but that's a stricty model only type, so no GUI in there. This means I think I'll have to make a new GUI-side node object which will store my TGEDNode and the node TGadget object, and use that to track them both. So, when I select a node in the treeview, I'll have to find it in my gui-nodes tree, and use the cross-referenced TGEDNode to work from. Or something like that... Isn't OO fun? :-p -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
In the name of good design (not!), I realized that I could probably use
the Item List Editor framework to create editors for the TreeView (with
nodes and Items) and Menus (with nodes and menus). So, I created a super type called TListEditor from which my TItemListEditor now extends, in the process moving generic code from the subtype to the super. The TreeView and Menu editors will use a TreeView list for construction. This brings up an interesting quandry in that the TreeView editor would also like to use all Item controls that the Item List does, but the list-handling code (the node stuff) of that the Menu editor will. (Ideally, I duplicate as little code as possible, to make maintenance and bugs minimal) Ho hum... Anyways, I had this other idea for the code-generation. Instead of saying, *this* is the format for the generated code you must use, I thought instead that we could define different generator classes (subtyped from a super type) and you could choose your preferred option. I hate to made to use something that I would personally like to have done slightly differently. This way, the nice folks in the community could provide their favourite frameworks, for integration... (heh... well, we'll see how that goes) So all we'd need would be a nice super type that you would extend to which you could write your own formatting.... (internally the preferred generator would be passed to the generation routine, and use that to create the code) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
Was having a browse throught the Max IDE source earlier, and noticed
that things extend TEventHandler, which internally passes down events
into the various panels. So, in an effort to make my life easier *now*, rather than working out how I might back-fit things in later, my properties are now extending TToolPanel (whether or not this is a good idea, time will tell :-p ) While on this integration drive, I decided to integrate yesterdays Item List Editor into the properties. (which turned out to be as easy as adding about 4 lines of code :-D ) I also got some colour property working (click the coloured panel, and up pops the color requester thingy). My little standalone test app can be tried "here" (167k win32 zip). The label has a color selector, and the combobox uses the list editor (see "modify"). Linux update: Mr A. ;-) has already found a solution for one of the issues I was having with the ListBox in linux. Tho he should probably lock his PC away while he's on holiday! Hopefully, with the next lot of syncmods some of the problems I'm finding now will go away... maybe... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| I tried the Item editor on Linux (FC4), and the window looks great! (no, really, it looks very nice indeed :-) Everything is placed nice, so I won't have to make any more adjustments. Unfortunately, the ListBox functionality is pretty much less than barely useful. (see bugs section) And I don't really want to be having to code around functionality that one would hope would be the same on *all three* platforms. (since the usages matches on win32 and Mac, I can only assume that the linux GUI stuff hasn't been used / tested that much) And boy... what a hell of a lot of events you get in Linux! -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
The item editor is almost done now. Only thing left is the Iconstrip
handling stuff, which can be added later (as it is only a "nice to have"
feature). The conversion to Mac wasn't too bad :  Things to note about some differences between Mac and Win32 GUI. * Buttons on Mac appear much smaller (width-wise) than they do on win32. So I've had to add some adjustments : ?win32 Const buttonWidth:Int = 80 Const buttonXOffset:Int = 0 ? ?macos Const buttonWidth:Int = 95 Const buttonXOffset:Int = -10 ? and is used for example, like this CreateButton("New Item", 10 + buttonXOffset, ClientHeight(window) - 63, buttonWidth, 25, window, BUTTON_PUSH)
The offset moves the visible portion of the button to the left on the Mac, and we need to make the buttons longer, since the button part of the gadget is smaller than the "real" width of the control... Starting to get the hang of it... ;-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| There are a few gadgets that hold lists of items. So, I suppose we should have a little Item list editor dialog to help. Here is a mockup (UPDATE : With actual BlitzMax window on the right)   I know... ack... it's been mocked up in VB6... but hey, GED ain't finished yet, so what did you expect? And laying out a GUI, as you know, without seeing it before you code it is a right royal... well.. ;-) The idea behind the icon bit is that you can pass a pixmap (or whatever) to the editor, and it will show the strip of icons scaled to fit. Hitting the "Choose" button would then let you select the image from the strip, rather than typing in the number - which you could still do. The iconstrip would only be available here, if you'd already chosen on for the parent "list" gadget. I don't think, at the moment, the preview list would also show the relevent icon, but that could always be changed later... and so it goes on... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Have been piecing together a control hierarchy for the editor which can be seen in this Hierarchy Diagram. Notice that the gadgets such as the different types of button-styles are listed as separate controls, for reasons no more obvious than stopping the user from having to fiddle with those flags. The TreeView might well appear in the "list controls" at some point, although it would probably use a different dialog to edit its content. (what with all those nodes in nodes possibilities) More things to add to the todo list... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Apart from the very
obvious issues that are apparent at this time, I think things will have
to be tweaked slightly for each platform so that they at least appear
more like one another. For example, the labels on Win32 are very much closer to the left than the same labels on Mac. But on Win32 the combobox is a bit nicer, in that if you populate it with 3 items, it only shows 3 items. On Mac, you get your 3 items plus an extra couple of blank entries. Not that they are selectable, but it looks a bit strange having all that white-space. (This is probably a bug rather than a UI quirk) :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
Thought I would try out the current test stuff on Windows, just to see how it's going... Don't you just love the way labels aren't transparent, but instead take on the background color of the parent window (well, I'm assuming that's what they are doing). and of course, setGadgetColor( myLabel, 255, 255, 255) ain't working ;-) I'm setting it anyway, on the off-chance that one day it might. Since MaxGUI is still only a baby, it's not really surprising that not everything is working properly yet, so I can live with it. -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
I've been a bit distracted today throwing together setGadgetFont stuff
for some of the Mac gadgets that don't support it. (sadly, I also appear
to be getting a basic understanding of Objective-C at the same time...
argh!) Anyhoo, it seems I forgot about Menus. These are a bit trickier in that they aren't really gadgets as such (since they have no visual presence inside a window - I know what I mean by that :-p ) I think for Menus, other than not having them drag-and-droppable, they will need their own specialized edit window or something, to allow you to customise it in some way. Requires more thought at some point in the future. Of course, if anyone has any ideas.. ;-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
Dynamically creating properties : ...for a Window.  ...and a Push Button. Looking quite nice so far. Next stop... have to go through each and every gadget and see what properties they can have.... joys... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
I thought it might be fun, seeing as the code for the IDE is available,
to design and build a Gui EDitor for it... that is, have it built-in to
the IDE rather than as a standalone application. I would see it split into two parts, visually... In the main editing area we would have a tab per "form", just like we do for a .bmx file. This itself would be split in two, containing a toolbar and the main form-building section.  with of course the proper draggy, resizable thingies,  The second part would be a Properties page, which would change dynamically depending on the currently selected control (gadget). This could be placed into the right-hand tabbed area.  Currently, everything is standalone, and in very early development, but has designed so that, in theory, once all the pieces are working, it should be a fairly easy job of dropping it all into the IDE. (tweak here, tweak there, etc). Stuff that hasn't been looked at yet : Form file format. Forms (that is, a window definition and its controls etc) should probably be stored in their own file format, being a self-contained entity that can be used to extract everything required to generate code from. Code generation. Haven't decided on the best way to create the code for handling all the gadget events and such like. There are two obvious systems available, 1) using the standard while-loop, and 2) using that event hook stuff as seen in that Applet example. Of course, the easiest option is to get to a point where most of the editing works, and then offer it up for the community ide project ;-) haw... If anyone has any ideas.... :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
It appears that developing with the newest version of eclipse (3.1) can
lead to all kinds of problems when you find yourself using 3.1 specific
functionality, and then attempt to use the plugin on something not so
new - it breaks. Anyways, after undoing some things, and a little re-wiring in places, hopefully it'll work on 3.0x still... Finally managed to get the three - Compiling / Debugging / Running (release build) - options working. Ouput appears in the console view. No console input though, so if it's required, the exe would need to be run from a command-line. (not a major priority though, but hope that I can solve the problem at some point) Really want to add the "default file" option for a project, next(ish). That way, when you build or run, you won't need to have the main .bmx file selected in the editor. I'm considering re-writing the bmx parser. It's not very strong at the moment. I can see how I could improve it alot, but it will require starting over on it. However, as it is mostly separate from the rest of the code, it's only the parser that I will need to work on - everything else should work as before. I'll need to sit down and plan it out first, to make sure - this time - that it's the best way to go forward. It should be :-) I believe I can integrate a "browser" view for the plugin. This would be good for showing the documentation. Even better if it's context-sensitive. Hover-over tooltip style documentation would also be good - perhaps using the bbdoc rem blocks as a source. Lots to do... :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Woops. I realised that I had inadvertantly lost the Blitz Max folder preference setting. So, did a wee bit of house-keeping, rearranging the prefs a bit, and getting the most important preference back in there. Yay! I managed to "debug" an app from eclipse. Click on the "debug" toolbar icon, and it went off, built what it had to, and finally ran the generated executable. Still lots of work to do there, but we are going forward - for a change. Need to look into tying the Process back into eclipse so that if you need to, you can kill the application from there. (for instance, clicking on the "stop" button in the processes view). Given that a Process is available when the app is run, it should simply be a case of using that reference and calling terminate or whatever on it, when we require it to end. (so the theory goes) OS X packaging would be nice at some point - simply, a couple of nested folders with the binary stored deep inside, and the option of either running it from within, or calling "open xxx.app" from the command-line. Need to check if windows builds have .exe on the end by default. Need to sort out the Console view. Clear doesn't work, and I can't seem to delete them either, once they are there. A dig around the docs should sort those out, eventually. I should finish getting the basic run/debug/compile working first though... :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Wouldn't it be nice if you could "narrow" the current view down to an "element" of the file you are editing? Perhaps you want to focus on a specific method or type, and could do without the issues of this element being a tiny part of a larger document... One way, could work like this :  ...where you select the element from the outline view, and the editor panel narrows itself to show only that element of the file. As a concept, it is working well. Just need to work on the "toolbar" icon handling for it. (toggle on/off) Compiling and Running is making progress. Can currently build from the toolbar, but only against the current active editor view. Probably want to add the facility whereby a "project" has a particular .bmx file designated as the main / default file to build against. A Project without this default file would assume to not have any, and compiling would work on the current file. I think Module development will need to work differently. Perhaps a "Module Project", which will cause the plugin to call different compile options. At least creating a new project finishes properly now... :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| There comes a time in every plugins' life when you realise that perhaps some things just weren't meant to be... After reading the Eclipse 3.1 release notes, I decided to do away with half of the Preferences, since it appears that these particular prefs (Text Editor settings for tab size, line numbering etc) were being merged into a single set, rather than duplicating the same ones in different plugins (eg. the same Java editor settings are going to be using the standard "text editor" ones too). So, for pre-3.1M4, to set whether or not line-numbering is enabled, etc, it's done through the Workbench -> Editors -> Text Editor preference pages. Otherwise, there's a more global page for those. While I was there, I added preferences for Folding, and also the ability to fold Rem blocks (as requested). The preferences allow one to determine which blocks are folded when a file is opened - if any. Other work continues... more tightening of the document model, and other tweaks for now. Hopefully I'll get compiling working again shortly... :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
Just when you thought it was safe to click on a "node" in the outline
view and see the block highlighted in the editor, it also now works for
cursor movement in the document : As you move the cursor around, the editor tracks the location and updates both the current block (in the left ruler) and the current node in the outline view. Hopefully this will make blocks stand out a little better... As yet, only normal blocks are handled (types, methods, etc), but perhaps in the future, iteration blocks and "if" blocks could be applied too. Progress continues... :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Update.... Here's an example of the content assist in action :  Not entirely sure if *everything* should be sorted - that is, mixing functions and keywords together, or to keep things in groups? If you enter enough for a "perfect match" (1 word), instead of the popup it completes the word for you. I like Eclipse ;-) ------------------------------------------------------------- So much to do, so much time to do it in.... (unless of course you find yourself falling into the deep, dark, spikey-bottomed trap of releasing a very early version of your code to ppl) But still, user-feedback is part of the fun, and it can help to open one's eyes to some things you hadn't thought about. Anyhoo... I've been working hard on getting the Preferences sorted out. As of now, you can change colours and styles, and they are updated immediately. Almost. The viewable-area doesn't always "update" itself, but if you scroll, the new stuff that appears shows the changes you saved. Certainly an improvement on having to close and reopen the editor. As has been pointed out, content assist isn't working very well. Indeed, there is a lot still to do. It's kind of almost half-way there at the moment. When the blitz max path is set up in prefs, a restart of eclipse (perhaps in time, a restart won't be required and it will know) will trigger the caching of all the mods - types, functions etc. These are then added to the content assist engine to appear where appropriate. The caching is working, the "appropriate" is heading off in generally the right direction. Back to work... :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Most of my time I seem to be spending working out why something or other doesn't do what I expect of it. The last one was - why won't it save my preferences? (or rather, I don't know if it is saving them even, cuz I can't find the file!). Anyhoo, all is well again it seems, and at least a deployed plugin seems to remember (most) settings now. Running things in debug and running as a normal plugin throws up different issues. I had to write an ant build script in the end, cuz using eclipse to compile the plugin wouldn't allow it to load in another eclipse. Dunno what all that was about - perhaps the compiler settings were bad. *sigh* However, despite all the little bitty problems, progress is heading in the right direction. Tonight I concentrated on trying different .bmx files to see what worked and what didn't. Mostly everything looks fine. The outline view shows some "fields" that aren't, and misses some out altogether (my parsing needs tightening up in places). Folding works great, after some more tweaks. I also re-did the default colouring, so it looks a little less freaky. The Prefs kind of work... but it's hit and miss at the moment as far as changing colours is concerned. I thought I'd try a deploy on my linux boxy... This is what it looks like running in Eclipse 3.1 on Fedora Core 2...  It looks the same... *shock*! (btw, screen-grabbing on Linux.. couldn't be any easier.. "import <filename>"... then choose the section of screen to grab. Learn something new everyday!) Looks not bad on there at all really.. and starts up a fair bit faster than the PB (given there's a helluva lot more grunt in the PC, it's not surprising) So, as an editor, it's almost bearable at the moment. :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
As usual, I threw away my plan, and instead decided to see about
getting the content assist stuff working (at least up to a point). When the plugin is first loaded (eclipse uses lazy-loading, so if you don't open a .bmx file, the plugin won't be taking up resources), it goes off and caches all the mods (in the background). Once they are in memory, this is the kind of thing that you'll see when you are giving your variable a type :  As you type, the context is narrowed, and the list decreases in size... Early days yet, but I'm happy with it so far... It will have to take "Framework" options into account at some point - that being, if you use Framework, the list it provides should be based on available imports, rather than the library as a whole. ;-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
|
I'm now happy with the code-folding... It updates when the outline view
does, using the outline view document model (which saves on a whole
parse). I tracked the "change" problem down to the fact that even though I was passing in the updated model, I wasn't using it... *doh!*... funny how the obvious is sometimes the least obvious. Anyways, the hours that I've spent debugging the folding stuff means at least it's all very clear now. The "type at the end of the document" problem was easy to find once the folding was working. Seems I was adding 1 onto the size of the "type" region, which meant that it ended on the next line (which, if the document ended by then meant that folding mechanism would try and fold off the bottom, caught itself, and decided not to try). Yay for exception handling :-) I've done a wee bit more on the building, but I think I'm getting myself kind of lost... I'm not entirely sure what I want to be able to do here - which options should be readily available, which should be something you get from a menu instead? Maybe someone has some ideas of their own... Also, Modules will have to work differently from a standard build. The IDE will need to know the difference between the two kinds, I think. Perhaps some Module / ModuleInfo handling too. Integrated Help will be nice to have. Mouse-over annotations perhaps? I think fredborg's help stuff looks pretty awesome... perhaps that in a context-sensitive way? Stuff working :
* Content Outline (types, functions, methods, variables)
* Code folding
* The document model is reasonably accurate.
* Pref colouring options available - but haven't worked out how to update an open editor.
The current TODO-ish list :
* Create a nice list of build actions - compile / clean / run / etc.
* get import loading/parsing working
* Add a "default" .bmx file for building in the project (optional). Calling Build would compile this one, regardless
of the current selection.
Back to the building I suppose... :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Updates : The folding mechanism revealed some issues with my document model - which has tightened some stuff up in that respect. I need to enable a listener for the 'folder' to pick up document changes - kind of pointless otherwise. I think the best place will be to tie it into the outline view update (which acts after a short delay in typing). There's a problem with the Type that ends the document. For some reason the 'folder' isn't picking this up as a foldable region, and so the last Type is always open (with no little arrow) Problem markers - When to clear them? On save, probably.. when you start editing even? They aren't dynamic, so if you add code, I doubt they'll move with the line they refer to. And you will only have one - given that BMX only reports one error per compile... I really need to sort out the building stuff next... then we might have something vaguely useable... Oh.. and having BlitzMax files and CVS integrating seemlessly in one environment is rather cool.... ;-) ------------------------------------------------------------------------------------- .. move along, move along... nothing to see here.... ...BEFORE...  ...AFTER...  (that's right, there *isn't* anything to see ;-) ...and there was me thinking that sitting here for the last 8 hours was wasting my Sunday... I am actually *very* impressed with this feature - well, more surprised at the moment in that it works at all :-D Issues : * All folds are closed when the document opens. Kinda backwards ? Or should this be optional? anyways... I really need to not get myself distracted any more and get the build/run stuff working.... :o) ( btw, I don't recommend sitting in front of your computer for most of the weekend - especially if the decision to get some sleep comes a distant 2nd) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Just some ideas for things that might be nice to have in the editor : >> Folding << (type and function folding - I think folding loops and other blocks is pointless?) >> Tag Handling << ( like TODO tags - perhaps implementing the Java Tag list stuff where you can define your *own* ) ...more... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
About bloody time too.... Rem / End Rem blocks work.... :-) (what's for tea, monkey?) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Yes... here we are... 8 whole days into the project... At least it doesn't crash now, every 5 minutes (which, in anyones' book must be some kind of progress!). The whole crashing issue was a lack of trapping for empty things, which the outlineview appears to puke at, given every opportunity. The latest work has been re-writing the Preferences stuff, moving default colour settings to a file, and adding a proper Preference page...  It's by no means finished. I haven't yet got the editor to update to reflect pref changes (to see them, you've to close and re-open the file) - this is likely only a single function-call away from working... and even with all my books, I've not found it yet... The example piccy shows the preference page over pixmap mod. (All .bmx's I've tried, now seem to load okay :-) As for the colouring... well... I dunno... maybe someone will come up with a nice default... ;-) The Rem/EndRem issue is still HALF an issue.... :-( The half that works - the "document" knows that stuff inside the Rem block is not for parsing. The half that doesn't - the syntax highlighter, I cannot for the life of me get it to work, so for now, that part is disabled. (I've tried a couple of different ways, the second of which fixed the dom recognition of it...) I "borrowed" the preference page styling from the Java editor prefs, which is why it looks familiar ( I liked the list editing of colours, which isn't a standard control - so, monkey see, monkey do ;-) I'm happy enough to leave the format / syntax stuff for now, as it's mostly working. Onto the bigger beefy stuff now : Compiling and Running :-) I'm going to add (or borrow) the standard toolbar buttons that eclipse uses for Run and Debug - click on it, it runs your current .bmx (possibly using quick-compile first?). You hit run, and it runs (and compiles) a release version. I think to start with, that would be enough to have a useable system. (Although the idea of a "default" .bmx is rather important, and perhaps I need to add that too, before anyone else gets their paws on it - no point trying something out that doesn't do anything else that allow you to edit the files..?) I've been wrong before tho... -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Update : We now have "problem markers"...  Just need to add a "hover" feature to that now, so that the error message appears when you mouse-over the red cross in the editor. Okay, now time to solve this rem/endrem problem... : The issue itself has been that the default multiline rule in eclipse is not "word" savvy, and will see the word "rem" in the midst of the text of another word... and then things go rather pear-shaped. Me thinketh a word-based-multiline-rule is the order of the day... The current TODO-ish list :
* Fix the Rem/EndRem issue
* Create a nice list of build actions - compile / clean / run / etc.
* Add a "default" .bmx file for building in the project (optional). Calling Build would compile this one, regardless
of the current selection.
* Make prefs nice - colouring options.
* Packaging facilities for OSX builds - (ack - write my own? :-( )
---
* get import loading/parsing working
* mods loading will work once imports work.
* Content Assist - works basically for now. needs import stuff working to be useful.
I can't really think of anything else for now... ideas?? ------------------------------------------------------------ Finally implemented the first-stage of compiling a .bmx file....  Output appears in the console. Errors highlight in red (for now). Haven't yet tied the error message to the code - which I would like to use the built-in error-marking / annotation (eg. a little cross on the line with the error). The piccy above also shows that the syntax colouring is off at present - I'm rewriting it to run off the preferences screen instead of a file. One big issue is that Rem/EndRem is not currently working at all. I've disabled it altogether for the moment, as it broke on most BRL mods. Therefore, it sees all text inside the block as "live"... I have a plan for a fix... I've decided not to use Eclipse's Auto-building functionality. I don't think it's feasible as it stands, since there would have to be some way for it to know which file should be the one to build first (rather than the file you may just have edited). Perhaps it needs to be clever enough to recognise the dependency tree? I could change my mind later... we shall see. One thing of interest.. if I do bmk -d file.bmx , it doesn't create a proper OS X .app package... I wonder if there's anything else that the IDE does on top of the straight compile? :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Not that anyone would notice, but forward progress was indeed made today... Apart from spending several hours trying to track down first, some documentation on a specific functionality (which turned out to be staring me in the face all the time!?!?!), and secondly a bug which broke the outline view. But both are sorted now. Word recognition :  Or, as we see here - a distinct lack of it. (or should that be, too much recognition?) Whichever, I appears to have a small issue. That and numbers in a variable name appear coloured too. haw haw... I'll look into this tomorrow. On the plus side, once you've configured the location of bmx, it sets up a linked folder to the mods for you. Useful because you can quickly access them from inside the IDE, and it gives the plugin access to them as if they were part of the project. Current TODO list in order of priority(ish) : * Fix word-detection issues * Get imports working * Building - initially, basic bmx compiling - option for quick / full (perhaps how java works using the idea of a "clean build" or "rebuild") :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Today I learned about Actions and Preferences... I've added a basic Action to Hide Imports on the outlineview. Kind of a proof-of-concept thing, and it works well. (ie. it does what it says on the tin). However, it closes all the treeview branches when it refreshes, which ain't so good. I hope I don't have to remember the status of every branch (open or closed)... We now have a Preference page with a single entry currently - the Blitz Max path. From here we've got docs, compiler and mods. Yay. I suppose one should be able to change syntax colouring, and perhaps the font too. Can't think of much else for now with regards the prefs... Building is going to be an important issue. However, having toyed in BMX for a while, I've often found myself modifying a .bmx and automatically hitting the "rebuild" keys, and unfortunately breaking the compile as the .bmx in question isn't the "main" one, but a sub... Why is that an issue? - Mainly because it creates debug binaries, and when it comes to building the main .bmx, there's an error of duplicate symbols and such. Should there be somewhere that specifies a particular .bmx as the primary, or do we assume the user knows what they are doing, and let them build whichever they wish? Or make available a slew of build options, and let them have fun... Choices, choices... :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| It's not often, but sometimes things just work first time... Basic support added for simple fields :  Need to think about how to parse variables for commas and the magic ".." Fortunately, fields and variables (const, global and local) are essentially of the same essence, so once one works, the rest will (hopefully) fall into place too. <new> This looks promising :-) ...  </new> EDIT - I think that the outlineview may require options to show/hide things at some point, given that it's starting to get quite busy in there... The next step, I think, once variables are working, will be to invest some time into setting up some preferences - most usefully, directions to the default BlitxMax installation folder. From there we'll have access to bmk and all the mods. And then... it's time to have a look at importing things... I was thinking that perhaps the best thing is for the plugin to automagically load all the mods into memory at startup time. Kind of like an online mod-library. This should save mucho time when it comes to determining types and content assist - since only a quick-lookup will be required, rather than a load-and-search. Also, I think folding is a possibilty, although it could turn out to be a big job - documentation seems a wee bit thin on the ground. We shall see. :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
After much humming and hawing, the outlineview is now able to show function / method detail : A is for Abstract F is for Final S is for Static (ie. a Function - which you can call without first instantiating the type) Variables are next :-) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
| Progress is going forward, for a pleasant change... Types now recognize they have functions :  ... still not entirely sure how to go about the variables, given that they can be declared in a multitude of ways. (where there's a will?) Given that Type-functions are essentially "static", I suppose they'll want their own icon too (geepers.. icons too...) :o) -+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |
| ||
...there wasn't much there... Work is coming on well, for the first days' efforts. Keyword syntax-highlighting is kind of working. There are issues with keywords being picked up within texts, but I imagine that should be easy enough to track down. Can detect multiple Types in a .bmx file. Seems to work properly too, getting the region correctly, and appearing in the outlineview. Clicking on the outlineview highlights the code-section. Basic content-assist is working :  Things to do (not in any specific order):
* Modules / Imports - tied together as getting one working, should make the other work too.
Parsing of imported files to pick up Type definitions and their fields etc.
* Variable recognition (Const, Global, Local, Field)
* Ability to build from eclipse - kinda very important, otherwise, what's the point?
* Debugging? Assuming that you just run bmk in debug mode?
* ... loads more ...
-+ Brucey +- Come to Brucey's Modules for useful BlitzMax Modules!! . . . See my Modules Worklog - wxMax - * The Definitive Module List * Qt-On-BlitzMax |