Well, after a little playing around with my interface, I've made some new decisions. These don't effect most of how the program will function, but they do change the basic interface and how it works from the above image. I don't have a replacement image yet, when I do, this post will be edited.
First of all, for first seeing if I could create my interface to match my drawings of it, I hard-coded everything in a single file. Now that I'm working on the combobox, I've found it much easier to work with classes, and so have started creating a 'tkeditors' Python module (basically a library) to store a whole bunch of different new widgets I'm making in classes for modularity and re-usability (which was the plan from the beginning).
Second, the image in my first post above shows two buffers: One for the 'From:' language, the other for the 'To:' language. But I thought about the function of 'Import' and 'Export', and how there's only one 'Compile!' button. There really is no need for two editable buffers. It's nice, at first, but the use of the second buffer is trivial. It might mean you could edit both buffers' code simultaneously, but that really doesn't have any use in any case: If you have errors you need to fix, it shouldn't fill the second buffer. If you just want to make changes, it's much easier to make the changes to one language only and compile. And when you hit the 'Compile!' button to error-check, it only works on the top buffer. I was going to have 'export' also run the error-checker, but then that was redundant, and the bottom 'Export' could just be replaced by 'Compile!' and the extra button removed entirely.
In the end, I decided to reduce it to one buffer, and instead reduce the size of the bottom text window, making it a multiline label instead of an editable buffer, and make that the error-check buffer instead of opening a separate window for it.
I'll also remove 'Import' and 'Export' since Open/Save do the same thing. Ctrl+S and Ctrl+O will be able to open those dialogs quickly, too. And Ctrl+N can add a new project (open a new tab with a blank buffer).
Maybe, as well as the 'Compile' button, there'll be an 'Uncompile' to act in reverse (Compile from To: to From: instead of the normal way). But of course, you could also with only slightly more work, simply change the From: and To: to set the app to recompile to your original language. There will also be an Undo/Redo option in the Edit menu, for which Ctrl+Z and Ctrl+Y should work as well. Maybe I'll have the From: language automatically change when you compile to the compiled language, and clear the To: language (Or set it to the original From: language?)
I'll also allow Compiling from a language to itself, so you can simply error-check (and possibly optimize) your code in any language.
On a completely different topic, I'm going to start playing with Tkinter's Canvas widget, at first not using any special graphics, but just creating a Window Canvas Item, and placing existing widgets inside it. I'm going to see if this gives me any additional positioning and altering control. If so, I'll start designing EVERYTHING through the canvas widget so skins are possible.
If this works out, skins will be very simple. In the Options menu will be the program configuration dialog ('Configure...'😉. One of the tabs in this dialog will be 'Skins'. You will be able to select either '<none>' or a few existing Skins, or Add/Edit/Remove your own.
Below that section of options will be the skin design section. This will be disabled (grayed-out) for the default skins, but usable for any custom ones.
There will be a combobox (drop-down) for different widgets, from larger ones such as 'default' (what any unset widget uses), 'application', and 'frame' to 'button', 'menu', 'label', and 'buffer'. There'll also probably be a 'titlebar' option, which is simply a custom widget built off of canvases to cover the existing titlebar.
Then it will contain on the left nine buttons arranged in a square, and on the right a preview.
The default graphics will be from one of the default skins. Only 3 of the buttons will have graphics, and this is the minimum you need set. Any one of the four corners, any one of the four sides, and the center (background). If you add more, they will simply be used separately for the sides they represent. For instance, if you use both a horizontal and a vertical side set which are different, the horizontal one will be used on both right and left (of course flipped), and the vertical one used on top and bottom. The more images you set, the more unique the sides can be.
When you click one of the buttons, a small dialog will pop up allowing you to choose an image, color, and/or a shape (a standard drawing shape with fill and outline colors, and any rectangular section of the shape can be used for the actual graphic). The center button, for the widget background, will also have font settings (Face, Style, and Color). You have the option of setting gif frames to use for different events (normal, mouse-over, and click), or choosing additional images, colors, and/or shapes for this purpose. For gif animations, you can set it to play once (ending on the last frame), loop, loop and rewind, or play once and reset (to the first frame). You could potentially have a very colorful and animated interface this way. ^_^ When the widget is entered at all, any of these segments with animations will play as set, at the same time. They can be longer/shorter than each other, so you can make really dynamic animations, but have to make sure they're all the same length if you want them all to end at the same time. There will probably be a 'delay' setting available too, so you could make the animation 'roll across' your widget in any desired direction. ^_^ You don't have to set any of these, however. Also, if you use an animated gif and don't use any of it's settings, it will stay on the first frame normally, and 'play once and reset' the whole animation whenever the mouse enters or clicks on the widget.
Below the nine buttons will be the background display settings.
First there will be a combobox for background orientation: N, S, E, W, NW, NE, SW, SE, and CENTER.
Then there will be some radiobuttons for the fill type: 'Normal', 'Tile', 'Stretch', and 'Stretch and Tile'. 'Normal' just fills in a background color around the image, depending on its orientation. The next two work just like the options for a desktop image: tiling it at its current size or stretching it to fill the whole window. The final option is kind of special: It will always make sure only whole images are tiled. For instance, if your image is 512x512 pixels, it will shrink the image when the window is anywhere below that (which it can't be anyways, but could with larger images), and will stretch it at any larger size, until the window's width or height (or both) become(s) larger than 1024. Then it will tile the image in that direction, and continue stretching both evenly until another 512 pixels is passed. So your tiled image will never be cut off in the middle.
Finally, there will be a combobox and a 'Change...' button for all the standard application graphics. Depending on how well I can control Canvas space, this could include the window icon, minimize/iconify, window/maximize, and close, and it will always include things like the info, warning, and error graphics, radiobutton and checkbox graphics (for each both checked and unchecked), scrollbar and combobox graphics, new, open, save, cut, copy, paste, undo, and redo, and probably a few other program-specific ones.
All this will be saved to something like a 'skins.ini' file, and read at start-up. The different options will be categorized under '[Type]' headers, and options will simply be in the format 'option_name = value'. The options chosen from a list will use numbers or constants (commented at the top of the file), whereas the images will always be in 'path/file.ext' format.
There will be super-headers for each custom skin made, containing all the settings for that skin. The default skins will not be included in this file, nor will the file exist until a custom skin is made.
At this point, I'm going to have skins no matter what, the only question is whether they can leave the window or not. If they can, you can design your entire window look (the real window will never be visible). If not, they will sit inside the window's border and 'decorations' (basically the titlebar).
Tkinter doesn't support partial transparency as far as I can currently tell. However, besides bitmaps it also supports gifs with a transparent color set, so you can create rounded borders, etc. I'll try to include some other image handlers, and if I can find some support for partial window transparency that's multiplatform, I'll try to include it.
As I work on all this, I'll get more screenshots up. The first one will be a skinless view of the new interface, however. Skins will come after I get my widgets all moved to Canvas Items (and the methods of creating widgets in Canvases simplified).
This'll still take a while as I create my custom widget classes, but it'll be done soon enough. I also have a new job to work around though, so most of my work will get done on the weekends. I'll only have a few hours each day during the week to work on it, otherwise, and I really need larger blocks of time to accomplish much.
