GUI app

[ggamel]

When using a modern UI asset design application, such as Sketch, the ability to easily engage a series of helper GUI is a simple hotkey press away.

See a screenshot & GIF:

The purpose of this UI is to allow a designer to quickly, and briefly, view pixel-perfect spacing between elements. A simple bit of UI for a simple task.

Some questions:

• Would this functionality fit into the QMLKit mission? I lean towards that answer being 'yes,' but want to discuss.
• It's likely a designer/developer would not always want the helper GUI enabled. This is particularly true when deploying apps. How do we easily allow a user of QMLKit to enable/disable this functionality?
• This functionality would need a simple hotkey/keypress (I vote for alt/option) when enabled in QMLKit on a running app.

@JoshuaKolden, what are your thoughts?

[mrjoshuak]

Yes this is along the lines of what I was thinking. However, I think we can do better. These tools often have a limited selection of pre-made widgets but QML doesn't have such limitations. You can pretty much draw whatever you want and make it into whatever kind of ui element you want. So an interactive GUI editor would need to be pretty feature filled to be able to encompass that.

I think the right approach is to start with monitoring text files and updating the UI as the files are changed, than add some basic interactive alignment tools that write UI adjustments made graphically back into the text file (most text editors will notice the external change to the file you're working on and reload).

Then we can move incrementally from there adding features. I just want to make sure that one way of interacting with QMLKit doesn't block the other.

I'm not so sure about a hot key, since that would block the app from using that hot key. I was, however, thinking that we should have a separate control panel from the app itself that could provide mode selection, widget library etc.

Also, not to get too ambitious, but I think this can be setup to build c++ objects too. Perhaps something a little like this:

https://www.youtube.com/watch?v=rbAj7hn24vo

[ggamel]

Yes this is along the lines of what I was thinking.

Perfect. I also agree, now, regarding the hotkey; your argument makes sense.

A separate QMLKit control panel app would be far more useful, too. This is a very cool idea to move forward with, especially if we could include the following:

• the QMLKit app can launch term commands (e.g. start/stop livereload for a given app/project)
• quick toggles for QMLKit features (e.g. interactive alignment tools, etc.)
• effective and unobtrusive organization/management of apps/projects (e.g. similar to an application like CodeKit, LiveReload, GitHub for Mac). This aspect doesn't need to be a feature that caters to lowest common denominator users, but instead a helping hand for developers & designers.

Final note: let's stay ambitious with QMLKit's roadmap, especially the idea of building C++ objects. I'll note it would be pretty swell to have something similar for scaffolding out QML objects, as well.

[ggamel]

I've chatted with @nathanjahnke about this, but not for any considerable amount of time. We were totally focused on getting the core functionality in place, first.

Nathan and I discussed two paths the project should pursue: CLI & GUI.

Since this issue is related to the GUi, it's helpful to mention @JoshuaKolden pointed out QML offers enormous flexibility in terms of drawing any sort of helper GUI. If implemented correctly, the most hardcore devs that are 'CLI-only" could even benefit from this wok.

My preference would be to start with custom QML components that help provide interactive guides for alignment purposes.

These can be interactive, of course, in order to help us start our UI in code, then make adjustments interactively that are instantly written to code.

I'm imagining this scenario:

1. Quiver features custom, core QML components that provide tremendous value
2. Every helper can get out of your way and is optional
3. The helpers really have to help developers and designers move quickly in prototyping, then in producing real work; see point 1.
4. The code written after interactive adjustments can't be ugly.

Now, this solution is not necessarily without potential faults, especially because experienced developers and designers are trained to distrust layout code generated for them. BUT, this ability to make alignment tweaks could be very useful if implemented correctly.

Thoughts, everyone?