LÖVE

> Partly because it behaves oddly under Arch with Gnome 3
>>Any more details on this? Maybe it's something that can be addressed?

You can probably see from the screenshots but I get no tabs (They are there but invisible) so anything that is more than a single file becomes a mess to manage. The file tree doesn't open files (happened with 0.4 and now with 0.5). Almost sure that it is the same thing that is causing the invisible tabs (wxWidget thingy).


> Increase font size
>>Agree; the font size should probably be set based on the screen size (by default); still can be changed in the config.

Aye. I think letting the user further otimize it is great. As always though, sane defaults


> Change default colors
>>Tend to agree. ZBS comes with several popular color schemes (btw, Notepadd++ is one of them; contributed by SiENcE ), but the default one may have less contrast. You can see/test the different schemes by opening cfg/scheme-picker.lua in ZBS and clicking on those links. v0.50 made some improvements there as it also allows to set back/foreground colors on the filetree/stack/watch windows.

I did test the themes out - a few of them are really good!
I gotta be honest, I don't know how much of an improvement it is to change the filetree window colors. The custom colors work great for displaying code but for everything else, a sober, sane default is usually better. A big reason why Adobe's Brackets is such a joy to use has to do with the interface - the left side, as you can see from the screenshot, is dominated by a darker grey. If you open SublimeText, the standard theme and font are gorgeous. It separates the filetree with a sane, non-vibrant color.
When coding in either of these two applications, you completely forget that the file tree is there - until you need it. That is the beauty of it.

I want to be able to say the same about ZBStudio

> Comments as big blocks of green draws a lot of attention and really breaks the flow of the software. Instead, why not lowering contrast, removing the background and using a non-vibrant color?
>>Good suggestions; I just got too used to the current scheme to see its flaws. Having said that, some users do want more contrast

Indeed, different people, different strokes. I do think that the current green block is a tad too much though
Perhaps themeing could be more exposed? As in, easily show the possible themes in the options file? Not sure if it would work or look nice but I'm all for highly-exposed APIs.


> Fix the padding; The line number padding feels honestly wrong. It is just too much. This contributes to the overall feeling of chunkyness. But maybe it has to do with the point I raise next
>>I thought about making it smaller, for example 999 by default, but what if the file has more lines? Increase the margin dynamically?

Hmm. This might be possible to "fix" simply by improving the colors of the line numbers and general interface. I've taken a second look and it is not really that different from, say, Gedit, Brackets or a myriad of other editors.


>>Thank you for the screenshots and specific suggestions. I do want to stay minimalistic and most of the suggestions are already doable with config changes, although margin width and folding symbols require code changes to make them configurable.
>>Do you mind sharing your ZBS config from the second screenshot? I'd like to play with the colors to see if I can come up with a better overall look as the default.

I don't mind it at all!
I can make a quick mockup of a few ideas for ZB, if you are interested

paulclinger wrote: All the available packages are now in this repository: https://github.com/pkulchenko/ZeroBranePackage and "zoommenu" plugin is one of them.

Although it is nice that you have made a plugin repository, the zoom shortcut keys are pretty general and expected in a text editor. They are found almost ubiquitously in every modern text editor and even web browser. Especially the shortcut key ctrl+0 to restore the default zoom level. I was pretty surprised when it didn't work.

So even if not the View menu options (although the View menu is far from cluttered), you should consider merging the zoom shortcut keys into the vanilla zbstudio. Or if you'd like to keep it as a plugin, maybe you could have a set of plugins that are used by default.

EDIT: Ah, the analyzeall plugin. I always wanted that functionality! Thanks!

paulclinger wrote:I have Arch Linux running in a VM and should be able to check over the weekend.

If you need more information, I can do more tests. All GTK themes I tried seems to work fine, except for the default Gnome theme, Adwaita. If I launch ZeroBrane from a terminal, I get hundreds of GDK errors, most of them being assertions:
Note that the theme works perfectly everywhere else, and afaik comes directly from the Gnome project.

paulclinger wrote:Globals across project files are planned, but table fields are going to be difficult.

I thought so. I'm not sure what the lua static anlyzers can do. If all else fail, having a better UI for "replace in files" might be a good enough alternative (i.e. a window presenting all occurences with a few lines of context, where you can quickly select or deselect each one before validating the replace).

paulclinger wrote:What do you mean by not "validated" if you type the whole word? If the typed word matches, the auto-complete will be hidden

Not for me: the window is only hidden if I start typing something else. But if that something else is a line break, then it's used to validate the autocomplete, and is not inserted in the editor. It's worse if there is two possibilities for a word, e.g. "foob" and "foobar". If I type "foob" then return, this will insert "foobar". IMHAO autocomplete should consider that "foob" is a closest match.

paulclinger wrote:Do you mean along the lines of what OttoRobba has suggested? Or do you mean hiding things like the toolbar and the menubar?

Yes, I agree with OttoRobba. This might include hiding the toolbar, but it goes beyond that. There are many elements of the interface that are only useful on specific occasions:

- The title bars of the dockable frames/windows. If you really want to keep the ability to undock them, this should be done with a menu and/or a keyboard shortcut. Most of the time they just take space and add visual clutter.

- The "Project" frame repeat the top level directory two times. IMHO it shouldn't be displayed at all: knowing what project you are working on is not something you have to check on a regular basis, so that's useless information. Also it adds an indentation level to the file tree, so more space lost.

- Still in the project frame, having one item selected serves no purpose, but is visually proeminent (highlighted). I think the files should open with a single click, and the active file should be the one highlighted. In fact this could completely replace the tabs: knowing which files are currently in memory is not useful. The only useful information in the tabs is the "modified and not saved" status: this could be displayed in the project pane (Sublime does that really well, by replacing the close icon with a dot).

- The "output" and "local console" pane could be more discrete. Output could be shown automatically when running, and hidden either automatically or by just pressing escape. EDIT: The "Local pane" could be displayed in the editor, as a fake file.

- The horizontal scrollbar of the editor should be hidden by default.

- The status bar contains a lot of information, most of which is redundant: current file, current line, INS/OVR, lua interpreter. All of this is already displayed elsewhere. This leaves only the current column, which I don't think is useful enough to take a whole line of the screen.

- The toolbar, I'm not sure how many people use them among coders. Maybe it could be situational (e.g. only while debugging). Should be easy to hide.

- As OttoRobba suggested, using colors and simple lines to separate the various part of the interface would leave more breathing room.

All of this is IMHO, of course. It's easy to spot small problems like these, it's another thing to come up with a good solution (and then implement it)... If I find the time I may look at the code, but I'm really not familiar with WxGTK.

Anyway, thanks for the work so far!

OttoRobba wrote:> Partly because it behaves oddly under Arch with Gnome 3
You can probably see from the screenshots but I get no tabs (They are there but invisible) so anything that is more than a single file becomes a mess to manage. The file tree doesn't open files (happened with 0.4 and now with 0.5). Almost sure that it is the same thing that is causing the invisible tabs (wxWidget thingy).

very strange. It does look like something wxwidgets related. When you say filetree doesn't open files, do you mean that it doesn't show them or that it doesn't open them in the editor on double click? Any errors thrown?

> When coding in either of these two applications, you completely forget that the file tree is there - until you need it. That is the beauty of it.
> I want to be able to say the same about ZBStudio

Good points; although I'm not sure about dark vs. white. Need to play with the colors...

> Perhaps themeing could be more exposed? As in, easily show the possible themes in the options file? Not sure if it would work or look nice but I'm all for highly-exposed APIs.

yes, I'm thinking about the same thing. Maybe changed defaults, but also some sort of "minimal" config that would remove all the things that clutter the UI.

> I don't mind it at all!

Thank you!

> I can make a quick mockup of a few ideas for ZB, if you are interested

yes, I'm interested .

SneakySnake wrote: So even if not the View menu options (although the View menu is far from cluttered), you should consider merging the zoom shortcut keys into the vanilla zbstudio. Or if you'd like to keep it as a plugin, maybe you could have a set of plugins that are used by default.

That's exactly what I'm thinking about. Not sure about bundling default plugins, but I definitely want to provide an easy way to install plugins or bundles. A bundle would install several plugins.

> EDIT: Ah, the analyzeall plugin. I always wanted that functionality! Thanks!

Great!

paulclinger wrote:Ctrl/Cmd-DblClick does this for variables, but not for arbitrary words. Are you looking for something that works for things like table fields or for anything at all (including text in comments)?

No, just dblClick and all words are highlighted. It's the way Notepad++ works. I mean, why Ctrl+DblClick when just DblClick is enough.

paulclinger wrote: Possibly, but not at the moment. Do you mean something like this:

Code: Select all

local Fruit = class('Fruit')
function Fruit:isSweet() return true end
local Lemon = class('Lemon', Fruit)
local lemon = Lemon:new()
lemon: --<-- this would offer isSweet?

This would be quite challenging (especially if this code is in some other file in the project as often happens). I'm interested, what are the expectations here?

Yes exactly. I have a big lua project and most time i have opened two editors, one to edit and one to look for functions from my classes.

paulclinger wrote: > I had some issues trying Live-Coding:
> - Firewall needs to be deactivated

That's strange; live coding has exactly the same requirements as normal debugging, so if the debugging works, there shouldn't be any additional firewall requirements.

Tested and confirmed that i need to disable my firewall (Comodo Firewall, Windows 7). So I suggest a hint somewhere.

paulclinger wrote: > My game also crashes every time i change a value in the draw routine.

I'll need some details to see what may be going on; maybe a simplified example?

Take this as an example: https://github.com/kennethdamica/Monocle

It crashes with: Another example from me. When you do this...saying _mouse_ is nil.
But when I do this, everything works fine as expected. The Problem is, I cannot do this in a big project, when working with classes. So you might need to call "love.load" first when updating!?

I really like this IDE. I actually would like to know if there is a list of the commands (like the shift+tab) I actually found something like that in the past, I just can't find it anymore.

Going to try 0.50 now

Zarty55 wrote:I really like this IDE. I actually would like to know if there is a list of the commands (like the shift+tab) I actually found something like that in the past, I just can't find it anymore.

@Zarty55, do you mean this list: http://studio.zerobrane.com/doc-editor- ... tcuts.html? There is also the list of menu shortcuts you can change.

SiENcE wrote:No, just dblClick and all words are highlighted. It's the way Notepad++ works. I mean, why Ctrl+DblClick when just DblClick is enough.

Some users argued against that: https://github.com/pkulchenko/ZeroBrane ... issues/159. It makes it difficult to select just one instance (when you need it) and it's not clear what to copy as it will copy all instances instead of just one.

> Yes exactly. I have a big lua project and most time i have opened two editors, one to edit and one to look for functions from my classes.

I agree; it would be good to have, although, as I said, it would be quite challenging/interesting to implement, especially across multiple files.

> Tested and confirmed that i need to disable my firewall (Comodo Firewall, Windows 7). So I suggest a hint somewhere.

Do you mean that the debugging works without filewall changes, but live coding doesn't? Does it simply not connect?

> Take this as an example: https://github.com/kennethdamica/Monocle
> [string "(function()local lights = requ..."]:1: attempt to call global 'require' (a nil value)

I'll need to check that. I took a quick look, but main.lua in the project starts with "lights = require('monocle')" and in your example, it starts with "local lights...". Have you made any changes to the project code?

> But when I do this, everything works fine as expected. The Problem is, I cannot do this in a big project, when working with classes. So you might need to call "love.load" first when updating!?

Right; because love.load is only executed once, any initialization you do in it will not be repeated, so any global variables will keep their values, but any local ones wont (as new local variables will be created and the current value of variables will not be re-assigned).

To fix this, you can try something like this:
This would only be executed when you use live coding and would have no impact on any "normal" execution. (not tested, but you get the idea.)

drakmaniso wrote:If you need more information, I can do more tests.

> ** (lua:1988): WARNING **: Pixbuf theme: Cannot load pixmap file /usr/share/themes/Adwaita/gtk-2.0/Tabs/notebook.png: Failed to load image '/usr/share/themes/Adwaita/gtk-2.0/Tabs/notebook.png': Fatal error in PNG image file: bad parameters to zlib

ZBS is compiled with its own libpng (1.6) and its own zlib, so it's interesting that the error is about bad parameter to zlib. Do you know what versions of libpng and zlib GNOME 3 is shipped with?

> I thought so. I'm not sure what the lua static anlyzers can do. If all else fail, having a better UI for "replace in files" might be a good enough alternative (i.e. a window presenting all occurences with a few lines of context, where you can quickly select or deselect each one before validating the replace).

Yes, I've been prototyping something like this; I'd like to show all occurrences from different files as one document that you can do local replacements in (or at least that's roughly the idea).

> Not for me: the window is only hidden if I start typing something else. But if that something else is a line break, then it's used to validate the autocomplete, and is not inserted in the editor. It's worse if there is two possibilities for a word, e.g. "foob" and "foobar". If I type "foob" then return, this will insert "foobar". IMHAO autocomplete should consider that "foob" is a closest match.

You mean to select "foob" automatically when you click Enter even though "foobar" is currently selected in auto-complete? I think it's problematic, because it makes it difficult to separate Enter to confirm your choice from Enter to ignore the choice and enter Enter. I can always move the selection that matches the current word to the first position, but this only partially solves the issue. I can also add something like Shift-Enter or Ctrl-Enter to ignore the opened auto-complete and behave like Enter, but not sure if people are going to use it. I'm open to suggestions .

> - The title bars of the dockable frames/windows. If you really want to keep the ability to undock them, this should be done with a menu and/or a keyboard shortcut. Most of the time they just take space and add visual clutter.

I played with it and I like the way it looks. You can see it yourself; try this command from the Local console:

ide.frame.uimgr:GetPane("bottomnotebook"):CaptionVisible(false); ide.frame.uimgr:Update()

This will remove the caption from the Output/Local console window.

The problem is that the window can't be easily undocked now, but I can add "View Caption" menu that will allow you to toggle captions on/off.

> The "Project" frame repeat the top level directory two times. IMHO it shouldn't be displayed at all: knowing what project you are working on is not something you have to check on a regular basis, so that's useless information. Also it adds an indentation level to the file tree, so more space lost.

I've been considering changing it, but couldn't find a good way to provide a choice of projects. I can probably do the following: Remove the caption and move the project dropdown to its own tab. The project tree becomes a notebook with Files / Projects / Symbols tabs, similar to editor tabs and Output/Console tabs. This will keep things more consistent. This will also allow to provide some additional information on the Project tab if needed. Symbols is reserved for project wide symbol navigation...

Something to think about...

> Still in the project frame, having one item selected serves no purpose, but is visually proeminent (highlighted). I think the files should open with a single click, and the active file should be the one highlighted. In fact this could completely replace the tabs: knowing which files are currently in memory is not useful. The only useful information in the tabs is the "modified and not saved" status: this could be displayed in the project pane (Sublime does that really well, by replacing the close icon with a dot).

I'm limited by what wxwidgets/wxaui provides here in terms of the "modified" dot; although there may be ways around it. In terms of the selected item, it still has its use as you can do delete/rename operations from the keyboard on an item that is not necessarily opened in the editor. You can also rename folders, which can't be opened in the editor at all.

> The "output" and "local console" pane could be more discrete. Output could be shown automatically when running, and hidden either automatically or by just pressing escape. EDIT: The "Local pane" could be displayed in the editor, as a fake file.

This already works that way. If you hide Output/Local console, it will pop back up if there is any new output to it. See activateoutput in general preferences.

> The horizontal scrollbar of the editor should be hidden by default.

This is something handled by Scintilla, which doesn't seem to support auto-hiding.

> The status bar contains a lot of information, most of which is redundant: current file, current line, INS/OVR, lua interpreter. All of this is already displayed elsewhere. This leaves only the current column, which I don't think is useful enough to take a whole line of the screen.
> The toolbar, I'm not sure how many people use them among coders. Maybe it could be situational (e.g. only while debugging). Should be easy to hide.

I can probably enable turning menubar/toolbar/statusbar on/off and also add "Minimal layout" that turns all of these off and disables captions. Having said that, there is already something that does this: Full screen mode. You can use Ctrl-Shift-A to turn full screen mode on, which will remove all those elements. It will also open Output/Console automatically, exactly as you want. You can keep the filetree open as well in full screen mode (and paint it dark ), so it should probably be quite close to what you envision.

> All of this is IMHO, of course. It's easy to spot small problems like these, it's another thing to come up with a good solution (and then implement it)... If I find the time I may look at the code, but I'm really not familiar with WxGTK.

Indeed. For some of the aspects I recognize their deficiencies, but can't find a good alternative. Some of the things you see in other editors may not be directly applicable simply because they make things confusing (or not obvious) to new users. Maybe I should have "expert mode" (rather than "minimalist mode") to hide all those elements that users are already familiar with.

> Anyway, thanks for the work so far!

Thanks for all the suggestions!