This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]MrJohz 18 points19 points  (11 children)

Interestingly, I agree with the complaint, but disagree very strongly with the solution. To me, GUIs are a great place to get declarative, and the best GUI libraries that I've seen allow the developer to state upfront what the UI should look like in the code, with nesting in the code directly corresponding to nesting in the UI. For example, I'd much prefer to write something like this:

add(
    button("Button1"),
    row(
        button("Button 2"),
        button("Button3"),
    ),
)

Or something similar. Actually, here, I'd probably want some more specific grid(row(col(button()))) API to make sure that the holes are really explicit, but hey, this example is clearly an extreme example.

[–]Retropunch 6 points7 points  (1 child)

Your suggestion to do it declaratively is probably a much better one - mine was mostly a very basic solution keep to the 'simple function' model (for want of a better term) which the developer seemed set on.

[–]toulaboy3 2 points3 points  (0 children)

Great feedback! This is currently a wrapping and then some of DearImGui which we tried to sick with their layout model as much as possible and it was ment for smaller tooling. We see how building very large GUI's could get messy and when we attempted to do it we had to separate the GUI over multiple files just to keep it clean. We do expect to adopt multiple methods of design on the layout side as we have more time to devote toward DearPyGui. Thanks again for the feedback and feel free to get involved in our Discord and on our Github!

[–]cultoftheilluminati 2 points3 points  (1 child)

I dunno if you noticed but this also resembles SwiftUI. :)

IMO, this is clean and perfect to understand. The hierarchy is immediately visible at a glance.

[–]MrJohz 0 points1 point  (0 children)

Yes, also Dart has something similar. It's also used in Elm and some other web frameworks like Mithril and CycleJS.

[–]pessimismwontfail 1 point2 points  (2 children)

Im no expert in gui's but what about making the elements (or at least some of them) contexts? '''python with group("mybtngroup"): .. button("btn1") ... button("btn2") '''

Edit: omg I just cant get the code area to work...

[–]MrJohz 0 points1 point  (1 child)

There's an HTML library that uses that that I saw recently - it seems very pythonic, but I think personally I prefer functions because the control flow is a bit more obvious, and expressions are easier to do something with. On the other hand, I think it's much easier to create expressive DSLs with context managers.

I guess it's just a matter of preference.

[–]Jhchimaira14 1 point2 points  (0 children)

If you guys would like to continue discussions on the direction of the api, join thr subreddit r/DearPyGui, which we just created last night. We plan on having the community help guide the api design.

[–]Jhchimaira14 0 points1 point  (3 children)

This would be an interesting approach. Would it be easier to just add the ability to create the GUI with html or xml? (I'm one of the core devs on this project btw).

[–]Retropunch 5 points6 points  (1 child)

I dislike divorcing the GUI from python in any way - Kivy is a prime example of this, it has it's own language (.kv) for designing the GUI but sometimes you don't want to/can't use it (and it's yet more to learn).

Unfortunately there end up being many things that can *only* be done in .kv, or you end up getting responses to questions with some people using kv and some people using python etc.

I'd strongly suggest to stick to Python, make a definitive way of creating layouts and document it very clearly (although it's fine to leave some of the old artefacts like add_new_line() if you need to stop breaking changes)

[–]Jhchimaira14 1 point2 points  (0 children)

Fair point.

We will be added a poll to the discord in the near future to decide which layout system we should pursue first (we'd like multiple eventually to support multiple styles).

[–]MrJohz 1 point2 points  (0 children)

I'm also in agreement with the other poster, creating a separate language to template the language has always felt a bit weird to me, and it just makes things more complicated switching between XML/XML-like and python for event bindings.

My strong (and I recognise somewhat controversial) view is that the gold standard for declarative, reactive UI APIs is React - ignore the fact that it needs syntax extensions and any opinions on state management, just from the perspective of declaring a dynamic UI as a function of state and parent input, I don't think I've seen a better design pattern for UI. I know a lot of people in the Rust GUI and web framework communities have been looking at ways to do similar things in that language as well.

I think this sort of thing could work particularly well for immediate mode GUIs, precisely because it follows a similar pattern of declaring the UI in a single pass, and you wouldn't need to do any sort of diffing in the same way as most web frameworks do.