Control Icons

[insunaa]

I'm sure most people use keyboard shortcuts for such things, but I tend to use the mouse to control menus. Would it make sense to add / is there a target group for symbols like in other IDEs (for example Visual Studio or CLion with the Arrow for run, the Square for stop, etc.)

I created a text-only version here, but the text renderer doesn't really like consistency.
insunaa@03f04bb

Edit: I deleted my fork, here's a patch file that does the same thing:
edit2: nvm github doesn't like me doing patch files. I'll upload it properly in a second.

Here is the patchfile that does what I wanted in a Gist: https://gist.github.com/d3rrial/a3f14a6b806519f546196bbfff9a0707

[eidheim]

At least in my opinion, one should use the mouse as little as possible, and it might be kinder to users to actually make them use shortcuts instead of clicking on such symbols. Also, when one has learned and is using the shortcuts, such symbols do nothing but take up screen space. Finally, one can actually compile and run more than one program from juCi++, so which one should the symbols represent? Still, I like the minimal look on the symbols, but not sure how we could place them there, especially when some systems have detached menus.

edit: I saw your commit now. Disregard the last sentence above.

[insunaa]

The reason why I don't like keyboard shortcuts is because I have a terrible memory. Granted, I'm the exception here and at the very least I'll keep those symbols in my own build. I more or less created the issue to see what your stance is on this and if there is interest in a proper implementation.

As for what the symbols do, I haven't put a hover-text or anything on them to clearly mark what they do, but they do exactly what their corresponding menu item would do. The commit is a mere proof of concept

[eidheim]

I admit it looks cool:) The main issue I guess, given it looks approximately the same on all platforms (need testing on especially Ubuntu and OS X), is that we can run multiple programs at the same time in juCi++, and if one adds colors to indicate that an application is stoppable or already running, it would be hard to do so. It might be that there are a good solution for this, but my initial thought is that there might not be one. I'll give it some more thought!

[insunaa]

Don't worry about it too much. It's just a suggestion and juCi++ is no less solid without it. If it's only beneficial for edge cases like me, then there's no point in actually implementing it after all :)

Unfortunately I don't really know enough about the menus you used, gtk I assume?, to make something better. I'll probably read myself into this topic, but I don't expect to find a properly working solution for a few weeks if not months (unfortunately busy doing other things).

[eidheim]

I tried this on Manjaro and it worked great, but I had to double click on the symbols to make them work. Do you have the same issue? I like that the symbols does not take up extra screen space!

The symbols did not show at all on OS X, which is as expected, and I have not tested it on Ubuntu (sorry Ubuntu fans, but Ubuntu really needs to start fixing their GUI bugs).

[insunaa]

I have the same issue. The problem is that I'm ad-hocing this on the gtk menu item without a thorough understanding of it. As I have it right now, the interface thinks of these "icons" as a dropdown menu and so it doesn't immediately activate the function, but just goes into the ready state, so it only works after clicking twice. I'm sure there's an easy fix for this, but I'm not knowledgable enough in gtk to figure out how yet.

[eidheim]

Not sure if this ever was intended for gtk menus either. But its a great idea! Someone (that is, someone that has spare time, not me!) could maybe create an issue at the gtk bugzilla and ask them to fix this. Or better yet, send a commit to them, but that requires more work of course.

[insunaa]

I'm not even sure yet that it's an issue on the end of GTK, it's most likely just me being incompetent and not using the correct method. I'll be looking into this a bit further and I'll come back to you if I have any results

[eidheim]

@zalox are you happy with these symbols by the way? If we can make it work? It'll probably only work on Linux in the near future though.

[insunaa]

After trawling through a lot of gtk documentation my result seems to be that it would require a completely different approach. Right now the menu is built by hand (as it seems to me). If the menu were built with glade I could make it work. That'd be a major rewrite tho, so I'll leave it as is right now. I'm going to ask on stackexchange if they know of a method that doesn't require a rewrite, if that's alright with you

[eidheim]

There are two ways of building menus in gtk, one is deprecated. We use the new non-deprecated approach. Also, it should not matter if the file is in a string (like in juCi++) or in a file. Although, having it in a string makes it more flexible. We can for instance disable these symbols on OS X with a #ifndef.

Sure, feel free to ask on stackexchange.

[zalox]

Hi, and thanks for your contributions!

First, I don't think the debugging buttons belong there. However, they might become useful near the debugging panel when that feature is complete.

The two remaining buttons aren't behaving as they currently indicate. Stop is entirely different from kill last process and start runs compile and run the project. Therefore, if we are adding buttons, we need to define the stop and start artefacts. Right now, I can't see any way to determine these features in an adequate matter since we need to write a parser to find executables in the build system used, in any case, it would be best effort, not a feature.

[insunaa]

Alright, I'll put my approach on ice then. Thanks for the feedback!
Please close the issue at your discretion :)